Depanarea problemelor de AD FS în Azure Active Directory și Office 365

IMPORTANT: Acest articol este tradus cu ajutorul software-ului Microsoft de traducere automată și poate fi corectat prin intermediul tehnologiei Community Translation Framework (CTF). Microsoft oferă articole traduse automat, post-editate de comunitate și articole traduse de oameni, pentru a permite accesul la toate articolele din Baza noastră de cunoștințe în mai multe limbi. Articolele traduse automat și post-editate pot conține greșeli de vocabular, sintaxă și/sau gramatică. Microsoft nu este responsabil de inexactitățile, erorile sau daunele cauzate de traducerea greșită a conținutului sau de utilizarea acestuia de către clienți. Găsiți mai multe informații despre traducerea în colaborare la http://support.microsoft.com/gp/machine-translation-corrections/ro.

Faceți clic aici pentru a vizualiza versiunea în limba engleză a acestui articol: 3079872
Acest articol discută despre flux de lucru de depanare pentru probleme cu autentificarea pentru utilizatorii federalizați în Azure Active Directory sau Office 365.
Simptome
  • Utilizatorii federalizați nu Faceți conecta la Office 365 sau Microsoft Azure chiar dacă gestionate cloud numai utilizatorii care au domainxx.onmicrosoft.com UPN sufix poate face conecta fără probleme.
  • Redirecționare pentru Active Directory Federation Services (AD FS) sau STS nu se produce pentru un utilizator federativ. Sau, se declanșează o eroare "Imposibil de afișat pagina".
  • Primiți un avertisment legate de certificat un browser atunci când încercați să autentifica cu AD FS. Aceasta afirmă că nu reușește validarea certificatului sau că certificatul nu este de încredere.
  • "Unknown Auth metoda" eroare sau erori care declară că AuthnContext nu este acceptată. De asemenea, erori la nivelul AD FS sau STS atunci când sunteți redirecționați la Office 365.
  • AD FS lansează o eroare "Acces refuzat".
  • AD FS lansează o eroare care declară că există o problemă de accesare a site-ul; Aceasta include un număr ID de referință.
  • Utilizatorului i se solicită în mod repetat acreditările la nivelul AD FS.
  • Utilizatorii federalizați nu se pot autentifica la o rețea externă sau când utilizează o aplicație care durează calea de rețea externă (Outlook, de exemplu).
  • Utilizatorii federalizați nu pot face conecta după un certificat de semnare simbol este modificat în AD FS.
  • O eroare "Ne pare rău, dar am întâmpinați probleme de conectare ce" se declanșează atunci când un utilizator federativ semnele la Office 365 în Microsoft Azure. Această eroare include coduri de eroare, cum ar fi 8004786 C, 80041034, 80041317, 80043431, 80048163, 80045C 06, 8004789A sau rău solicitare.

Depanare flux de lucru
  1. Acces https://login.microsoftonline.com, apoi introduceți (nume) login utilizator federativcineva@exemplu.com). După ce apăsați Tab pentru a elimina focalizarea la caseta de conectare, verificați dacă starea modificările pagina "Redirecționarea" şi apoi sunteți Redirecționat către dvs. Active Directory Federation Service (AD FS) pentru conectare.

    Când apare redirecționare, vedeți pagina următoare:

    Captura de ecran pentru Pasul 1
    1. Dacă redirecţionarea nu apare și vi se solicită să introduceți o parolă pe aceeași pagină, aceasta înseamnă că Azure Active Directory (AD) sau Office 365 nu recunoaște utilizatorului sau domeniul utilizatorului să fi fost federalizată. Pentru a verifica dacă există o federație de încredere între Azure AD sau Office 365 și serverul AD FS, executați Get-msoldomain cmdletul la Azure AD PowerShell. Dacă un domeniu este federalizate, proprietatea de autentificare va afișa ca "Federalizat," ca în următoarea fotografie de ecran:

      Pasul despre federalizat domeniu
    2. Dacă apare redirecționare, dar nu sunt redirecționate la serverul AD FS pentru conectare, verificați dacă nume de sign-in de serviciu AD FS rezolvă pentru a corecta IP și dacă se poate conecta la acel IP port TCP 443.

      Dacă domeniul este afișat ca "Federalizat", obține informații despre federation trust executând următoarele comenzi:
      Get-MsolFederationProperty -DomainName <domain>
      Get-MsolDomainFederationSettings -DomainName <domain>
      Verificați URI, URL-ul și certificate de federalizare partenerul care este configurat cu Office 365 sau Azure AD.
  2. După ce sunt redirecționate în AD FS, browserul poate lansează o eroare legată de încredere certificat și pentru unii clienți și dispozitive se poate vă permit să stabilească o sesiune SSL cu AD FS. Pentru a rezolva această problemă, urmați acești pași:
    1. Asiguraţi-vă că AD FS service comunicare certificatul este prezentat clientul este aceeaşi pe care este configurată pe AD FS.

      Captura de ecran despre Pasul A

      Ideal ar fi certificatul de comunicare AD FS service ar trebui să fie la fel ca certificatul SSL este prezentat clientul atunci când încearcă să stabilească un tunel SSL cu serviciul AD FS.

      În AD FS 2.0:

      • Se leagă certificatul IIS-> implicit prima site-ul.
      • Utilizarea AD FS completare snap-in pentru a adăuga certificatul același ca certificatul de comunicare service.

      În AD FS 2012 R2:

      • Utilizați utilitarul snap-in AD FS sauAdăugați-adfscertificatecomandă pentru a adăuga un certificat de comunicare service.
      • UtilizareaSet-adfssslcertificatecomanda se setează acelaşi certificat pentru legare SSL.

    2. Asigurați-vă AD FS service comunicare certificat este de încredere de către client.
    3. Dacă non-SNI – suportă clienți încearcă să stabilească o sesiune SSL cu AD FS sau WAP 2-12 R2, încercarea poate să nu reușească. În acest caz, aveți în vedere adăugarea o intrare de rezervă pe serverele AD FS sau WAP pentru a accepta clienţi non-SNI. Pentru mai multe informații, consultați următorul blog post:
  3. Este posibil să întâmpinați o eroare "Metodă de autorizare necunoscută" sau erori care declară că AuthnContext nu este acceptată de la nivelul AD FS sau STS atunci când sunteți redirecționați la Office 365. Aceasta este cea mai comună la Office 365 și Azure AD redirecționează pentru AD FS sau STS utilizând un parametru care impune o metodă de autorizare. Pentru a impune o metodă de autorizare, utilizați una dintre următoarele metode:
    • Pentru WS-federalizare, utilizați un șir de interogare WAUTH pentru a impune o metodă de autorizare preferată.
    • Pentru SAML2.0, utilizați următoarele:
      <saml:AuthnContext><saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef></saml:AuthnContext>
    Atunci când metoda de autentificare executată este trimis cu o valoare incorectă sau dacă această metodă de autorizare nu este acceptată pe AD FS sau STS, primiți un mesaj de eroare, înainte de a vă sunt autentificate.

    Următorul tabel Arată uri-uri care sunt recunoscute de AD FS pentru tipul de autentificare WS-federalizare autentificare pasiv.
    Metoda de autentificare doritwauth URI
    Autentificarea utilizatorului nume de sign-in și parolaurn: oasis: Nume: tc: SAML:1.0:am:password
    Autentificare client SSLurn: ietf:rfc:2246
    autentificare Windows integratăurn: federation: autentificarea windows:

    Acceptate SAML autentificare context clase

    metodă de autorizare Autentificare context class URI
    nume de sign-in de utilizator și parolaurn: oasis: Nume: tc: SAML:2.0:ac:classes:Password
    Transport protejat prin parolăurn: oasis: Nume: tc: SAML:2.0:ac:classes:PasswordProtectedTransport
    protocol TLS (TLS) clienturn: oasis: Nume: tc: SAML:2.0:ac:classes:TLSClient
    X.509 certificaturn: oasis: Nume: tc: SAML:2.0:ac:classes:X 509
    autentificare Windows integratăurn: federation: autentificarea windows:
    Kerberosurn: oasis: Nume: tc: SAML:2.0:ac:classes:Kerberos

    Pentru a vă asigura că metoda de autentificare este acceptat la nivel AD FS, verificați următoarele.

    AD FS 2.0

    Sub /adfs/LS/web.config, asigurați-vă că este prezentă intrarea pentru tipul de autentificare.

    <microsoft.identityServer.web></microsoft.identityServer.web>
    <localAuthenticationTypes></localAuthenticationTypes>
    Adăugare nume = "Formulare" page="FormsSignIn.aspx" / >
    <add name="Integrated" page="auth/integrated/"></add>
    <add name="TlsClient" page="auth/sslclient/"></add>
    <add name="Basic" page="auth/basic/"></add>


    AD FS 2.0: Cum se modifică tipul de autentificare locală

    AD FS 2012 R2

    Sub AD FS Management, faceți clic pe Politici de autentificare în AD FS de completare snap-in.

    În Autentificare principală secțiune, faceți clic pe Editare lângă Setări globale. De asemenea, posibilitatea să faceți clic dreapta Politici de autentificare apoi selectați Editare autentificare principală Global. Sau, în Acțiuni panou, selectați Editare autentificare principală Global.

    În Editare politică de autentificare Global cadru fereastră, Principală fila, aveți posibilitatea să configurați setările ca parte a politicii de autentificare global. De exemplu, pentru autentificare principal, aveți posibilitatea să selectați metode de autentificare disponibile sub Extranet și Intranet.

    ** Asigurați-vă că este bifată casetă de selectare metodă de autorizare necesare.
  4. Dacă se ajunge la AD FS dvs. și să introduceți acreditările, dar se poate face autentificarea, verificați următoarele probleme.
    1. Problemă de reproducere Active Directory

      Dacă AD reproducerea este întreruptă, modificările efectuate de utilizator sau grup nu pot fi sincronizate pe controlerele de domeniu. Între controlerelor de domeniu, este posibil să existe o parolă, UPN, GroupMembership, sau ProxyAddressNepotrivire care afectează răspuns AD FS (autentificare și solicitări). Ar trebui să înceapă în căutarea la controlerele de domeniu pe același site ca AD FS. Execută oRepadmin /showreps sau o DCdiag /v comandă ar trebui să dezvălui dacă există o problemă pe controlerele de domeniu care este cel mai probabil să contactați AD FS.

      Puteţi colecta, de asemenea, un rezumat de reproducere AD pentru a vă asigura că modificările AD sunt se reproduce corect în toate controlerele de domeniu. The Repadmin /showrepl * /csv > showrepl.csv rezultatul este util pentru a verifica starea de reproducere. Pentru mai multe informații, consultați Depanarea problemelor de reproducere Active Directory.
    2. Cont blocat sau dezactivat în Active Directory

      Când un utilizator final este autentificat prin AD FS, el sau ea nu va primi o eroare mesaj care declară că contul este blocat sau dezactivat. AD FS şi audit de conecta, trebuie să fie capabil să determine dacă autentificarea nu a reușit din cauza o parolă incorectă, dacă contul este dezactivat sau blocat, și așa mai departe.

      Pentru a activa AD FS şi audit AD FS fermă de servere de conecta, urmați acești pași:
      1. Utilizați politica locală sau domeniu pentru a activa succes şi eşec pentru politicile următoarele:
        • Audit event conecta, amplasate în Computer configuration\Windows Settings\Security setting\Local Policy\Audit politica"
        • Obiect de acces, aflat în Computer configuration\Windows Settings\Security setting\Local Policy\Audit politică de audit"
        Captura de ecran despre politicile
      2. Dezactivați politica următoarele:

        Audit: Force audit setările de politică de titlu (Windows Vista sau o versiune ulterioară) pentru a înlocui setările de politică de audit categorie

        Această politică se află în Computer configuration\Windows Settings\Security setting\Local Policy\Security opţiune.

        Fotografia despre politica de ecran

        Dacă doriți să configurați acest lucru utilizând audit complexe, faceți clic pe aici.
      3. Configurați AD FS pentru audit:
        1. Deschiderea AD FS 2.0 Management de completare snap-in.
        2. În panoul acțiuni , faceți clic pe Edit Federation Service Properties.
        3. În Federation Service Properties casetă de dialog, faceți clic pe evenimente fila.
        4. Selectați succes auditurilor și Failure audits casetele de selectare.

          Sceenshot despre activare AD FS audit
        5. Executare GPupdate/Force pe server.
    3. Nume Principal serviciu (SPN) este înregistrată incorect

      Pot exista spn dublate sau un SPN care este înregistrată sub un cont la contul de serviciu AD FS. Pentru o instalare AD FS fermă, asigurați-vă că SPN gazdă/AD FSservicename este adăugat la contul de serviciu pe care se execută serviciul AD FS. Pentru o instalare autonomă AD FS, în cazul în care serviciul se execută sub Serviciu de rețea, SPN trebuie să fie sub contul de computer serverul care găzduiește AD FS.

      Captura de ecran pentru nume de sign-in de serviciu AD FS

      Asigurați-vă că nu există dubluri spn pentru serviciul AD FS, deoarece acest lucru poate cauza erori de autentificare intermitente cu AD FS. Listă tabel de SPN, executați SETSPN – L<ServiceAccount></ServiceAccount>.

      Captura de ecran despre Listă tabel de SPN

      Executare SETSPN – O gazdă/AD FSservicename ServiceAccount pentru a adăuga SPN.

      Executare SETSPN – X -F pentru a căuta spn dublate.
    4. UPNs dublate în Active Directory

      Un utilizator să poată autentifica prin AD FS atunci când acestea sunt folosind SAMAccountName dar putea autentifica la utilizarea UPN. În acest scenariu, Active Directory, pot conține două utilizatorii care au același UPN. Este posibil să se termine cu două utilizatorii care au același UPN atunci când utilizatorii sunt adăugate şi modificate prin scripting (ADSIedit, de exemplu).

      Atunci când UPN este utilizat pentru autentificarea în acest scenariu, utilizatorul este autentificat împotriva utilizatorului dublate. De aceea, nu sunt validate acreditările furnizate.

      Puteţi utiliza pentru a verifica dacă există mai multe obiecte în AD care au aceleași valori pentru un atribut interogări ca următoarele:
      Dsquery * forestroot -filter UserPrincipalName=problemuser_UPN

      Asigurați-vă că este redenumit UPN dublate utilizatorului, astfel încât solicitarea de autentificare cu UPN este validat împotriva obiectele corecte.
    5. Într-un scenariu, în cazul în care utilizați adresa de e-mail ca ID de log in în Office 365 și introduceți aceeași adresă de e-mail când sunteți Redirecționați către AD FS pentru autentificarea, autentificarea poate să nu reușească cu o eroare "NO_SUCH_USER" în jurnalele de Audit. Pentru a activa AD FS pentru a găsi un utilizator pentru autentificare prin utilizarea unui atribut decât UPN sau SAMaccountname, trebuie să configurați AD FS pentru a accepta un ID de autentificare alternativă. Pentru mai multe informații, consultați Configurarea ID conectare alternativă.

      AD FS 2012 R2

      1. Instalați Actualizare 2919355.
      2. Actualizarea configuraţiei AD FS executând următoarea cmdlet PowerShell pe oricare din serverele de federalizare în ferma (dacă aveți o fermă uri, trebuie să executați această comandă pe serverul AD FS principală în ferma):

        Set-AdfsClaimsProviderTrust - TargetIdentifier "AD autoritate" - AlternateLoginID <attribute>- LookupForests <forest domain=""></forest> </attribute>

        NotăAlternateLoginID este nume de sign-in LDAP atributul pe care doriți să o utilizați pentru conectare. Și LookupForests este Listă tabel de păduri intrările DNS care aparține utilizatorilor.

        Pentru a activa caracteristica ID de autentificare alternativă, trebuie să configurați atât AlternateLoginID și LookupForests parametrii cu o valoare non-null, validă.

    6. Contul de serviciu AD FS nu are acces de citire a simbolul AD FS este semnarea cheie privată certificat. Pentru a adăuga această permisiune, urmați acești pași:
      1. Atunci când adăugați un certificat de semnare simbol nou, primiți următorul avertisment: "Asigură că cheia privată pentru certificatul alese este accesibil la contul de serviciu pentru acest serviciu Federation pe fiecare server din Uniunea de."
      2. Faceți clic pe Start, faceți clic pe executare, tastați MMC.exe, apoi apăsați Enter.
      3. Faceți clic pe fișierși apoi faceți clic pe Add/Remove Snap-in.
      4. Faceți dublu clic pe certificate.
      5. Selectați contul de computer în cauză și apoi faceți clic pe Următorul.
      6. Selectați computer localși faceți clic pe Terminare.
      7. Extindeți certificate (Local Computer), extindeți <b00> </b00>personalitatel și apoi selectați certificate.
      8. Faceți clic dreapta pe certificat nou simbol semnarea, selectați Toate activitățileși apoi selectați Gestionarea cheilor Private.

        Sceenshot despre Pasul 8
      9. Adăugați acces de citire pentru contul AD FS 2.0 service și apoi faceți clic pe OK.
      10. Închideți certificate MMC.
    7. Opțiunea de Protecție extins pentru autentificare Windows este activat pentru directorul virtual AD FS sau LS. Acest lucru poate provoca probleme cu anumite browsere. Uneori, este posibil să vedeți AD FS solicita în mod repetat acreditările, și acest lucru ar putea fi legată de Protecţie extinsă setare care este activat pentru Windows Authentication pentru aplicație AD FS sau LS în IIS.

      Sceenshot despre Pasul 8
      Când Protecţie extinsă pentru autentificare este activat, solicitările de autentificare sunt legate la ambele nume principale de serviciu (spn) serverului la care clientul încearcă să se conecteze la exterior canal de protocol TLS (TLS) prin care se produce autentificare Windows integrată. Protecţie extinsă îmbunătățește funcționalitatea Windows Authentication existent pentru a diminua autentificare relee sau "man in the middle" atacuri. Cu toate acestea, anumite browsere nu funcționează cu Protecţie extinsă setare; în schimb, se solicită în mod repetat acreditările și apoi refuza accesul. Dezactivarea Protecţie extinsă ajută la este acest scenariu.

      Pentru mai multe informații, consultați AD FS 2.0: Solicitate încontinuu în timpul utilizării Fiddler web debugger.

      AD FS 2012 R2

      Executați cmdletul următoare pentru a dezactiva Extendedprotection:

      Set-ADFSProperties – ExtendedProtectionTokenCheck None

    8. Reguli de autorizare emitere în încredere parte intermediară de încredere (RP) poate refuza accesul utilizatorilor. În AD FS se bazeze terți de încredere, aveți posibilitatea să configurați regulile de emitere autorizare care controlează dacă un utilizator autorizat se eliberează un simbol pentru o parte intermediară de încredere. Administratorii pot utiliza cererile care sunt emise pentru a decide dacă se refuză acorda acces la un utilizator care este membru al unui grup care este scos ca o cerere.

      Dacă anumite utilizatorii federalizați nu se pot autentifica prin AD FS, se recomandă să verificați regulile de emitere autorizare pentru Office 365 RP dacă Permite acorda acces la toți utilizatorii regula este configurată.

      Fotografia despre reguli de ecran
      Dacă această regulă nu este configurat, citi cu atenţie regulile de autorizare particularizată pentru a verifica dacă condiția în această regulă evaluează "true" pentru utilizatorului în cauză. Pentru mai multe informații, consultați următoarele resurse:
      Dacă se poate autentifica la intranet când accesați serverul AD FS direct, dar care nu se pot autentifica la accesarea AD FS prin intermediul unui proxy AD FS, verificați pentru următoarele probleme:
      • Problemă de sincronizare de marcă de timp pe server AD FS și proxy AD FS

        Asigurați-vă că ora de pe serverul AD FS și ora pe proxy sunt sincronizate. La ora de pe serverul AD FS este dezactivată în mod mai mult de cinci minute la ora de pe controlerele de domeniu, apar erori de autentificare. În timpul AD FS proxy nu se sincronizează cu AD FS, încredere proxy este afectat și rupt. De aceea, o solicitare care este distribuit prin proxy AD FS nu reușește.
      • Verificați dacă proxy AD FS încredere cu serviciul AD FS funcționează corect. Dacă suspectați că proxy de încredere se întrerupe, executați din nou configurația proxy.
  5. După ce vă AD FS probleme legate de un simbol, Azure AD sau Office 365 lansează o eroare. În această situație, căutați următoarele probleme:
    • Cererile care sunt emise de AD FS în simbol trebuie să se potrivească atributele respective de utilizator în Azure AD. În simbol pentru Azure AD sau Office 365, cereri următoarele sunt necesare.

      WSFED:
      UPN: Valoarea această solicitare trebuie să corespundă UPN utilizatorilor în Azure AD.
      ImmutableID: Valoarea această solicitare trebuie să se potrivească sourceAnchor sau ImmutableID de utilizator în Azure AD.

      Pentru a obține valoarea atribut utilizator în Azure AD, executaţi următoarea linia Către de comandă: Get-MsolUser – UserPrincipalName<UPN></UPN>

      SAML 2.0:
      IDPEmail: Valoarea această cerere ar trebui să se potrivesc cu nume principal de utilizator utilizatorilor în Azure AD.
      NAMEID: Valoarea această solicitare trebuie să se potrivească sourceAnchor sau ImmutableID de utilizator în Azure AD.

      Pentru mai multe informații, consultați Utilizați un furnizor de identitate SAML 2.0 pentru a implementa sign-on unic.

      Exemple:
      Această problemă poate apărea când UPN de un utilizator sincronizat s-a modificat în AD, dar fără actualizarea directorul online. În acest scenariu, aveți posibilitatea să corectați fie UPN utilizator în AD (pentru a se potrivi nume de sign-in de conecta al utilizatorului asociate) sau executați cmdletul următoare pentru a modifica nume de sign-in de conecta al utilizatorului asociate în directorul Online:

      Set-MsolUserPrincipalName - UserPrincipalName [ExistingUPN] - NewUserPrincipalName [DomainUPN-AD]

      De asemenea, este posibil să fie că utilizați AADsync pentru a sincroniza MAIL ca UPN și EMPID ca SourceAnchor, dar parte intermediară de încredere pretind reguli la nivel de AD FS nu au fost actualizate pentru a trimite MAIL ca UPN și EMPID ca ImmutableID.
    • Există o nepotrivire de certificat de semnare simbol între AD FS și Office 365.

      Aceasta este una dintre cele mai frecvente probleme. AD FS utilizează certificatul semnarea simbol să semneze simbol care este trimis la utilizator sau o aplicație. Încredere între AD FS și Office 365 este o încredere externă care se bazează pe acest certificat de semnare simbol (de exemplu, Office 365 verifică faptul că simbolul primit este semnat utilizând un certificat de semnare simbol Provider pretenție [serviciul AD FS] care se acordă încredere).

      Cu toate acestea, dacă simbolul-semnarea certificat pe AD FS s-a modificat din cauza Auto certificat de comutare sau de un administrator intervenţia (după sau înainte de expirarea certificatului), detalii de noul certificat trebuie să fie actualizate în Office 365 entitate găzduită pentru domeniu federativ. Acest lucru nu se poate întâmpla automat; Acesta poate solicita un admin intervenția. Atunci când este diferit de ceea ce Office 365 cunoaște semnarea simbol primar certificatul AD FS, simbolul emise de AD FS nu are încredere Office 365. De aceea, utilizator federativ nu este permis pentru a face conecta.

      Aveți posibilitatea să utilizați Get-MsolFederationProperty - NumeDomeniu<domain></domain> pentru a dump proprietatea de federalizare AD FS și Office 365. Aici se pot compara amprenta TokenSigningCertificate, pentru a verifica dacă configurația de entitate găzduită Office 365 pentru domeniu federativ este sincronizat cu AD FS. Dacă găsiți o nepotrivire în configurația de certificat de semnare simbol, executaţi următoarea comandă pentru a o actualizare:
      Update-MsolFederatedDomain -DomainName <domain> -SupportMultipleDomain

      De asemenea, executaţi instrumentul următor pentru a programa o activitate pe serverul AD FS, care va monitoriza pentru comutare de Auto-certificat de semnare simbol certificat și actualizare Office 365 un entităţi găzduite automat.

      Microsoft Office 365 instrumentul federalizare de metadate Update automatizare instalare

      Verificați și să gestionați sign-on unic cu AD FS
    • Emitere transformare pretenție reguli pentru Office 365 RP nu sunt configurate corect.

      Într-un scenariu în cazul în care aveți mai multe nume de domenii rădăcină (cele mai frecvente domenii de nivel), ar putea avea probleme de conecta, dacă Supportmultipledomain nu s-a utilizat argumentul când încrederea RP s-a creat și actualizate. Pentru mai multe informații, faceți clic pe aici.
    • Asigurați-vă că criptarea simbol este nu utilizat de AD FS sau STS atunci când un simbol este eliberat Azure AD sau Office 365.
  6. Există acreditări cache învechite în Windows Manager de acreditări.

    Uneori, în timpul de conectare în dintr-o stație de lucru la portalul (sau la utilizarea Outlook), atunci când vi se solicită acreditările, acreditările pot fi salvate pentru țintă (serviciu Office 365 sau AD FS) în managerul de acreditări Windows (Control Panel\User Accounts\Credential Manager). Aceasta ajută la prevenirea linia acreditările de ceva marcă de timp, dar poate provoca o problemă după ce s-a modificat parola de utilizator și managerul de acreditări nu este actualizat. În acest scenariu, învechite acreditări sunt trimise către serviciul AD FS, și, prin urmare, autentificarea nu reușește. Poate ajuta la eliminarea sau actualizarea acreditările memorate în cache, în Windows Manager de acreditări.
  7. Asigurați-vă că Secure Hash Algorithm care este configurată pe se bazeze Party încredere pentru Office 365 este setat la SHA1.

    Încredere între STS/AD FS și Azure AD/Office 365 utilizează protocolul SAML 2.0, Secure Hash Algorithm configurat pentru semnătura digitală trebuie SHA1.
  8. Dacă niciuna dintre cauzele anterior se aplică pentru situația dvs., creați un caz de suport cu Microsoft și puneți-le pentru a verifica dacă contul de utilizator apare în mod constant sub entitate găzduită Office 365. Pentru mai multe informații, consultați următoarele resurse:

    Mesaj de eroare la AD FS 2.0 atunci când un utilizator federativ semne în la Office 365: "a fost o problemă de accesare a site-ul"

    Utilizator federativ se solicită repetat acreditările la el sau ea se conectează la punctul final de AD FS 2.0 serviciu Office 365 sign-in
  9. În funcție de ce serviciu cloud (integrat cu Azure AD) sunt accesarea, solicitarea de autentificare care sunt trimise către AD FS pot varia. De exemplu: anumitor solicitări pot include parametrii suplimentare, cum ar fiWauth sau Wfresh, și acești parametri poate provoca comportamente diferite la nivelul AD FS.

    Se recomandă ca AD FS binare întotdeauna să fie actualizate pentru a include remedieri pentru problemele cunoscute. Pentru mai multe informații despre cele mai recente actualizări, consultați următorul tabel.

Avertisment: acest articol a fost tradus automat

Свойства

Номер статьи: 3079872 — последний просмотр: 08/09/2015 01:50:00 — редакция: 1.0

Windows Server 2008 Datacenter, Windows Server 2008 Enterprise, Windows Server 2008 Foundation, Windows Server 2008 Standard, Windows Server 2008 R2 Datacenter, Windows Server 2008 R2 Enterprise, Windows Server 2008 R2 Foundation, Windows Server 2008 R2 Standard, Windows Server 2012 Foundation, Windows Server 2012 Essentials, Windows Server 2012 Datacenter, Windows Server 2012 Standard, Windows Server 2012 R2 Datacenter, Windows Server 2012 R2 Essentials, Windows Server 2012 R2 Foundation, Windows Server 2012 R2 Standard

  • kbmt KB3079872 KbMtro
Отзывы и предложения