Capitolo 16 Client, groupware & CLI Admin: #pIdentity

Fonti di identità: Active Directory, LDAP, Entra ID, Keycloak e SCIM

In Admin > Fonti di identità si collega un tenant o singoli domini ad Active Directory o LDAP (accesso tramite bind, sincronizzazione di utenti, gruppi annidati e contatti) oppure a Microsoft Entra ID, Keycloak e altri provider OpenID Connect (accesso tramite SSO, provisioning tramite SCIM 2.0). Gli account locali restano pienamente utilizzabili accanto a questi (funzionamento misto). Ogni account ha esattamente una fonte; l'abbinamento usa l'ExternalId (AD objectGUID, Entra objectId, LDAP entryUUID), mai solo l'indirizzo e-mail. I campi gestiti dalla fonte sono di sola lettura nell'admin e in "Il mio account".

Suggerimento operativo & nota sull'architettura

Mantenere almeno un amministratore del server locale senza origine come accesso di emergenza (break glass). Non viene mai acquisito da AD, non accede mai tramite l'abbinamento della posta SSO e funziona anche quando AD o Entra non sono raggiungibili. Impostare la soglia di blocco di nextxch (predefinito 5 errori) al di sotto della soglia di blocco degli account AD: in questo modo gli attaccanti non bloccano mai un account AD, perché nextxch si ferma prima del bind.

Entra ID: registrazione dell'app per accesso e SCIM

Accesso: registrazione dell'app propria (piattaforma web) con il redirect URI da Admin > Origini di identità. Provisioning: app enterprise non della galleria con modalità di provisioning "Automatica", URL del tenant e token segreto da nextxch.

Riferimento / configurazione

1. Entra admin center > App registrations > New registration
   Name:            nextxch Webmail
   Account types:   Accounts in this organizational directory only (single tenant)
   Redirect URI:    Web  https://mail.example.com/api/auth/sso/callback
2. Certificates & secrets > New client secret  -> enter it in nextxch as client secret
3. Token configuration > Add optional claim: ID token "email" (otherwise preferred_username = UPN is used)
4. App roles (optional): e.g. create "Nextxch.TenantAdmins", assign users,
   in nextxch: claim "roles", value "Nextxch.TenantAdmins" -> role TenantAdmin
5. nextxch Admin > Identity sources > Add Entra ID / OIDC
   Authority:  https://login.microsoftonline.com/<directory id>/v2.0
   Client id:  <application id>
6. SCIM: Enterprise applications > New application > Create your own (non-gallery)
   Provisioning > Automatic
   Tenant URL:    https://mail.example.com/scim/v2
   Secret token:  nxscim_...   (Admin > Identity sources > Create SCIM token)
   Mappings: userName <- userPrincipalName, emails[type eq "work"].value <- mail,
             externalId <- objectId (recommended) or mailNickname

Impostazioni, valori predefiniti e best practice

Impostazione / posizione	Descrizione	Valore predefinito	Best practice per la produzione
`Active Directory: Dienstkonto`	Normale utente di dominio senza diritti amministrativi, sola lettura (è sufficiente l'accesso in lettura predefinito di "Authenticated Users"). La password non scade. Memorizzata crittografata, mai mostrata.	`CN=svc-nextxch,OU=Service,...`	Nessun amministratore di dominio. La lettura è sufficiente per foto e proxyAddresses. Facoltativamente limitare "Accedi a" ai DC.
`LDAPS 636 / StartTLS 389`	Connessione crittografata ai domain controller. Più DC vengono provati in ordine (failover), timeout per DC configurabile.	`LDAPS, 10 s`	Considerare attendibile il certificato del DC (o della CA interna) sul server nextxch. "Non verificare il certificato" solo brevemente durante la configurazione.
`Anmeldung (alle Protokolle)`	Webmail, admin, IMAP, SMTP, POP3, ActiveSync, EWS, MAPI e DAV verificano la password AD tramite bind. Nomi di accesso: indirizzo e-mail, userPrincipalName, sAMAccountName o DOMAIN\user.	`Cache 15 min (Hash)`	La breve cache di accesso memorizza solo un HMAC, mai la password, e mantiene l'accesso funzionante durante una breve interruzione del DC. 0 la disattiva.
`Abgleich: Benutzer, Gruppen, Kontakte`	mail e proxyAddresses (SMTP: = principale, smtp: = alias), displayName, givenName, sn, telephoneNumber, mobile, title, department, company, physicalDeliveryOfficeName, manager, thumbnailPhoto; userAccountControl e accountExpires disattivano la casella di posta. I gruppi abilitati alla posta diventano liste di distribuzione (annidate tramite LDAP_MATCHING_RULE_IN_CHAIN), i contatti compaiono nella rubrica.	`Delta 15 min, voll 02:00`	Usare "Anteprima" prima della prima esecuzione: mostra quali account verrebbero creati, rilevati o disattivati senza modificare nulla. Filtrare su un gruppo "Utenti di posta".
`Gelöschte Objekte`	Quando un oggetto scompare da AD (o Entra invia SCIM DELETE), la casella di posta viene disattivata immediatamente. Dopo il periodo di tolleranza l'amministratore decide: eliminarla, mantenerla come casella condivisa o lasciarla disattivata.	`30 Tage`	Le rinomine non sono eliminazioni: il vecchio indirizzo principale resta come alias.
`Vorlagen`	Mappatura degli attributi per Microsoft AD, Samba AD, OpenLDAP, Univention Corporate Server e FreeIPA; ogni campo può essere sovrascritto o disattivato con "-".	`Active Directory`	OpenLDAP richiede l'overlay memberOf per il filtro dei gruppi; in quel caso nextxch risolve autonomamente i gruppi annidati.
`OIDC (Entra ID, Keycloak)`	Authorization code flow con PKCE sul server, discovery e JWKS con rotazione automatica delle chiavi, RS256/ES256, verifica di iss, aud, exp, nonce e del tid del tenant Entra. Le claim di gruppo o di ruolo app vengono mappate su User, TenantAdmin e ServerAdmin.	`Knopf auf der Anmeldeseite`	Keycloak: authority https://kc.example.com/realms/<realm>, client confidenziale con standard flow, redirect URI come sopra; ruoli tramite il claim realm_access.roles.
`Lokale Passwörter pro Domain`	Disattivabile separatamente per webmail/admin e per i protocolli. Le password Entra non raggiungono mai nextxch: le app di posta (Outlook, iPhone, Thunderbird) usano password per app; la Webmail guida nella configurazione con un assistente.	`An`	Per ogni protocollo è inoltre possibile imporre "Solo OAuth / Kerberos" (vedere i capitoli 16a e 16b). Gli utenti AD possono cambiare la propria password nella webmail se l'origine lo consente.
`Kennwort ändern (AD / LDAP)`	Con "Gli utenti possono cambiare la propria password" la webmail mostra un modulo in Impostazioni > Sicurezza (password attuale e nuova). AD: unicodePwd tramite LDAPS con la vecchia password, quindi si applicano complessità AD, cronologia delle password ed età minima; altre directory: RFC 3062. Gli amministratori reimpostano le password nella finestra di dialogo dell'account (facoltativamente "cambio al prossimo accesso").	`Aus`	Per il reset da parte dell'amministratore delegare all'account di servizio solo "Reimposta password" sulla OU utenti. Le password non vengono mai registrate nei log.