Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
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 delle identità sono costituite da una combinazione di directory Active Directory, AD LDS o 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 l'accesso Single Sign-On (SSO), l'autenticazione dei dispositivi, i criteri di accesso condizionale flessibili, il supporto per il lavoro da qualsiasi posizione tramite l'integrazione con il proxy applicazione Web e la perfetta federazione con Microsoft Entra, che a sua volta consente all'utente e agli utenti di usare 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 dichiarazioni locale è un oggetto di trust che rappresenta una directory LDAP nella farm di AD FS. Un oggetto trust del provider di attestazioni locale è costituito da un'ampia gamma di identificatori, nomi e regole che identificano questa directory LDAP al 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, le foreste di Active Directory Domain Services non considerate attendibili dalla foresta in cui si trova AD FS possono anche essere modellate come trust del provider di attestazioni locali. È possibile creare relazioni di trust con i provider di attestazioni locali usando Windows PowerShell.
Le directory LDAP (provider di attestazioni locali) possono coesistere con le directory AD (provider di attestazioni) nello stesso server AD FS, 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 nelle directory AD che in quelle non AD.
Per autenticare gli utenti dalle directory LDAP è supportata solo l'autenticazione basata su form. 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 WS-Trust protocollo di autorizzazione attivo è supportato anche per le identità archiviate nelle directory LDAP.
Configurare AD FS per autenticare gli utenti archiviati in una 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, ad esempio domain\username 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 stai creando un trust del provider locale di attestazioni denominato "Vendors". Specificate le informazioni di connessione per AD FS per stabilire una connessione con la directory LDAP che questo trust del provider di attestazioni locale rappresenta, assegnando
$vendorDirectoryal parametro-LdapServerConnection. Si noti che nel passaggio 1 è stato assegnato$vendorDirectoryuna stringa di connessione da usare per la connessione alla directory LDAP specifica. Infine, si specifica che gli attributi$GivenName,$Surnamee$CommonNameLDAP (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 disambiguare tra i trust del provider di attestazioni locali durante la manutenzione di una richiesta di autorizzazione attiva.