Identity and access

Windows identity, end to end

The lab runs a small Windows domain the way a company would: an internal certificate authority issues the certificates, remote desktop needs a second factor, and users and their access are defined in code rather than clicked into existence. This page walks each piece, and it keeps an honest open investigation in view: a real auth failure that is still being run down, shown as eliminated branches versus live candidates rather than hidden until it is solved.

The certificate authority

Every internal service that speaks TLS needs a certificate, and something has to vouch for those certificates or every browser and client throws warnings. An enterprise certificate authority is that something. It is the lab's own trusted issuer: it signs the certificates for internal services, and because every domain-joined machine trusts it, those certificates are accepted without a warning. Running your own authority is how an internal network gets real TLS everywhere without buying a public certificate for a name the public internet will never see.

Multi-factor on remote desktop

Remote desktop is the front door to a Windows machine, and a password alone is a front door with one lock. Remote desktop here requires a second factor, so a stolen or guessed password is not enough to get in. This matters most for the administrative accounts, which are exactly the ones worth stealing. The point is simple: the more powerful the door, the less it should trust a password by itself.

The user lifecycle, defined in code

People join, change roles, and leave. Doing that by hand means someone remembers to create the right accounts, grant the right groups, and, the part everyone forgets, remove access on the way out. The lab defines users and roles in files that are checked against a schema before they take effect, so a malformed role or a typo in a group name is rejected rather than half-applied. A pipeline reads those definitions and provisions the accounts, including the cloud directory side through its management interface. Access becomes a reviewed change in version control instead of a memory of who clicked what, and offboarding is a file edit rather than a hope.

Group policy as a baseline

Group policy is how a Windows domain pushes settings to every machine at once: password rules, screen locks, which services are on, what the security configuration must be. The lab keeps a baseline so a newly joined machine inherits the same hardening as every other machine rather than starting from Windows defaults. A baseline is the difference between "each machine is configured" and "each machine is configured the same way," and only the second one is defensible.

Split-horizon DNS

The same name can mean different things inside and outside the network, and that is on purpose. Split-horizon DNS answers an internal client with the internal address for a service and answers the outside world with the public one, or with nothing at all for names that should never resolve publicly. It is what lets one hostname be convenient inside the lab without advertising the internal layout to anyone who runs a public lookup.

Open investigation: a FIPS versus NTLM auth failure

Status: under investigation. The branches marked eliminated below are ruled out. The candidates are still being tested. This line is generated from the tracked case, so it updates here when the case closes, not by a hand edit.

Here is a problem that is still open, kept in the daylight because a portfolio that only shows solved things is not honest about the work. The automation control host runs in a hardened cryptographic mode that only permits government-approved algorithms. The standard way to run automation against Windows servers, a protocol called NTLM over a remote management channel, depends on two older algorithms that this mode forbids. So every automated run against the Windows servers from that host stops at the handshake with the same error:

ntlm: digital envelope routines::unsupported

The reproducible failure the whole investigation hangs off.

The value of writing it up this way is the discipline it forces: separate what has been ruled out from what is still a live guess, so the search keeps narrowing instead of circling.

Eliminated branches

Each of these was a plausible cause that the evidence has ruled out.

Bad credentials. Ruled out: the same account authenticates fine to the same servers from a host that is not in the hardened mode. The secret is correct.
A network or firewall block. Ruled out: the connection reaches the server and the handshake begins. It fails partway through the negotiation, not at the door.
A misconfigured server. Ruled out: other clients that are not in the hardened mode connect to those same Windows servers without complaint. The servers are fine; the constraint is on the calling host.

Live candidates

These are the fixes still being weighed, each with the cost that keeps it from being an obvious win.

Switch the Windows connection to Kerberos. Kerberos is approved under the hardened mode and sidesteps the forbidden algorithms entirely. Cost: it needs the calling host set up to obtain Kerberos tickets for the domain, which is its own piece of work.
Run the Windows work from a dedicated host that is not in the hardened mode. Cost: another machine to build, patch, and secure, which partly gives back the reason the mode was turned on.
Move to a connection method the hardened mode is happy with, such as remote management over a TLS channel with a different authentication, or a secure shell on the Windows side. Cost: each path has its own enablement work on every target.

The reason this belongs on the page rather than in a private notebook is the resolution mechanism. When the case closes, the status line above flips from under investigation to resolved through a regeneration driven by the tracked case, not by someone remembering to hand-edit this paragraph. The page cannot quietly go stale about its own open question.

See the security posture → How the platform is built →