68 lines
3.2 KiB
Markdown
68 lines
3.2 KiB
Markdown
# Security model
|
|
|
|
## 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.
|
|
- Profile enrichment reads only allow-listed HTTPS pages and caps the response
|
|
body at 512 KiB by default. Portal cookies are request-scoped and held only in
|
|
memory.
|
|
|
|
## Profile minimization
|
|
|
|
- Administrative enrichment reads only employee number, display name,
|
|
employee type/status, email, job title, and department from known element IDs.
|
|
- Incident details, calendars, photographs, manager names, and manager positions
|
|
are deliberately ignored.
|
|
- The employee number must match the authenticated `AD` key before metadata is
|
|
synchronized.
|
|
- If SGU changes its HTML, authentication and exact-password synchronization
|
|
continue without enrichment; existing AD metadata is not erased.
|
|
|
|
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.
|
|
|
|
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.
|