Ez a szakasz a Microsoft Entra Jelszóvédelemmel kapcsolatos gyakori kérdésekre ad választ.
Általános kérdések
Milyen útmutatást kell adni a felhasználóknak a biztonságos jelszó kiválasztásához?
A Microsoft aktuális útmutatója ebben a témakörben az alábbi hivatkozáson érhető el:
Útmutató a Microsoft jelszóhoz
Támogatott a helyszíni Microsoft Entra Password Protection nem nyilvános felhőkben?
A helyszíni Microsoft Entra Password Protection mind az Azure Global, mind az Azure Government felhőkben támogatott.
A Microsoft Entra felügyeleti központ lehetővé teszi a helyszíni "Jelszóvédelem a Windows Server Active Directoryhoz" konfiguráció módosítását a nem támogatott felhőkben; az ilyen módosítások megmaradnak, de soha nem lépnek érvénybe. A helyszíni proxyügynökök vagy erdők regisztrációja nem támogatott a nem támogatott felhőkben, és az ilyen regisztrációs kísérletek mindig sikertelenek.
Hogyan alkalmazhatom a Microsoft Entra Password Protection előnyeit a helyszíni felhasználók egy részhalmazára?
Nem támogatott. Az üzembe helyezés és engedélyezés után a Microsoft Entra Password Protection minden felhasználóra egyformán érvényes.
Mi a különbség a jelszómódosítás és a jelszókészlet (vagy az alaphelyzetbe állítás) között?
A jelszómódosítás az, amikor a felhasználó új jelszót választ, miután igazolta, hogy ismeri a régi jelszót. Például a jelszó módosítása az, ami akkor történik, amikor egy felhasználó bejelentkezik a Windowsba, és a rendszer kérni fogja, hogy válasszon új jelszót.
A jelszókészlet (más néven jelszó-visszaállítás) az, amikor a rendszergazda egy fiók jelszavát új jelszóra cseréli, például a Active Directory - felhasználók és számítógépek felügyeleti eszköz használatával. Ez a művelet magas szintű jogosultságot igényel (általában tartományi rendszergazda), és a műveletet végrehajtó személy általában nem ismeri a régi jelszót. Az ügyfélszolgálati forgatókönyvek gyakran végeznek jelszókészleteket, például amikor segítséget nyújtanak egy olyan felhasználónak, aki elfelejtette a jelszavát. A jelszókészlet eseményei akkor is megjelennek, ha egy teljesen új felhasználói fiók jön létre először jelszóval.
A jelszóérvényesítési szabályzat ugyanúgy viselkedik, függetlenül attól, hogy a jelszó módosítása vagy beállítása folyamatban van-e. A Microsoft Entra Password Protection DC Agent szolgáltatás különböző eseményeket naplóz, hogy tájékoztassa Önt arról, hogy történt-e jelszómódosítási vagy -beállítási művelet. Lásd: Microsoft Entra Password Protection monitorozás és naplózás.
A Microsoft Entra Password Protection ellenőrzi a meglévő jelszavakat a telepítés után?
Nem – A Microsoft Entra Password Protection csak a jelszó módosítása vagy beállítása során kényszeríthet jelszóházirendet a egyértelmű szöveges jelszavakra. Miután az Active Directory elfogadta a jelszót, a rendszer csak a jelszó hitelesítési protokollspecifikus kivonatait megőrzi. A tiszta szöveges jelszó soha nem marad meg, ezért a Microsoft Entra Password Protection nem tudja érvényesíteni a meglévő jelszavakat.
A Microsoft Entra Password Protection kezdeti üzembe helyezése után az összes felhasználó és fiók végül egy Microsoft Entra Password Protection által ellenőrzött jelszót fog használni, mivel a meglévő jelszavaik általában lejárnak az idő múlásával. Igény szerint felgyorsíthatja ezt a folyamatot a felhasználói fiókok jelszavainak egyszeri manuális lejáratával.
A "jelszó soha nem jár le" beállítással konfigurált fiókoknak nem kell módosítaniuk a jelszavukat, hacsak a manuális lejárat nem történik meg.
Miért vannak naplózva a duplikált jelszó-elutasítási események, amikor gyenge jelszót próbál beállítani a Active Directory - felhasználók és számítógépek felügyeleti beépülő modul használatával?
A Active Directory - felhasználók és számítógépek felügyeleti beépülő modul először megpróbálja beállítani az új jelszót a Kerberos protokoll használatával. Hiba esetén a beépülő modul egy második kísérletet tesz a jelszó beállítására egy örökölt (SAM RPC) protokoll használatával. A használt protokollok nem fontosak. Ha a Microsoft Entra Password Protection gyengének tekinti az új jelszót, ez a beépülő modul két jelszó-visszaállítási elutasítási eseményt naplóz.
Miért van a Microsoft Entra Password Protection jelszóérvényesítési eseményeinek naplózása üres felhasználónévvel?
Az Active Directory támogatja a jelszó tesztelését annak ellenőrzéséhez, hogy megfelel-e a tartomány jelenlegi jelszóbonyolítási követelményeinek, például a NetValidatePasswordPolicy api használatával. Ha egy jelszó ilyen módon van érvényesítve, a tesztelés magában foglalja a jelszószűrő-dll-alapú termékek, például a Microsoft Entra Password Protection általi ellenőrzést is, de az adott jelszószűrő DLL-nek átadott felhasználónevek üresek. Ebben a forgatókönyvben a Microsoft Entra Password Protection továbbra is érvényesíti a jelszót a jelenleg hatályos jelszószabályzat használatával, és eseménynapló-üzenetet ad ki az eredmény rögzítéséhez. Az eseménynapló üzenetében azonban üres felhasználónévmezők jelennek meg.
Vannak hibrid felhasználóim, akik megpróbálják módosítani a jelszavukat a Microsoft Entra-azonosítóban, és a következő választ kapják: "Ezt a jelszót túl sokszor láttuk korábban. Válasszon valamit, amit nehezebb kitalálni." Ebben az esetben miért nem látok helyszíni érvényesítési kísérletet?
Amikor egy hibrid felhasználó megváltoztatja a jelszavát a Microsoft Entra ID-ban, akár a Microsoft Entra SSPR, a MyAccount vagy egy másik Microsoft Entra jelszómódosítási mechanizmuson keresztül, a rendszer kiértékeli a jelszót a felhőben található globális és egyéni tiltott jelszólisták alapján. Amikor a jelszó jelszóvisszaíróval éri el az Active Directoryt, az már érvényesítve lesz a Microsoft Entra-azonosítóban.
A microsoft entra-azonosítóban kezdeményezett jelszó-visszaállítások és a hibrid felhasználók sikertelen ellenőrzése során kezdeményezett módosítások a Microsoft Entra naplózási naplóiban találhatók. Lásd: Az önkiszolgáló jelszó-visszaállítás hibaelhárítása a Microsoft Entra-azonosítóban.
Támogatott a Microsoft Entra Password Protection telepítése más jelszószűrő-alapú termékekkel együtt?
Igen. A több regisztrált jelszószűrő dll támogatása egy alapvető Windows-funkció, amely nem a Microsoft Entra Password Protectionre vonatkozik. A jelszó elfogadása előtt minden regisztrált jelszószűrő dll-nek meg kell egyeznie.
Hogyan helyezhetem üzembe és konfigurálhatom a Microsoft Entra Password Protectiont az Active Directory-környezetemben az Azure használata nélkül?
Nem támogatott. A Microsoft Entra Password Protection egy Azure-funkció, amely támogatja a helyi Active Directory környezetbe való kiterjesztését.
Hogyan módosíthatom a szabályzat tartalmát az Active Directory szintjén?
Nem támogatott. A szabályzat csak a Microsoft Entra felügyeleti központban felügyelhető. Lásd az előző kérdést is.
Miért van szükség elosztott fájlrendszer-replikációra a sysvol replikációhoz?
Az FRS (az DFSR megelőző technológiája) számos ismert problémával rendelkezik, és teljes mértékben nem támogatott a Windows Server Active Directory újabb verzióiban. A Microsoft Entra Password Protection nulla tesztelése frS-konfigurált tartományokon történik.
További információkért tekintse meg a következő cikkeket:
A sysvol replikáció DFSR-be való migrálásának esete
Ha a tartománya még nem használja az elosztott fájlrendszert, a Microsoft Entra Password Protection telepítése előtt át kell telepítenie az elosztott fájlrendszer használatára. További információkért tekintse meg az alábbi hivatkozást:
SYSVOL replikációs migrálási útmutató: FRS–elosztott fájlrendszerbeli replikáció
Figyelmeztetés
A Microsoft Entra Password Protection DC Agent szoftver jelenleg olyan tartományok tartományvezérlőire települ, amelyek még frS-t használnak a sysvol replikációhoz, de a szoftver ebben a környezetben nem működik megfelelően. A negatív mellékhatások közé tartoznak az egyes fájlok replikálása sikertelensége, és a sysvol visszaállítási eljárásai sikeresnek tűnnek, de csendesen nem replikálják az összes fájlt. A tartományt migrálnia kell, hogy a lehető leghamarabb használhassa az elosztott fájlrendszert, mind az elosztott fájlrendszer alapvető előnyeinek érdekében, mind a Microsoft Entra Password Protection telepítésének letiltásához. A szoftver jövőbeli verziói automatikusan le lesznek tiltva, ha az FRS-t még használó tartományban fut.
Mennyi lemezterületre van szüksége a szolgáltatásnak a sysvol tartománymegosztáson?
A pontos helyhasználat változó, mivel olyan tényezőktől függ, mint a Microsoft globális tiltott listájában szereplő tiltott jogkivonatok száma és hossza, valamint a bérlőnkénti egyéni lista, valamint a titkosítási többletterhelés. Ezeknek a listáknak a tartalma valószínűleg növekedni fog a jövőben. Ezt szem előtt tartva ésszerű elvárás, hogy a szolgáltatás legalább öt (5) megabájtnyi területet igényel a sysvol tartománymegosztáson.
Miért van szükség újraindításra a DC agent szoftver telepítéséhez vagy frissítéséhez?
Ezt a követelményt a Windows alapvető viselkedése okozza.
Konfigurálható egy tartományvezérlő-ügynök egy adott proxykiszolgáló használatára?
Szám Mivel a proxykiszolgáló állapot nélküli, nem fontos, hogy melyik proxykiszolgálót használja a rendszer.
Nem baj, ha a Microsoft Entra jelszóvédelmi proxyszolgáltatást más szolgáltatásokkal, például a Microsoft Entra Connecttel együtt telepíti?
Igen. A Microsoft Entra Jelszóvédelmi proxyszolgáltatás és a Microsoft Entra Connect soha nem ütközhet közvetlenül egymással.
Sajnos a Microsoft Entra jelszóvédelmi proxyszoftver telepíti a Microsoft Entra Connect Agent Updater szolgáltatás olyan verzióját, amely nem kompatibilis a Microsoft Entra alkalmazásproxy szoftver által telepített verzióval. Ez az inkompatibilitás azt eredményezheti, hogy az Ügynökfrissítési szolgáltatás nem tud kapcsolatba lépni az Azure-sal szoftverfrissítésekért. Nem ajánlott a Microsoft Entra jelszóvédelmi proxy és a Microsoft Entra alkalmazásproxy telepítése ugyanazon a gépen.
Milyen sorrendben kell telepíteni és regisztrálni a DC-ügynököket és proxykat?
A proxyügynök telepítésének, a tartományvezérlő-ügynök telepítésének, az erdőregisztrációnak és a proxyregisztrációnak a megrendelése támogatott.
Nem kell aggódnom a tartományvezérlők teljesítménycsökkenése miatt a funkció üzembe helyezésétől?
A Microsoft Entra Password Protection DC Agent szolgáltatásnak nem szabad jelentősen befolyásolnia a tartományvezérlő teljesítményét egy meglévő kifogástalan Active Directory-telepítésben.
A legtöbb Active Directory-telepítés esetében a jelszómódosítási műveletek az adott tartományvezérlő teljes számítási feladatainak kis hányadát képezik. Tegyük fel például, hogy egy 10 000 felhasználói fiókkal rendelkező Active Directory-tartomány és egy MaxPasswordAge szabályzat 30 napra van beállítva. Ez a tartomány naponta átlagosan 10000/30=~333 jelszómódosítási műveletet lát, ami még egyetlen tartományvezérlő esetében is kisebb számú művelet. Tekintsünk egy lehetséges legrosszabb esetet: tegyük fel, hogy ezek a ~333 jelszómódosítások egyetlen tartományvezérlőn egy órán keresztül történtek. Ez a forgatókönyv például akkor fordulhat elő, ha sok alkalmazott hétfő reggel dolgozik. Még ebben az esetben is ~333/60 perc = percenként hat jelszómódosítást vizsgáljuk, ami szintén nem jelentős terhelés.
Ha azonban a jelenlegi tartományvezérlők már teljesítménykorlátozott szinten futnak (például a processzor, a lemezterület, a lemez I/O és így tovább), célszerű további tartományvezérlőket hozzáadni, vagy bővíteni a rendelkezésre álló lemezterületet a szolgáltatás üzembe helyezése előtt. Tekintse meg a fenti sysvol lemezterület-használattal kapcsolatos előző kérdést.
A Microsoft Entra Password Protectiont a tartományom néhány tartományvezérlőjén szeretném tesztelni. Kényszeríthető a felhasználói jelszó módosítása az adott tartományvezérlők használatára?
Szám A Windows-ügyfél operációs rendszere szabályozza, hogy melyik tartományvezérlőt használja a rendszer, amikor egy felhasználó módosítja a jelszavát. A tartományvezérlő olyan tényezők alapján van kiválasztva, mint az Active Directory-hely- és alhálózat-hozzárendelések, a környezetspecifikus hálózati konfiguráció stb. A Microsoft Entra Password Protection nem szabályozza ezeket a tényezőket, és nem tudja befolyásolni, hogy melyik tartományvezérlő legyen kiválasztva a felhasználó jelszavának módosításához.
Ennek a célnak a részleges elérésének egyik módja a Microsoft Entra Password Protection üzembe helyezése egy adott Active Directory-webhelyen található összes tartományvezérlőn. Ez a megközelítés ésszerű lefedettséget biztosít az adott helyhez rendelt Windows-ügyfelekre, valamint azokra a felhasználókra, akik bejelentkeznek ezekbe az ügyfelekbe, és módosítják a jelszavukat.
Ha a Microsoft Entra Password Protection DC Agent szolgáltatást csak az elsődleges tartományvezérlőre (PDC) telepítem, akkor a tartomány összes többi tartományvezérlője is védett lesz?
Szám Ha egy felhasználó jelszava egy adott nem PDC-tartományvezérlőn módosul, a rendszer soha nem küldi el a tiszta szöveges jelszót a PDC-nek (ez az ötlet gyakori téves észlelés). Ha egy adott tartományvezérlő új jelszót fogad el, a tartományvezérlő ezzel a jelszóval hozza létre a jelszó különböző hitelesítési protokollspecifikus kivonatait, majd megőrzi ezeket a kivonatokat a címtárban. A tiszta szöveges jelszó nem marad meg. A frissített kivonatok ezután replikálódnak a PDC-be. A felhasználói jelszavak bizonyos esetekben közvetlenül a PDC-n módosíthatók, más tényezőktől függően, mint például a hálózati topológia és az Active Directory-hely kialakítása. (Lásd az előző kérdést.)
Összefoglalva, a Microsoft Entra Password Protection DC Agent szolgáltatás központi telepítése a PDC-n a szolgáltatás 100%-os biztonsági lefedettségének eléréséhez szükséges a tartományban. A szolgáltatás csak a PDC-n való üzembe helyezése nem nyújt biztonsági előnyöket a Microsoft Entra Password Protection számára a tartomány bármely más tartományvezérlője számára.
Miért nem működik az egyéni intelligens zárolás, miután az ügynökök telepítve lettek a helyi Active Directory környezetben?
Az egyéni intelligens zárolás csak a Microsoft Entra-azonosítóban támogatott. A Microsoft Entra felügyeleti központban az egyéni intelligens zárolási beállítások módosítása nincs hatással a helyi Active Directory környezetre, még a telepített ügynökök esetében sem.
Elérhető a System Center Operations Manager felügyeleti csomagja a Microsoft Entra Password Protectionhez?
Szám
Miért utasítja el továbbra is a Microsoft Entra-azonosító a gyenge jelszavakat annak ellenére, hogy a szabályzatot naplózási módban konfiguráltam?
A naplózási mód csak a helyi Active Directory környezetben támogatott. A Microsoft Entra ID implicit módon mindig "kényszerítés" módban van, amikor kiértékeli a jelszavakat.
A felhasználók a Hagyományos Windows hibaüzenetet látják, amikor a Microsoft Entra Password Protection elutasít egy jelszót. Testre szabható ez a hibaüzenet, hogy a felhasználók tudják, mi történt valójában?
Szám A felhasználók által a jelszó tartományvezérlő általi elutasításakor megjelenő hibaüzenetet nem a tartományvezérlő, hanem az ügyfélszámítógép vezérli. Ez a viselkedés akkor fordul elő, ha az alapértelmezett Active Directory-jelszószabályzatok elutasítják a jelszót, vagy egy jelszószűrőn alapuló megoldás, például a Microsoft Entra Password Protection.
Jelszótesztelési eljárások
Érdemes lehet a különböző jelszavak alapszintű tesztelését elvégezni a szoftver megfelelő működésének ellenőrzése és a jelszó-kiértékelési algoritmus jobb megismerése érdekében. Ez a szakasz egy olyan módszert vázol fel az ilyen teszteléshez, amely megismételhető eredmények előállítására szolgál.
Miért van szükség az ilyen lépések végrehajtására? Számos tényező megnehezíti a jelszavak ellenőrzött, megismételhető tesztelését a helyi Active Directory környezetben:
- A jelszóházirend konfigurálva és megőrizve van az Azure-ban, és a szabályzat másolatait a helyszíni tartományvezérlő-ügynök(ek) rendszeresen szinkronizálják egy lekérdezési mechanizmus használatával. A lekérdezési ciklusban rejlő késés zavart okozhat. Ha például az Azure-ban konfigurálja a szabályzatot, de elfelejti szinkronizálni a DC-ügynökkel, akkor előfordulhat, hogy a tesztek nem adják meg a várt eredményeket. A lekérdezési időköz jelenleg óránként egyszer van kódolva, de a szabályzatmódosítások közötti várakozás nem ideális interaktív tesztelési forgatókönyvekhez.
- Ha egy új jelszóházirend szinkronizálva van egy tartományvezérlővel, több késés következik be, miközben más tartományvezérlőkre replikálódik. Ezek a késések váratlan eredményeket okozhatnak, ha olyan tartományvezérlőn teszteli a jelszómódosítást, amely nem kapta meg a szabályzat legújabb verzióját.
- A jelszómódosítások felhasználói felületen történő tesztelése megnehezíti az eredmények megbízhatóságát. Könnyen beírhat például egy érvénytelen jelszót egy felhasználói felületbe, különösen azért, mert a legtöbb jelszókezelő felület elrejti a felhasználói bemenetet (például a Windows Ctrl-Alt-Delete –> Jelszó módosítása felhasználói felület).
- Nem lehet szigorúan szabályozni, hogy melyik tartományvezérlőt használja a rendszer a tartományhoz csatlakoztatott ügyfelek jelszómódosításának tesztelése során. A Windows-ügyfél operációs rendszere olyan tényezők alapján választ ki egy tartományvezérlőt, mint az Active Directory-hely- és alhálózat-hozzárendelések, a környezetspecifikus hálózati konfiguráció stb.
A problémák elkerülése érdekében az alábbi lépések a jelszó-visszaállítás parancssori tesztelésén alapulnak, miközben bejelentkeztek egy tartományvezérlőbe.
Figyelmeztetés
Ezeket az eljárásokat csak tesztkörnyezetben használja. Amíg a DC-ügynök szolgáltatás le van állítva, a rendszer érvényesítés nélkül fogadja el az összes bejövő jelszómódosítást és visszaállítást. Ez segít elkerülni a tartományvezérlőbe való bejelentkezés megnövekedett kockázatát is.
Az alábbi lépések feltételezik, hogy a DC-ügynököt legalább egy tartományvezérlőre telepítette, legalább egy proxyt telepített, és regisztrálta a proxyt és az erdőt is.
Jelentkezzen be egy tartományvezérlőre tartományi rendszergazdai hitelesítő adatokkal vagy más hitelesítő adatokkal, amelyek megfelelő jogosultságokkal rendelkeznek a teszt felhasználói fiókok létrehozásához és a jelszavak alaphelyzetbe állításához. Győződjön meg arról, hogy a tartományvezérlő telepítette a tartományvezérlő ügynökszoftverét, és újra lett indítva.
Nyissa meg Eseménynapló, és lépjen a DC Agent Admin eseménynaplójához.
Nyisson meg egy emelt szintű parancssori ablakot.
Tesztfiók létrehozása jelszóteszteléshez
A felhasználói fiókok sokféleképpen hozhatók létre, de itt egy parancssori lehetőség is elérhető, amely megkönnyíti az ismétlődő tesztelési ciklusok során:
net.exe user <testuseraccountname> /add <password>Az alábbi vitafórumok céljából tegyük fel, hogy létrehoztunk egy "ContosoUser" nevű tesztfiókot, például:
net.exe user ContosoUser /add <password>Jelentkezzen be a Microsoft Entra felügyeleti központba legalább hitelesítési rendszergazdaként.
Keresse meg a Védelmi > hitelesítési módszerek jelszóvédelem parancsát > .
Szükség szerint módosítsa a Microsoft Entra Jelszóvédelmi szabályzatát a végrehajtandó teszteléshez. Dönthet például a kényszerített vagy a naplózási mód konfigurálása mellett, vagy dönthet úgy, hogy módosítja a tiltott kifejezések listáját az egyéni tiltott jelszavak listájában.
Szinkronizálja az új szabályzatot a DC agent szolgáltatás leállításával és újraindításával.
Ez a lépés többféleképpen is elvégezhető. Ennek egyik módja a Service Management felügyeleti konzol használata, ha a jobb gombbal a Microsoft Entra Password Protection DC Agent szolgáltatásra kattint, majd az "Újraindítás" lehetőséget választja. A parancssori ablakból egy másik módszer is elvégezhető a következő módon:
net stop AzureADPasswordProtectionDCAgent && net start AzureADPasswordProtectionDCAgentAz új szabályzat letöltésének ellenőrzéséhez ellenőrizze a Eseménynapló.
Minden alkalommal, amikor a DC-ügynök szolgáltatás le van állítva és elindult, két 30006 eseménynek kell megjelennie egymás után. Az első 30006-os esemény a sysvol-megosztás lemezén gyorsítótárazott szabályzatot tükrözi. A második 30006-os eseménynek (ha van ilyen) frissített bérlői szabályzattal kell rendelkeznie, és ha igen, az az Azure-ból letöltött szabályzatot fogja tükrözni. A bérlői szabályzat dátumértéke jelenleg a szabályzat Azure-ból letöltött hozzávetőleges időbélyegének megjelenítésére van kódolva.
Ha a második 30006-os esemény nem jelenik meg, a folytatás előtt hárítsa el a problémát.
A 30006-os események az alábbi példához hasonlóan fognak kinézni:
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: 1Ha például a Kényszerített és a Naplózás mód között változik, az AuditOnly jelölő módosul (az AuditOnly=0 listában szereplő szabályzat kényszerítve módban van). Az egyéni tiltott jelszólista módosításai közvetlenül nem jelennek meg a fenti 30006-os eseményben, és biztonsági okokból máshol nem naplózhatók. A szabályzat sikeres letöltése az Azure-ból a módosítás után a módosított egyéni tiltott jelszólistát is tartalmazza.
Futtasson egy tesztet úgy, hogy megpróbál alaphelyzetbe állítani egy új jelszót a teszt felhasználói fiókjában.
Ez a lépés a parancssori ablakban a következőképpen végezhető el:
net.exe user ContosoUser <password>A parancs futtatása után az eseménynaplóban további információt kaphat a parancs kimeneteléről. A jelszó-érvényesítési eredmények eseményeit a DC Agent Admin eseménynapló-témaköre dokumentálja. Az ilyen események segítségével a teszt eredményét a net.exe parancsok interaktív kimenetén kívül is ellenőrizheti.
Próbáljunk ki egy példát: megpróbálunk beállítani egy jelszót, amelyet a Microsoft globális listája tilt be (vegye figyelembe, hogy a lista nincs dokumentálva , de itt tesztelhetjük egy ismert tiltott kifejezéssel). Ez a példa feltételezi, hogy a szabályzatot kényszerített módban konfigurálta, és nulla feltételeket adott hozzá az egyéni tiltott jelszólistához.
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.A dokumentáció szerint, mivel a teszt jelszó-visszaállítási művelet volt, egy 10017-et és egy 30005-ös eseményt kell látnia a ContosoUser-felhasználó számára.
Az 10017-eseménynek a következő példához hasonlóan kell kinéznie:
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:A 30005-ös eseménynek a következő példához hasonlóan kell kinéznie:
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:Ez vicces volt - próbáljunk ki egy másik példát! Most megpróbálunk beállítani egy jelszót, amelyet az egyéni tiltott lista tilt be, miközben a szabályzat naplózási módban van. Ez a példa feltételezi, hogy végrehajtotta a következő lépéseket: konfigurálta a házirendet naplózási módban, hozzáadta a "lachrymose" kifejezést az egyéni tiltott jelszólistához, és szinkronizálta az eredményül kapott új szabályzatot a tartományvezérlővel úgy, hogy a korábban ismertetett tartományvezérlő-ügynökszolgáltatást használja.
Ok, állítsa be a tiltott jelszó egy variációját:
net.exe user ContosoUser LaChRymoSE!1 The command completed successfully.Ne feledje, ezúttal sikerült, mert a szabályzat naplózási módban van. Egy 10025-ös és egy 30007-ös eseménynek kell megjelennie a ContosoUser-felhasználó számára.
Az 10025-ös eseménynek a következő példához hasonlóan kell kinéznie:
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:A 30007-eseménynek a következő példához hasonlóan kell kinéznie:
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:Folytassa a választott jelszavak tesztelését, és ellenőrizze az eredményeket az eseménynaplóban az előző lépésekben ismertetett eljárásokkal. Ha módosítania kell a házirendet a Microsoft Entra Felügyeleti központban, ne felejtse el szinkronizálni az új szabályzatot a DC-ügynökkel a korábban leírtak szerint.
Bemutattuk azokat az eljárásokat, amelyek lehetővé teszik a Microsoft Entra Password Protection jelszóérvényesítési viselkedésének szabályozott tesztelését. A felhasználói jelszavak közvetlenül a tartományvezérlő parancssorából való alaphelyzetbe állítása furcsának tűnhet az ilyen tesztelés elvégzésére, de a korábban ismertetett módon megismételhető eredményeket eredményezett. A különböző jelszavak tesztelése során tartsa szem előtt a jelszó-kiértékelési algoritmust , mivel ez segíthet a nem várt eredmények magyarázatában.
Figyelmeztetés
Ha minden tesztelés befejeződött, ne felejtse el törölni a tesztelés céljából létrehozott felhasználói fiókokat!
További tartalom
Az alábbi hivatkozások nem részei a Microsoft Entra Password Protection alapvető dokumentációjának, de hasznos forrásként szolgálnak a funkcióval kapcsolatos további információkhoz.
A Microsoft Entra Password Protection mostantól általánosan elérhető!
Microsoft Premier\Unified support training available
Ha többet szeretne megtudni a Microsoft Entra Password Protectionről és annak üzembe helyezéséről, használhatja a Microsoft proaktív szolgáltatását. Ez a szolgáltatás premier vagy egységes támogatási szerződéssel rendelkező ügyfelek számára érhető el. A szolgáltatás neve Microsoft Entra ID: Password Protection. További információért forduljon az Ügyfél sikerfiók-kezelőjéhez.
Következő lépések
Ha helyszíni Microsoft Entra Password Protection-kérdése van, amelyre itt nem kapott választ, küldjön egy visszajelzési elemet alább – köszönjük!