| Před nedávnem jsem napsal článek o tom, že se ještě nějakou dobu po změně hesla (bez ohledu na to, jestli je to reset správcem, nebo změna ze strany uživatele) dá použít jedno starší heslo. Původní článeček je zde. Pod článkem vznikla poměrně obsáhlá nedůvěra s těmi informacemi, takže tu je konečně několiv věcí, které bych k tomu dodal a rovnou to dávám jako samostatný článeček, aby to bylo vidět.
Nejprve k otázce, že si uživatel změní heslo a může se i nadále přihlásit tím původním
- psal jsem to, protože jsme si už párkrát všiml, že to tak funguje a nikdy jsem neměl čas to pořádně dořešit do detailu. Jak jsem právě ověřil, funguje to přesně tak i při DFL (domain functional level) a FFL (forest functional level) na Windows 2012.
- jedná se opravdu jen o jedno předchozí heslo. Tzn. pokud si heslo změníte, nebo vám ho vyresetují dvakrát, tak to funguje zase jenom na to jedno přechozí heslo, bez ohledu na délku historie hesel.
- teď jsem si vypnul historii hesel a přestalo to fungovat. Takže musíte mít historii hesel zapnutu pro dané účty. Bez ohledu na to, jestli heslo resetujete, nebo jenom měníte, tak prostě DC ukládá historii hesel, tedy pokud je zapnutá (ve výchozím stavuje je zapnutá). Pokud je vypnutá, zdá se, že potom ani tahle věc nefunguje.
- jak jsem právě zjistil, tak pokud resetuju heslo, nesmím tam nechat že "user must change password at next logon". Prostě - pokud heslo resetujete a přitom se vyžaduje, aby si uživatel změnil heslo při příštím přihlášení, tak to pak se starým heslem nejde a dostanete standardní hlášku "invalid password"
- jak jsem i v tom přechozím článku zmiňoval, funguje to jenom pro LDAP simple bind a pro NTLM. Pro Kerberos to nefunguje. Pokud to chcete vyzkoušet, tak musíte resetovat heslo (a přitom nesmíte chtít, aby si ho uživatel musel hned změnit), nebo prostě si uživatel musí změnit heslo. A potom buď LDAP simple bind za pomoci LDP nástroje, nebo NTLM. NTLM nejlépe vyzkoušíte, pokud půjdete například na file server pomocí IP adresy - tedy něco jako \\10.10.0.16\Docs. Ale hlavně to dělejte pod nějakým lokálním, nedoménovým účtem, nebo v tom budete mít chaos. Precizně vyzkoušet NTLM není žádná sranda. Případně dojděte na GOC172 do GOPASu. Zrovna bude za 14 dni v Praze.
- znovu zdůrazňuju, že pro místní přihlášení to nefunguje. Takže to nefunguje ani pro Basic authentication na IIS nebo jiné web servery. To je totiž lokální přihlášení! Bacha na to. Do toho sice vstupuje ještě jedna věc - a to je keš basic ověření na IIS, ale ta vydrží jen 15 minut a má to další podmínky a speciality. Jestli to chcete zkoušet, musíte se prostě pod tím změněným účtem připojit někam do sítě přes NTLM, nebo LDAP simple bind.
- co se týče Outlook Web Access a Outlook Anywhere (RPC over HTTP) podobných případů - to hodně závisí na tom, jaké ve skutečnosti podnikáte ověřování do té konkrétní webové stránky, jestli to je NTLM, Kerberos, nebo Basic, nebo forms authentication a jestli před tím máte, nebo nemáte TMG/ISA reverse HTTPS proxy, nebo něco jiného, jako jsou různá Cisco a UAG apod a opět s jakou je tohle ověřovací metodou. Uvědomte si, že to možná znamená, dvě současná ověření na různých místech, jedno z nich může být Kerberos, druhé klidně NTLM, nebo třeba lokální Basic. Není to tak jednoduché, to by chtělo detailní znalost scénáře. Pokud se nepoužije NTLM, tak to prostě se starým heslem nemůže proběhnout.
A teďka k otázce druhé, tedy že se účet nezamyká, pokud použiju dvě starší hesla
Nejprve si uvědomte, že tohle je záležitost jak Kerberos, tak i NTLM. V případě Kerberos se nemůžete přihlásit ani jedním starším heslem. Ale účet se vám stejně nezamkne, i kdybyste to starší heslo zadávali jak dlouho chtěli. V případě NTLM se přihlásíte na předchozí heslo, takže o zamykání ani nemůže být řeč. V případě NTLM se ale taky nezamyká, pokud použijete před-předposlední heslo, stejně jako u Kerberosu. Ověřeno, FFL/DFL na úrovni Windows 2012. Projevuje se to tím, že se na účtu neobjeví ani badPwdCount ani badPasswordTime.
Pokud to zkoumáte, nezapomeňte na to, že tyto dva atributy se nereplikují. Tzn. pokud máte více řadičů domény (DC), tak tyhle atributy uvidíte přesně pouze na jednom jediném DCčku - tam zaručeně. A potom ještě velmi pravděpodobně na PDC, o které se to proťukávalo. Jenže "proťukávání" není povinné, dá se vypnout a nemusí vždycky uspět, takže bych byl poměrně opatrný s testováním této funkcionality ve složitých prostředích. To chce zase velikou citlivost na různé detialíky.
Tohle funguje jak lokálně, tak přes síť. Ověřeno. Prostě se to nezamkne, protože se ani neví, že to člověk zkoušel několikrát "špatně". To se pozná jenom z normálního security logu, kde byste viděli skutečně Failure Audit.
Opět se dostáváme k Outlook Web Access nebo Outlook Anywhere. Pokud použijete starší heslo, o jedničku, nebo o dvojku starší, tak by se vám účet neměl zamknout. To je v pohodě. Pokud se to děje, tak to je opět na pořádný průzkum konkrétního scénáře, je samozřejmě možné, že za nějakých souvislostí to prostě zamyká i při použití staršího hesla.
Ale podle mě jsou ty problémy se zamykáním OWA a OA spíše způsobeny tím, že si uživatel prostě změní heslo a rovnou ho použije. Jenže tím, že použijete nové heslo, jedná se o úplně jinou situaci. Co když to ta OWA, nebo OA zkouší o jiné DCčko, než o to, na kterém jste si to heslo zrovna změnili? Co když vám nefunguje správně (nebo prostě jenom chvilku trvá) replikace nového hesla do PDC (ona není synchronní, dělá se na pozadí a opět ne povinně)? A podobné důvody.
Tohle jsou věci, které se těžko zkoumají ve složitějším prostředí. Jestli se vám dějí nějaké podivnosti, je potřeba mít zapnuté auditování Account Logon událostí, mít sesynchronizované hodiny a spojit to s průzkumem lastLogon, badPwdCount, badPasswordTime a dalších nereplikovaných atributů na všech DC současně, nezapomínat na PDC replikaci a proťuk apod.
Tohle je moc věcí, které vás naučím na GOC172 :-) |