Partager via

Nieusuwalne obiekty w Active Directory

  • Article

Czesto zdarza sie, ze chcemy usunac zbedne dane z Active Directory. Jednak ze wzgledu na model replikacyjny, obiekty z bazy danych AD sa usuwane dopiero po uplynieciu Tombstone Lifetime (TSL – wiecej szczególów na temat procesu replikacji nagrobków mozna znalezc tutaj: https://technet.microsoft.com/en-us/library/cc772726(v=ws.10).aspx#w2k3tr_repup_how_okdq)

Jednak zanim obiekt w Active Directory moze zostac zamieniony w nagrobek (celowo unikam okreslenia “usuniety”), czynnosc ta musi przejsc wielostopniowy proces weryfikacji, czy ta czynnosc jest naprawde bezpieczna. Zgodnie z tym artykulem: https://technet.microsoft.com/pl-pl/magazine/2007.09.tombstones(en-us).aspx; sprawdzane sa nastepujace rzeczy:

  • czy kasowany obiekt nie ma juz ustawionej flagi isDeleted na true (nie da sie usunac nagrobka)
  • Security Descriptor obiektu (jego czesc zawierajaca uprawnienia) nie okresla go jako obiektu prywatnego (efektywnie sprawia, ze nikt inny poza AD nie moze go modyfikowac)
  • atrybut systemFlags nie przecyzuje wartosci 1 na bicie DISALLOW_DELETE 0x80000000
  • isCriticalSystemObject nie jest true (nie chcemy usuwac obiektów o krytycznym znaczeniu dla systemu – na przyklad obiektu NTDS Settings dla dzialajacego kontrolera domeny)
  • uzytkownik wykonujacy próbe kasowania ma uprawnienia do danej czynnosci
  • obiekt nie jest wskaznikiem typu crossRef (cross-reference) dla istniejacej partycji AD (nie chcemy pozwolic na usuniecie wskaznika do istniejacej domeny lub partycji aplikacyjnej)

Wystarczy, ze którykolwiek z powyzszych nie zostanie spelniony, to próba skasowania obiektu zakonczy sie niepowodzeniem.

Taki wlasnie przypadek ostatnio przytrafil sie mi osobiscie. W ADSIEdit w kontenerze z uzytkownikami mialem obiekt o nazwie CORP$ . Co ciekawe, to CORP bylo stara domena z której nasz klient sie zmigrowal. Co jeszcze ciekawsze, obiekt ten nie byl widoczny w konsoli AD Users & Computers. Niestety porzadek musi byc, wiec rozpoczelismy wraz z kolezankami i kolegami z dzialu wsparcia proces rozwiazywania problemu. W tym celu przedsiewzielismy m.in. nastepujace kroki:

  • Wiedzielismy, ze próba jego usuniecia daje nam nastepujacy komunikat:
    image
  • Weryfikacja, czy relacja zaufania na cele migracji, ciagle istnieje;
    Tu stwierdzilismy, migracja zostala przeprowadzona prawidlowo i po jej zakonczeniu trust zostal usuniety
  • Zrzut atrybutów obiektu, zeby sie dokladnie dowiedziec czym on jest;
    Okazalo sie, ze byl on klasy user (dziwne, bo zazwyczaj konta komputerów maja znak dolara na koncu)
    Mial ustawiona flage isCriticalSystemObject na true
    SAMAccountType byl ustawiony na wartosc: 0x30000002. zgodnie z MSDN oznacz to, ze jest to konta uzytkownika relacji zaufania (SAM_TRUST_ACCOUNT https://msdn.microsoft.com/en-us/library/cc228417.aspx); potrzebne sa one do zestawiania secure channel pomiedzy kontrolerami z róznych domen: https://support.microsoft.com/kb/128489 
  • Ponowna weryfikacja braku trust-u;
    Nie ma go. Nie pojawia sie w konsoli AD Domains & Trusts oraz nie istnieje jego TDO w kontenerze system (https://technet.microsoft.com/en-us/library/cc773178(v=ws.10).aspx)
  • SAMAccountName konta byl wygladal nastepujaco:
    image

No i dzieki temu wiedzielismy, co sie stalo (taka zmiana sAMAccountName nastepuje dla obiektów skonfliktowanych w czasie replikacji). Wynik analizy byl nastepujacy:
Niekasowalny obiekt jest wynikiem stworzenia konfliktowej relacji zaufania (na dwóch serwerach jednoczesnie). najprawdopodobniej relacja zaufania jeszcze sie nie zreplikowala do któregos z kontrolerów domeny i PDC Emulator (który jest odpowiedzialny za utrzymanie relacji zaufania) byl wylaczony. Wiec rola FSMO zostala przejeta, relacja zaufania zostala stworzona ponownie na innym DC. Po wznowieniu lacznosci ze starym PDC, sytuacja sie sama rozwiazala, ale powstaly obiekty CNF (zgodnie z https://technet.microsoft.com/library/Cc961782). Na szczescie taki obiekt nikomu nie wadzi, wiec nie trzeba go kasowac. Na zawsze pozostanie w bazie danych. Jedyny problem, jaki moze sie pojawic w przyszlosci, to próba zestawienia trust-u z inna domena o nazwie CORP. Zeby temu zapobiec, wystarczy zmienic DN felernego obiektu.

PS. Inna opcja stworzenia takich obiektów jest… odzyskanie ich z AD Recycle Bin. Ale jednakowo nie beda one usuwalne.
image

Comments

  • Anonymous
    December 11, 2014
    Dzięki, przyda się kiedyś pewnie :)