Nejčastější dotazy týkající se microsoft Entra Password Protection v místním prostředí

Tato část obsahuje odpovědi na řadu nejčastějších dotazů k ochraně heslem Microsoft Entra.

Obecné dotazy

Jaké pokyny by měli uživatelé zadat, jak vybrat zabezpečené heslo?

Aktuální pokyny microsoftu k tomuto tématu najdete na následujícím odkazu:

Pokyny k heslu Microsoftu

Podporuje se místní ochrana heslem Microsoft Entra v neveřejných cloudech?

Místní ochrana heslem Microsoft Entra se podporuje v cloudech Azure Global i Azure Government.

Centrum pro správu Microsoft Entra umožňuje úpravu konfigurace "Ochrana hesel pro Windows Server Active Directory" v nepodporovaných cloudech; tyto změny se zachovají, ale nikdy se neprojeví. Registrace místních agentů proxy serveru nebo doménových struktur není podporována v nepodporovaných cloudech a všechny takové pokusy o registraci vždy selžou.

Jak můžu na podmnožinu místních uživatelů použít výhody microsoft Entra Password Protection?

Nepodporováno Po nasazení a povolení se ochrana heslem Microsoft Entra vztahuje stejně na všechny uživatele.

Jaký je rozdíl mezi změnou hesla a nastavením hesla (nebo resetováním)?

Změna hesla spočívá v tom, že uživatel zvolí nové heslo po prokázání, že má znalosti o starém heslu. Například změna hesla se stane, když se uživatel přihlásí do Windows a zobrazí se výzva k výběru nového hesla.

Sada hesel (někdy označovaná jako resetování hesla) je, když správce nahradí heslo účtu novým heslem, například pomocí nástroje pro správu Uživatelé a počítače služby Active Directory. Tato operace vyžaduje vysokou úroveň oprávnění (obvykle Správce domény) a osoba, která operaci provádí, obvykle nemá znalosti o starém heslu. Scénáře help-desku často provádějí sady hesel, například při pomoci uživateli, který zapomněl heslo. Při prvním vytvoření zcela nového uživatelského účtu s heslem se zobrazí také události nastavení hesla.

Zásady ověřování hesel se chovají stejně bez ohledu na to, jestli se provádí změna nebo nastavení hesla. Služba agenta DC služby Microsoft Entra Password Protection provádí protokoly různých událostí, které vás informují o tom, jestli byla provedena operace změny nebo nastavení hesla. Podívejte se na monitorování a protokolování microsoft Entra Password Protection.

Ověřuje Microsoft Entra Password Protection stávající hesla po instalaci?

Ne – Microsoft Entra Password Protection může vynutit zásady hesel pouze pro hesla s vymazáním textu během operace změny nebo nastavení hesla. Jakmile služba Active Directory přijme heslo, zachovají se pouze hodnoty hash specifické pro protokol ověřování daného hesla. Heslo s vymazáním textu se nikdy neuchová, proto Microsoft Entra Password Protection nemůže ověřit stávající hesla.

Po počátečním nasazení microsoft Entra Password Protection začnou všichni uživatelé a účty nakonec používat heslo ověřené heslem Microsoft Entra, protože jejich stávající hesla obvykle vyprší v průběhu času. V případě potřeby můžete tento proces urychlit jednorázovým ručním vypršením hesel uživatelských účtů.

Účty nakonfigurované s textem "Heslo nikdy nevyprší platnost" se nevynucují ke změně hesla, pokud se nedokončí ruční vypršení platnosti.

Proč se duplicitní události zamítnutí hesla protokolují při pokusu o nastavení slabého hesla pomocí modulu snap-in správy Uživatelé a počítače služby Active Directory?

Modul snap-in správa Uživatelé a počítače služby Active Directory se nejprve pokusí nastavit nové heslo pomocí protokolu Kerberos. Při selhání provede modul snap-in druhý pokus o nastavení hesla pomocí starší verze protokolu (SAM RPC). Používané konkrétní protokoly nejsou důležité. Pokud je nové heslo považováno za slabé službou Microsoft Entra Password Protection, toto chování modulu snap-in vytvoří dvě sady událostí zamítnutí resetování hesel, které se protokolují.

Proč se protokolují události ověřování hesel microsoft Entra Password Protection s prázdným uživatelským jménem?

Služba Active Directory podporuje možnost otestovat heslo a zjistit, jestli splňuje aktuální požadavky na složitost hesla domény, například pomocí rozhraní API NetValidatePasswordPolicy . Při ověření hesla tímto způsobem zahrnuje testování také ověřování pomocí produktů založených na filtru hesel, jako je microsoft Entra Password Protection, ale uživatelská jména předaná dané knihovně DLL filtru hesel jsou prázdná. V tomto scénáři microsoft Entra Password Protection stále ověřuje heslo pomocí aktuálně aktivních zásad hesel a vydává zprávu protokolu událostí, aby zachytil výsledek. Zpráva protokolu událostí ale bude obsahovat prázdná pole uživatelského jména.

Mám hybridní uživatele, kteří se pokusí změnit heslo v Microsoft Entra ID a obdrží odpověď "Toto heslo jsme viděli příliš mnohokrát předtím. Zvolte něco, co je těžší odhadnout." Proč se v tomto případě nezobrazuje pokus o ověření místně?

Když hybridní uživatel změní heslo v Microsoft Entra ID, ať už prostřednictvím Microsoft Entra SSPR, MyAccount nebo jiného mechanismu změny hesla Microsoft Entra, vyhodnotí se jeho heslo vůči globálním a vlastním zakázaným seznamům hesel v cloudu. Když heslo dosáhne služby Active Directory prostřednictvím zpětného zápisu hesla, je již ověřeno v ID Microsoft Entra.

Resetování hesla a změny zahájené v ID Microsoft Entra, které ověřování hybridních uživatelů selžou, najdete v protokolech auditu Microsoft Entra. Viz Řešení potíží s samoobslužným resetováním hesla v Microsoft Entra ID.

Podporuje se instalace služby Microsoft Entra Password Protection vedle jiných produktů založených na filtrování hesel?

Ano. Podpora více registrovaných knihoven DLL filtru hesel je základní funkce systému Windows, která není specifická pro microsoft Entra Password Protection. Všechny knihovny DLL registrovaného filtru hesel musí souhlasit před přijetím hesla.

Jak můžu nasadit a nakonfigurovat ochranu heslem Microsoft Entra v prostředí Active Directory bez použití Azure?

Nepodporováno Microsoft Entra Password Protection je funkce Azure, která podporuje rozšíření do místní Active Directory prostředí.

Jak můžu upravit obsah zásad na úrovni služby Active Directory?

Nepodporováno Zásady je možné spravovat pouze pomocí Centra pro správu Microsoft Entra. Podívejte se také na předchozí otázku.

Proč se pro replikaci sysvol vyžaduje replikace DFSR?

Služba FRS (předchůdce distribuovaného systému souborů DFSR) má mnoho známých problémů a v novějších verzích služby Windows Server Active Directory je zcela nepodporovaná. Testování ochrany heslem Microsoft Entra se provádí na doménách nakonfigurovaných službou FRS.

Další informace najdete v následujících článcích:

Případ migrace replikace sysvol do DFSR

Konec je pro FRS nigh

Pokud vaše doména ještě nepoužívá DFSR, musíte ji před instalací služby Microsoft Entra Password Protection migrovat, aby používala DFSR. Další informace najdete na následujícím odkazu:

Průvodce migrací replikace SYSVOL: Replikace FRS do DFS

Upozorňující

Microsoft Entra Password Protection DC Agent software v současné době instaluje na řadiče domény v doménách, které stále používají frS pro replikaci sysvol, ale software v tomto prostředí nefunguje správně. Negativní vedlejší účinky zahrnují jednotlivé soubory, které se nedaří replikovat, a procedury obnovení sysvol se jeví jako úspěšné, ale bezobslužné replikace všech souborů. Doménu byste měli migrovat tak, aby co nejdříve používala DFSR, a to jak pro vlastní výhody DFSR, tak i pro odblokování nasazení služby Microsoft Entra Password Protection. Budoucí verze softwaru se automaticky deaktivují při spuštění v doméně, která stále používá službu FRS.

Kolik místa na disku tato funkce vyžaduje ve sdílené složce sysvol domény?

Přesné využití místa se liší, protože závisí na faktorech, jako je počet a délka zakázaných tokenů v globálním seznamu zakázaných v Microsoftu a na vlastním seznamu pro jednotlivé tenanty a na režii šifrování. Obsah těchto seznamů bude pravděpodobně v budoucnu růst. S ohledem na to je rozumné očekávání, že funkce vyžaduje alespoň pět (5) megabajtů prostoru ve sdílené složce sysvol domény.

Proč se k instalaci nebo upgradu softwaru agenta DC vyžaduje restartování?

Tento požadavek je způsoben základním chováním systému Windows.

Existuje nějaký způsob, jak nakonfigurovat agenta řadiče domény tak, aby používal konkrétní proxy server?

Ne. Vzhledem k tomu, že proxy server je bezstavový, není důležité, který konkrétní proxy server se používá.

Je v pořádku nasadit službu Proxy služby Microsoft Entra Password Protection souběžně s dalšími službami, jako je Microsoft Entra Connect?

Ano. Služba Proxy služby Microsoft Entra Password Protection a Microsoft Entra Connect by nikdy neměly být v konfliktu přímo s ostatními.

Software proxy služby Microsoft Entra Password Protection bohužel nainstaluje verzi služby Microsoft Entra Connect Agent Updater, která není kompatibilní s verzí nainstalovanou softwarem proxy aplikací Microsoft Entra. Kvůli tomuto nekompatibilitě může dojít k tomu, že služba Agent Updater nemůže kontaktovat Azure pro aktualizace softwaru. Nedoporučuje se instalovat proxy služby Microsoft Entra Password Protection a proxy aplikací Microsoft Entra na stejný počítač.

V jakém pořadí by se agenti řadiče domény a proxy servery měli nainstalovat a zaregistrovat?

Je podporováno řazení instalace agenta proxy serveru, instalace agenta řadiče domény, registrace doménové struktury a registrace proxy serveru.

Mám se obávat výkonu řadičů domény při nasazování této funkce?

Služba agenta DC služby Microsoft Entra Password Protection by neměla výrazně ovlivnit výkon řadiče domény v existujícím nasazení služby Active Directory, která je v pořádku.

U většiny nasazení služby Active Directory jsou operace změn hesel malým podílem celkové úlohy na jakémkoli řadiči domény. Představte si například doménu služby Active Directory s 10 000 uživatelskými účty a zásadou MaxPasswordAge nastavenou na 30 dnů. V průměru tato doména vidí 1 0000/30=~333 operací změny hesla každý den, což je malý počet operací pro dokonce jeden řadič domény. Představte si potenciální scénář nejhoršího případu: Předpokládejme, že se tyto změny hesla v jednom řadiči domény provedly během jedné hodiny přibližně 333. Tento scénář může například nastat, když mnoho zaměstnanců přijde do práce v pondělí ráno. I v takovém případě se stále díváme na přibližně 333/60 minut = šest změn hesla za minutu, což opět není významné zatížení.

Pokud ale vaše aktuální řadiče domény už běží na úrovních s omezeným výkonem (například s ohledem na procesor, místo na disku, vstupně-výstupní operace disku atd.), je vhodné před nasazením této funkce přidat další řadiče domény nebo rozšířit dostupné místo na disku. Projděte si předchozí otázku týkající se výše uvedeného využití místa na disku sysvol.

Chci otestovat ochranu heslem Microsoft Entra na několika řadičích domény v mé doméně. Je možné vynutit, aby změny uživatelského hesla používaly tyto konkrétní řadiče domény?

Ne. Klientský operační systém Windows určuje, který řadič domény se používá, když uživatel změní heslo. Řadič domény je vybrán na základě faktorů, jako jsou přiřazení lokality služby Active Directory a podsítě, konfigurace sítě specifické pro prostředí atd. Microsoft Entra Password Protection neřídí tyto faktory a nemůže ovlivnit, který řadič domény je vybrán pro změnu hesla uživatele.

Jedním ze způsobů, jak tento cíl částečně dosáhnout, je nasadit ochranu heslem Microsoft Entra na všechny řadiče domény v dané lokalitě služby Active Directory. Tento přístup poskytuje přiměřené pokrytí pro klienty Windows přiřazené k dané lokalitě a pro uživatele, kteří se k těmto klientům přihlašují a mění svá hesla.

Pokud nainstaluji službu agenta DC služby Microsoft Entra Password Protection na pouze primární řadič domény (PDC), budou také chráněny všechny ostatní řadiče domény v doméně?

Ne. Když se heslo uživatele změní na daném řadiči domény, který není primárním řadičem domény, heslo pro vymazání textu se nikdy neodesílají do primárního řadiče domény (tato myšlenka je běžným nesprávným vnímáním). Po přijetí nového hesla na daném řadiči domény tento řadič domény použije toto heslo k vytvoření různých hodnot hash specifických pro protokol ověřování tohoto hesla a pak tyto hodnoty hash zachovají v adresáři. Heslo pro vymazání textu se neuchová. Aktualizované hodnoty hash se pak replikují do primárního řadiče domény. Uživatelská hesla se v některých případech můžou změnit přímo na primárním řadiči domény, a to znovu v závislosti na různých faktorech, jako je například síťová topologie a návrh lokality služby Active Directory. (Viz předchozí otázka.)

Stručně řečeno, nasazení služby agenta DC služby Microsoft Entra Password Protection DC na primárním řadiči domény je nutné k dosažení 100% pokrytí zabezpečení funkce v celé doméně. Nasazení funkce na primárním řadiči domény neposkytuje výhody zabezpečení microsoft Entra Password Protection jenom pro žádné jiné řadiče domény v doméně.

Proč vlastní inteligentní uzamčení nefunguje ani po instalaci agentů v mém místní Active Directory prostředí?

Vlastní inteligentní uzamčení je podporováno pouze v Microsoft Entra ID. Změny vlastního nastavení inteligentního uzamčení v Centru pro správu Microsoft Entra nemají žádný vliv na místní Active Directory prostředí, a to ani s nainstalovanými agenty.

Je sada Management Pack nástroje System Center Operations Manager dostupná pro ochranu heslem společnosti Microsoft Entra?

Ne.

Proč Microsoft Entra ID stále odmítá slabá hesla, i když jsem nakonfiguroval zásady tak, aby byly v režimu auditování?

Režim auditu se podporuje jenom v místní Active Directory prostředí. Id Microsoft Entra je při vyhodnocování hesel implicitně vždy v režimu vynucení.

Moji uživatelé uvidí tradiční chybovou zprávu systému Windows, když je heslo odmítnuto službou Microsoft Entra Password Protection. Je možné tuto chybovou zprávu přizpůsobit tak, aby uživatelé věděli, co se skutečně stalo?

Ne. Chybová zpráva, kterou uživatelé vidí, když je heslo odmítnuto řadičem domény, je řízeno klientským počítačem, nikoli řadičem domény. K tomuto chování dochází, pokud je heslo odmítnuto výchozími zásadami hesel služby Active Directory nebo řešením založeným na filtru hesel, jako je například Ochrana heslem Microsoft Entra.

Postupy testování hesel

Možná budete chtít provést základní testování různých hesel, abyste ověřili správné fungování softwaru a lépe porozuměli algoritmu vyhodnocení hesla. Tato část popisuje metodu takového testování, která je navržená tak, aby vytvářela opakovatelné výsledky.

Proč je nutné postupovat podle těchto kroků? Existuje několik faktorů, které ztěžují provádění kontrolovaných a opakovatelných testů hesel v prostředí místní Active Directory:

• Zásady hesel se konfigurují a uchovávají v Azure a kopie zásad se pravidelně synchronizují místními agenty DC pomocí mechanismu dotazování. Latence spojená s tímto cyklem dotazování může způsobit nejasnosti. Pokud například nakonfigurujete zásadu v Azure, ale zapomenete ji synchronizovat s agentem řadiče domény, nemusí testy přinést očekávané výsledky. Interval dotazování je momentálně pevně zakódovaný tak, aby byl jednou za hodinu, ale čekání na hodinu mezi změnami zásad není ideální pro interaktivní scénář testování.
• Jakmile se nové zásady hesel synchronizují s řadičem domény, dojde při replikaci do jiných řadičů domény s větší latencí. Tato zpoždění můžou způsobit neočekávané výsledky, pokud otestujete změnu hesla na řadiči domény, který nepřijal nejnovější verzi zásady.
• Testování změn hesel prostřednictvím uživatelského rozhraní znesnadňuje spolehlivost výsledků. Do uživatelského rozhraní je například snadné chybně zadat neplatné heslo, zejména proto, že většina uživatelských rozhraní hesel skryje uživatelský vstup (například Windows Ctrl-Alt-Delete -> Změnit uživatelské rozhraní hesla).
• Při testování změn hesel z klientů připojených k doméně není možné striktně řídit, který řadič domény se používá. Klientský operační systém Windows vybere řadič domény na základě faktorů, jako jsou lokality služby Active Directory a přiřazení podsítí, konfigurace sítě specifické pro prostředí atd.

Abyste se těmto problémům vyhnuli, jsou následující kroky založené na testování resetování hesel pomocí příkazového řádku při přihlášení k řadiči domény.

Upozorňující

Tyto postupy používejte pouze v testovacím prostředí. Zatímco je služba agenta řadiče domény zastavená, všechny příchozí změny hesla a resetování se přijímají bez ověření. To také pomáhá vyhnout se zvýšeným rizikům přihlášení k řadiči domény.

Následující kroky předpokládají, že jste agenta řadiče domény nainstalovali alespoň na jeden řadič domény, nainstalovali aspoň jeden proxy server a zaregistrovali proxy server i doménovou strukturu.

1. Přihlaste se k řadiči domény pomocí přihlašovacích údajů správce domény nebo jiných přihlašovacích údajů, které mají dostatečná oprávnění k vytvoření testovacích uživatelských účtů a resetování hesel. Ujistěte se, že je na řadiči domény nainstalovaný software agenta řadiče domény a že se restartoval.

2. Otevřete Prohlížeč událostí a přejděte do protokolu událostí správce agenta DC.

3. Otevřete okno příkazového řádku se zvýšenými oprávněními.

4. Vytvoření testovacího účtu pro testování hesel

   Existuje mnoho způsobů, jak vytvořit uživatelský účet, ale možnost příkazového řádku je zde nabízena jako způsob, jak ho během opakovaných testovacích cyklů snadno usnadnit:

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

   Pro účely diskuze níže předpokládejme, že jsme vytvořili testovací účet s názvem ContosoUser, například:

   net.exe user ContosoUser /add <password>
   

5. Přihlaste se do Centra pro správu Microsoft Entra jako alespoň správce ověřování.

6. Přejděte k metodám > ověřování ochrany > heslem.

7. Podle potřeby upravte zásady ochrany heslem microsoft Entra pro testování, které chcete provést. Můžete se například rozhodnout, že nakonfigurujete vynucený nebo auditní režim, nebo se rozhodnete změnit seznam zakázaných termínů ve vašem vlastním seznamu zakázaných hesel.

8. Synchronizujte nové zásady zastavením a restartováním služby agenta řadiče domény.

   Tento krok lze provést různými způsoby. Jedním ze způsobů je použít konzolu pro správu správy služeb tak, že kliknete pravým tlačítkem myši na službu Agent DC služby Microsoft Entra Password Protection a zvolíte Možnost Restartovat. Z okna příkazového řádku je možné provést jiný způsob:

   net stop AzureADPasswordProtectionDCAgent && net start AzureADPasswordProtectionDCAgent
   

9. Zkontrolujte Prohlížeč událostí a ověřte, že byly staženy nové zásady.

   Při každém zastavení a spuštění služby agenta DC by se měly zobrazit dvě události 30006 vydané v úzkém pořadí. První událost 30006 bude odrážet zásadu uloženou na disku ve sdílené složce sysvol. Druhá událost 30006 (pokud je k dispozici) by měla mít aktualizované datum zásady tenanta, a pokud ano, bude odrážet zásady, které byly staženy z Azure. Hodnota data zásad tenanta je aktuálně zakódovaná tak, aby zobrazovala přibližné časové razítko, které byly zásady staženy z Azure.

   Pokud se druhá událost 30006 nezobrazí, měli byste problém vyřešit, než budete pokračovat.

   Události 30006 budou vypadat podobně jako v tomto příkladu:

   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
   

   Změna mezi režimem vynucení a auditování například způsobí úpravu příznaku AuditOnly (zásada uvedená s AuditOnly=0 je v režimu vynucení). Změny vlastního seznamu zakázaných hesel se neprojeví přímo ve výše uvedené události 30006 a nejsou zaprotokolovány nikde jinde z bezpečnostních důvodů. Po dokončení této změny se zásada z Azure úspěšně stáhne i do upraveného seznamu zakázaných hesel.

10. Spusťte test tak, že se pokusíte resetovat nové heslo na testovacím uživatelském účtu.

    Tento krok je možné provést z okna příkazového řádku, například takto:

    net.exe user ContosoUser <password>
    

    Po spuštění příkazu můžete získat další informace o výsledku příkazu tak, že se podíváte do prohlížeče událostí. Události výsledku ověření hesla jsou popsané v tématu protokolu událostí správce agenta DC. Tyto události použijete k ověření výsledku testu kromě interaktivního výstupu z příkazů net.exe.

    Pojďme si vyzkoušet příklad: pokus o nastavení hesla, které je zakázáno globálním seznamem Microsoftu (všimněte si, že tento seznam není zdokumentovaný , ale můžeme zde testovat proti známému zakázanému termínu). Tento příklad předpokládá, že jste nakonfigurovali zásadu v režimu vynucení a přidali jste do vlastního seznamu zakázaných hesel nulové termíny.

    net.exe user ContosoUser PassWord
    The password doesn't 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.
    

    Podle dokumentace, protože náš test byl operace resetování hesla, měla by se zobrazit událost 10017 a 30005 pro uživatele ContosoUser.

    Událost 10017 by měla vypadat jako v tomto příkladu:

    The reset password for the specified user was rejected because it didn't comply with the current Azure password policy. For more information, please see the correlated event log message.
    
    UserName: ContosoUser
    FullName: 
    

    Událost 30005 by měla vypadat jako v tomto příkladu:

    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: 
    

    To bylo zábavné - pojďme vyzkoušet další příklad! Teď se pokusíme nastavit heslo, které je zakázané vlastním zakázaným seznamem, zatímco zásady jsou v režimu auditování. Tento příklad předpokládá, že jste dokončili následující kroky: nakonfigurovali jste zásadu tak, aby byla v režimu auditování, přidali do vlastního seznamu zakázaných hesel termín "lachrymose" a synchronizovali výsledné nové zásady s řadičem domény tak, že jste službu agenta řadiče domény překonfigurovali podle předchozího popisu.

    Ok, nastavte variantu zakázaného hesla:

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

    Mějte na paměti, že tentokrát bylo úspěšné, protože zásada je v režimu auditování. Pro uživatele ContosoUser by se měla zobrazit událost 10025 a 30007.

    Událost 10025 by měla vypadat jako v tomto příkladu:

    The reset password for the specified user would normally have been rejected because it didn't 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: 
    

    Událost 30007 by měla vypadat jako v tomto příkladu:

    The reset password for the specified user would normally be 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. Pokračujte v testování různých hesel podle vašeho výběru a kontrolujte výsledky v prohlížeči událostí pomocí postupů popsaných v předchozích krocích. Pokud potřebujete změnit zásady v Centru pro správu Microsoft Entra, nezapomeňte nové zásady synchronizovat s agentem dc, jak je popsáno výše.

Probrali jsme postupy, které vám umožňují provádět řízené testování chování ověřování hesel microsoft Entra Password Protection. Resetování uživatelských hesel z příkazového řádku přímo na řadiči domény může vypadat jako lichý způsob testování, ale jak je popsáno dříve, je navržené tak, aby vytvářelo opakovatelné výsledky. Při testování různých hesel mějte na paměti algoritmus vyhodnocení hesla, protože vám může pomoct vysvětlit výsledky, které jste neočekádali.

Upozorňující

Po dokončení veškerého testování nezapomeňte odstranit všechny uživatelské účty vytvořené pro účely testování.

Další obsah

Následující odkazy nejsou součástí základní dokumentace microsoft Entra Password Protection, ale mohou být užitečným zdrojem dalších informací o této funkci.

Microsoft Entra Password Protection je nyní obecně dostupný!

Průvodce ochranou před útoky phishing e-mailu – část 15: Implementujte službu Microsoft Entra Password Protection Service (pro místní prostředí!)

Microsoft Entra Password Protection a Inteligentní uzamčení jsou teď ve verzi Public Preview!

K dispozici je školení podpory Microsoft Premier\Unified

Pokud se chcete dozvědět více o službě Microsoft Entra Password Protection a jejím nasazení, můžete použít proaktivní službu Microsoftu. Tato služba je k dispozici zákazníkům se smlouvou Premier nebo Unified Support. Tato služba se nazývá Microsoft Entra ID: Ochrana heslem. Další informace získáte od manažera zákaznického úspěchu.

Další kroky

Pokud máte místní otázku Microsoft Entra Password Protection, která zde není zodpovězena, odešlete níže položku Váš názor – děkujeme vám!

Nasazení ochrany heslem Microsoft Entra

Tato část obsahuje odpovědi na řadu nejčastějších dotazů k ochraně heslem Microsoft Entra.

Jaké pokyny by měli uživatelé zadat, jak vybrat zabezpečené heslo?

Aktuální pokyny microsoftu k tomuto tématu najdete na následujícím odkazu:

Pokyny k heslu Microsoftu

Podporuje se místní ochrana heslem Microsoft Entra v neveřejných cloudech?

Místní ochrana heslem Microsoft Entra se podporuje v cloudech Azure Global i Azure Government.

Centrum pro správu Microsoft Entra umožňuje úpravu konfigurace "Ochrana hesel pro Windows Server Active Directory" v nepodporovaných cloudech; tyto změny se zachovají, ale nikdy se neprojeví. Registrace místních agentů proxy serveru nebo doménových struktur není podporována v nepodporovaných cloudech a všechny takové pokusy o registraci vždy selžou.

Jak můžu na podmnožinu místních uživatelů použít výhody microsoft Entra Password Protection?

Nepodporováno Po nasazení a povolení se ochrana heslem Microsoft Entra vztahuje stejně na všechny uživatele.

Jaký je rozdíl mezi změnou hesla a nastavením hesla (nebo resetováním)?

Změna hesla spočívá v tom, že uživatel zvolí nové heslo po prokázání, že má znalosti o starém heslu. Například změna hesla se stane, když se uživatel přihlásí do Windows a zobrazí se výzva k výběru nového hesla.

Sada hesel (někdy označovaná jako resetování hesla) je, když správce nahradí heslo účtu novým heslem, například pomocí nástroje pro správu Uživatelé a počítače služby Active Directory. Tato operace vyžaduje vysokou úroveň oprávnění (obvykle Správce domény) a osoba, která operaci provádí, obvykle nemá znalosti o starém heslu. Scénáře help-desku často provádějí sady hesel, například při pomoci uživateli, který zapomněl heslo. Při prvním vytvoření zcela nového uživatelského účtu s heslem se zobrazí také události nastavení hesla.

Zásady ověřování hesel se chovají stejně bez ohledu na to, jestli se provádí změna nebo nastavení hesla. Služba agenta DC služby Microsoft Entra Password Protection provádí protokoly různých událostí, které vás informují o tom, jestli byla provedena operace změny nebo nastavení hesla. Podívejte se na monitorování a protokolování microsoft Entra Password Protection.

Ověřuje Microsoft Entra Password Protection stávající hesla po instalaci?

Ne – Microsoft Entra Password Protection může vynutit zásady hesel pouze pro hesla s vymazáním textu během operace změny nebo nastavení hesla. Jakmile služba Active Directory přijme heslo, zachovají se pouze hodnoty hash specifické pro protokol ověřování daného hesla. Heslo s vymazáním textu se nikdy neuchová, proto Microsoft Entra Password Protection nemůže ověřit stávající hesla.

Po počátečním nasazení microsoft Entra Password Protection začnou všichni uživatelé a účty nakonec používat heslo ověřené heslem Microsoft Entra, protože jejich stávající hesla obvykle vyprší v průběhu času. V případě potřeby můžete tento proces urychlit jednorázovým ručním vypršením hesel uživatelských účtů.

Účty nakonfigurované s textem "Heslo nikdy nevyprší platnost" se nevynucují ke změně hesla, pokud se nedokončí ruční vypršení platnosti.

Proč se duplicitní události zamítnutí hesla protokolují při pokusu o nastavení slabého hesla pomocí modulu snap-in správy Uživatelé a počítače služby Active Directory?

Modul snap-in správa Uživatelé a počítače služby Active Directory se nejprve pokusí nastavit nové heslo pomocí protokolu Kerberos. Při selhání provede modul snap-in druhý pokus o nastavení hesla pomocí starší verze protokolu (SAM RPC). Používané konkrétní protokoly nejsou důležité. Pokud je nové heslo považováno za slabé službou Microsoft Entra Password Protection, toto chování modulu snap-in vytvoří dvě sady událostí zamítnutí resetování hesel, které se protokolují.

Proč se protokolují události ověřování hesel microsoft Entra Password Protection s prázdným uživatelským jménem?

Služba Active Directory podporuje možnost otestovat heslo a zjistit, jestli splňuje aktuální požadavky na složitost hesla domény, například pomocí rozhraní API NetValidatePasswordPolicy . Při ověření hesla tímto způsobem zahrnuje testování také ověřování pomocí produktů založených na filtru hesel, jako je microsoft Entra Password Protection, ale uživatelská jména předaná dané knihovně DLL filtru hesel jsou prázdná. V tomto scénáři microsoft Entra Password Protection stále ověřuje heslo pomocí aktuálně aktivních zásad hesel a vydává zprávu protokolu událostí, aby zachytil výsledek. Zpráva protokolu událostí ale bude obsahovat prázdná pole uživatelského jména.

Mám hybridní uživatele, kteří se pokusí změnit heslo v Microsoft Entra ID a obdrží odpověď "Toto heslo jsme viděli příliš mnohokrát předtím. Zvolte něco, co je těžší odhadnout." Proč se v tomto případě nezobrazuje pokus o ověření místně?

Když hybridní uživatel změní heslo v Microsoft Entra ID, ať už prostřednictvím Microsoft Entra SSPR, MyAccount nebo jiného mechanismu změny hesla Microsoft Entra, vyhodnotí se jeho heslo vůči globálním a vlastním zakázaným seznamům hesel v cloudu. Když heslo dosáhne služby Active Directory prostřednictvím zpětného zápisu hesla, je již ověřeno v ID Microsoft Entra.

Resetování hesla a změny zahájené v ID Microsoft Entra, které ověřování hybridních uživatelů selžou, najdete v protokolech auditu Microsoft Entra. Viz Řešení potíží s samoobslužným resetováním hesla v Microsoft Entra ID.

Podporuje se instalace služby Microsoft Entra Password Protection vedle jiných produktů založených na filtrování hesel?

Ano. Podpora více registrovaných knihoven DLL filtru hesel je základní funkce systému Windows, která není specifická pro microsoft Entra Password Protection. Všechny knihovny DLL registrovaného filtru hesel musí souhlasit před přijetím hesla.

Jak můžu nasadit a nakonfigurovat ochranu heslem Microsoft Entra v prostředí Active Directory bez použití Azure?

Nepodporováno Microsoft Entra Password Protection je funkce Azure, která podporuje rozšíření do místní Active Directory prostředí.

Jak můžu upravit obsah zásad na úrovni služby Active Directory?

Nepodporováno Zásady je možné spravovat pouze pomocí Centra pro správu Microsoft Entra. Podívejte se také na předchozí otázku.

Proč se pro replikaci sysvol vyžaduje replikace DFSR?

Služba FRS (předchůdce distribuovaného systému souborů DFSR) má mnoho známých problémů a v novějších verzích služby Windows Server Active Directory je zcela nepodporovaná. Testování ochrany heslem Microsoft Entra se provádí na doménách nakonfigurovaných službou FRS.

Další informace najdete v následujících článcích:

Případ migrace replikace sysvol do DFSR

Konec je pro FRS nigh

Pokud vaše doména ještě nepoužívá DFSR, musíte ji před instalací služby Microsoft Entra Password Protection migrovat, aby používala DFSR. Další informace najdete na následujícím odkazu:

Průvodce migrací replikace SYSVOL: Replikace FRS do DFS

Upozorňující

Microsoft Entra Password Protection DC Agent software v současné době instaluje na řadiče domény v doménách, které stále používají frS pro replikaci sysvol, ale software v tomto prostředí nefunguje správně. Negativní vedlejší účinky zahrnují jednotlivé soubory, které se nedaří replikovat, a procedury obnovení sysvol se jeví jako úspěšné, ale bezobslužné replikace všech souborů. Doménu byste měli migrovat tak, aby co nejdříve používala DFSR, a to jak pro vlastní výhody DFSR, tak i pro odblokování nasazení služby Microsoft Entra Password Protection. Budoucí verze softwaru se automaticky deaktivují při spuštění v doméně, která stále používá službu FRS.

Kolik místa na disku tato funkce vyžaduje ve sdílené složce sysvol domény?

Přesné využití místa se liší, protože závisí na faktorech, jako je počet a délka zakázaných tokenů v globálním seznamu zakázaných v Microsoftu a na vlastním seznamu pro jednotlivé tenanty a na režii šifrování. Obsah těchto seznamů bude pravděpodobně v budoucnu růst. S ohledem na to je rozumné očekávání, že funkce vyžaduje alespoň pět (5) megabajtů prostoru ve sdílené složce sysvol domény.

Proč se k instalaci nebo upgradu softwaru agenta DC vyžaduje restartování?

Tento požadavek je způsoben základním chováním systému Windows.

Existuje nějaký způsob, jak nakonfigurovat agenta řadiče domény tak, aby používal konkrétní proxy server?

Ne. Vzhledem k tomu, že proxy server je bezstavový, není důležité, který konkrétní proxy server se používá.

Je v pořádku nasadit službu Proxy služby Microsoft Entra Password Protection souběžně s dalšími službami, jako je Microsoft Entra Connect?

Ano. Služba Proxy služby Microsoft Entra Password Protection a Microsoft Entra Connect by nikdy neměly být v konfliktu přímo s ostatními.

Software proxy služby Microsoft Entra Password Protection bohužel nainstaluje verzi služby Microsoft Entra Connect Agent Updater, která není kompatibilní s verzí nainstalovanou softwarem proxy aplikací Microsoft Entra. Kvůli tomuto nekompatibilitě může dojít k tomu, že služba Agent Updater nemůže kontaktovat Azure pro aktualizace softwaru. Nedoporučuje se instalovat proxy služby Microsoft Entra Password Protection a proxy aplikací Microsoft Entra na stejný počítač.

V jakém pořadí by se agenti řadiče domény a proxy servery měli nainstalovat a zaregistrovat?

Je podporováno řazení instalace agenta proxy serveru, instalace agenta řadiče domény, registrace doménové struktury a registrace proxy serveru.

Mám se obávat výkonu řadičů domény při nasazování této funkce?

Služba agenta DC služby Microsoft Entra Password Protection by neměla výrazně ovlivnit výkon řadiče domény v existujícím nasazení služby Active Directory, která je v pořádku.

U většiny nasazení služby Active Directory jsou operace změn hesel malým podílem celkové úlohy na jakémkoli řadiči domény. Představte si například doménu služby Active Directory s 10 000 uživatelskými účty a zásadou MaxPasswordAge nastavenou na 30 dnů. V průměru tato doména vidí 1 0000/30=~333 operací změny hesla každý den, což je malý počet operací pro dokonce jeden řadič domény. Představte si potenciální scénář nejhoršího případu: Předpokládejme, že se tyto změny hesla v jednom řadiči domény provedly během jedné hodiny přibližně 333. Tento scénář může například nastat, když mnoho zaměstnanců přijde do práce v pondělí ráno. I v takovém případě se stále díváme na přibližně 333/60 minut = šest změn hesla za minutu, což opět není významné zatížení.

Pokud ale vaše aktuální řadiče domény už běží na úrovních s omezeným výkonem (například s ohledem na procesor, místo na disku, vstupně-výstupní operace disku atd.), je vhodné před nasazením této funkce přidat další řadiče domény nebo rozšířit dostupné místo na disku. Projděte si předchozí otázku týkající se výše uvedeného využití místa na disku sysvol.

Chci otestovat ochranu heslem Microsoft Entra na několika řadičích domény v mé doméně. Je možné vynutit, aby změny uživatelského hesla používaly tyto konkrétní řadiče domény?

Ne. Klientský operační systém Windows určuje, který řadič domény se používá, když uživatel změní heslo. Řadič domény je vybrán na základě faktorů, jako jsou přiřazení lokality služby Active Directory a podsítě, konfigurace sítě specifické pro prostředí atd. Microsoft Entra Password Protection neřídí tyto faktory a nemůže ovlivnit, který řadič domény je vybrán pro změnu hesla uživatele.

Jedním ze způsobů, jak tento cíl částečně dosáhnout, je nasadit ochranu heslem Microsoft Entra na všechny řadiče domény v dané lokalitě služby Active Directory. Tento přístup poskytuje přiměřené pokrytí pro klienty Windows přiřazené k dané lokalitě a pro uživatele, kteří se k těmto klientům přihlašují a mění svá hesla.

Pokud nainstaluji službu agenta DC služby Microsoft Entra Password Protection na pouze primární řadič domény (PDC), budou také chráněny všechny ostatní řadiče domény v doméně?

Ne. Když se heslo uživatele změní na daném řadiči domény, který není primárním řadičem domény, heslo pro vymazání textu se nikdy neodesílají do primárního řadiče domény (tato myšlenka je běžným nesprávným vnímáním). Po přijetí nového hesla na daném řadiči domény tento řadič domény použije toto heslo k vytvoření různých hodnot hash specifických pro protokol ověřování tohoto hesla a pak tyto hodnoty hash zachovají v adresáři. Heslo pro vymazání textu se neuchová. Aktualizované hodnoty hash se pak replikují do primárního řadiče domény. Uživatelská hesla se v některých případech můžou změnit přímo na primárním řadiči domény, a to znovu v závislosti na různých faktorech, jako je například síťová topologie a návrh lokality služby Active Directory. (Viz předchozí otázka.)

Stručně řečeno, nasazení služby agenta DC služby Microsoft Entra Password Protection DC na primárním řadiči domény je nutné k dosažení 100% pokrytí zabezpečení funkce v celé doméně. Nasazení funkce na primárním řadiči domény neposkytuje výhody zabezpečení microsoft Entra Password Protection jenom pro žádné jiné řadiče domény v doméně.

Proč vlastní inteligentní uzamčení nefunguje ani po instalaci agentů v mém místní Active Directory prostředí?

Vlastní inteligentní uzamčení je podporováno pouze v Microsoft Entra ID. Změny vlastního nastavení inteligentního uzamčení v Centru pro správu Microsoft Entra nemají žádný vliv na místní Active Directory prostředí, a to ani s nainstalovanými agenty.

Je sada Management Pack nástroje System Center Operations Manager dostupná pro ochranu heslem společnosti Microsoft Entra?

Ne.

Proč Microsoft Entra ID stále odmítá slabá hesla, i když jsem nakonfiguroval zásady tak, aby byly v režimu auditování?

Režim auditu se podporuje jenom v místní Active Directory prostředí. Id Microsoft Entra je při vyhodnocování hesel implicitně vždy v režimu vynucení.

Moji uživatelé uvidí tradiční chybovou zprávu systému Windows, když je heslo odmítnuto službou Microsoft Entra Password Protection. Je možné tuto chybovou zprávu přizpůsobit tak, aby uživatelé věděli, co se skutečně stalo?

Ne. Chybová zpráva, kterou uživatelé vidí, když je heslo odmítnuto řadičem domény, je řízeno klientským počítačem, nikoli řadičem domény. K tomuto chování dochází, pokud je heslo odmítnuto výchozími zásadami hesel služby Active Directory nebo řešením založeným na filtru hesel, jako je například Ochrana heslem Microsoft Entra.

Možná budete chtít provést základní testování různých hesel, abyste ověřili správné fungování softwaru a lépe porozuměli algoritmu vyhodnocení hesla. Tato část popisuje metodu takového testování, která je navržená tak, aby vytvářela opakovatelné výsledky.

Proč je nutné postupovat podle těchto kroků? Existuje několik faktorů, které ztěžují provádění kontrolovaných a opakovatelných testů hesel v prostředí místní Active Directory:

• Zásady hesel se konfigurují a uchovávají v Azure a kopie zásad se pravidelně synchronizují místními agenty DC pomocí mechanismu dotazování. Latence spojená s tímto cyklem dotazování může způsobit nejasnosti. Pokud například nakonfigurujete zásadu v Azure, ale zapomenete ji synchronizovat s agentem řadiče domény, nemusí testy přinést očekávané výsledky. Interval dotazování je momentálně pevně zakódovaný tak, aby byl jednou za hodinu, ale čekání na hodinu mezi změnami zásad není ideální pro interaktivní scénář testování.
• Jakmile se nové zásady hesel synchronizují s řadičem domény, dojde při replikaci do jiných řadičů domény s větší latencí. Tato zpoždění můžou způsobit neočekávané výsledky, pokud otestujete změnu hesla na řadiči domény, který nepřijal nejnovější verzi zásady.
• Testování změn hesel prostřednictvím uživatelského rozhraní znesnadňuje spolehlivost výsledků. Do uživatelského rozhraní je například snadné chybně zadat neplatné heslo, zejména proto, že většina uživatelských rozhraní hesel skryje uživatelský vstup (například Windows Ctrl-Alt-Delete -> Změnit uživatelské rozhraní hesla).
• Při testování změn hesel z klientů připojených k doméně není možné striktně řídit, který řadič domény se používá. Klientský operační systém Windows vybere řadič domény na základě faktorů, jako jsou lokality služby Active Directory a přiřazení podsítí, konfigurace sítě specifické pro prostředí atd.

Abyste se těmto problémům vyhnuli, jsou následující kroky založené na testování resetování hesel pomocí příkazového řádku při přihlášení k řadiči domény.

Upozorňující

Tyto postupy používejte pouze v testovacím prostředí. Zatímco je služba agenta řadiče domény zastavená, všechny příchozí změny hesla a resetování se přijímají bez ověření. To také pomáhá vyhnout se zvýšeným rizikům přihlášení k řadiči domény.

Následující kroky předpokládají, že jste agenta řadiče domény nainstalovali alespoň na jeden řadič domény, nainstalovali aspoň jeden proxy server a zaregistrovali proxy server i doménovou strukturu.

1. Přihlaste se k řadiči domény pomocí přihlašovacích údajů správce domény nebo jiných přihlašovacích údajů, které mají dostatečná oprávnění k vytvoření testovacích uživatelských účtů a resetování hesel. Ujistěte se, že je na řadiči domény nainstalovaný software agenta řadiče domény a že se restartoval.

2. Otevřete Prohlížeč událostí a přejděte do protokolu událostí správce agenta DC.

3. Otevřete okno příkazového řádku se zvýšenými oprávněními.

4. Vytvoření testovacího účtu pro testování hesel

   Existuje mnoho způsobů, jak vytvořit uživatelský účet, ale možnost příkazového řádku je zde nabízena jako způsob, jak ho během opakovaných testovacích cyklů snadno usnadnit:

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

   Pro účely diskuze níže předpokládejme, že jsme vytvořili testovací účet s názvem ContosoUser, například:

   net.exe user ContosoUser /add <password>
   

5. Přihlaste se do Centra pro správu Microsoft Entra jako alespoň správce ověřování.

6. Přejděte k metodám > ověřování ochrany > heslem.

7. Podle potřeby upravte zásady ochrany heslem microsoft Entra pro testování, které chcete provést. Můžete se například rozhodnout, že nakonfigurujete vynucený nebo auditní režim, nebo se rozhodnete změnit seznam zakázaných termínů ve vašem vlastním seznamu zakázaných hesel.

8. Synchronizujte nové zásady zastavením a restartováním služby agenta řadiče domény.

   Tento krok lze provést různými způsoby. Jedním ze způsobů je použít konzolu pro správu správy služeb tak, že kliknete pravým tlačítkem myši na službu Agent DC služby Microsoft Entra Password Protection a zvolíte Možnost Restartovat. Z okna příkazového řádku je možné provést jiný způsob:

   net stop AzureADPasswordProtectionDCAgent && net start AzureADPasswordProtectionDCAgent
   

9. Zkontrolujte Prohlížeč událostí a ověřte, že byly staženy nové zásady.

   Při každém zastavení a spuštění služby agenta DC by se měly zobrazit dvě události 30006 vydané v úzkém pořadí. První událost 30006 bude odrážet zásadu uloženou na disku ve sdílené složce sysvol. Druhá událost 30006 (pokud je k dispozici) by měla mít aktualizované datum zásady tenanta, a pokud ano, bude odrážet zásady, které byly staženy z Azure. Hodnota data zásad tenanta je aktuálně zakódovaná tak, aby zobrazovala přibližné časové razítko, které byly zásady staženy z Azure.

   Pokud se druhá událost 30006 nezobrazí, měli byste problém vyřešit, než budete pokračovat.

   Události 30006 budou vypadat podobně jako v tomto příkladu:

   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
   

   Změna mezi režimem vynucení a auditování například způsobí úpravu příznaku AuditOnly (zásada uvedená s AuditOnly=0 je v režimu vynucení). Změny vlastního seznamu zakázaných hesel se neprojeví přímo ve výše uvedené události 30006 a nejsou zaprotokolovány nikde jinde z bezpečnostních důvodů. Po dokončení této změny se zásada z Azure úspěšně stáhne i do upraveného seznamu zakázaných hesel.

10. Spusťte test tak, že se pokusíte resetovat nové heslo na testovacím uživatelském účtu.

    Tento krok je možné provést z okna příkazového řádku, například takto:

    net.exe user ContosoUser <password>
    

    Po spuštění příkazu můžete získat další informace o výsledku příkazu tak, že se podíváte do prohlížeče událostí. Události výsledku ověření hesla jsou popsané v tématu protokolu událostí správce agenta DC. Tyto události použijete k ověření výsledku testu kromě interaktivního výstupu z příkazů net.exe.

    Pojďme si vyzkoušet příklad: pokus o nastavení hesla, které je zakázáno globálním seznamem Microsoftu (všimněte si, že tento seznam není zdokumentovaný , ale můžeme zde testovat proti známému zakázanému termínu). Tento příklad předpokládá, že jste nakonfigurovali zásadu v režimu vynucení a přidali jste do vlastního seznamu zakázaných hesel nulové termíny.

    net.exe user ContosoUser PassWord
    The password doesn't 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.
    

    Podle dokumentace, protože náš test byl operace resetování hesla, měla by se zobrazit událost 10017 a 30005 pro uživatele ContosoUser.

    Událost 10017 by měla vypadat jako v tomto příkladu:

    The reset password for the specified user was rejected because it didn't comply with the current Azure password policy. For more information, please see the correlated event log message.
    
    UserName: ContosoUser
    FullName: 
    

    Událost 30005 by měla vypadat jako v tomto příkladu:

    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: 
    

    To bylo zábavné - pojďme vyzkoušet další příklad! Teď se pokusíme nastavit heslo, které je zakázané vlastním zakázaným seznamem, zatímco zásady jsou v režimu auditování. Tento příklad předpokládá, že jste dokončili následující kroky: nakonfigurovali jste zásadu tak, aby byla v režimu auditování, přidali do vlastního seznamu zakázaných hesel termín "lachrymose" a synchronizovali výsledné nové zásady s řadičem domény tak, že jste službu agenta řadiče domény překonfigurovali podle předchozího popisu.

    Ok, nastavte variantu zakázaného hesla:

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

    Mějte na paměti, že tentokrát bylo úspěšné, protože zásada je v režimu auditování. Pro uživatele ContosoUser by se měla zobrazit událost 10025 a 30007.

    Událost 10025 by měla vypadat jako v tomto příkladu:

    The reset password for the specified user would normally have been rejected because it didn't 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: 
    

    Událost 30007 by měla vypadat jako v tomto příkladu:

    The reset password for the specified user would normally be 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. Pokračujte v testování různých hesel podle vašeho výběru a kontrolujte výsledky v prohlížeči událostí pomocí postupů popsaných v předchozích krocích. Pokud potřebujete změnit zásady v Centru pro správu Microsoft Entra, nezapomeňte nové zásady synchronizovat s agentem dc, jak je popsáno výše.

Probrali jsme postupy, které vám umožňují provádět řízené testování chování ověřování hesel microsoft Entra Password Protection. Resetování uživatelských hesel z příkazového řádku přímo na řadiči domény může vypadat jako lichý způsob testování, ale jak je popsáno dříve, je navržené tak, aby vytvářelo opakovatelné výsledky. Při testování různých hesel mějte na paměti algoritmus vyhodnocení hesla, protože vám může pomoct vysvětlit výsledky, které jste neočekádali.

Upozorňující

Po dokončení veškerého testování nezapomeňte odstranit všechny uživatelské účty vytvořené pro účely testování.

Následující odkazy nejsou součástí základní dokumentace microsoft Entra Password Protection, ale mohou být užitečným zdrojem dalších informací o této funkci.

Microsoft Entra Password Protection je nyní obecně dostupný!

Průvodce ochranou před útoky phishing e-mailu – část 15: Implementujte službu Microsoft Entra Password Protection Service (pro místní prostředí!)

Microsoft Entra Password Protection a Inteligentní uzamčení jsou teď ve verzi Public Preview!

Pokud se chcete dozvědět více o službě Microsoft Entra Password Protection a jejím nasazení, můžete použít proaktivní službu Microsoftu. Tato služba je k dispozici zákazníkům se smlouvou Premier nebo Unified Support. Tato služba se nazývá Microsoft Entra ID: Ochrana heslem. Další informace získáte od manažera zákaznického úspěchu.

Další kroky

Pokud máte místní otázku Microsoft Entra Password Protection, která zde není zodpovězena, odešlete níže položku Váš názor – děkujeme vám!

Nasazení ochrany heslem Microsoft Entra