Configurare AD FS per l'autenticazione di utenti memorizzati nelle directory LDAP in Windows Server 2016 o una versione successiva
L'argomento seguente descrive la configurazione necessaria per consentire all'infrastruttura AD FS di autenticare gli utenti le cui identità sono archiviate nelle directory conformi a LDAP (Lightweight Directory Access Protocol) v3.
In molte organizzazioni le soluzioni di gestione dell'identità si basa su una combinazione di directory Active Directory, AD LDS o directory LDAP di terze parti. Con l'aggiunta del supporto di AD FS per l'autenticazione degli utenti archiviati in directory conformi a LDAP v3, è possibile trarre vantaggio dall'intero set di funzionalità di AD FS di livello aziendale indipendentemente dalla posizione in cui sono archiviate le identità utente. AD FS supporta qualsiasi directory conforme a LDAP v3.
Nota
Alcune delle funzionalità di AD FS includono accesso singolo (SSO), autenticazione del dispositivo, criteri di accesso condizionale flessibili, supporto per il lavoro da qualsiasi luogo tramite l'integrazione con Web Application Proxy e federazione senza problemi con Microsoft Entra, che a sua volta consente all'utente e agli utenti di utilizzare il cloud, tra cui Office 365 e altre applicazioni SaaS. Per altre informazioni, vedere Panoramica di Active Directory Federation Services.
Per consentire ad AD FS di autenticare gli utenti da una directory LDAP, è necessario connettere questa directory LDAP alla farm AD FS creando un trust del provider di attestazioni locale. Un trust del provider di attestazioni locale è un oggetto trust che rappresenta una directory LDAP nella farm AD FS. Un oggetto trust del provider di attestazioni locale è costituito da diversi identificatori, nomi e regole che identificano la directory LDAP nel Servizio federativo locale.
È possibile supportare più directory LDAP, ognuna con la propria configurazione, all'interno della stessa farm AD FS aggiungendo più trust del provider di attestazioni locali. Inoltre, anche le foreste di Active Directory Domain Services non considerate attendibili dalla foresta in cui si trova AD FS possono essere modellate come trust del provider di attestazioni locali. È possibile creare trust del provider di attestazioni locali usando Windows PowerShell.
Le directory LDAP (trust del provider di attestazioni locali) possono coesistere con le directory AD (trust del provider di attestazioni) nello stesso server AD FS e all'interno della stessa farm AD FS, pertanto una singola istanza di AD FS è in grado di autenticare e autorizzare l'accesso per gli utenti archiviati sia in directory AD che non AD.
Per autenticare gli utenti dalle directory LDAP è supportata solo l'autenticazione basata su moduli. L'autenticazione integrata e basata su certificati di Windows non è supportata per l'autenticazione degli utenti nelle directory LDAP.
Tutti i protocolli di autorizzazione passivi supportati da AD FS, inclusi SAML, WS-Federation e OAuth, sono supportati anche per le identità archiviate nelle directory LDAP.
Il protocollo di autorizzazione attivo WS-Trust è supportato anche per le identità archiviate nelle directory LDAP.
Configurare AD FS per l'autenticazione di utenti memorizzati nelle directory LDAP
Per configurare la farm AD FS per autenticare gli utenti da una directory LDAP, è possibile completare la procedura seguente:
Configurare prima di tutto una connessione alla directory LDAP usando il cmdlet New-AdfsLdapServerConnection:
$DirectoryCred = Get-Credential $vendorDirectory = New-AdfsLdapServerConnection -HostName dirserver -Port 50000 -SslMode None -AuthenticationMethod Basic -Credential $DirectoryCredNota
È consigliabile creare un nuovo oggetto connessione per ogni server LDAP a cui connettersi. AD FS può connettersi a più server LDAP di replica ed eseguire automaticamente il failover nel caso in cui un server LDAP specifico sia inattivo. In questo caso, è possibile creare un oggetto AdfsLdapServerConnection per ognuno di questi server LDAP di replica e quindi aggiungere la matrice di oggetti connessione usando il parametro -LdapServerConnection del cmdlet Add-AdfsLocalClaimsProviderTrust.
NOTA: il tentativo di usare Get-Credential e digitare un DN e una password da usare per l'associazione a un'istanza LDAP potrebbe causare un errore a causa del requisito dell'interfaccia utente per formati di input specifici, come dominio\nomeutente o user@domain.tld. È invece possibile usare il cmdlet ConvertTo-SecureString come indicato di seguito (l'esempio seguente presuppone uid=admin,ou=system come DN delle credenziali da usare per l'associazione all'istanza LDAP):
$ldapuser = ConvertTo-SecureString -string "uid=admin,ou=system" -asplaintext -force $DirectoryCred = Get-Credential -username $ldapuser -Message "Enter the credentials to bind to the LDAP instance:"Immettere quindi la password per uid=admin e completare il resto dei passaggi.
Successivamente, è possibile eseguire il passaggio facoltativo del mapping degli attributi LDAP alle attestazioni AD FS esistenti usando il cmdlet New-AdfsLdapAttributeToClaimMapping. Nell'esempio seguente viene eseguito il mapping degli attributi LDAP givenName, Surname e CommonName alle attestazioni AD FS:
#Map given name claim $GivenName = New-AdfsLdapAttributeToClaimMapping -LdapAttribute givenName -ClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname" # Map surname claim $Surname = New-AdfsLdapAttributeToClaimMapping -LdapAttribute sn -ClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname" # Map common name claim $CommonName = New-AdfsLdapAttributeToClaimMapping -LdapAttribute cn -ClaimType "http://schemas.xmlsoap.org/claims/CommonName"Questo mapping viene eseguito per rendere disponibili gli attributi dall'archivio LDAP come attestazioni in AD FS per creare regole di controllo di accesso condizionale in AD FS. Consente inoltre ad AD FS di lavorare con schemi personalizzati negli archivi LDAP offrendo un modo semplice per eseguire il mapping degli attributi LDAP alle attestazioni.
Infine, è necessario registrare l'archivio LDAP con AD FS come trust del provider di attestazioni locale usando il cmdlet Add-AdfsLocalClaimsProviderTrust:
Add-AdfsLocalClaimsProviderTrust -Name "Vendors" -Identifier "urn:vendors" -Type Ldap # Connection info -LdapServerConnection $vendorDirectory # How to locate user objects in directory -UserObjectClass inetOrgPerson -UserContainer "CN=VendorsContainer,CN=VendorsPartition" -LdapAuthenticationMethod Basic # Claims for authenticated users -AnchorClaimLdapAttribute mail -AnchorClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn" -LdapAttributeToClaimMapping @($GivenName, $Surname, $CommonName) # General claims provider properties -AcceptanceTransformRules "c:[Type != ''] => issue(claim=c);" -Enabled $true # Optional - supply user name suffix if you want to use Ws-Trust -OrganizationalAccountSuffix "vendors.contoso.com"Nell'esempio precedente si sta creando un trust del provider di attestazioni locale denominato "Vendors". Si specificano informazioni di connessione per permettere ad AD FS di connettersi alla directory LDAP rappresentata da questo trust del provider di attestazioni locale assegnando
$vendorDirectoryal parametro-LdapServerConnection. Si noti che nel passaggio 1 è stata assegnata a$vendorDirectoryuna stringa di connessione da usare per la connessione alla directory LDAP specifica. Infine, si specifica che gli attributi LDAP$GivenName,$Surnamee$CommonName(di cui è stato eseguito il mapping alle attestazioni AD FS) devono essere usati per il controllo dell'accesso condizionale, inclusi i criteri di autenticazione a più fattori e le regole di autorizzazione di rilascio, nonché per il rilascio tramite attestazioni nei token di sicurezza rilasciati da AD FS. Per usare protocolli attivi come Ws-Trust con AD FS, è necessario specificare il parametro OrganizationalAccountSuffix, che consente ad AD FS di distinguere tra i trust del provider di attestazioni locali durante la manutenzione di una richiesta di autorizzazione attiva.