SGU-CredentialProvider/docs/security.md

Security model

Public Azure deployment

The Azure topology supports certificate-authenticated P2S or direct enrollment. P2S keeps AD services inside the VNet. Direct enrollment exposes the required AD, DNS/DoH, WinRM, broker and RustDesk ports only to explicit public IPv4 CIDRs; an empty allowlist exposes none of them. Azure NSG and Windows Firewall enforce the same source list. RDP uses a separate allowlist. See azure-vpn-deployment.md.

Password handling

• The Credential Provider receives the password in Lithnet's secure password control and keeps that SecureString for Windows serialization.
• A temporary managed string is unavoidable when creating the HTTPS JSON body. The unmanaged conversion buffer is zeroed immediately with Marshal.ZeroFreeGlobalAllocUnicode; managed references are released as soon as each request completes.
• The broker uses the exact received value for both NTLM and AD SetPassword.
• There is no HMAC password, pepper, local password cache, Supabase password, or other derived credential in this Windows path.
• Neither application logs request bodies or passwords. Deployment configuration contains certificate thumbprints, not passwords or private keys.

Transport

• HTTPS is mandatory on both links.
• Credential Provider to broker uses mutual TLS. The provider requires normal Windows certificate validation and pins the configured server certificate.
• The broker requires a trusted client certificate and an explicit allow-listed thumbprint.
• Client private keys are non-exportable and reside in LocalMachine\My.
• The NTLM validator rejects non-HTTPS redirects, URI user information, and hosts outside its explicit redirect allow-list.
• Authentication and profile enrichment read only allow-listed HTTPS pages. Profile bodies are capped at 512 KiB by default; portal cookies are request-scoped and held only in memory.

Profile minimization

• Administrative enrichment first verifies the employee number and reads employee type/status, email, job title, and department from the incident overview. Only after that match, it reads given names and paternal/maternal surnames and the normalized Male/Female value from the personal page plus street, exterior/interior number, neighborhood, locality, state, and postal code from the location page. AD stores only the controlled SGU-Gender line, not the original HTML field.
• Administrative birth date, RFC, CURP, blood type, marital status, nationality, telephone, email lists, housing type, and emergency-contact fields are ignored.
• Student enrichment reads only the matching student number, given names, paternal/maternal surnames, email, career, street, neighborhood, city/municipality, state, postal code, and normalized sex from known element IDs.
• Student CURP, birth date, blood type, marital status, telephone, mobile, guardian, medical, financial, and academic-history values are ignored.
• Professor enrichment keeps the menu display name as its base. From the payroll consultation header it reads only a matching employee number, name, email, employee type/status, job title, and the optional department field. It then optionally reads the same structured-name and postal-address element IDs used by staff pages. A missing professor route or element never makes authentication fail.
• Payroll/receipt contents, incident details, calendars, photographs, manager names, and manager positions are deliberately ignored.
• The employee or student number must match the authenticated AD or AL key before role-specific metadata is synchronized. The two supplemental administrative pages are never requested unless the incident page supplied the matching employee number. Professor payroll metadata independently requires the matching six-digit number, and every supplemental request uses the same fresh, request-scoped NTLM session as its menu fallback.
• If SGU changes its HTML, authentication and exact-password synchronization continue without enrichment; existing AD metadata is not erased.
• Slow profile pages cannot change an accepted credential into a rejection. The lightweight NTLM root is authoritative; enrichment has its own independent total timeout.

Lab self-signed certificates are appropriate only for the isolated VM network. Use an enterprise CA with revocation checking in production.

Recovery and availability

The provider distinguishes an authoritative rejection from unavailable infrastructure:

• 400/401: fail closed and show an error.
• timeout, TLS/connectivity error, 429, or 5xx: submit the unchanged credential to Windows. Windows must still validate it against AD or the cached domain verifier, so this does not grant access without the last synchronized password.

Redis is deliberately not used for password continuity. A second persistent password verifier duplicates attackable credential material, while a reversible encrypted password becomes a credential vault. AD and Windows cached domain logon already implement the required last-known-password behavior. See decisions/0001-no-password-cache.md.

The installer never registers a Credential Provider filter and never disables Microsoft's password, PIN, smart-card, or Windows Hello providers.

Operational controls

• Limit the firewall rule to the Domain profile and required client networks.
• Delegate the broker service account only to OU=Usuarios-SGU and its managed child OUs.
• Keep broker/client certificates short lived and rotate their allow-list entries.
• Monitor service availability and AD provisioning events without enabling HTTP body logging.
• Test uninstall and the built-in password provider before broad rollout.
• Do not test a new build first on a physical production endpoint; use a VM with a recent checkpoint and a known local administrator recovery account.