Monday, June 21st, 2010...12:48 am

O grupach w tokenach

Jump to Comments

Intensywny sezon prezentacji zakończony i czas na wakacje, czyli można wrócić do pisania bloga. Do prezentacji nawiązując jeszcze tylko krótko … mam nadzieję, że się podobały i były przydatne. Komentarze, uwagi, sugestie, co do zmian mile widziane na e-mail.

Nexor na W-Files ostatnio próbował zgryźć problem uzyskania informacji o przynależności konta komputera do grup Active Directory. Nie wprost, ale wywołał mnie do tablicy i w komentarzach chwilę w temacie powymienialiśmy się uwagami. Myślałem, że podsunięte mu rozwiązanie już opisałem tutaj, ale szybkie wyszukanie w sieci pokazało mi, że pamięć już nie ta. Na pewno mówiłem o tym na spotkaniu Warszawskiej Grupy .NET, ale czas opowiedzieć o tym i na blogu.

Constructed attributes

Na początek o atrybutach dynamicznie konstruowanych – czyli constructed attributes. Usługa katalogowa Active Directory nie jedno potrafi, między innymi potrafi budować wartość szczególnych atrybutów w przypadku, gdy użytkownik o nie poprosi. Atrybuty tego typu nie są widoczne na obiekcie, gdy na przykład przeglądamy jego zawartość przy pomocy narzędzi takich jak LDP.EXE, ADSIEdit czy właściwości obiektu w konsoli ADU&C. Wystarczy jednak zapytać o nie katalog i voile, wyskakują jak diabeł z pudełka.


(cc) Swansea Photographer

Pierwszym z brzegu przykładem tego typu atrybutu są wszystkie atrybuty typu back link, czyli stanowiące odwzorowanie połączeń pomiędzy atrybutami w ramach par atrybutów połączonych. Spójrzmy chociażby na atrybut memberOf użytkownika. Jeżeli zajrzymy do właściwości użytkownika używając edytora atrybutów z Windows 2008 R2 nie zobaczymy go:

Wystarczy jednak, że zapytamy się wprost o taki atrybut używając adfind.exe:

C:\ >adfind -b CN=tom.tom,ou=Accounting,DC=w2k,DC=pl -s base memberOF

AdFind V01.42.00cpp Joe Richards (joe@joeware.net) April 2010

Using server: FIMDC01.w2k.pl:389
Directory: Windows Server 2008 R2

dn:CN=tom.tom,ou=Accounting,DC=w2k,DC=pl
>memberOf: CN=Ksiegowosc,OU=FIMGroups,DC=w2k,DC=pl

1 Objects returned

I otrzymujemy odpowiedź. Cała magia realizowana jest przez usługę katalogową, która na nasze żądanie wyliczyło wartość tego atrybutu.
Atrybutów takich jest więcej i mogą one występować w jednym z trzech przypadków:

  1. Jeżeli atrybut jest oznaczony w schemacie poprzez ustawienie flagi ATTR_IS_CONSTRUCTED w ramach systemFlags
  2. Jeżeli atrybut jest atrybutem typu back link (jak pokazano powyżej)
  3. Jeżeli atrybut jest atrybutem obiektu rootDSE.

Lista atrybutów konstruowanych dostępna jest na MSDN jak i całość opis usługi katalogowej dla zainteresowanych.

tokenGroups

I tak dochodzimy do sedna wymiany komentarzy z Nexorem. Jednym z atrybutów konstruowanych na żądanie przez system jest tokenGroups. Oficjalny opis poniżej:

These two computed attributes return the set of SIDs from a transitive group membership expansion operation on a given object

Czyli pytając katalog o atrybut tokenGroups dowolnego obiektu, będącego podmiotem zabezpieczeń otrzymamy listę SIDów grup, do których ten obiekt należy i które będą znajdowały się w jego tokenie zabezpieczeń po zalogowaniu.
Ponieważ obiekt komputera jest takim samym obiektem zabezpieczeń jak obiekt użytkownika i również loguje się w usłudze katalogowej, to możemy w ten sposób uzyskać informację o członkostwie w grupach danego obiektu komputera.

Spróbujmy używając ADFIND.EXE:

C:\ >adfind -b CN=STS,CN=Computers,DC=w2k,DC=pl -s base tokenGroups
AdFind V01.42.00cpp Joe Richards (joe@joeware.net) April 2010

Using server: FIMDC01.w2k.pl:389
Directory: Windows Server 2008 R2

dn:CN=STS,CN=Computers,DC=w2k,DC=pl
>tokenGroups: S-1-5-21-2045789631-2668715847-4178987103-1162
>tokenGroups: S-1-5-21-2045789631-2668715847-4178987103-515

Jak widać uzyskaliśmy listę SID dla grup, do których należy obiekt komputera. Jak zamienić SID na coś bardziej czytelnego? Może po prostu użyć ADFIND .EXE ponownie używając SID jako argumentu:

C:\ >adfind -b dc=w2k,dc=pl -s subtree -f “(&(objectSid=S-1-5-21-2045789631-2668715847-4178987103-1162))” name

AdFind V01.42.00cpp Joe Richards (joe@joeware.net) April 2010

Using server: FIMDC01.w2k.pl:389
Directory: Windows Server 2008 R2

dn:CN=ADFS Servers,OU=FIMGroups,DC=w2k,DC=pl
>name: ADFS Servers

1 Objects returned

To miłego analizowania członkostwa w grupach …

3 Comments

  • dzięki (: niemniej nie pomaga mi to zdebugować problemu, bo tak jak pisałem – AD ładnie widzi kompa w grupie. tak jak zasugerowałeś, od razu sprawdziłem tokenGroups i AD widzi kompa w grupie TSLS… ale komp nie widzi siebie w tej grupie!! więc pytanie – jak to samo sprawdzić z poziomu systemu? i ważniejsze w tym momencie pytanie – WTF?! jak to możliwe, że podczas procesu logowania nie dostaje/nie przyjmuje tej informacji? zastanawiam się jeszcze nad najprostszym rozwiązaniem – czy nie zmienić mu nazwy systemu i wygenerować nowego SIDa systemu. nie potrafię tego ugryźć a całość utrudnia mi fakt, że wszystko musi przechodzić przez korpo ):

  • @nexor – nie widzi siebie w tej grupie czy cos nie dziala jakbyś chciał. Jeżeli chodzi o członkostwo w grupie to prosta weryfikacja – zaplanuj zadanie w kontekscie systemu zeby zapisal cos do folderu z uprawnieniami tylko dla tej grupy – moze byc na zdalnym udziale sieciowym … i bedziesz widzial czy efektywnie system ma uprawnienia.

    A on nie wylecial Ci z domeny??

  • nie to, że wyleciał – to świeża instalacja i przez tą cholerną grupę go 3krotnie wywalałem i dodawałem jeszcze raz!
    gpresult:
    The computer is a part of the following security groups
    ——————————————————-
    BUILTIN\Administrators
    Everyone
    BUILTIN\Users
    NT AUTHORITY\NETWORK
    NT AUTHORITY\Authenticated Users
    This Organization
    WASRDS01$
    RU_Wireless
    Domain Computers
    SMSSiteServers
    Terminal Server Computers
    System Mandatory Level
    a jak sprawdzam tokenGroups to widzi grupę TSLS ): memberOf oczywiście też pokazuje.
    w życiu takiej hecy nie widziałem i nie wiem jak to w ogóle możliwe.

Leave a Reply