Det här avsnittet innehåller svar på många vanliga frågor om Microsoft Entra Password Protection.
Allmänna frågor
Vilken vägledning bör användarna få om hur de väljer ett säkert lösenord?
Microsofts aktuella vägledning om det här avsnittet finns på följande länk:
Vägledning för Microsofts lösenord
Stöds lokalt Microsoft Entra-lösenordsskydd i icke-offentliga moln?
Lokalt Microsoft Entra Password Protection stöds i både Azure Global- och Azure Government-moln.
Administrationscentret för Microsoft Entra tillåter ändring av den lokala konfigurationen "Lösenordsskydd för Windows Server Active Directory" även i moln som inte stöds. sådana ändringar kommer att bevaras, men annars börjar de aldrig gälla. Registrering av lokala proxyagenter eller skogar stöds inte i moln som inte stöds, och sådana registreringsförsök misslyckas alltid.
Hur kan jag tillämpa Microsoft Entra-lösenordsskyddsförmåner på en delmängd av mina lokala användare?
Stöds ej. När microsoft Entra-lösenordsskydd har distribuerats och aktiverats diskrimineras inte – alla användare får lika säkerhetsförmåner.
Vad är skillnaden mellan en lösenordsändring och en lösenordsuppsättning (eller återställning)?
En lösenordsändring är när en användare väljer ett nytt lösenord efter att ha bevisat att de har kunskap om det gamla lösenordet. En lösenordsändring är till exempel vad som händer när en användare loggar in i Windows och sedan uppmanas att välja ett nytt lösenord.
En lösenordsuppsättning (kallas ibland för lösenordsåterställning) är när en administratör ersätter lösenordet för ett konto med ett nytt lösenord, till exempel med hjälp av hanteringsverktyget Active Directory - användare och datorer. Den här åtgärden kräver en hög behörighetsnivå (vanligtvis domänadministratör) och den person som utför åtgärden har vanligtvis inte kunskap om det gamla lösenordet. Supportscenarier utför ofta lösenordsuppsättningar, till exempel när du hjälper en användare som har glömt sitt lösenord. Du kommer också att se händelser för lösenordsuppsättningar när ett helt nytt användarkonto skapas för första gången med ett lösenord.
Principen för lösenordsverifiering fungerar på samma sätt oavsett om en lösenordsändring eller en uppsättning görs. Tjänsten Microsoft Entra Password Protection DC Agent loggar olika händelser för att informera dig om en lösenordsändring eller en uppsättningsåtgärd har utförts. Se Övervakning och loggning av Microsoft Entra-lösenordsskydd.
Verifierar Microsoft Entra Password Protection befintliga lösenord när de har installerats?
Nej – Microsoft Entra Password Protection kan bara framtvinga lösenordsprinciper i klartext under en lösenordsändring eller en uppsättningsåtgärd. När ett lösenord har godkänts av Active Directory sparas endast autentiseringsprotokollspecifika hashvärden för lösenordet. Lösenordet för klartext sparas aldrig, därför kan Microsoft Entra Password Protection inte verifiera befintliga lösenord.
Efter den första distributionen av Microsoft Entra Password Protection börjar alla användare och konton så småningom använda ett Microsoft Entra Password Protection-verifierat lösenord eftersom deras befintliga lösenord upphör att gälla normalt över tid. Om du vill kan den här processen påskyndas genom att lösenord för användarkonton upphör att gälla en gång.
Konton som har konfigurerats med "lösenordet upphör aldrig att gälla" kommer aldrig att tvingas ändra sitt lösenord om inte manuell förfallotid har gjorts.
Varför loggas duplicerade lösenordsavslagshändelser när du försöker ange ett svagt lösenord med hjälp av snapin-modulen Active Directory - användare och datorer hantering?
Snapin-modulen för Active Directory - användare och datorer-hantering försöker först ange det nya lösenordet med hjälp av Kerberos-protokollet. Vid fel gör snapin-modulen ett andra försök att ange lösenordet med hjälp av ett äldre protokoll (SAM RPC) (de specifika protokoll som används är inte viktiga). Om det nya lösenordet anses vara svagt av Microsoft Entra Password Protection resulterar det här snapin-beteendet i att två uppsättningar av avslagshändelser för lösenordsåterställning loggas.
Varför loggas lösenordsvalideringshändelser för Microsoft Entra-lösenordsskydd med ett tomt användarnamn?
Active Directory stöder möjligheten att testa ett lösenord för att se om det uppfyller domänens aktuella krav på lösenordskomplexitet, till exempel med hjälp av Api:et NetValidatePasswordPolicy . När ett lösenord verifieras på det här sättet innehåller testningen även validering av lösenordsfilter-dll-baserade produkter som Microsoft Entra Password Protection – men användarnamnen som skickas till en angiven dll för lösenordsfilter är tomma. I det här scenariot validerar Microsoft Entra Password Protection fortfarande lösenordet med hjälp av den lösenordsprincip som för närvarande tillämpas och utfärdar ett händelseloggmeddelande för att avbilda resultatet, men händelseloggmeddelandet har tomma användarnamnsfält.
Jag har hybridanvändare som försöker ändra sitt lösenord i Microsoft Entra-ID och får svaret "Vi har sett lösenordet för många gånger tidigare. Välj något som är svårare att gissa." I det här fallet kan jag se ett verifieringsförsök lokalt?
När en hybridanvändare ändrar sitt lösenord i Microsoft Entra-ID, antingen via Microsoft Entra SSPR, MyAccount eller någon annan Microsoft Entra-mekanism för lösenordsändring, utvärderas deras lösenord mot de globala och anpassade listor över förbjudna lösenord i molnet. När lösenordet når Active Directory via tillbakaskrivning av lösenord har det redan verifierats i Microsoft Entra-ID.
Lösenordsåterställningar och ändringar som initieras i Microsoft Entra-ID som misslyckas med validering för hybridanvändare finns i Microsoft Entra-granskningsloggarna. Se Felsöka lösenordsåterställning med självbetjäning i Microsoft Entra-ID.
Stöds det att installera Microsoft Entra Password Protection sida vid sida med andra lösenordsfilterbaserade produkter?
Ja. Stöd för flera registrerade dll-filer för lösenordsfilter är en viktig Windows-funktion och är inte specifikt för Microsoft Entra Password Protection. Alla registrerade lösenordsfilter-dll:er måste överensstämma innan ett lösenord godkänns.
Hur kan jag distribuera och konfigurera Microsoft Entra-lösenordsskydd i min Active Directory-miljö utan att använda Azure?
Stöds ej. Microsoft Entra Password Protection är en Azure-funktion som har stöd för att utökas till en lokal Active Directory miljö.
Hur ändrar jag innehållet i principen på Active Directory-nivå?
Stöds ej. Principen kan endast administreras med hjälp av administrationscentret för Microsoft Entra. Se även föregående fråga.
Varför krävs DFSR för sysvol-replikering?
FRS (föregående teknik till DFSR) har många kända problem och stöds inte helt i nyare versioner av Windows Server Active Directory. Ingen testning av Microsoft Entra Password Protection görs på FRS-konfigurerade domäner.
Mer information finns i följande artiklar:
Fallet för migrering av sysvol-replikering till DFSR
Om din domän inte redan använder DFSR måste du migrera den för att använda DFSR innan du installerar Microsoft Entra Password Protection. Mer information finns i följande länk:
Migreringsguide för SYSVOL Replication: FRS till DFS Replication
Varning
Programvaran Microsoft Entra Password Protection DC Agent installeras för närvarande på domänkontrollanter i domäner som fortfarande använder FRS för sysvol-replikering, men programvaran fungerar inte korrekt i den här miljön. Ytterligare negativa biverkningar inkluderar enskilda filer som inte kan replikeras och sysvol-återställningsprocedurer som verkar lyckas men misslyckas tyst med att replikera alla filer. Du bör migrera din domän för att använda DFSR så snart som möjligt, både för DFSR:s inneboende fördelar och för att avblockera distributionen av Microsoft Entra Password Protection. Framtida versioner av programvaran inaktiveras automatiskt när de körs i en domän som fortfarande använder FRS.
Hur mycket diskutrymme kräver funktionen på domänens sysvol-resurs?
Den exakta utrymmesanvändningen varierar eftersom den beror på faktorer som antalet och längden på de förbjudna token i Microsofts globala lista över förbjudna token och den anpassade listan per klient, plus krypteringskostnader. Innehållet i dessa listor kommer sannolikt att växa i framtiden. Med det i åtanke är en rimlig förväntan att funktionen behöver minst fem (5) megabyte utrymme på domänens sysvol-resurs.
Varför krävs en omstart för att installera eller uppgradera DC-agentprogramvaran?
Det här kravet orsakas av grundläggande Windows-beteende.
Finns det något sätt att konfigurera en DC-agent att använda en specifik proxyserver?
Nej. Eftersom proxyservern är tillståndslös är det inte viktigt vilken specifik proxyserver som används.
Är det okej att distribuera Tjänsten Microsoft Entra Password Protection Proxy sida vid sida med andra tjänster som Microsoft Entra Anslut?
Ja. Microsoft Entra-tjänsten för lösenordsskydd och Microsoft Entra-Anslut bör aldrig vara i direkt konflikt med varandra.
Tyvärr har en inkompatibilitet hittats mellan versionen av Microsoft Entra Anslut Agent Updater-tjänsten som installeras av Microsoft Entra Password Protection Proxy-programvaran och den version av tjänsten som installeras av Microsoft Entra-programproxyprogramvaran. Den här inkompatibiliteten kan leda till att Agent Updater-tjänsten inte kan kontakta Azure för programuppdateringar. Vi rekommenderar inte att du installerar Microsoft Entra Password Protection Proxy och Microsoft Entra-programproxy på samma dator.
I vilken ordning ska DC-agenter och proxyservrar installeras och registreras?
All beställning av proxyagentinstallation, DC-agentinstallation, skogsregistrering och proxyregistrering stöds.
Bör jag oroa mig för prestandan på mina domänkontrollanter när jag distribuerar den här funktionen?
Tjänsten Microsoft Entra Password Protection DC Agent bör inte avsevärt påverka domänkontrollantens prestanda i en befintlig felfri Active Directory-distribution.
För de flesta Active Directory-distributioner är lösenordsändringsåtgärder en liten del av den totala arbetsbelastningen på en viss domänkontrollant. Tänk dig till exempel en Active Directory-domän med 1 0000 användarkonton och en MaxPasswordAge-princip inställd på 30 dagar. I genomsnitt ser den här domänen 10000/30=~333 lösenordsändringsåtgärder varje dag, vilket är ett mindre antal åtgärder för även en enda domänkontrollant. Tänk dig ett potentiellt värsta scenario: anta att dessa ~333 lösenordsändringar på en enskild domänkontrollant gjordes under en enda timme. Det här scenariot kan till exempel inträffa när många anställda alla kommer till jobbet en måndagsmorgon. Även i det fallet tittar vi fortfarande på ~333/60 minuter = sex lösenordsändringar per minut, vilket återigen inte är en betydande belastning.
Men om dina aktuella domänkontrollanter redan körs på prestandabegränsade nivåer (t.ex. maxat med avseende på PROCESSOR, diskutrymme, disk-I/O och så vidare) rekommenderar vi att du lägger till ytterligare domänkontrollanter eller utökar tillgängligt diskutrymme innan du distribuerar den här funktionen. Se även frågan ovan om användning av sysvol-diskutrymme ovan.
Jag vill testa Microsoft Entra Password Protection på bara några domänkontrollanter i min domän. Är det möjligt att tvinga ändringar av användarlösenord att använda dessa specifika domänkontrollanter?
Nej. Windows-klientoperativsystemet styr vilken domänkontrollant som används när en användare ändrar sitt lösenord. Domänkontrollanten väljs baserat på faktorer som Active Directory-plats- och undernätstilldelningar, miljöspecifik nätverkskonfiguration och så vidare. Microsoft Entra Password Protection styr inte dessa faktorer och kan inte påverka vilken domänkontrollant som väljs för att ändra en användares lösenord.
Ett sätt att delvis nå det här målet är att distribuera Microsoft Entra Password Protection på alla domänkontrollanter på en viss Active Directory-plats. Den här metoden ger rimlig täckning för De Windows-klienter som är tilldelade till den webbplatsen, och därför även för de användare som loggar in på dessa klienter och ändrar sina lösenord.
Om jag installerar Tjänsten Microsoft Entra Password Protection DC Agent på bara den primära domänkontrollanten (PDC), kommer alla andra domänkontrollanter i domänen också att skyddas?
Nej. När en användares lösenord ändras på en viss icke-PDC-domänkontrollant skickas lösenordet med klartext aldrig till PDC (den här idén är en vanlig missuppfattning). När ett nytt lösenord har godkänts på en viss domänkontrollant använder domänkontrollanten lösenordet för att skapa de olika autentiseringsprotokollspecifika hashvärdena för lösenordet och bevarar sedan dessa hashvärden i katalogen. Lösenordet för klartext sparas inte. De uppdaterade hashvärdena replikeras sedan till PDC. Användarlösenord kan i vissa fall ändras direkt på PDC, återigen beroende på olika faktorer som nätverkstopologi och Active Directory-webbplatsdesign. (Se föregående fråga.)
Sammanfattningsvis krävs distribution av Tjänsten Microsoft Entra Password Protection DC Agent på PDC för att nå 100 % säkerhetstäckning för funktionen i hela domänen. Att distribuera funktionen på PDC ger inte microsoft entra-säkerhetsförmåner för lösenordsskydd för andra domänkontrollanter.
Varför fungerar inte anpassad smart utelåsning även efter att agenterna har installerats i min lokal Active Directory miljö?
Anpassad smart utelåsning stöds endast i Microsoft Entra-ID. Ändringar i de anpassade inställningarna för smart utelåsning i administrationscentret för Microsoft Entra påverkar inte lokal Active Directory miljön, inte ens med agenterna installerade.
Är ett System Center Operations Manager-hanteringspaket tillgängligt för Microsoft Entra Password Protection?
Nej.
Varför avvisar Microsoft Entra-ID fortfarande svaga lösenord trots att jag har konfigurerat principen att vara i granskningsläge?
Granskningsläget stöds endast i lokal Active Directory miljö. Microsoft Entra-ID är implicit alltid i "framtvinga"-läge när lösenord utvärderas.
Mina användare ser det traditionella Windows-felmeddelandet när ett lösenord avvisas av Microsoft Entra Password Protection. Går det att anpassa det här felmeddelandet så att användarna vet vad som verkligen hände?
Nej. Felmeddelandet som visas av användare när ett lösenord avvisas av en domänkontrollant styrs av klientdatorn, inte av domänkontrollanten. Det här beteendet inträffar om ett lösenord avvisas av standardprinciperna för Active Directory-lösenord eller av en lösenordsfilterbaserad lösning som Microsoft Entra Password Protection.
Procedurer för lösenordstestning
Du kanske vill göra några grundläggande tester av olika lösenord för att verifiera korrekt drift av programvaran och få en bättre förståelse för algoritmen för lösenordsutvärdering. I det här avsnittet beskrivs en metod för sådan testning som är utformad för att ge upprepningsbara resultat.
Varför är det nödvändigt att följa sådana steg? Det finns flera faktorer som gör det svårt att utföra kontrollerad, repeterbar testning av lösenord i den lokal Active Directory miljön:
- Lösenordsprincipen konfigureras och bevaras i Azure, och kopior av principen synkroniseras regelbundet av de lokala DC-agenterna med hjälp av en avsökningsmekanism. Svarstiden i den här avsökningscykeln kan orsaka förvirring. Om du till exempel konfigurerar principen i Azure men glömmer att synkronisera den med DC-agenten kanske dina tester inte ger de förväntade resultaten. Avsökningsintervallet är för närvarande hårdkodat till en gång per timme, men att vänta en timme mellan principändringar är inte idealiskt för ett interaktivt testscenario.
- När en ny lösenordsprincip har synkroniserats ned till en domänkontrollant sker mer svarstid medan den replikeras till andra domänkontrollanter. Dessa fördröjningar kan orsaka oväntade resultat om du testar en lösenordsändring mot en domänkontrollant som ännu inte har fått den senaste versionen av principen.
- Att testa lösenordsändringar via ett användargränssnitt gör det svårt att ha förtroende för dina resultat. Det är till exempel enkelt att feltypa ett ogiltigt lösenord i ett användargränssnitt, särskilt eftersom de flesta lösenordsanvändargränssnitt döljer användarindata (till exempel Windows Ctrl-Alt-Delete –> Ändra lösenordsgränssnittet).
- Det går inte att strikt kontrollera vilken domänkontrollant som används vid testning av lösenordsändringar från domänanslutna klienter. Windows-klientoperativsystemet väljer en domänkontrollant baserat på faktorer som Active Directory-plats- och undernätstilldelningar, miljöspecifik nätverkskonfiguration och så vidare.
För att undvika dessa problem baseras stegen nedan på kommandoradstestning av lösenordsåterställningar när de är inloggade på en domänkontrollant.
Varning
Dessa procedurer bör endast användas i en testmiljö eftersom alla inkommande lösenordsändringar och återställningar godkänns utan validering medan DC-agenttjänsten stoppas, och även för att undvika de ökade riskerna med att logga in på en domänkontrollant.
Följande steg förutsätter att du har installerat DC-agenten på minst en domänkontrollant, har installerat minst en proxy och har registrerat både proxyn och skogen.
Logga in på en domänkontrollant med autentiseringsuppgifter för domänadministratör (eller andra autentiseringsuppgifter som har tillräcklig behörighet för att skapa testanvändarkonton och återställa lösenord), som har dc-agentprogramvaran installerad och har startats om.
Öppna Loggboken och gå till händelseloggen för dc-agentadministratören.
Öppna ett fönster för upphöjd kommandotolk.
Skapa ett testkonto för att utföra lösenordstestning
Det finns många sätt att skapa ett användarkonto, men ett kommandoradsalternativ erbjuds här som ett sätt att göra det enkelt under repetitiva testcykler:
net.exe user <testuseraccountname> /add <password>I diskussionssyfte nedan förutsätter vi att vi har skapat ett testkonto med namnet "ContosoUser", till exempel:
net.exe user ContosoUser /add <password>Logga in på administrationscentret för Microsoft Entra som minst autentiseringsadministratör.
Bläddra till Skydd > Autentiseringsmetoder > Lösenordsskydd.
Ändra Microsoft Entra-lösenordsskyddsprincipen efter behov för testningen som du vill utföra. Du kan till exempel välja att konfigurera antingen Framtvingat läge eller Granskningsläge, eller så kan du välja att ändra listan över förbjudna termer i listan över anpassade förbjudna lösenord.
Synkronisera den nya principen genom att stoppa och starta om DC-agenttjänsten.
Det här steget kan utföras på olika sätt. Ett sätt är att använda administrationskonsolen för tjänsthantering genom att högerklicka på tjänsten Microsoft Entra Password Protection DC Agent och välja "Starta om". Ett annat sätt kan utföras från kommandotolken så här:
net stop AzureADPasswordProtectionDCAgent && net start AzureADPasswordProtectionDCAgentKontrollera Loggboken för att kontrollera att en ny princip har laddats ned.
Varje gång DC-agenttjänsten stoppas och startas bör du se två 30006-händelser som utfärdas i nära följd. Den första händelsen 30006 återspeglar principen som cachelagrades på disken i sysvol-resursen. Den andra händelsen 30006 (om den finns) bör ha ett uppdaterat datum för klientprincipen och i så fall återspeglas principen som laddades ned från Azure. Datumvärdet för klientprincipen är för närvarande kodat för att visa den ungefärliga tidsstämpel som principen laddades ned från Azure.
Om den andra 30006-händelsen inte visas bör du felsöka problemet innan du fortsätter.
Händelserna 30006 ser ut ungefär som i det här exemplet:
The service is now enforcing the following Azure password policy. Enabled: 1 AuditOnly: 0 Global policy date: 2018-05-15T00:00:00.000000000Z Tenant policy date: 2018-06-10T20:15:24.432457600Z Enforce tenant policy: 1Om du till exempel ändrar mellan Framtvingat läge och Granskningsläge kommer flaggan AuditOnly att ändras (principen ovan med AuditOnly=0 är i framtvingat läge); Ändringar i listan över anpassade förbjudna lösenord återspeglas inte direkt i 30006-händelsen ovan (och loggas inte någon annanstans av säkerhetsskäl). Om du laddar ned principen från Azure efter en sådan ändring inkluderas även listan med ändrade anpassade förbjudna lösenord.
Kör ett test genom att försöka återställa ett nytt lösenord på testanvändarkontot.
Det här steget kan utföras från kommandotolken så här:
net.exe user ContosoUser <password>När du har kört kommandot kan du få mer information om resultatet av kommandot genom att titta i loggboken. Händelser för lösenordsvalideringsutfall dokumenteras i händelseloggen för DC Agent Admin. Du kommer att använda sådana händelser för att verifiera resultatet av testet utöver de interaktiva utdata från net.exe-kommandona.
Låt oss prova ett exempel: försök att ange ett lösenord som är förbjudet av Microsofts globala lista (observera att listan inte är dokumenterad men vi kan testa här mot en känd förbjuden term). Det här exemplet förutsätter att du har konfigurerat principen i framtvingat läge och har lagt till noll termer i listan över anpassade förbjudna lösenord.
net.exe user ContosoUser PassWord The password does not meet the password policy requirements. Check the minimum password length, password complexity and password history requirements. More help is available by typing NET HELPMSG 2245.Eftersom vårt test var en lösenordsåterställningsåtgärd i dokumentationen bör du se en 10017- och 30005-händelse för ContosoUser-användaren.
Händelsen 10017 bör se ut så här:
The reset password for the specified user was rejected because it did not comply with the current Azure password policy. Please see the correlated event log message for more details. UserName: ContosoUser FullName:Händelsen 30005 bör se ut så här:
The reset password for the specified user was rejected because it matched at least one of the tokens present in the Microsoft global banned password list of the current Azure password policy. UserName: ContosoUser FullName:Det var kul - låt oss prova ett annat exempel! Den här gången försöker vi ange ett lösenord som är förbjudet i listan över förbjudna lösenord medan principen är i granskningsläge. Det här exemplet förutsätter att du har gjort följande steg: konfigurerat principen så att den är i granskningsläge, lagt till termen "lachrymose" i listan över anpassade förbjudna lösenord och synkroniserat den resulterande nya principen till domänkontrollanten genom att cykla dc-agenttjänsten enligt beskrivningen ovan.
Ange en variant av det förbjudna lösenordet:
net.exe user ContosoUser LaChRymoSE!1 The command completed successfully.Kom ihåg att den här gången lyckades den eftersom principen är i granskningsläge. Du bör se en 10025- och 30007-händelse för ContosoUser-användaren.
Händelsen 10025 bör se ut så här:
The reset password for the specified user would normally have been rejected because it did not comply with the current Azure password policy. The current Azure password policy is configured for audit-only mode so the password was accepted. Please see the correlated event log message for more details. UserName: ContosoUser FullName:Händelsen 30007 bör se ut så här:
The reset password for the specified user would normally have been rejected because it matches at least one of the tokens present in the per-tenant banned password list of the current Azure password policy. The current Azure password policy is configured for audit-only mode so the password was accepted. UserName: ContosoUser FullName:Fortsätt att testa olika lösenord och kontrollera resultatet i loggboken med hjälp av de procedurer som beskrivs i föregående steg. Om du behöver ändra principen i administrationscentret för Microsoft Entra ska du inte glömma att synkronisera den nya principen till DC-agenten enligt beskrivningen tidigare.
Vi har gått igenom procedurer som gör att du kan utföra kontrollerad testning av Microsoft Entra Password Protections lösenordsverifieringsbeteende. Att återställa användarlösenord från kommandoraden direkt på en domänkontrollant kan tyckas vara ett konstigt sätt att utföra sådana tester, men som beskrivits tidigare är det utformat för att ge upprepningsbara resultat. När du testar olika lösenord bör du ha algoritmen för lösenordsutvärdering i åtanke eftersom det kan hjälpa dig att förklara resultat som du inte förväntade dig.
Varning
När alla tester har slutförts glöm inte att ta bort användarkonton som skapats i testsyfte!
Ytterligare innehåll
Följande länkar är inte en del av microsoft Entras grundläggande dokumentation om lösenordsskydd, men kan vara en användbar källa till ytterligare information om funktionen.
Microsoft Entra Password Protection är nu allmänt tillgängligt!
Microsoft Entra Password Protection och Smart Lockout finns nu i offentlig förhandsversion!
Microsoft Premier\Unified-supportutbildning tillgänglig
Om du är intresserad av att lära dig mer om Microsoft Entra Password Protection och distribuera det i din miljö kan du dra nytta av en proaktiv Microsoft-tjänst som är tillgänglig för dessa kunder med ett Premier- eller Unified-supportavtal. Tjänsten heter Microsoft Entra ID: Password Protection. Kontakta kundframgångskontohanteraren för mer information.
Nästa steg
Om du har en lokal Microsoft Entra-lösenordsskyddsfråga som inte besvaras här skickar du ett feedbackobjekt nedan – tack!