Så här fungerar kontoarkiv

AD FS är nära integrerat med AD DS. AD FS hämtar användarattribut och autentiserar användare mot AD DS. AD FS använder också Windows-integrerad autentisering och säkerhetstoken som AD DS skapar.

För att en användare ska kunna logga in i AD DS måste användarnamnet vara i UPN-format (User Principal Name), ex. user@adatum.com, eller i kontonamnformatet SAM (Security Accounts Manager), ex. adatum\user.

Åtkomsttoken skapas när en användare loggar in. De innehåller säkerhets-ID:n (Security Identifiers) för användaren och de grupper som användaren tillhör. En kopia av åtkomsttoken tilldelas alla processer som användaren startar.

När användaren är inloggad och personifierad räknas användarsäkerhets-ID:n (SID) upp från åtkomsttoken. Dessa SID mappas sedan till gruppanspråk för organisationen.

Varning

När alternativet Windows-förtroende aktiveras i kontots federationstjänst skickas verkliga säkerhets-ID:n till resurspartnerorganisationen via Internet. Detta kan innebära en säkerhetsrisk. Dessa säkerhets-ID paketeras i AD FS-SAML-token (Security Assertion Markup Language). Därför ska du bara aktivera det här alternativet när du använder designen Federerad enkel inloggning på webben med skogsförtroende. Den designen är avsedd att upprätta säker kommunikation inom en organisation.

E-postanspråk, anspråk för eget namn och anpassade anspråk kan extraheras från användarobjektattribut som har definierats i AD DS när federationstjänstkontot används för att göra en LDAP-sökning av ett objekt.

Federationstjänstkontot måste ha åtkomst till användarobjektet. Om användarobjektet finns i en annan domän än den där federationstjänstkontot finns måste den förra domänen ha ett AD DS-domänförtroende till den senare domänen.

Det finns inget direkt sätt att fastställa om ett visst användarnamn finns i AD DS och i alla kataloger som det har förtroende för (antingen direkt eller transitivt). AD DS returnerar ett auktoriseringsmisslyckande endast om inloggningsförsöket misslyckas på grund av principbegränsningar. Exempel på sådana principbegränsningar är följande:

• Kontot är inaktiverat.
  
  
• Kontots lösenord har upphört att gälla.
  
  
• Kontot har inte behörighet att logga in på den här datorn.
  
  
• Kontot har begränsningar gällande inloggningstid och har inte behörighet att logga in den här gången.
  
  

I annat fall är misslyckade inloggningar till AD DS-kontoarkiv alltid icke-auktoritära och nästa kontoarkiv i prioritetslistan prövas. Mer information om misslyckade inloggningar till kontoarkiv finns i avsnittet Felsökning av AD FS.

AD LDS innehåller lagring och hämtning av data för katalogaktiverade program utan de beroenden som AD DS kräver. AD LDS tillhandahåller i stort sett samma funktioner som AD DS men kräver inte att domäner eller domänkontrollanter används. På ungefär samma sätt som AD FS använder kontoarkivinformation i AD DS kan även AD FS hämta användarattribut och autentisera användare med AD LDS.

	OBS
	AD FS kan inte autentisera AD LDS-konton som använder parenteser som en del av kontonamnet. Konton som har en öppen parentes i användarnamnet resulterar i en misslyckad LDAP-sökning eftersom användarnamnet är ett ogiltigt LDAP-filter.

Federationstjänstkontot erhåller anspråken som används för att utföra en LDAP-sökning för objektet. Med information finns i avsnittet Så här fungerar anspråk. Det här är en process i två steg:

• Först hittar federationstjänstkontot användarobjektet via en sökning för det objekt vars konfigurerade attribut är identiskt med det medskickade användarnamnet. Federationstjänstkontot använder Kerberos-autentisering eller NTLM-kryptering för att skydda den här kommunikationen.
  
  

  	OBS
  	Processen kräver att AD LDS-servern är ansluten till en domän som har förtroende för den domän som federationstjänsten är medlem i.

• Därefter valideras användarautentiseringsuppgifterna med det medskickade lösenordet, genom en LDAP-bindning till det identifierade användarobjektet. Om TLS/SSL (Transport Layer Security and Secure Sockets Layer) har konfigurerats för AD LDS-kontoarkivets egenskaper i förtroendeprincipen, skyddas användarautentiseringsuppgifterna.
  
  

  	Viktigt!
  	Trafiken mellan AD LDS-servern och federationsservern bör skyddas med TLS/SSL eller på annat sätt, t.ex. IPsec (Internet Protocol security).

Om fler än ett objekt returneras från LDAP-frågan med det medskickade användarnamnet, betraktas det som en misslyckad autentisering.

Först söks användarkontot i AD LDS-kontoarkivet om det är konfigurerat och sedan konfigureras övriga LDAP-arkiv i den ordningen. Om användarkontot hittas i något av arkiven loggas användaren in auktoritärt och resten av kontoarkiven anropas inte för behandling av inloggningsbegäran.

När en användare gör en inloggningsbegäran till antingen AD DS eller AD LDS genom en AD FS-klient skickas begäran omedelbart till det angivna kontoarkivet. Om kontoarkivets URI (Uniform Resource Identifier) inte har angetts försöker federationstjänsten att logga in användaren på något av arkiven enligt prioritetsordningen. Autentiseringsresultatet returneras i följande fall:

• Det finns bara ett konfigurerat arkiv och informationen om verifiering av autentiseringsuppgifter returneras.
  
  
• Arkivets URI har angetts i inloggningsbegäran och informationen om verifiering av autentiseringsuppgifter returneras.
  
  
• Autentiseringresultatet av ett av arkiven var auktoritärt.
  
  
• Autentiseringen av ett av arkiven lyckades.
  
  

Det går att markera vart och ett av kontoarkiven som aktivt eller inaktivt. Om ett kontoarkiv är inaktiverat deltar det inte i några kontoarkivrelaterade åtgärder. Cookies med anspråk som har sitt ursprung i ett kontoarkiv som för närvarande är inaktiverat ignoreras eller tas bort och klienten dirigeras till inloggningssidan.