That flow is technically valid, but it’s important to be very precise about what is being authenticated, when, and with which security guarantees. I’ll break it down rigorously and then tell you when it’s a good idea and when it’s a trap.
PC
+ → HTTP Auth Service (username/password)
+ → Service validates credentials
+ → Service creates / updates user in LDAP (AD)
+ → PC authenticates user against LDAP
+ → Windows session is considered authenticated
+This is essentially “AD as a just-in-time identity cache”.
Yes. Windows + AD fully support this pattern.
This is known as:
Just-In-Time (JIT) user provisioning into Active Directory
It is used in:
Universities
Labs with external IdPs
Temporary users
Federated identity bridges
There are three different authentication layers that people often conflate:
+Layer | Meaning +-- | -- +Windows logon | LSASS validates credentials (Kerberos/NTLM) +Identity authority | Who decides the user is legit +Authorization | What the user is allowed to do + +Your flow makes this true:
✔ Windows logon is authenticated by AD
✔ Identity authority is your HTTP service
✔ Authorization comes from AD groups / GPO
That separation is clean and valid.
PC collects {username, password}
Sends to your HTTP service
Receives {isSuccessful, username, mail, group}
At this point, Windows is NOT logged in yet.
Your service:
Creates or updates:
sAMAccountName
userPrincipalName
group membership
Sets a temporary password
Flags:
Password never expires (or controlled TTL)
Optionally Account expires
This must be done using:
LDAPS
Service account with minimal rights
Now Windows:
Authenticates against AD normally
Kerberos / NTLM works
GPOs apply
File ACLs work
Auditing is native
At this moment:
The PC is cryptographically authenticated by AD
This is the strongest model you’ve discussed so far.
✔ Native Windows logon
✔ Kerberos / NTLM
✔ User-based GPO
✔ NTFS ACLs
✔ Full auditing (who did what)
✔ No local users
✔ No kiosk hacks
This is enterprise-grade.
This is not trivial.
You must handle:
Race conditions (login before replication)
Password sync timing
Account cleanup
Lockouts
Failed provisioning rollback
You now:
Receive passwords
Set passwords
Store or proxy passwords
This increases:
Legal exposure
Compliance burden
Attack surface
A breach here is catastrophic.
If:
Multiple DCs
Short TTL accounts
Then:
Kerberos ticket failures
“User not found”
Login delays
Mitigation:
Single DC for labs
Or pre-create disabled users
You must define:
When users are deleted
When they expire
What happens to profiles
How roaming / local profiles behave
Otherwise AD becomes polluted.
This model is ideal if:
✔ You need real Windows sessions
✔ You need per-user ACLs
✔ You need full audit trails
✔ Users are semi-persistent
✔ You can operate AD securely
Typical environments:
Universities
Research labs
Corporate training rooms
Exam environments
Avoid this if:
❌ Users are ultra-ephemeral (minutes only)
❌ You want zero password handling
❌ You don’t need per-user ACLs
❌ You want kiosk-style behavior
In those cases:
➡ Computer-only AD + external auth is cleaner.
HTTP service authenticates user
AD password is never shown
PC uses password injected at logon time
accountExpires
Scheduled cleanup
Block inheritance
Strict GPO
No interactive admin rights
Yes — this is a correct, professional, enterprise-grade design, but:
It is identity infrastructure, not “just glue code”.
If implemented sloppily, it becomes a security nightmare.
If implemented correctly, it’s the best possible solution.
I can:
Design the exact AD schema
Provide PowerShell + LDAP code
Define account lifecycle policies
Harden the DC
Model attack vectors
Tell me:
Are users persistent or ephemeral?
Single DC or multiple?
Password storage allowed or forbidden?
Windows Pro or Enterprise?
Then we go from possible → correct.
+ + \ No newline at end of file