One identity path from a request to every login
A reviewed request creates the person in Active Directory, waits for that directory-owned identity to appear in Entra, adds the cloud access defined by the person’s role, and hands the first password through Vault. Windows servers join the same domain, enroll for internal certificates, inherit policy, and enforce Duo MFA on remote desktop. Offboarding disables access first and keeps a restore snapshot before deletion.
The result is one lifecycle rather than separate on-premises and cloud accounts. The same written role drives directory groups, application assignments, mapped storage, and later removal. A failure stops at the boundary that could not be verified, and a rerun reconciles what already exists.
Built from the provisioning, deprovisioning, certificate-enrollment, Duo, Group Policy, directory-sync, and WinRM migration paths tracked in the repository.
The directory is the source; the other systems extend it
Active Directory owns the user object, manager, department, organizational unit, and Windows groups. Entra receives that object through directory synchronization. The pipeline then uses Microsoft Graph, the management API for Entra, to add only the cloud groups and application assignments that synchronization does not own.
That division matters. Creating a second cloud user would produce two identities with independent passwords and removal paths. Waiting for the synchronized object keeps one person attached to one source, even though the access reaches both Windows and cloud applications.
A role is a small reviewed definition of the access a job needs. It names the on-premises groups, cloud groups, and enterprise applications that belong together. Changing the role changes the reconciliation input; it does not require an operator to remember every console touched the first time.
How one reviewed request becomes a usable account
- Validate the request before creating anything. The pipeline checks the account name against Active Directory, validates the request schema, and loads the selected role. A duplicate name or malformed role stops before a password or account exists.
- Create the first password without putting it in a build log. The pipeline generates a random password and stores it in Vault. A single-use, short-lived wrapped token crosses the stage boundary, so the next stage can retrieve the value without making it a normal pipeline variable.
- Create or reconcile the Active Directory user. A Windows agent uses native domain authentication to set the manager, organizational unit, role groups, home directory, and force-password-change flag. Its rights are delegated to the managed user area rather than granted across the domain.
- Wait for the same object in Entra. Directory synchronization runs on its own schedule. The pipeline polls for the synchronized object instead of racing ahead or creating a second identity.
- Add cloud-only access. After the object is visible, Microsoft Graph assigns the Entra groups and enterprise applications defined by the role. Active Directory still owns the person; Graph owns only these cloud-side additions.
- Hand off the password once. The manager receives a pointer to the Vault handoff, not the password in email. The user must replace it at first login.
Role changes use the same reconciliation path
The job reads current state before it writes. Existing group membership is left in place when it matches the role, missing membership is added, and already-created objects are reused. That is what makes a rerun safe after synchronization or Graph fails halfway through.
Offboarding is disable-first
A named requester and a different authorized approver stand before mutation. The pipeline records the original groups, manager, organizational unit, and account state before it strips access. It disables the account, removes on-premises and cloud entitlements, moves the object to a disabled area, and hands working data to the manager. A daily sweep deletes only a disabled account that also has the pipeline’s offboard record and has completed its grace period. An enabled account or an unrecorded object is reported and left alone.
A joined Windows server receives the same trust fabric
- Machine identity
- Joining the domain gives the server its own directory object and Kerberos identity. Automation and policy can address the machine without sharing a person’s login.
- Internal certificates
- Active Directory Certificate Services is the private certificate authority. An approved template limits what a machine may request; auto-enrollment can issue and renew the certificate for a domain-joined Windows host.
- Group Policy
- Group Policy carries central Windows settings such as certificate enrollment, mapped drives, and the legal banner. The desired banner text is source-controlled, but the Group Policy objects are not yet fully created and reconciled from code.
- Duo MFA
- Duo inserts a second-factor prompt after Windows accepts the remote desktop password. The current deployment is fail-open when Duo cannot be reached, an availability choice that leaves a recorded security trade-off rather than claiming a stronger boundary.
- Name resolution
- Split-horizon DNS gives internal clients the private answer for a service name while public DNS publishes only the intended external answer. It keeps user-facing names stable without exposing the internal layout.
The Windows automation transport is being replaced without breaking the working path
Status: under investigation. The branches marked complete in the tracked case are proven, including the interim enrollment path. Fleet rollout of the durable Kerberos path is still open. This line is generated from the tracked case, so it changes when the case closes, not by a hand edit.
The hardened automation control host runs in FIPS mode, which refuses algorithms used by NTLM. The original WinRM connection therefore failed during authentication even though the password, network path, and Windows service were valid.
A dedicated compatible runner now provides the interim enrollment path, and it has completed an end-to-end Windows enrollment on one domain controller. That proof exposed a second problem: WinRM authorization denied the automation identity after authentication. A targeted Remote Management Users membership and WinRM security descriptor grant corrected that host.
Kerberos over WinRM HTTPS is the selected durable path because it works with the hardened control host and uses the machine and service identities already present in the domain. The required roles and playbooks are committed and gated. They are not yet described as fleet-complete because the second controller, remaining Windows hosts, and durable Group Policy grant still need the same proof.
How it runs now
| When | What runs | What happens next |
|---|---|---|
| On a join request | The pipeline validates the role and name, creates the Vault handoff, writes Active Directory, waits for synchronization, then adds cloud-only access. | The person receives one directory-owned identity and a first-login password handoff. |
| On a role change | The same definitions are compared with current directory and cloud membership. | Missing access is added and matching access is left alone; the run can be repeated. |
| On Windows server provisioning | The guest joins the domain, receives the Windows baseline, certificate enrollment, monitoring, DNS, and Duo configuration. | The server enters the same identity, trust, and operating model as the existing fleet. |
| On an offboard request | A separate approver reviews the target, a restore snapshot is written, then access is disabled and stripped. | The object remains recoverable during the grace period; deletion is a later sweep decision. |
| When directory sync is late | The pipeline keeps polling until its bounded wait expires. | Active Directory remains authoritative, the cloud stage fails visibly, and a rerun resumes from the existing user. |
| When a sweep finds an anomaly | It checks whether the object is disabled and has the matching offboard record. | Unknown or enabled objects are reported and left untouched. |
What is complete, and what is still owed
The join, role reconciliation, directory synchronization, Graph assignment, one-time password handoff, disable-first offboarding, and delayed sweep paths are implemented. Existing users are not yet all represented by the role definitions, so the files are not a complete import of every historical identity.
The manager picker still uses a directory bind that is not protected by LDAPS. Group Policy is used in production, but its objects are not yet fully managed as code. Duo’s current fail-open behavior remains an accepted availability trade-off. The Kerberos transport has a proven design and staged implementation, but fleet cutover is not finished.
Those boundaries matter because “implemented” is not the same as “automatic everywhere.” The page will be strongest when the remaining transport and policy work can be described with the same live proof as the provisioning and lifecycle paths.
If I were recreating this from scratch
- Choose one source for the person. Decide whether Active Directory or Entra owns the object before writing either pipeline.
- Define roles before users. A role should explain why each group and application travels together.
- Build the disable and restore path beside creation. Record pre-change state before access is removed.
- Separate human and machine credentials. Give the pipeline delegated rights, not a domain administrator account.
- Prove synchronization as a state transition. Poll for the same object and make timeout behavior safe to rerun.
- Migrate remote management one host at a time. Keep the known-good channel until Kerberos, authorization, and HTTPS all pass from the real control host.