Centro_Experiencia_Digital/policies

Fork 0

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

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.

Proposed flow (restated precisely)

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”.

1. Is this possible?

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

2. What “PC is authenticated” actually means (critical)

There are three different authentication layers that people often conflate:

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.

3. How this is implemented correctly

Step A — External auth (HTTP)

PC collects {username, password}
Sends to your HTTP service
Receives {isSuccessful, username, mail, group}

At this point, Windows is NOT logged in yet.

Step B — JIT provisioning into LDAP / AD

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

Step C — Windows logon (real authentication)

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

4. Advantages of this model

This is the strongest model you’ve discussed so far.

You gain:

✔ 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.

5. The hidden costs (very important)

⚠️ 1. You are now running an Identity Bridge

This is not trivial.

You must handle:

Race conditions (login before replication)
Password sync timing
Account cleanup
Lockouts
Failed provisioning rollback

⚠️ 2. Password handling risk

You now:

Receive passwords
Set passwords
Store or proxy passwords

This increases:

Legal exposure
Compliance burden
Attack surface

A breach here is catastrophic.

⚠️ 3. Kerberos timing & replication

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

⚠️ 4. Account lifecycle management

You must define:

When users are deleted
When they expire
What happens to profiles
How roaming / local profiles behave

Otherwise AD becomes polluted.

6. When this architecture is the RIGHT choice

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

7. When this is the WRONG choice

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.

8. Best-practice refinements (recommended)

🔐 Use random AD passwords

HTTP service authenticates user
AD password is never shown
PC uses password injected at logon time

⏱ Use account expiration

accountExpires
Scheduled cleanup

🧱 Use dedicated OU

Block inheritance
Strict GPO
No interactive admin rights

9. Architectural verdict

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.

If you want next-level help

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.

</html> </html>