Enrich AD users from SGU profile metadata

README.md

@@ -13,14 +13,24 @@ Directory synchronization, deployment scripts, and tests.
 1. The Windows tile collects a `DO`, `AL`, or `AD` institutional key and a password.
 2. It sends that exact password over mutually authenticated TLS to the broker.
 3. The broker validates the same key/password pair against the configured SGU
-   NTLM endpoint.
-4. On success, the broker creates or moves the AD user and sets the AD password
+   NTLM endpoint. The same logical authenticated request reads the minimum
+   available SGU profile fields.
+4. On success, the broker creates or moves the AD user, updates the available
+   name/mail/title/department metadata, and sets the AD password
    to the exact submitted password.
 5. The Credential Provider serializes the original `SecureString` to Windows.
 
 No derived password is created. Passwords are not written to a database, file,
 event log, application log, command line, or response.
 
+For administrative accounts, profile enrichment targets the read-only incident
+overview and reads only the employee number, name, account type/status, email,
+job title, and department from their stable element IDs. Incident, calendar,
+photo, and manager fields are ignored. For students and professors, the menu
+display name is a conservative fallback until a richer role-specific page is
+verified. Missing or changed presentation HTML never blocks authentication or
+password synchronization.
+
 | Prefix | Role | Default OU |
 |---|---|---|
 | `DO` | Professor / docente | `OU=Docentes,OU=Usuarios-SGU,DC=lci,DC=lasalle,DC=mx` |