Dela via

Implementera synkronisering av lösenordshash med Microsoft Entra Connect Sync

  • Artikel

Den här artikeln innehåller information som du behöver för att synkronisera dina användarlösenord från en lokal Active Directory-instans till en molnbaserad Microsoft Entra-instans.

Så här fungerar hash-synkronisering

Active Directory-domäntjänsten lagrar lösenord i form av en hashvärderepresentation av det faktiska användarlösenordet. Ett hashvärde är ett resultat av en enkelriktad matematisk funktion (hashalgoritmen). Det finns ingen metod för att återställa resultatet av en enkelriktad funktion till oformaterad textversion av ett lösenord.

För att synkronisera ditt lösenord extraherar Microsoft Entra Connect Sync din lösenordshash från lokal Active Directory-instansen. Extra säkerhetsbearbetning tillämpas på lösenordshash innan den synkroniseras med Microsoft Entra-autentiseringstjänsten. Lösenord synkroniseras per användare och i kronologisk ordning.

Det faktiska dataflödet i synkroniseringsprocessen för lösenordshash liknar synkroniseringen av användardata. Lösenord synkroniseras dock oftare än standardkatalogsynkroniseringsfönstret för andra attribut. Synkroniseringsprocessen för lösenordshash körs var 2:e minut. Du kan inte ändra frekvensen för den här processen. När du synkroniserar ett lösenord skriver det över det befintliga molnlösenordet.

Första gången du aktiverar funktionen för synkronisering av lösenordshash utförs en inledande synkronisering av lösenorden för alla användare inom omfånget. Med stegvis distribution kan du selektivt testa grupper av användare med molnautentiseringsfunktioner som Microsoft Entra multifaktorautentisering, villkorsstyrd åtkomst, Microsoft Entra ID Protection för läckta autentiseringsuppgifter, identitetsstyrning och andra innan du skär över dina domäner. Du kan inte uttryckligen definiera en delmängd av användarlösenord som du vill synkronisera. Men om det finns flera anslutningsappar är det möjligt att inaktivera synkronisering av lösenordshash för vissa anslutningsappar, men inte andra med hjälp av cmdleten Set-ADSyncAPasswordSyncConfiguration .

När du ändrar ett lokalt lösenord synkroniseras det uppdaterade lösenordet, oftast på några minuter. Funktionen för synkronisering av lösenordshash försöker automatiskt synkronisera om misslyckade synkroniseringsförsök. Om ett fel inträffar under ett försök att synkronisera ett lösenord loggas ett fel i loggboken.

Synkroniseringen av ett lösenord påverkar inte den användare som för närvarande är inloggad. Den aktuella molntjänstsessionen påverkas inte omedelbart av en synkroniserad lösenordsändring som sker, när du är inloggad, till en molntjänst. Men när molntjänsten kräver att du autentiserar igen måste du ange ditt nya lösenord.

En användare måste ange sina företagsautentiseringsuppgifter en andra gång för att autentisera till Microsoft Entra-ID, oavsett om de är inloggade i företagets nätverk. Det här mönstret kan dock minimeras om användaren väljer kryssrutan Håll mig inloggad (KMSI) vid inloggningen. Det här valet anger en sessionscookie som kringgår autentisering i 180 dagar. KMSI-beteende kan aktiveras eller inaktiveras av Microsoft Entra-administratören. Dessutom kan du minska antalet frågor om lösenord genom att konfigurera Microsoft Entra-anslutning eller Microsoft Entra-hybridanslutning, som automatiskt loggar in användare när de är på sina företagsenheter som är anslutna till företagets nätverk.

Fler fördelar

  • Vanligtvis är synkronisering av lösenordshash enklare att implementera än en federationstjänst. Det kräver inga fler servrar och eliminerar beroendet av en federationstjänst med hög tillgänglighet för att autentisera användare.
  • Synkronisering av lösenordshash kan också aktiveras utöver federation. Det kan användas som reserv om federationstjänsten drabbas av ett avbrott.

Kommentar

Lösenordssynkronisering stöds endast för objekttypsanvändaren i Active Directory. Det stöds inte för objekttypen iNetOrgPerson.

Detaljerad beskrivning av hur synkronisering av lösenordshash fungerar

I följande avsnitt beskrivs ingående hur synkronisering av lösenordshash fungerar mellan Active Directory och Microsoft Entra ID.

Detaljerat lösenordsflöde

  1. Varannan minut begär synkroniseringsagenten för lösenordshash på AD Connect-servern lagrade lösenordshashvärden (unicodePwd-attributet) från en domänkontrollant. Den här begäran sker via standardprotokollet för MS-DRSR-replikering som används för att synkronisera data mellan domänkontrollanter. AD DS Connector-kontot måste ha behörigheten Replikera katalogändringar och Replikera katalogändringar Alla AD -behörigheter (beviljas som standard vid installationen) för att hämta lösenordshasharna.

  2. Innan du skickar krypterar domänkontrollanten MD4-lösenordshashen med hjälp av en nyckel som är en MD5-hash för RPC-sessionsnyckeln och ett salt. Resultatet skickas sedan till synkroniseringsagenten för lösenordshash via RPC. Domänkontrollanten skickar också saltet till synkroniseringsagenten med hjälp av DC-replikeringsprotokollet, så att agenten kan dekryptera kuvertet.

  3. När synkroniseringsagenten för lösenordshash har det krypterade kuvertet använder den MD5CryptoServiceProvider och saltet för att generera en nyckel för att dekryptera mottagna data tillbaka till sitt ursprungliga MD4-format. Synkroniseringsagenten för lösenordshash har aldrig åtkomst till lösenordet för klartext. Lösenordshashsynkroniseringsagentens användning av MD5 är strikt för replikeringsprotokollkompatibilitet med domänkontrollanten och används endast lokalt mellan domänkontrollanten och synkroniseringsagenten för lösenordshash.

  4. Synkroniseringsagenten för lösenordshash utökar hashvärdet för binärt lösenord med 16 byte till 64 byte genom att först konvertera hashen till en hexadecimal sträng med 32 byte och sedan konvertera den här strängen tillbaka till binär med UTF-16-kodning.

  5. Synkroniseringsagenten för lösenordshash lägger till ett salt per användare, som består av ett salt med 10 bytes längd, till binärfilen på 64 byte för att ytterligare skydda den ursprungliga hashen.

  6. Synkroniseringsagenten för lösenordshash kombinerar sedan MD4-hashen plus per användarsalt och matar in den i PBKDF2-funktionen . 1 000 iterationer av HMAC-SHA256-algoritmen för nyckelbaserad hashning används. Mer information finns i Microsoft Entra White paper.

  7. Synkroniseringsagenten för lösenordshash tar den resulterande hashen på 32 byte, sammanfogar både per användarsalt och antalet SHA256-iterationer till det (för användning av Microsoft Entra-ID) och överför sedan strängen från Microsoft Entra Connect till Microsoft Entra ID via TLS.

  8. När en användare försöker logga in på Microsoft Entra-ID och anger sitt lösenord körs lösenordet via samma MD4+salt+PBKDF2+HMAC-SHA256-process. Om den resulterande hashen matchar den hash som lagras i Microsoft Entra-ID betyder det att användaren har angett rätt lösenord och autentiserats.

Kommentar

Den ursprungliga MD4-hashen överförs inte till Microsoft Entra-ID. I stället överförs SHA256-hashen för den ursprungliga MD4-hashen. Om den hash som lagras i Microsoft Entra-ID hämtas kan den därför inte användas i en lokal pass-the-hash-attack.

Kommentar

Värdet för lösenordshash lagras ALDRIG i SQL. Dessa värden bearbetas endast i minnet innan de skickas till Microsoft Entra-ID.

Säkerhetsfrågor

När lösenord synkroniseras exponeras inte den oformaterade versionen av lösenordet för synkroniseringsfunktionen för lösenordshash, Microsoft Entra-ID eller någon av de associerade tjänsterna.

Användarautentisering sker mot Microsoft Entra i stället för mot organisationens egen Active Directory-instans. SHA256-lösenordsdata som lagras i Microsoft Entra-ID (en hash av den ursprungliga MD4-hashen) är säkrare än vad som lagras i Active Directory. Eftersom sha256-hashen inte kan dekrypteras kan den inte föras tillbaka till organisationens Active Directory-miljö och visas som ett giltigt användarlösenord i en pass-the-hash-attack.

Överväganden för lösenordsprinciper

Det finns två typer av lösenordsprinciper som påverkas av aktivering av synkronisering av lösenordshash:

  • Policy för lösenordskomplexitet
  • Förfalloprincip för lösenord

Policy för lösenordskomplexitet

När synkronisering av lösenordshash är aktiverat åsidosätter principerna för lösenordskomplexitet i din lokal Active Directory instans komplexitetsprinciper i molnet för synkroniserade användare. Du kan använda alla giltiga lösenord från din lokal Active Directory-instans för att få åtkomst till Microsoft Entra-tjänster.

Kommentar

Lösenord för användare som skapas direkt i molnet omfattas fortfarande av lösenordsprinciper enligt definitionen i molnet.

Förfalloprincip för lösenord

Om en användare är inom omfånget för synkronisering av lösenordshash är lösenordet för molnkontot som standard inställt på Upphör aldrig att gälla.

Du kan fortsätta att logga in på dina molntjänster med hjälp av ett synkroniserat lösenord som har upphört att gälla i din lokala miljö. Ditt molnlösenord uppdateras nästa gång du ändrar lösenordet i den lokala miljön.

CloudPasswordPolicyForPasswordSyncedUsersEnabled

Om det finns synkroniserade användare som bara interagerar med Microsoft Entra-integrerade tjänster och måste följa en policy för lösenordsförfallotid kan du tvinga dem att följa din Microsoft Entra-princip för lösenordsförfallotid genom att aktivera funktionen CloudPasswordPolicyForPasswordSyncedUsersEnabled (i den inaktuella MSOnline PowerShell-modulen kallades den EnforceCloudPasswordPolicyForPasswordSyncedUsers).

När CloudPasswordPolicyForPasswordSyncedUsersEnabled är inaktiverat (vilket är standardinställningen) uppdaterar Microsoft Entra Connect attributet PasswordPolicies för synkroniserade användare till "DisablePasswordExpiration". Den här uppdateringen görs varje gång en användares lösenord synkroniseras och instruerar Microsoft Entra-ID att ignorera förfalloprincipen för molnlösenord för användaren. Du kan kontrollera värdet för attributet med hjälp av Microsoft Graph PowerShell-modulen med följande kommando:

(Get-MgUser -UserId <User Object ID> -Property PasswordPolicies).PasswordPolicies

Om du vill aktivera funktionen CloudPasswordPolicyForPasswordSyncedUsersEnabled kör du följande kommandon med hjälp av Graph PowerShell-modulen:

$OnPremSync = Get-MgDirectoryOnPremiseSynchronization
$OnPremSync.Features.CloudPasswordPolicyForPasswordSyncedUsersEnabled = $true

Update-MgDirectoryOnPremiseSynchronization `
  -OnPremisesDirectorySynchronizationId $OnPremSync.Id `
  -Features $OnPremSync.Features

Kommentar

Du måste installera MSGraph PowerShell-modulen för att föregående skript ska fungera. Om du får fel som rör otillräcklig behörighet kontrollerar du att du har godkänt API-omfånget korrekt med hjälp av följande kommando när du ansluter Connect-MgGraph -Scopes "OnPremDirectorySynchronization.ReadWrite.All"

När det är aktiverat går inte Microsoft Entra-ID:t till varje synkroniserad användare för att ta bort DisablePasswordExpiration värdet från attributet PasswordPolicies. DisablePasswordExpiration I stället tas värdet bort från PasswordPolicies under nästa synkronisering av lösenordshash för varje användare vid nästa lösenordsändring i lokal AD.

När funktionen CloudPasswordPolicyForPasswordSyncedUsersEnabled har aktiverats etableras nya användare utan ett PasswordPolicies-värde.

Dricks

Vi rekommenderar att du aktiverar CloudPasswordPolicyForPasswordSyncedUsersEnabled innan du aktiverar synkronisering av lösenordshash, så att den första synkroniseringen av lösenordshasharna inte lägger till DisablePasswordExpiration värdet i attributet PasswordPolicies för användarna.

Standardprincipen för Microsoft Entra-lösenord kräver att användarna ändrar sina lösenord var 90:e dag. Om din princip i AD också är 90 dagar ska de två principerna matcha. Men om AD-principen inte är 90 dagar kan du uppdatera Microsoft Entra-lösenordsprincipen så att den matchar med hjälp av PowerShell-kommandot Update-MgDomain.

Microsoft Entra-ID har stöd för en separat lösenordsförfalloprincip per registrerad domän.

Varning: Om det finns synkroniserade konton som måste ha lösenord som inte krävs i Microsoft Entra-ID måste du uttryckligen DisablePasswordExpiration lägga till värdet i attributet PasswordPolicies för användarobjektet i Microsoft Entra-ID. Du kan lägga till det här värdet genom att köra följande kommando:

Update-MgUser -UserID <User Object ID> -PasswordPolicies "DisablePasswordExpiration"`

Kommentar

För hybridanvändare som har värdet PasswordPolicies inställt DisablePasswordExpirationpå växlar det här värdet till efter att None en lösenordsändring har körts lokalt.

Kommentar

PowerShell-kommandot Update-MgDomain fungerar inte på federerade domäner.

Kommentar

PowerShell-kommandot Update-MgUser fungerar inte på federerade domäner.

Synkroniserar tillfälliga lösenord och "Framtvinga lösenordsändring vid nästa inloggning"

Det är vanligt att tvinga en användare att ändra sitt lösenord under sin första inloggning, särskilt efter att en återställning av administratörslösenord inträffar. Det kallas ofta för att ange ett "tillfälligt" lösenord och slutförs genom att kontrollera flaggan "Användaren måste ändra lösenord vid nästa inloggning" på ett användarobjekt i Active Directory (AD).

Den tillfälliga lösenordsfunktionen hjälper till att säkerställa att överföringen av ägarskapet för autentiseringsuppgifterna slutförs vid första användningen, för att minimera hur lång tid mer än en individ har kunskap om autentiseringsuppgifterna.

Om du vill ha stöd för tillfälliga lösenord i Microsoft Entra-ID för synkroniserade användare kan du aktivera funktionen ForcePasswordChangeOnLogOn genom att köra följande kommandon med hjälp av Graph PowerShell-modulen:

$OnPremSync = Get-MgDirectoryOnPremiseSynchronization
$OnPremSync.Features.UserForcePasswordChangeOnLogonEnabled = $true

Update-MgDirectoryOnPremiseSynchronization `
  -OnPremisesDirectorySynchronizationId $OnPremSync.Id `
  -Features $OnPremSync.Features

Kommentar

En ny användare som skapats i Active Directory med flaggan "Användaren måste ändra lösenord vid nästa inloggning" etableras alltid i Microsoft Entra-ID med en lösenordsprincip för att framtvinga lösenordsändring vid nästa inloggning, oavsett om funktionen ForcePasswordChangeOnLogOn är sant eller falskt. Det här är en intern Microsoft Entra-logik eftersom den nya användaren etableras utan lösenord, medan funktionen ForcePasswordChangeOnLogOn endast påverkar scenarier för administratörslösenordsåterställning.

Om en användare skapades i Active Directory med "Användaren måste ändra lösenord vid nästa inloggning" innan funktionen aktiverades får användaren ett fel när han eller hon loggar in. Åtgärda problemet genom att avmarkera och kontrollera fältet "Användaren måste ändra lösenord vid nästa inloggning" i Active Directory - användare och datorer. När användaren har synkroniserat ändringarna av användarobjektet får användaren den förväntade uppmaningen i Microsoft Entra-ID:t att uppdatera sitt lösenord.

Varning

Du bör bara använda den här funktionen när SSPR och Tillbakaskrivning av lösenord är aktiverade i klientorganisationen. Detta gör att om en användare ändrar sitt lösenord via SSPR synkroniseras det till Active Directory.

Förfallodatum för konto

Om din organisation använder attributet accountExpires som en del av kontohanteringen synkroniseras inte det här attributet med Microsoft Entra-ID. Därför är ett Active Directory-konto som har upphört att gälla i en miljö som konfigurerats för synkronisering av lösenordshash fortfarande aktiv i Microsoft Entra-ID. Vi rekommenderar att du använder ett schemalagt PowerShell-skript som inaktiverar användarnas AD-konton när de upphör att gälla (använd cmdleten Set-ADUser ). Under borttagningen av förfallodatumet från ett AD-konto bör kontot däremot återaktiveras.

Synkronisering av lösenordshash och smartkortsautentisering

Kunder kan kräva att användarna loggar in på Windows-domäner med ett fysiskt CAC/PIV-smartkort. De gör detta genom att konfigurera inställningen Smart Card Required for Interactive Logon (SCRIL) user property (SCRIL) i Active Directory.

När SCRIL är aktiverat på ett användarobjekt randomiseras användarens AD-lösenord av domänkontrollanten till ett värde som ingen vet, och användaren måste registrera och därefter autentisera till Windows-domänen via smartkort.

När synkronisering av lösenordshash är aktiverat synkroniseras denna AD-lösenordshash med Microsoft Entra-ID så att den även kan användas för molnautentisering.

Kommentar

Med versionen av version 2.4.18.0 av Microsoft Entra Connect Sync har vi åtgärdat ett problem som uppstod när SCRIL återaktiveras på ett användarobjekt. Återaktivering av SCRIL är vanligt i scenarier när en användare förlorar sitt smartkort, vilket kräver att SCRIL inaktiveras och att användaren får ett tillfälligt lösenord tills de får ett nytt smartkort

Tidigare, när SCRIL återaktiverades och ett nytt slumpmässigt AD-lösenord genererades, kunde användaren fortfarande använda sitt gamla lösenord för att autentisera till Microsoft Entra-ID. Nu har Connect Sync uppdaterats så att nytt slumpmässigt AD-lösenord synkroniseras med Microsoft Entra-ID och det gamla lösenordet kan inte användas när inloggning med smartkort har aktiverats.

Vi rekommenderar att administratörer utför en fullständig synkronisering om du har användare med en SCRIL-bit i din AD-domän. Om du utför en fullständig synkronisering finns det en chans att slutanvändarna uppmanas att logga in igen med det uppdaterade lösenordet om certifikatbaserad autentisering inte används.

Skriv över synkroniserade lösenord

En administratör kan återställa lösenordet manuellt direkt i Microsoft Entra-ID med hjälp av PowerShell (såvida inte användaren finns i en federerad domän).

I det här fallet åsidosätter det nya lösenordet ditt synkroniserade lösenord och alla lösenordsprinciper som definierats i molnet tillämpas på det nya lösenordet.

Om du ändrar ditt lokala lösenord igen synkroniseras det nya lösenordet till molnet och det åsidosätter det manuellt uppdaterade lösenordet.

Synkroniseringen av ett lösenord påverkar inte den Azure-användare som är inloggad. Den aktuella molntjänstsessionen påverkas inte omedelbart av en synkroniserad lösenordsändring som sker när du är inloggad på en molntjänst. KMSI förlänger varaktigheten för den här skillnaden. När molntjänsten kräver att du autentiserar igen måste du ange ditt nya lösenord.

Synkroniseringsprocessen för lösenordshash för Microsoft Entra Domain Services

Om du använder Microsoft Entra Domain Services för att tillhandahålla äldre autentisering för program och tjänster som behöver använda Kerberos, LDAP eller NTLM är vissa extra processer en del av synkroniseringsflödet för lösenordshash. Microsoft Entra Connect använder följande process för att synkronisera lösenordshashvärden till Microsoft Entra-ID för användning i Microsoft Entra Domain Services:

Viktigt!

Microsoft Entra Connect bör endast installeras och konfigureras för synkronisering med lokala AD DS-miljöer. Det går inte att installera Microsoft Entra Connect i en hanterad Domän för Microsoft Entra Domain Services för att synkronisera objekt tillbaka till Microsoft Entra-ID.

Microsoft Entra Connect synkroniserar bara äldre lösenordshashvärden när du aktiverar Microsoft Entra Domain Services för din Microsoft Entra-klientorganisation. Följande steg används inte om du bara använder Microsoft Entra Connect för att synkronisera en lokal AD DS-miljö med Microsoft Entra-ID.

Om dina äldre program inte använder NTLM-autentisering eller enkla LDAP-bindningar rekommenderar vi att du inaktiverar synkronisering av NTLM-lösenordshash för Microsoft Entra Domain Services. Mer information finns i Inaktivera svaga chiffersviter och hashsynkronisering för NTLM-autentiseringsuppgifter.

  1. Microsoft Entra Connect hämtar den offentliga nyckeln för klientorganisationens instans av Microsoft Entra Domain Services.
  2. När en användare ändrar sitt lösenord lagrar den lokala domänkontrollanten resultatet av lösenordsändringen (hashvärden) i två attribut:
    • unicodePwd för NTLM-lösenordshashen.
    • supplementalCredentials för Kerberos-lösenordshash.
  3. Microsoft Entra Connect identifierar lösenordsändringar via katalogreplikeringskanalen (attributändringar som behöver replikeras till andra domänkontrollanter).
  4. För varje användare vars lösenord har ändrats utför Microsoft Entra Connect följande steg:
    • Genererar en slumpmässig AES 256-bitars symmetrisk nyckel.
    • Genererar en slumpmässig initieringsvektor som behövs för den första krypteringsrundan.
    • Extraherar Kerberos-lösenordshashvärden från attributen supplementalCredentials .
    • Kontrollerar säkerhetskonfigurationsinställningen SyncNtlmPasswords för Microsoft Entra Domain Services.
      • Om den här inställningen är inaktiverad genererar en slumpmässig NTLM-hash med hög entropi (skiljer sig från användarens lösenord). Denna hash kombineras sedan med de exakta Kerberos-lösenordshasharna från attributet supplementalCrendetials till en datastruktur.
      • Om det är aktiverat kombineras värdet för unicodePwd-attributet med de extraherade Kerberos-lösenordshasherna från attributet supplementalCredentials till en datastruktur.
    • Krypterar den enskilda datastrukturen med hjälp av den symmetriska AES-nyckeln.
    • Krypterar den symmetriska AES-nyckeln med klientorganisationens offentliga nyckel Microsoft Entra Domain Services.
  5. Microsoft Entra Connect överför den krypterade AES-symmetriska nyckeln, den krypterade datastrukturen som innehåller lösenordshasherna och initieringsvektorn till Microsoft Entra ID.
  6. Microsoft Entra ID lagrar den krypterade AES-symmetriska nyckeln, den krypterade datastrukturen och initieringsvektorn för användaren.
  7. Microsoft Entra ID push-överför den krypterade AES-symmetriska nyckeln, den krypterade datastrukturen och initieringsvektorn med hjälp av en intern synkroniseringsmekanism över en krypterad HTTP-session till Microsoft Entra Domain Services.
  8. Microsoft Entra Domain Services hämtar den privata nyckeln för klientorganisationens instans från Azure Key Vault.
  9. För varje krypterad uppsättning data (som representerar en enskild användares lösenordsändring) utför Microsoft Entra Domain Services sedan följande steg:
    • Använder sin privata nyckel för att dekryptera den symmetriska AES-nyckeln.
    • Använder den symmetriska AES-nyckeln med initieringsvektorn för att dekryptera den krypterade datastrukturen som innehåller lösenordshasherna.
    • Skriver kerberos-lösenordshashar som det tar emot till Domänkontrollanten för Microsoft Entra Domain Services. Hashvärdena sparas i användarobjektets supplementalCredentials-attribut som krypteras till Microsoft Entra Domain Services-domänkontrollantens offentliga nyckel.
    • Microsoft Entra Domain Services skriver den NTLM-lösenordshash som den fick till domänkontrollanten Microsoft Entra Domain Services. Hashen sparas i användarobjektets unicodePwd-attribut som krypteras till Domänkontrollantens offentliga nyckel för Microsoft Entra Domain Services.

Aktivera hashsynkronisering för lösenord

Viktigt!

Om du migrerar från AD FS (eller andra federationstekniker) till Synkronisering av lösenordshash kan du visa Resurser för att migrera program till Microsoft Entra-ID.

När du installerar Microsoft Entra Connect med alternativet Expressinställningar aktiveras synkronisering av lösenordshash automatiskt. Mer information finns i Komma igång med Microsoft Entra Connect med expressinställningar.

Om du använder anpassade inställningar när du installerar Microsoft Entra Connect är synkronisering av lösenordshash tillgänglig på användarens inloggningssida. Mer information finns i Anpassad installation av Microsoft Entra Connect.

Aktivera synkronisering av lösenordshash

Synkronisering av lösenordshash och FIPS

Om servern är låst enligt FIPS (Federal Information Processing Standard) inaktiveras MD5.

Utför följande steg för att aktivera MD5 för synkronisering av lösenordshash:

  1. Gå till %programfiles%\Microsoft Azure AD Sync\Bin.
  2. Öppna miiserver.exe.config.
  3. Gå till noden configuration/runtime i slutet av filen.
  4. Lägg till följande nod: <enforceFIPSPolicy enabled="false" />
  5. Spara dina ändringar.
  6. Starta om för att ändringarna ska börja gälla.

Som referens är det här kodfragmentet hur det ska se ut:

    <configuration>
        <runtime>
            <enforceFIPSPolicy enabled="false" />
        </runtime>
    </configuration>

Information om säkerhet och FIPS finns i Microsoft Entra-synkronisering av lösenordshash, kryptering och FIPS-efterlevnad.

Felsöka synkronisering av lösenordshash

Om du har problem med synkronisering av lösenordshash läser du Felsöka synkronisering av lösenordshash.

Nästa steg