Veelgestelde vragen over Microsoft Entra Password Protection on-premises

Welke richtlijnen moeten gebruikers krijgen over het selecteren van een beveiligd wachtwoord?

De huidige richtlijnen van Microsoft over dit onderwerp vindt u op de volgende koppeling:

Richtlijnen voor Microsoft-wachtwoorden

Wordt on-premises Microsoft Entra Password Protection ondersteund in niet-openbare clouds?

On-premises Microsoft Entra Password Protection wordt ondersteund in zowel Azure Global- als Azure Government-clouds.

Het Microsoft Entra-beheercentrum staat het wijzigen van de on-premises specifieke configuratie voor wachtwoordbeveiliging voor Windows Server Active Directory toe, zelfs in niet-ondersteunde clouds; dergelijke wijzigingen blijven behouden, maar anders wordt dit nooit van kracht. De registratie van on-premises proxyagents of forests wordt niet ondersteund in niet-ondersteunde clouds en dergelijke registratiepogingen mislukken altijd.

Hoe kan ik de voordelen van Microsoft Entra Password Protection toepassen op een subset van mijn on-premises gebruikers?

Wordt niet ondersteund. Zodra Microsoft Entra Password Protection is geïmplementeerd en ingeschakeld, worden deze niet gediscrimineerd. Alle gebruikers krijgen gelijke beveiligingsvoordelen.

Wat is het verschil tussen een wachtwoordwijziging en een wachtwoordset (of opnieuw instellen)?

Een wachtwoordwijziging is wanneer een gebruiker een nieuw wachtwoord kiest nadat wordt aangetoond dat hij of zij kennis heeft van het oude wachtwoord. Een wachtwoordwijziging gebeurt bijvoorbeeld wanneer een gebruiker zich aanmeldt bij Windows en vervolgens wordt gevraagd een nieuw wachtwoord te kiezen.

Een wachtwoordset (ook wel een wachtwoord opnieuw instellen genoemd) is wanneer een beheerder het wachtwoord voor een account vervangt door een nieuw wachtwoord, bijvoorbeeld met behulp van het hulpprogramma voor Active Directory beheer. Deze bewerking vereist een hoog bevoegdheidsniveau (meestal domein Beheer) en de persoon die de bewerking uitvoert, heeft meestal geen kennis van het oude wachtwoord. Helpdeskscenario's voeren vaak wachtwoordsets uit, bijvoorbeeld bij het helpen van een gebruiker die zijn wachtwoord is vergeten. U ziet ook gebeurtenissen voor het instellen van wachtwoorden wanneer er voor het eerst een nieuw gebruikersaccount wordt gemaakt met een wachtwoord.

Het wachtwoordvalidatiebeleid gedraagt zich hetzelfde, ongeacht of een wachtwoordwijziging of -set wordt uitgevoerd. De Microsoft Entra Password Protection DC Agent-service registreert verschillende gebeurtenissen om u te informeren of er een wachtwoordwijziging of een ingestelde bewerking is uitgevoerd. Zie Bewaking en logboekregistratie van Microsoft Entra Password Protection.

Valideert Microsoft Entra Password Protection bestaande wachtwoorden nadat deze zijn geïnstalleerd?

Nee: Microsoft Entra Password Protection kan alleen wachtwoordbeleid afdwingen bij wachtwoorden zonder tekst tijdens een wachtwoordwijziging of een ingestelde bewerking. Zodra een wachtwoord is geaccepteerd door Active Directory, worden alleen verificatieprotocolspecifieke hashes van dat wachtwoord behouden. Het wachtwoord zonder tekst wordt nooit behouden, daarom kan Microsoft Entra Password Protection bestaande wachtwoorden niet valideren.

Na de eerste implementatie van Microsoft Entra-wachtwoordbeveiliging zullen alle gebruikers en accounts uiteindelijk een door Microsoft Entra-wachtwoordbeveiliging gevalideerd wachtwoord gebruiken, omdat hun bestaande wachtwoorden na verloop van tijd normaal verlopen. Indien gewenst kan dit proces worden versneld door een eenmalige handmatige vervaldatum van wachtwoorden voor gebruikersaccounts.

Accounts die zijn geconfigureerd met 'wachtwoord verlopen nooit' worden nooit gedwongen hun wachtwoord te wijzigen, tenzij handmatige vervaldatum is voltooid.

Waarom worden dubbele gebeurtenissen voor het afwijzen van wachtwoorden geregistreerd wanneer u probeert een zwak wachtwoord in te stellen met behulp van de module Active Directory-beheer?

De Active Directory beheermodule probeert eerst het nieuwe wachtwoord in te stellen met behulp van het Kerberos-protocol. Bij een fout wordt met de module een tweede poging gedaan om het wachtwoord in te stellen met behulp van een verouderd (SAM RPC)-protocol (de gebruikte specifieke protocollen zijn niet belangrijk). Als het nieuwe wachtwoord als zwak wordt beschouwd door Microsoft Entra Password Protection, resulteert dit modulegedrag in twee sets afwijzingsgebeurtenissen voor wachtwoordherstel die worden geregistreerd.

Waarom worden wachtwoordvalidatiegebeurtenissen van Microsoft Entra Password Protection geregistreerd met een lege gebruikersnaam?

Active Directory ondersteunt de mogelijkheid om een wachtwoord te testen om te zien of het voldoet aan de huidige vereisten voor wachtwoordcomplexiteit van het domein, bijvoorbeeld met behulp van de NetValidatePasswordPolicy-API . Wanneer een wachtwoord op deze manier wordt gevalideerd, bevat het testen ook validatie door producten op basis van wachtwoordfilters, zoals Microsoft Entra Password Protection, maar de gebruikersnamen die zijn doorgegeven aan een bepaald dll-wachtwoordfilter zijn leeg. In dit scenario valideert Microsoft Entra Password Protection nog steeds het wachtwoord met behulp van het huidige in-effect wachtwoordbeleid en geeft een gebeurtenislogboekbericht uit om het resultaat vast te leggen, maar het gebeurtenislogboekbericht bevat lege gebruikersnaamvelden.

Ik heb hybride gebruikers die hun wachtwoord proberen te wijzigen in Microsoft Entra ID en het antwoord 'We hebben dat wachtwoord al te vaak gezien. Kies iets moeilijker om te raden." Waarom zie ik in dit geval geen validatiepoging on-premises?

Wanneer een hybride gebruiker zijn wachtwoord wijzigt in Microsoft Entra ID, of dit nu via Microsoft Entra SSPR, MyAccount of een ander mechanisme voor wachtwoordwijziging van Microsoft Entra, wordt het wachtwoord geëvalueerd op basis van de algemene en aangepaste lijsten met verboden wachtwoorden in de cloud. Wanneer het wachtwoord Active Directory bereikt via wachtwoord terugschrijven, is het al gevalideerd in Microsoft Entra-id.

Wachtwoordherstel en wijzigingen die zijn geïnitieerd in Microsoft Entra ID die de validatie voor hybride gebruikers mislukken, vindt u in de Microsoft Entra-auditlogboeken. Zie Problemen met selfservice voor wachtwoordherstel in Microsoft Entra ID oplossen.

Wordt het ondersteund om Microsoft Entra Password Protection naast andere producten op basis van wachtwoordfilters te installeren?

Ja. Ondersteuning voor meerdere geregistreerde dll's voor wachtwoordfilters is een belangrijke Windows-functie en niet specifiek voor Microsoft Entra-wachtwoordbeveiliging. Alle geregistreerde dll's voor wachtwoordfilters moeten akkoord gaan voordat een wachtwoord wordt geaccepteerd.

Hoe kan ik Microsoft Entra-wachtwoordbeveiliging implementeren en configureren in mijn Active Directory-omgeving zonder Azure te gebruiken?

Wordt niet ondersteund. Microsoft Entra Password Protection is een Azure-functie die ondersteuning biedt voor uitbreiding in een on-premises Active Directory-omgeving.

Hoe kan ik de inhoud van het beleid wijzigen op Active Directory-niveau?

Wordt niet ondersteund. Het beleid kan alleen worden beheerd via het Microsoft Entra-beheercentrum. Zie ook de vorige vraag.

Waarom is DFSR vereist voor sysvol-replicatie?

FRS (de voorafgaande technologie voor DFSR) heeft veel bekende problemen en wordt volledig niet ondersteund in nieuwere versies van Windows Server Active Directory. Nul testen van Microsoft Entra Password Protection wordt uitgevoerd op door FRS geconfigureerde domeinen.

Zie de volgende artikelen voor meer informatie:

De case voor het migreren van sysvol-replicatie naar DFSR

Het einde is zucht voor FRS

Als uw domein nog geen DFSR gebruikt, moet u dit migreren om DFSR te gebruiken voordat u Microsoft Entra-wachtwoordbeveiliging installeert. Zie de volgende koppeling voor meer informatie:

Migratiehandleiding voor SYSVOL-replicatie: FRS naar DFS-replicatie

Hoeveel schijfruimte is vereist voor de functie op de sysvol-domeinshare?

Het precieze gebruik van de ruimte varieert, omdat dit afhankelijk is van factoren zoals het aantal en de lengte van de verboden tokens in de algemene lijst met verboden Microsoft-adressen en de aangepaste lijst per tenant, plus overhead voor versleuteling. De inhoud van deze lijsten zal in de toekomst waarschijnlijk toenemen. Met dat in gedachten is een redelijke verwachting dat de functie ten minste vijf (5) megabytes ruimte nodig heeft op de sysvol-share van het domein.

Waarom is opnieuw opstarten vereist om de DC-agentsoftware te installeren of bij te werken?

Deze vereiste wordt veroorzaakt door het belangrijkste Windows-gedrag.

Is er een manier om een DC-agent te configureren voor het gebruik van een specifieke proxyserver?

Nee Omdat de proxyserver staatloos is, is het niet belangrijk welke specifieke proxyserver wordt gebruikt.

Is het geen probleem om de Microsoft Entra Password Protection Proxy-service naast andere services zoals Microsoft Entra Verbinding maken te implementeren?

Ja. De Microsoft Entra Password Protection Proxy-service en Microsoft Entra Verbinding maken mogen nooit rechtstreeks met elkaar conflicteren.

Helaas is er een incompatibiliteit gevonden tussen de versie van de Microsoft Entra Verbinding maken Agent Updater-service die is geïnstalleerd door de Microsoft Entra Password Protection Proxy-software en de versie van de service die is geïnstalleerd door de Microsoft Entra-toepassingsproxysoftware. Deze incompatibiliteit kan ertoe leiden dat de Agent Updater-service geen contact kan opnemen met Azure voor software-updates. Het is niet raadzaam om Microsoft Entra Password Protection Proxy en Microsoft Entra-toepassingsproxy op dezelfde computer te installeren.

In welke volgorde moeten de DC-agents en proxy's worden geïnstalleerd en geregistreerd?

Elke volgorde van installatie van proxyagent, DC-agentinstallatie, forestregistratie en proxyregistratie wordt ondersteund.

Moet ik me zorgen maken over de prestatietreffer op mijn domeincontrollers van het implementeren van deze functie?

De Microsoft Entra Password Protection DC Agent-service mag geen aanzienlijke invloed hebben op de prestaties van de domeincontroller in een bestaande gezonde Active Directory-implementatie.

Voor de meeste Active Directory-implementaties zijn wachtwoordwijzigingsbewerkingen een klein deel van de totale werkbelasting op een bepaalde domeincontroller. Stel bijvoorbeeld dat een Active Directory-domein met 10000 gebruikersaccounts en een MaxPasswordAge-beleid is ingesteld op 30 dagen. Gemiddeld ziet dit domein elke dag 10000/30=~333 wachtwoordwijzigingsbewerkingen. Dit is een klein aantal bewerkingen voor zelfs één domeincontroller. Overweeg een mogelijk scenario met ergste gevallen: stel dat deze ~333 wachtwoordwijzigingen op één domeincontroller meer dan één uur zijn uitgevoerd. Dit scenario kan bijvoorbeeld optreden wanneer veel werknemers op maandagochtend aan het werk komen. Zelfs in dat geval kijken we nog steeds naar ~333/60 minuten = zes wachtwoordwijzigingen per minuut, wat opnieuw geen aanzienlijke belasting is.

Als uw huidige domeincontrollers echter al worden uitgevoerd op prestatiebeperkingen (bijvoorbeeld maxed out met betrekking tot CPU, schijfruimte, schijf-I/O, enzovoort), is het raadzaam om extra domeincontrollers toe te voegen of de beschikbare schijfruimte uit te breiden voordat u deze functie implementeert. Zie ook de bovenstaande vraag over het gebruik van sysvol-schijfruimte.

Ik wil Microsoft Entra Password Protection testen op slechts enkele DC's in mijn domein. Is het mogelijk om gebruikerswachtwoordwijzigingen af te dwingen om deze specifieke DC's te gebruiken?

Nee Het Windows-clientbesturingssysteem bepaalt welke domeincontroller wordt gebruikt wanneer een gebruiker het wachtwoord wijzigt. De domeincontroller is geselecteerd op basis van factoren zoals Active Directory-site- en subnettoewijzingen, omgevingsspecifieke netwerkconfiguratie, enzovoort. Microsoft Entra Password Protection bepaalt deze factoren niet en kan niet beïnvloeden welke domeincontroller is geselecteerd om het wachtwoord van een gebruiker te wijzigen.

Een manier om dit doel gedeeltelijk te bereiken, is het implementeren van Microsoft Entra-wachtwoordbeveiliging op alle domeincontrollers op een bepaalde Active Directory-site. Deze aanpak biedt redelijke dekking voor de Windows-clients die aan die site zijn toegewezen, en daarom ook voor de gebruikers die zich aanmelden bij deze clients en hun wachtwoorden wijzigen.

Als ik de MICROSOFT Entra Password Protection DC Agent-service installeer op alleen de primaire domeincontroller (PDC), worden alle andere domeincontrollers in het domein ook beveiligd?

Nee Wanneer het wachtwoord van een gebruiker wordt gewijzigd op een bepaalde niet-PDC-domeincontroller, wordt het wachtwoord voor tekst zonder tekst nooit naar de PDC verzonden (dit idee is een veelvoorkomende foutperceptie). Zodra een nieuw wachtwoord wordt geaccepteerd op een bepaalde domeincontroller, gebruikt die DC dat wachtwoord om de verschillende verificatieprotocolspecifieke hashes van dat wachtwoord te maken en deze hashes vervolgens in de map te behouden. Het wachtwoord voor tekst zonder tekst wordt niet behouden. De bijgewerkte hashes worden vervolgens gerepliceerd naar de PDC. Gebruikerswachtwoorden kunnen in sommige gevallen rechtstreeks op de PDC worden gewijzigd, afhankelijk van verschillende factoren, zoals netwerktopologie en Active Directory-siteontwerp. (Zie de vorige vraag.)

Kortom, de implementatie van de Microsoft Entra Password Protection DC Agent-service op de PDC is vereist voor een beveiligingsdekking van 100% van de functie in het hele domein. Het implementeren van de functie op de PDC biedt alleen geen beveiligingsvoordelen van Microsoft Entra Password Protection voor andere DC's in het domein.

Waarom werkt aangepaste slimme vergrendeling niet, zelfs niet nadat de agents zijn geïnstalleerd in mijn on-premises Active Directory-omgeving?

Aangepaste slimme vergrendeling wordt alleen ondersteund in Microsoft Entra ID. Wijzigingen in de aangepaste instellingen voor slimme vergrendeling in het Microsoft Entra-beheercentrum hebben geen invloed op de on-premises Active Directory-omgeving, zelfs als de agents zijn geïnstalleerd.

Is een System Center Operations Manager-management pack beschikbaar voor Microsoft Entra-wachtwoordbeveiliging?

Nee

Waarom negeert Microsoft Entra ID nog steeds zwakke wachtwoorden, ook al heb ik het beleid geconfigureerd voor de controlemodus?

De controlemodus wordt alleen ondersteund in de on-premises Active Directory-omgeving. Microsoft Entra-id bevindt zich impliciet altijd in de modus Afdwingen wanneer wachtwoorden worden geëvalueerd.

Mijn gebruikers zien het traditionele Windows-foutbericht wanneer een wachtwoord wordt geweigerd door Microsoft Entra-wachtwoordbeveiliging. Is het mogelijk om dit foutbericht aan te passen zodat gebruikers weten wat er echt is gebeurd?

Nee Het foutbericht dat gebruikers zien wanneer een wachtwoord wordt geweigerd door een domeincontroller, wordt beheerd door de clientcomputer, niet door de domeincontroller. Dit gedrag treedt op of een wachtwoord wordt geweigerd door het standaardBeleid voor Active Directory-wachtwoorden of door een oplossing op basis van wachtwoordfilters, zoals Microsoft Entra-wachtwoordbeveiliging.

U kunt enkele eenvoudige tests van verschillende wachtwoorden uitvoeren om de juiste werking van de software te valideren en een beter inzicht te krijgen in het algoritme voor wachtwoordevaluatie. In deze sectie wordt een methode beschreven voor dergelijke tests die zijn ontworpen om herhaalbare resultaten te produceren.

Waarom is het nodig om deze stappen uit te voeren? Er zijn verschillende factoren die het moeilijk maken om gecontroleerde, herhaalbare tests van wachtwoorden in de on-premises Active Directory-omgeving uit te voeren:

• Het wachtwoordbeleid wordt geconfigureerd en behouden in Azure en kopieën van het beleid worden periodiek gesynchroniseerd door de on-premises DC-agent(s) met behulp van een pollingmechanisme. De latentie die inherent is aan deze pollingcyclus kan verwarring veroorzaken. Als u bijvoorbeeld het beleid in Azure configureert, maar vergeet het beleid te synchroniseren met de DC-agent, levert uw tests mogelijk niet de verwachte resultaten op. Het polling-interval is momenteel vastgelegd om één keer per uur te zijn, maar het wachten op een uur tussen beleidswijzigingen is niet ideaal voor een interactief testscenario.
• Zodra een nieuw wachtwoordbeleid is gesynchroniseerd met een domeincontroller, treedt er meer latentie op terwijl het wordt gerepliceerd naar andere domeincontrollers. Deze vertragingen kunnen onverwachte resultaten veroorzaken als u een wachtwoordwijziging test op een domeincontroller die nog niet de nieuwste versie van het beleid heeft ontvangen.
• Het testen van wachtwoordwijzigingen via een gebruikersinterface maakt het lastig om vertrouwen te hebben in uw resultaten. Het is bijvoorbeeld eenvoudig om een ongeldig wachtwoord in een gebruikersinterface te typen, met name omdat de meeste gebruikersinterfaces voor wachtwoorden gebruikersinvoer verbergen (bijvoorbeeld windows Ctrl-Alt-Delete -> Wachtwoordgebruikersinterface wijzigen).
• Het is niet mogelijk om strikt te controleren welke domeincontroller wordt gebruikt bij het testen van wachtwoordwijzigingen van clients die lid zijn van een domein. Het Windows-clientbesturingssysteem selecteert een domeincontroller op basis van factoren zoals Active Directory-site- en subnettoewijzingen, omgevingsspecifieke netwerkconfiguratie, enzovoort.

Om deze problemen te voorkomen, zijn de onderstaande stappen gebaseerd op opdrachtregeltests van wachtwoordherstel tijdens het aanmelden bij een domeincontroller.

Bij de volgende stappen wordt ervan uitgegaan dat u de DC-agent hebt geïnstalleerd op ten minste één domeincontroller, ten minste één proxy hebt geïnstalleerd en dat u zowel de proxy als het forest hebt geregistreerd.

1. Meld u aan bij een domeincontroller met behulp van referenties voor domein Beheer (of andere referenties met voldoende bevoegdheden om testgebruikersaccounts te maken en wachtwoorden opnieuw in te stellen), waarop de DC-agentsoftware is geïnstalleerd en opnieuw is opgestart.

2. Open Logboeken en navigeer naar het gebeurtenislogboek van de DC-agent Beheer.

3. Open een opdrachtpromptvenster met verhoogde bevoegdheid.

4. Een testaccount maken voor het testen van wachtwoorden

   Er zijn veel manieren om een gebruikersaccount te maken, maar hier wordt een opdrachtregeloptie aangeboden als een manier om het eenvoudig te maken tijdens terugkerende testcycli:

   net.exe user <testuseraccountname> /add <password>
   

   Voor onderstaande discussiedoeleinden wordt ervan uitgegaan dat we een testaccount met de naam ContosoUser hebben gemaakt, bijvoorbeeld:

   net.exe user ContosoUser /add <password>
   

5. Meld u aan bij het Microsoft Entra-beheercentrum als ten minste een verificatie-Beheer istrator.

6. Blader naar > beveiligingsverificatiemethoden > voor wachtwoordbeveiliging.

7. Wijzig het Microsoft Entra Password Protection-beleid indien nodig voor het testen dat u wilt uitvoeren. U kunt bijvoorbeeld besluiten om afgedwongen of controlemodus te configureren, of u kunt besluiten om de lijst met verboden termen in uw aangepaste lijst met verboden wachtwoorden te wijzigen.

8. Synchroniseer het nieuwe beleid door de DC-agentservice te stoppen en opnieuw te starten.

   Deze stap kan op verschillende manieren worden uitgevoerd. Een manier is om de Beheerconsole van Service Management te gebruiken door met de rechtermuisknop op de Microsoft Entra Password Protection DC Agent-service te klikken en opnieuw opstarten te kiezen. Een andere manier kan worden uitgevoerd vanuit het opdrachtpromptvenster als volgt:

   net stop AzureADPasswordProtectionDCAgent && net start AzureADPasswordProtectionDCAgent
   

9. Controleer de Logboeken om te controleren of er een nieuw beleid is gedownload.

   Telkens wanneer de DC-agentservice wordt gestopt en gestart, ziet u twee 30006-gebeurtenissen die na elkaar zijn uitgegeven. De eerste 30006-gebeurtenis weerspiegelt het beleid dat is opgeslagen in de cache op schijf in de sysvol-share. De tweede 30006-gebeurtenis (indien aanwezig) moet een bijgewerkte datum van tenantbeleid hebben. Als dat het geval is, wordt het beleid weergegeven dat is gedownload uit Azure. De datumwaarde van het tenantbeleid is momenteel gecodeerd om het geschatte tijdstempel weer te geven dat het beleid is gedownload uit Azure.

   Als de tweede 30006-gebeurtenis niet wordt weergegeven, moet u het probleem oplossen voordat u doorgaat.

   De gebeurtenissen 30006 zien er ongeveer als volgt uit:

   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: 1
   

   Als u bijvoorbeeld wijzigt tussen de afgedwongen modus en de controlemodus, wordt de vlag AuditOnly gewijzigd (het bovenstaande beleid met AuditOnly=0 bevindt zich in de modus Afgedwongen); wijzigingen in de aangepaste lijst met verboden wachtwoorden worden niet rechtstreeks doorgevoerd in de bovenstaande gebeurtenis 30006 (en worden om veiligheidsredenen nergens anders geregistreerd). Het downloaden van het beleid van Azure na een dergelijke wijziging omvat ook de aangepaste aangepaste lijst met verboden wachtwoorden.

10. Voer een test uit door een nieuw wachtwoord opnieuw in te stellen op het testgebruikersaccount.

    Deze stap kan worden uitgevoerd vanuit het opdrachtpromptvenster als volgt:

    net.exe user ContosoUser <password>
    

    Nadat u de opdracht hebt uitgevoerd, kunt u meer informatie krijgen over het resultaat van de opdracht door in de logboeken te kijken. Gebeurtenissen met het resultaat van wachtwoordvalidatie worden beschreven in het onderwerp over het gebeurtenislogboek Beheer DC-agent. U gebruikt dergelijke gebeurtenissen om het resultaat van uw test te valideren, naast de interactieve uitvoer van de net.exe opdrachten.

    Laten we een voorbeeld proberen: een wachtwoord instellen dat is verboden door de algemene Microsoft-lijst (houd er rekening mee dat de lijst niet is gedocumenteerd , maar we kunnen hier testen op basis van een bekende verboden term). In dit voorbeeld wordt ervan uitgegaan dat u het beleid hebt geconfigureerd in de modus Afgedwongen en nul voorwaarden hebt toegevoegd aan de aangepaste lijst met verboden wachtwoorden.

    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.
    

    Volgens de documentatie, omdat onze test een bewerking voor wachtwoordherstel was, zou u een 10017- en 30005-gebeurtenis moeten zien voor de ContosoUser-gebruiker.

    De gebeurtenis 10017 moet er als volgt uitzien:

    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: 
    

    De gebeurtenis 30005 moet er als volgt uitzien:

    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: 
    

    Dat was leuk- laten we een ander voorbeeld proberen. Deze keer proberen we een wachtwoord in te stellen dat is verboden door de aangepaste lijst met verboden bestanden terwijl het beleid zich in de controlemodus bevindt. In dit voorbeeld wordt ervan uitgegaan dat u de volgende stappen hebt uitgevoerd: het beleid zo geconfigureerd dat het zich in de controlemodus bevindt, de term 'lachrymose' hebt toegevoegd aan de aangepaste lijst met verboden wachtwoorden en het resulterende nieuwe beleid hebt gesynchroniseerd met de domeincontroller door de DC-agentservice te fietsen zoals hierboven beschreven.

    Ok, stel een variatie van het verboden wachtwoord in:

    net.exe user ContosoUser LaChRymoSE!1
    The command completed successfully.
    

    Houd er rekening mee dat het deze keer is geslaagd omdat het beleid zich in de controlemodus bevindt. U ziet nu een 10025- en 30007-gebeurtenis voor de ContosoUser-gebruiker.

    De gebeurtenis 10025 moet er als volgt uitzien:

    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: 
    

    De gebeurtenis 30007 moet er als volgt uitzien:

    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: 
    

11. Ga door met het testen van verschillende wachtwoorden van uw keuze en controleer de resultaten in de logboeken met behulp van de procedures die in de vorige stappen zijn beschreven. Als u het beleid in het Microsoft Entra-beheercentrum wilt wijzigen, vergeet dan niet om het nieuwe beleid te synchroniseren met de DC-agent, zoals eerder beschreven.

We hebben procedures behandeld waarmee u gecontroleerde tests kunt uitvoeren op het wachtwoordvalidatiegedrag van Microsoft Entra Password Protection. Het opnieuw instellen van gebruikerswachtwoorden vanaf de opdrachtregel rechtstreeks op een domeincontroller lijkt een vreemd middel om dergelijke tests uit te voeren, maar zoals eerder is beschreven, is het ontworpen om herhaalbare resultaten te produceren. Terwijl u verschillende wachtwoorden test, moet u rekening houden met het algoritme voor wachtwoordevaluatie, omdat dit kan helpen bij het uitleggen van de resultaten die u niet had verwacht.

De volgende koppelingen maken geen deel uit van de kerndocumentatie van Microsoft Entra Password Protection, maar zijn mogelijk een nuttige bron van aanvullende informatie over de functie.

Microsoft Entra Password Protection is nu algemeen beschikbaar.

Handleiding voor e-mailphishingbeveiliging – deel 15: De Microsoft Entra-wachtwoordbeveiligingsservice implementeren (voor on-premises ook!)

Microsoft Entra Password Protection en Smart Lockout zijn nu beschikbaar als openbare preview.

Als u meer wilt weten over Microsoft Entra Password Protection en deze implementeert in uw omgeving, kunt u profiteren van een proactieve Microsoft-service die beschikbaar is voor die klanten met een Premier- of Unified-ondersteuningscontract. De service heet Microsoft Entra ID: Wachtwoordbeveiliging. Neem contact op met uw Customer Success Account Manager voor meer informatie.

Volgende stappen

Als u een on-premises vraag over Microsoft Entra-wachtwoordbeveiliging hebt die hier niet wordt beantwoord, dient u hieronder een feedbackitem in.

Wachtwoordbeveiliging van Microsoft Entra implementeren