Nelsar.Axia 0.3.0

PostgreSQL for the API's own state, Samba AD, and a Windows installer. Accounts and groups created in Active Directory are real ones, and administrators are protected whether or not the directory has marked them. Upgrading from 0.2 takes one decision: the database is no longer assumed, so Database:Provider has to be set before the new version starts — see Changed.

Security

• An administrator made after Active Directory last ran SDProp, or ever in Samba, which has none, is protected like any other. Protection read adminCount, the mark SDProp leaves on members of Domain Admins and the other protected groups; Windows sets it once an hour, Samba never on an administrator added after the domain was provisioned, and until then anyone allowed to reset passwords could reset theirs. Protected groups are now found by SID, and their members — however nested, or by primary group — by asking the directory. The same goes for groups nested in a protected group, computers in one, and units holding any of them.

Added

• Samba AD, as Active Directory, through ProviderType: StandardLdap. CI tests every pull request against a live Samba 4.22 domain controller, built from deploy/dev/samba — the first tests against a live directory rather than one faked at the provider boundary. See Directories → Samba AD.
• PostgreSQL: Database:Provider=PostgreSql, with ConnectionStrings:DefaultConnection naming the server. See Configuration.
• copy-database, which copies everything the API keeps — directories with their encrypted bind passwords, role mappings, role permissions, rate limits, the audit trail — from one database into another, whichever two engines they are. One transaction, every table's row count checked before it commits, and the old database never opened: a SQLite file is read from a copy. See Moving to another database.
• Images: releases are published to Docker Hub as well, as nelsar/axia-api and nelsar/axia-console, the same images and tags as on ghcr.io. See Production deployment.
• The API can serve the console itself, so that one process on one port is the whole application where there is no nginx: from wwwroot next to its binaries, or from Console:Path, with the headers the console image sends. dotnet publish -p:AxiaConsoleDist=… puts a built console there. Nothing changes for the container images, which have no wwwroot. See Configuration.
• The API runs as a Windows service or a systemd unit when started as one.
• A Windows installer, Nelsar.Axia-x.y.z-x64.msi and -arm64.msi, attached to each release: the API and its console as the NelsarAxia service, running as its own virtual account, with no Docker or .NET runtime to install first. Unattended installs take the directory and the admin group as msiexec properties; settings, keys, database and logs live in %ProgramData%\Nelsar.Axia and survive upgrades and uninstalls. Not signed yet; each carries a build provenance attestation instead, which gh attestation verify checks. See Windows installer.
• --SettingsFile <path> reads the settings from a file outside the folder of the binaries, and init-settings <path> creates that file with new keys, or brings one up to date without touching the keys. See Configuration.

Changed

• On upgrade: Database:Provider is required, and the API refuses to start without it. Every earlier version used SQLite without being told to, so there is no default to fall back on. To keep the SQLite database you have, set Database__Provider=Sqlite. To move to PostgreSQL, create an empty database, point the configuration at it, run copy-database once, then start.
• The quick start runs on PostgreSQL, with a password generated on the first start. A quick start set up by 0.2 keeps its SQLite database in the api-data volume, no longer mounted; the new one starts empty unless it is copied over.
• SQLite is still supported, for a single small instance and for the unit tests. Each database keeps its own migrations, in Nelsar.Axia.Migrations.PostgreSql and Nelsar.Axia.Migrations.Sqlite; a SQLite database from 0.2 is already up to date.
• Dependencies: every .NET 10 package at 10.0.13 — EF Core, the Microsoft.Extensions packages and System.DirectoryServices were on 10.0.10 — and Npgsql's EF Core provider 10.0.3. The native SQLite comes with EF Core again (2.1.13); the direct reference that held it above a vulnerable version is gone.

Fixed

• Creating an account in Active Directory through StandardLdap — the provider for every platform but Windows, and so for every container — creates an account. It wrote an inetOrgPerson named uid=…, which AD refuses with a naming violation; it now writes AD's user, named by cn, with the login in sAMAccountName, and switches it on once the password is set. A login AD cannot hold — over 20 characters, or one of the characters it forbids — is refused before anything is written.
• Creating a group in Active Directory through StandardLdap creates a security group. It wrote a groupOfNames, which AD accepts as an entry with no SID and no groupType: nothing Windows grants access by.

Windows installers

Nelsar.Axia-0.3.0-x64.msi and Nelsar.Axia-0.3.0-arm64.msi: the API and its console as a Windows service, see Windows installer. Not signed yet; gh attestation verify <file> --repo Nelsar/Axia shows that a file was built by this repository's workflow from this tag.