Skip Ribbon Commands
Skip to main content

Ondrej Sevecek's Blog

:

Engineering and troubleshooting by Directory Master!
Ondrej Sevecek's Blog > Posts > Bleskový a ověřený postup opravy AD lingering objects a Kerberos autentizace
listopad 26
Bleskový a ověřený postup opravy AD lingering objects a Kerberos autentizace

Dneska jsem na konferenci ms-fest prezentoval svoji léty vyzkoušenou, ověřenou a vyladěnou metodu, jak opravit Active Directory (AD) replikaci (replication) potom, co řadič(e) domény přešly tombstone lifetime a vznikly lingering objecty. O této situaci jste zřejmě už slyšeli. Jenže problém je prakticky vždycky kombinován s problémem rozhozených hesel počítačových účtů řadičů domén.

Každý řadič domény (DC - domain controller) si totiž mění heslo svého účtu (machine password) každých 30 dnů, stejně jako libovolný jiný členský stroj domény. Naproti tomu tombstone lifetime je obvykle 180 dnů. Pokud si řadič sám sobě změní heslo dvakrát a během té doby se to nedokáže zreplikovat, tak přestane fungovat Kerberos. Tzn. už po 30 dnech možná, po 60 dnech zaručeně. Takže tombstone lifetime a lingering objects je obvykle až druhý následek rozházeného času.

Důvody pro rozházený čas DC:

  • nějaká DC se prostě už dlouho neviděla - tento důvod není už dneska tak obvyklý, jako ten druhý
  • máte jedno, nebo více DC, na nějakém cloudu a oné virtualizaci se rozhodí čas a posune to čas na všech virtuálkách - to je dneska, jak pozoruji, velmi běžné (chyba obsluhy, chyba hardware, baterka, ...)

To co nastane mezi domain controllery je totální rozklad. Přestávají replikovat a ověřovat jak sebe, tak uživatele a počítače. V případě ověřování klientů to je chaticky podle toho, které DC si kdo vybere. Jsou to chyby jako třeba:

The directory service cannot replicate with this server because the time since the last replication with this server has exceeded the tombstone lifetime

Event Id: 2042
Message: It has been too long since this machine last replicated with the named source machine. The time between replications with this source has exceeded the tombstone lifetime. 

Kerberos error: The target principal name is incorrect
error: 2148074274 = 0x80090322 = SEC_E_WRONG_PRINCIPAL

The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server.
The target name used was LDAP/._msdcs. This indicates that the target server
failed to decrypt the ticket provided by the client.

Na opravu těchto dvou problémů existují standardní postupy. Problém je v jejich praktickém využití. Pokud nevíte přesně jak, bude vám oprava trvat minimálně několik hodin, ne-li dnů, a navíc to ještě neuděláte správně.

Po zkušenostech jsem si vypracoval ideální postup, který je nejrychlejší možný, spolehlivý a obecně funkční. Dneska jsem takto opravil pět DC během cca 40 minut, a to jsme u toho ještě vysvětloval.

Celý postup je na screenshotech a s popisky v následující prezentaci:

Fastest ever steps to repair tombstone lifetime, lingering objects and Kerberos machine passwords

Základní vysokoúrovňové kroky

Detailní návod je v prezentaci. Pro shrnutí jen nejdůležitější body. Prostě nepřemýšlejte a udělejte všechno na všech řadičích:

  • nejprve opravte čas
  • vytvořte si nějaký samostatný DNS server - něco nainstalujte, nebo použijte existující, ale potřebujete DNS server, který není na žádném AD DC, aby na tom nefunkčním AD nebyl závislý. Do tohoto DNS serveru nasměrujte všechna DC. Budete mít jen jeden DNS server a nebudete záviset na replikaci, která nefunguje
  • vypněte všechny Kerberos Key Distribution Center (KDC) služby, a nechejte si jen jednu - každé KDC používá svůj místní AD. Je to stejné jako s tím DNS serverem. Pokud nefunguje AD a nereplikuje, každé KDC potom vydává jinak špatné Kerberos tikety a celé se to chaotizuje. Stejně jako jedinný DNS server budeme mít tedy jen jediný KDC.
  • vyresetujete hesla počítačových účtů pomocí netdom resetpwd - tohle rozjede ověřování
  • vyčistíte lingering objecty - musíte to ale udělat správně a úplně. V prezentaci je na to skript. Musíte čistit každé DC oproti každému a navíc po jednom všechny AD partition (naming context).
  • no a nakonec pustíte replikaci
  • a nezapomenete to zase uvést do původního stavu - vrátit DNS servery a vypnout registrovou hodnotu

Tak ať slouží!

Comments

Re: Bleskový a ověřený postup opravy AD lingering objects a Kerberos autentizace

Bylo to skvělé, díky Ondro!
Patrik on 26.11.2016 22:08

Re: Bleskový a ověřený postup opravy AD lingering objects a Kerberos autentizace

Díky za výbornou prezentaci s řadou drahocenných rad. Jako vždy byla Vaše prezentace velmi přínosná!
Martin on 28.11.2016 10:54

Re: Bleskový a ověřený postup opravy AD lingering objects a Kerberos autentizace

Tak tohle už jsem taky jednou řešil. Naštěstí ne v produkčním prostředí, nýbrž jen v testovacím při jeho vytváření (několik domén ve stromu). Ale s chutí si to přečtu, protože člověk nikdy neví, kdy ho to potká. Dík!
Borek on 28.11.2016 19:34

Jiná možnost?

Díky za článek. Super.
Nebylo by ještě rychlejší a méně pracnější ty DCčka smazat, nechat jen jedno a ty ostatní znovu nainstalovat a poreplikovat?
RaT on 6.12.2016 11:22

Re: Bleskový a ověřený postup opravy AD lingering objects a Kerberos autentizace

smazat je jednodušší, ale problém je v tom, že my nevíme, jak dlouho ta DC už běžela rozbitá před tím, než sme to zjistili. Takže je taky možné, že mají už v sobě několik dnů-týdnů-měsíců změn hesel (uživatelů a počítačů) a dalších věcí, které nejsou odreplikované na ostatní DC a tím pádem si to nemůžeme dovolit zrušit, protože bychom měli přihlašovací problémy na nedefinovaném množství služeb. Lidem resetnout heslo není problém, ale když počítače přestanou fungovat, nebude to moc zdravé a kdo to bude řešit...
ondass on 6.12.2016 11:29

Re: Bleskový a ověřený postup opravy AD lingering objects a Kerberos autentizace

Presne tak - je tazke urcit, ktory DC je ten spravny a ma spolahlive data. V malych prostrediach sa to este da, ale pri vacsich je to problem, lebo postihnutych PC a sluzieb moze byt vela.
Ak by existoval postup (script), ktorym by sa dalo zistit, ake data su na jednotlivych DC odlisne, t.j. ktore cerstve nie su replikovane, tak podla vysledku dalo zvazit presunt role FSMO a odobrat problemovy/problemove DC.
Niekedy by som potreboval zistit, ktory DC overil PC resp. pouzivatela bez toho, aby som isiel na PC - da sa to ?
lupgo on 8.12.2016 11:40

Re: Bleskový a ověřený postup opravy AD lingering objects a Kerberos autentizace

to s těmi rozdílnými daty by šlo, jenom by se muselo vzít do úvahy, že některé atributy nejsou replikované, takže jsou z principu různé na všech DC. ale jinak by se to dalo nejspíš porovnat, všechno by se to vyreplikovalo a porovnalo. Takže principiálně to jde, ale nejspíš na to žádný nástroj není.

Co se týče toho ověření, tak můžete se podívat na každém DC právě na ne-replikovaný atribut logonTime. Tento se aktualizuje pokaždé, kdy se použijí primární přihlašovací údaje, tedy heslo počítače, k jeho ověření.

A je to nereplikovaný atribut, takže bude mít nejnovější hodnotu právě na tom DC, které to ověření provádělo poslední
ondass on 8.12.2016 15:47

Re: Bleskový a ověřený postup opravy AD lingering objects a Kerberos autentizace

Mohol by som poprosiť o obnovenie linku na tú prezentáciu? Aktuálne mám problém s novonainštalovaným exchangom prepojeným na 3x AD a možno je problém s týmito lingering objektami. Ale niesom si istý.
Jan on 5.8.2018 23:04

Add Comment

Title


Pole Title nemusíte vyplňovat, doplní se to samo na stejnou hodnotu jako je nadpis článku.

Author *


Pole Author nesmí být stejné jako pole Title! Mám to tu jako ochranu proti spamu. Roboti to nevyplní dobře :-)

Body *


Type number two as digit *


Semhle vyplňte číslici dvě. Předchozí antispemové pole nefunguje úplně dokonale, zdá se, že jsou i spamery, které pochopily, že je občas potřeba vyplnit autora :-)

Email


Emailová adresa, pokud na ni chcete ode mě dostat odpověď. Nikdo jiný než já vaši emailovou adresu neuvidí.

Attachments