Anteckning
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
I följande avsnitt beskrivs den konfiguration som krävs för att aktivera AD FS-infrastrukturen för att autentisera användare vars identiteter lagras i LDAP-kataloger (Lightweight Directory Access Protocol) v3-kompatibla kataloger.
I många organisationer består identitetshanteringslösningar av en kombination av Active Directory, AD LDS eller LDAP-kataloger från tredje part. Med tillägg av AD FS-stöd för autentisering av användare som lagras i LDAP v3-kompatibla kataloger kan du dra nytta av hela AD FS-funktionsuppsättningen i företagsklass oavsett var dina användaridentiteter lagras. AD FS stöder alla LDAP v3-kompatibla kataloger.
Anmärkning
Några av AD FS-funktionerna omfattar enkel inloggning (SSO), enhetsautentisering, flexibla principer för villkorlig åtkomst, stöd för arbete var som helst genom integrering med webbprogramproxyn och sömlös federation med Microsoft Entra som i sin tur gör att du och dina användare kan använda molnet, inklusive Office 365 och andra SaaS-program. För mer information, se Översikt över Active Directory Federation Services.
För att AD FS ska kunna autentisera användare från en LDAP-katalog måste du ansluta den här LDAP-katalogen till AD FS-servergruppen genom att skapa ett lokalt anspråksproviderförtroende. Ett lokalt anspråksproviderförtroende är ett förtroendeobjekt som representerar en LDAP-katalog i din AD FS-servergrupp. Ett lokalt anspråksproviderförtroendeobjekt består av en mängd olika identifierare, namn och regler som identifierar den här LDAP-katalogen för den lokala federationstjänsten.
Du kan stödja flera LDAP-kataloger, var och en med sin egen konfiguration, inom samma AD FS-servergrupp genom att lägga till flera lokala anspråksproviderförtroenden. Dessutom kan AD DS-skogar som inte har förtroende hos skogen där AD FS finns också modelleras som lokala anspråksleverantörsförtroenden. Du kan skapa lokala anspråksproviderförtroenden med hjälp av Windows PowerShell.
LDAP-kataloger (lokala anspråksproviderförtroenden) kan samexistera med AD-kataloger (anspråksproviderförtroenden) på samma AD FS-server, inom samma AD FS-servergrupp. Därför kan en enda instans av AD FS autentisera och auktorisera åtkomst för användare som lagras i både AD- och icke-AD-kataloger.
Endast formulärbaserad autentisering stöds för autentisering av användare från LDAP-kataloger. Certifikatbaserad och integrerad Windows-autentisering stöds inte för autentisering av användare i LDAP-kataloger.
Alla passiva auktoriseringsprotokoll som stöds av AD FS, inklusive SAML, WS-Federation och OAuth stöds också för identiteter som lagras i LDAP-kataloger.
WS-Trust aktivt auktoriseringsprotokoll stöds också för identiteter som lagras i LDAP-kataloger.
Konfigurera AD FS för att autentisera användare som lagras i en LDAP-katalog
Om du vill konfigurera AD FS-servergruppen för att autentisera användare från en LDAP-katalog kan du utföra följande steg:
Konfigurera först en anslutning till din LDAP-katalog med hjälp av cmdleten New-AdfsLdapServerConnection:
$DirectoryCred = Get-Credential $vendorDirectory = New-AdfsLdapServerConnection -HostName dirserver -Port 50000 -SslMode None -AuthenticationMethod Basic -Credential $DirectoryCredAnmärkning
Vi rekommenderar att du skapar ett nytt anslutningsobjekt för varje LDAP-server som du vill ansluta till. AD FS kan ansluta till flera LDAP-replikservrar och automatiskt växla över om en specifik LDAP-server inte fungerar. I ett sådant fall kan du skapa en AdfsLdapServerConnection för var och en av dessa replik-LDAP-servrar och sedan lägga till matrisen med anslutningsobjekt med parametern -LdapServerConnection för Add-AdfsLocalClaimsProviderTrust cmdlet.
OBS! Ditt försök att använda Get-Credential och ange ett DN och lösenord som ska användas för att binda till en LDAP-instans kan leda till ett fel på grund av användargränssnittskravet för specifika indataformat, till exempel domän\användarnamn eller user@domain.tld. Du kan i stället använda cmdleten ConvertTo-SecureString enligt följande (exemplet nedan förutsätter uid=admin,ou=system som DN för de autentiseringsuppgifter som ska användas för att binda till LDAP-instansen):
$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:"Ange sedan lösenordet för uid=admin och slutför resten av stegen.
Därefter kan du utföra det valfria steget för att mappa LDAP-attribut till befintliga AD FS-anspråk med hjälp av New-AdfsLdapAttributeToClaimMapping cmdlet. I exemplet nedan mappar du attributen givenName, Surname och CommonName LDAP till AD FS-anspråken:
#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"Den här mappningen görs för att göra attribut från LDAP-arkivet tillgängliga som anspråk i AD FS för att skapa regler för villkorlig åtkomstkontroll i AD FS. Det gör också att AD FS kan arbeta med anpassade scheman i LDAP-butiker genom att tillhandahålla ett enkelt sätt att mappa LDAP-attribut till anspråk.
Slutligen måste du registrera LDAP-arkivet med AD FS som ett lokalt anspråksproviderförtroende med hjälp av cmdleten 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"I exemplet ovan skapar du ett lokalt anspråksproviderförtroende med namnet "Leverantörer". Du anger anslutningsinformation för AD FS för att ansluta till den LDAP-katalog som det lokala anspråksproviderförtroendet representerar genom att tilldela
$vendorDirectorytill parametern-LdapServerConnection. Observera att du i steg ett har tilldelat$vendorDirectoryen anslutningssträng som ska användas när du ansluter till din specifika LDAP-katalog. Slutligen anger du att$GivenName,$Surnameoch$CommonNameLDAP-attribut (som du mappade till AD FS-anspråken) ska användas för villkorlig åtkomstkontroll, inklusive principer för multifaktorautentisering och utfärdandeauktoriseringsregler, samt för utfärdande via anspråk i AD FS-utfärdade säkerhetstoken. För att kunna använda aktiva protokoll som Ws-Trust med AD FS måste du ange parametern OrganizationalAccountSuffix, som gör det möjligt för AD FS att skilja mellan lokala anspråksproviderförtroenden när du hanterar en aktiv auktoriseringsbegäran.