SAMADCON 0.6.12

Debian security updates in the image, sortable policy list, updated dependencies.

Security updates that never reached the image. Measured on the
0.6.11 dev image: OpenSSL (libssl3t64, openssl, openssl-provider-legacy)
and PCRE2 were one Debian security update behind. The image's package
layer came out of the CI build cache, which is only invalidated when
Debian republishes its base image - fixes released in between never
arrived, and packages of the base image itself were not even touched by
an install.

• The package layer now upgrades before it installs and is rebuilt at
  most once a day (APT_REFRESH, set by CI to the build date); every other
  build of the day still uses the cache.
• CI now fails if the built image has any pending update from Debian's
  security suite. It failed on the four packages above before the change
  and passes after it.

If you pin an image version: this release carries the updates; earlier
ones keep what they were built with.

Sorting the policy list. A tester asked to choose how policies are
sorted. Name and Changed are now clickable column headers, as in the
object list, and the choice is remembered. With a domain or OU picked,
the list shows the link order as its first column - GPMC's "Link Order",
the order that decides which policy wins - and sorts by it unless asked
otherwise. That order is what had looked like "sorted by date".

Dependencies. pip-audit and npm audit report no known
vulnerabilities, before or after.

• Python: cryptography 50.0.2 (wheels with OpenSSL 4.0.3), fastapi
  0.142.2, python-dotenv 1.2.4, uvloop 0.23.0, websockets 17.2.
• FastAPI 0.142 brings native OpenTelemetry and a dependency on
  opentelemetry-api; by default it traces every request and sets up OTLP
  export by itself when an OTEL_EXPORTER_OTLP_* endpoint is set and the
  SDK is installed. The image has no SDK, so nothing would have left it;
  SAMADCON now switches all of it off explicitly regardless.
• Frontend: React 19.3.0, React Query 5.104.1.

Images: ghcr.io/onlinecrash24/samadcon:0.6.12, :0.6 and :latest.

SAMADCON 0.6.11

Empty attributes in the attribute editor, and preferences split the way GPMC splits them.

Attributes without a value. A tester asked for what RSAT's attribute
editor does: list every attribute an object may have, not only those
that are set. The attribute editor now has a switch, "Leere Attribute
anzeigen" / "Show empty attributes", off by default and remembered by the
browser. With it on, SAMADCON asks the object which attributes it may
have (allowedAttributes) and which of those your account may write
(allowedAttributesEffective), and reads the schema for the rest.

• Empty attributes are listed below the set ones as "not set".
• One can be filled in where your account may write it and it is plain
  text. Constructed attributes (tokenGroups), back links (memberOf),
  system-only attributes (objectGUID), binary values (thumbnailPhoto) and
  attributes SAMADCON edits elsewhere stay read-only; the tooltip says
  why.
• Every attribute now says whether it takes one value or several. For a
  single-valued one the edit dialog accepts one line only, instead of
  leaving the refusal to the DC.

Measured on a Samba 4.22 DC for a user object: 391 attributes allowed,
279 of them writable for the administrator, 38 with a value.

Preferences in two tabs. In GPMC, Preferences ("Einstellungen") has
two branches, and the single tab held types from both. It is now two
tabs, as in GPMC:

• "Windows-Einstellungen" / "Windows Settings": drive maps, registry,
  files, folders, shortcuts, environment.
• "Systemsteuerungseinstellungen" / "Control Panel Settings": printers,
  local users and groups, services, scheduled tasks.

Images: ghcr.io/onlinecrash24/samadcon:0.6.11, :0.6 and :latest.

SAMADCON 0.6.10

New policies get their folder permissions without object ACEs, on every DC.

Confirmed on Synology. The tester who could not create policies on a
Synology Directory Server reports that 0.6.9 works there.

What changes. 0.6.9 removed the "Apply group policy" object ACE from
a new policy's folder permissions only when the DC refused it. Samba's
dsacl2fsacl in 4.21 and 4.22 - the version in the image - puts it there
(Samba bug 14927, fixed in 4.23). A Samba DC accepts it, so there it
stayed. Measured since on a Samba 4.22 DC, that is not harmless: the DC
passes the ACE on to every file and folder created in the policy
afterwards, and the inherited copies come out malformed - Samba's
inheritance of object ACEs is broken (bug 9821). It happens whoever
creates the file: GPMC, samba-tool or SAMADCON.

From this release a new policy's folder gets only the allow and deny
ACEs, as Samba 4.23 writes them, on every DC. With nothing to inherit, a
file GPMC later added to such a policy carried clean permissions.

What it does not change. Policies created elsewhere, or reset with
samba-tool ntacl sysvolreset on Samba 4.21 or 4.22, still carry the
ACE on their folder, and new files in them still inherit it. That needs
a fix in Samba itself.

About sysvolcheck. samba-tool ntacl sysvolcheck expects every file
of a policy to carry exactly its folder's permissions. That holds right
after sysvolreset and for no file written afterwards, by any tool,
since new files inherit permissions instead. On a 4.21/4.22 DC it also
expects the object ACE on the folder. A report from it about policies
that have been edited, or created by SAMADCON, is therefore expected.

Images: ghcr.io/onlinecrash24/samadcon:0.6.10, :0.6 and :latest.

SAMADCON 0.6.9

New policies can be created on a Synology Directory Server.

A tester on a Synology Directory Server could not create, copy or restore
any policy: "Access denied" every time. 0.6.8 aligned SAMADCON with
samba-tool and removed a stray SACL flag, the first suspect - and it
still failed. Narrowed down on his DC:

• samba-tool gpo create on the DC itself (Samba 4.15.13) worked, with
  Kerberos too;
• the same command from the SAMADCON container (Samba 4.22.11) failed
  exactly as SAMADCON did, when setting the policy folder's permissions.

What happened. The folder's permissions are derived from the policy
object's with Samba's own dsacl2fsacl. In Samba 4.21 and 4.22 it carries
the object's "Apply group policy" entry - an object ACE, which only means
something in the directory - into the file permissions (Samba bug 14927,
fixed in 4.23). A Samba DC stores it. A Synology Directory Server keeps
permissions in its own ACL system and refuses the whole set.

Measured on his DC with a test folder: the permissions as Samba 4.22
builds them were refused, the same permissions without the object ACE
were accepted.

The fix. SAMADCON sets the permissions as before. If the DC refuses
them, it removes the object ACEs - which is what Samba 4.23 writes - and
sets them once more; the log says so. A DC that takes them the first
time, as every Samba DC does, gets them unchanged, and its own
samba-tool ntacl sysvolcheck stays clean.

Creating a policy on the Synology itself through SAMADCON is still to be
confirmed by the tester; the permissions it now sets there are the ones
measured as accepted.

Images: ghcr.io/onlinecrash24/samadcon:0.6.9, :0.6 and :latest.

SAMADCON 0.6.8

New policies get their SYSVOL permissions the way samba-tool sets them.

A tester could not create any policy: "Access denied" on every attempt,
while samba-tool gpo create with the same account worked. Comparing the
two on a Samba 4.22 DC turned up two differences, and the first one
affected every installation.

Permissions below the policy's folder. SAMADCON set the policy's
permissions on its folder after Machine, User and GPT.INI were already in
it - and over SMB, setting a folder's permissions does not reach what it
already holds. So every policy created, copied or restored with SAMADCON
kept the share's general permissions below its top folder:

• security filtering did not apply to the policy's files;
• someone delegated to edit the policy could not write its content;
• samba-tool ntacl sysvolcheck stopped at the first such file.

Now the empty folder gets the permissions first, and everything put in it
inherits them. Measured: folder, Machine and GPT.INI carry exactly the
permissions samba-tool gives them.

A SACL flag without a SACL. The permissions are derived from the
policy object's own, which SAMADCON read whole, SACL included. Samba's
dsacl2fsacl copies the descriptor's header flags but not the SACL, so the
folder's descriptor claimed one that was not there (type 0x9814 against
samba-tool's 0x9004). Samba passes over that. A Synology Directory Server,
which keeps permissions in its own ACL system, refused it - most likely
the tester's "Access denied". SAMADCON now asks for owner, group and DACL
only, as samba-tool does. Confirmation on Synology is still outstanding.

If you created, copied or restored policies with SAMADCON before:
their permissions below the top folder are still the share's. On the DC,
samba-tool ntacl sysvolreset sets all SYSVOL permissions anew from the
directory; samba-tool ntacl sysvolcheck should then pass. Not on a
Synology Directory Server - its sysvolcheck cannot read the permissions.

Images: ghcr.io/onlinecrash24/samadcon:0.6.8, :0.6 and :latest.

SAMADCON 0.6.7

Multi-line administrative template values no longer take the backend down.

A tester saved "Remove Default Microsoft Store packages from the system"
with a list of package names and got an HTTP 502 - and was signed out,
as was everyone else signed in to that console.

What happened. Since 0.6.6 SAMADCON packs Registry.pol itself, and it
handed Samba's preg binding a list for a multi-string (REG_MULTI_SZ). The
binding does not raise on that: it trips a C assertion (PyBytes_Check)
and aborts the process. nginx answered 502, and since sessions live in
the backend's memory, they went with it. Nothing was written - the abort
came before the file was saved - so affected policies are unchanged.

Only values of type REG_MULTI_SZ were affected: the template elements
shown as a multi-line text box. Check boxes, numbers, single-line text
and lists of values were not.

The fix. Measured in the image: preg takes and returns a multi-string
as one block of bytes - each string UTF-16LE with its terminator, then one
more. SAMADCON now builds that block when writing and splits it back into
its strings when reading, which it also got wrong.

Why it got through. The binding was only exercised by the integration
tests, which CI does not run. A new test now packs and reads back every
value type through Samba's own binding in the CI image. Pushed before the
fix, it aborted CI at the tester's package names; with the fix, it passes.

Checked on a Samba 4.22 DC: a policy with two multi-line fields saved,
edited and saved again - the lines in Registry.pol as entered, the
removed line gone, the version advanced once per save.

Images: ghcr.io/onlinecrash24/samadcon:0.6.7, :0.6 and :latest.

SAMADCON 0.6.6

Administrative templates on a policy whose GPT.INI is hidden.

A tester set an administrative template and was told his account lacked
the permission; saving again went through and the value was there. It
looked like a hiccup. It was worse: the policy's version never moved, so
every client that already had the policy kept the old setting, and no
console said why.

What happened. Templates were written through Samba's own
RegistryGroupPolicies. It writes Registry.pol, then the version in
GPT.INI, each with a plain savefile - and SMB refuses that with
ACCESS_DENIED on a file marked hidden or read-only. Registry.pol was
written, GPT.INI was refused. Saving again "worked" only because the
value was already in the file, so there was nothing left to write, the
version included.

The fix. Templates now go through the same paths as every other
editor in SAMADCON: Registry.pol merged in SAMADCON (key and value name
compared without case, a value replaced where it stands, new ones
appended, everything else kept), written by SAMADCON's SYSVOL writer -
which has opened hidden files in place since GPMC's hidden scripts.ini -
and the version advanced once, in AD and GPT.INI together.

If you met this: after updating, change one setting of the affected
policy and save it. That advances the version, and clients pick up the
earlier changes with it.

Reproduced on a Samba 4.22 DC before the fix: GPT.INI set hidden, the
first save refused, the second accepted, versionNumber and GPT.INI at 0
both times. After the fix: the first save accepted, both at 1, GPT.INI
still hidden.

Images: ghcr.io/onlinecrash24/samadcon:0.6.6, :0.6 and :latest.

SAMADCON 0.6.5

The event logs and the advanced audit policy, in the policy editor.

A tester asked where parts of GPMC's "Windows Settings" had gone. This is
the first of four gaps to be closed, one release each, and like every part
of the editor it was measured before it was built: a reference GPO made in
the German GPMC gave the files and the extension registration, and
auditpol /list /subcategory:* /v on Windows 11 gave the sixty
subcategories with their GUIDs. Both files are in the tests, and sha256sum
on the domain controller matched them byte for byte.

Advanced audit policy. A new node under Security Settings: nine
categories, sixty subcategories, each not configured, no auditing,
success, failure or both, saved a category at a time. It lives in
audit.csv - UTF-8 without a byte-order mark, CRLF, seven columns, header
and texts in the language of the console that wrote it - so SAMADCON reads
it by column and GUID, never by header name, and keeps rows it does not
edit. "Not configured" and "no auditing" are different: the first leaves
the subcategory out, the second writes it with 0. The file has its own
client-side extension, which is registered on save. The switch that makes
Windows apply the subcategories instead of the nine categories is shown
on its own card above them.

Event logs. Size, retention method, days and guest access for the
system, security and application log, in GptTmpl.inf with the other
security settings.

Two fixes found by the measurement.
[Registry Values] is now written without spaces around the equals sign,
as GPMC writes it; the rule had come from a file whose section was empty.
And the report did not know audit.csv, so the extension GPMC registers
for it read as surplus, and reconciling offered to remove it - leaving
every client ignoring the policy. The report now names the subcategories.

Verified against the DC and a Windows 11 client: a GPO made in SAMADCON
and linked to a test OU, then gpupdate. auditpol showed the two
subcategories as set; the registry held the new security log size
(MaxSize 0x4000000) while wevtutil still showed the old one, which is
why the editor points at the registry value. GPMC opened the GPO without
error and showed the same values. Unlinking it took both back on the
client.

Images: ghcr.io/onlinecrash24/samadcon:0.6.5, :0.6 and :latest.

SAMADCON 0.6.4

Template uploads above 8 MB, a SYSVOL connection that recovers, and every error in German.

Most of this release came out of testing the template import against the
maintainer's Samba 4.22 DC.

Uploads above 8 MB failed. nginx spools a request body above its
memory buffer to disk before the application sees it, and the spool sat
on /run/samadcon - an 8 MB tmpfs in the compose file, sized for a pid
file. Microsoft's 14 MB template MSI met nginx's own HTML 500 ("No space
left on device") and never reached SAMADCON; large downloads such as a
GPO backup used the same spool. The spools now live in /var/lib/nginx.
A new CI step starts the container with that same 8 MB tmpfs and sends
20 MB through it; it was committed first, on its own, and failed with
the error from the DC before the fix made it pass.

An answer that did not come from SAMADCON said only "The upload failed."
It now names the HTTP status, says it was not SAMADCON answering, and
points at nginx's error log.

A dropped SYSVOL connection is opened again. smbcontrol smbd close-share sysvol - the README's remedy for a client's lease on the
central store - ended SAMADCON's own connection to the share too. It was
never reopened, and every failure read as "not there": the central store
appeared absent, the editor offered to create one, and configured
policies had no templates to be shown with, until the administrator
signed out. A call the server dropped is now repeated once on a new
connection, and a refused path is reported as refused. Verified on the
DC: close-share, then the store and a policy's settings still shown
without signing in again, and the log naming NETWORK_NAME_DELETED.

Every error code has German words. 117 of the 236 codes the backend
can raise had none, and an administrator working in German met them in
English. Where the English sentence names a value - a field, a limit, a
record type, the file - the value now travels in the error's context so
the translation can name it too; a refused template says which file and
why. scripts/check_translations.py reads every code from the backend's
syntax tree and fails the lint job on one without a German entry.

The interface language can be set for a deployment.
SAMADCON_DEFAULT_LANGUAGE (en or de) applies to anyone who has not picked
a language with the DE/EN switch; unset, the browser decides as before,
and a picked language always wins. Both compose files carry it commented
out. Anything but en or de stops the container from starting.

Verified on the DC: the 14 MB MSI imported with "skip" (696 skipped) and
with "replace" (696 replaced), a broken .admx refused and not written,
and the SYSVOL reconnect as above. The German texts and the default
language were checked by tests, not yet in a browser against the DC.

Images: ghcr.io/onlinecrash24/samadcon:0.6.4, :0.6 and :latest.

SAMADCON 0.6.3

Choose where a copied account goes.

A follow-up to 0.6.2's onboarding. The copy dialog put the new account in
the template's OU and only said so; the server already accepted another.
"Change..." beside the target now opens a container browser - up one
level, and the containers below - and OK takes the one on screen. The
template's OU stays the default, since that is where a template is kept.

The browser is the one Move uses, taken out of the Move dialog so the
two walk the directory the same way. On the way, Move's "up one level"
now finds the parent with the same escape-aware parsing as the rest of
the interface, instead of cutting at the first comma - a container
whose name holds an escaped comma no longer sends it somewhere wrong.

The rows in the copy dialog that hold buttons are no longer labels: a
click on a label's caption presses the first button inside it, which
would have opened the picker or copied the password.

Verified on a Samba 4.22 DC: a template in one OU, the copy created in
another, with groups, primary group, paths and a generated password
that answered NT_STATUS_PASSWORD_MUST_CHANGE; the audit entry named the
new OU and held no password. Move, which now shares the browser, was
checked on the same DC once the release was out: a user moved into an
OU, back to CN=Users by way of "up one level", and into the OU again.

Images: ghcr.io/onlinecrash24/samadcon:0.6.3, :0.6 and :latest.