Thursday, October 25th, 2007...9:57 pm
CN=Infrastructure – ki diabeÅ‚?
Dzisiaj na jednej z grup dyskusyjnych (tak, tak – jeszcze takie istniejÄ…) padÅ‚o pytanie “Co to za obiekt CN=Infrastructure i czy może odpowiadać za moje problemy z GPO?”. Może nie dosÅ‚ownie takie, ale powiedzmy, że treść posta odpowiadaÅ‚a temu zdaniu.
Po gÅ‚owie już od pewnego czasu chodziÅ‚o mi opisanie jednego zagadnienia zwiÄ…zanego z tym obiektem, wiÄ™c jest to dobry pretekst. W części pierwszej wiÄ™c krótkie wprowadzenie – ki diabeÅ‚ ten CN=Infrastructure?
Obiekt Infrastructure klasy infrastructureUpdate istnieje w każdej domenie (inaczej mówiąc partycji katalogu, ale partycją jest też konfiguracja, schemat) wchodzącej w skład lasu Active Directory pod DN CN=Infrastructure,DC=<domena>,DC=<tld>. Widoczny jest dopiero w trybie zaawansowanym ADU&C lub z poziomu dowolnego narzędzia pozwalającego na połączenie się do serwera LDAP.
W sieci można znaleźć stwierdzenie, że “reprezentuje” on rolÄ™ Infrastructure Master w domenie, ale to pewnego rodzaju uproszczenie. Napewno w ramach atrybutów tego obiektu zdefiniowany jest kontroler domeny peÅ‚niÄ…cy rolÄ™ Infrastructure Master, poprzez uprawnienie na tym obiekcie możemy też delegować uprawnienia do zarzÄ…dzania tÄ… rolÄ… w domenie.
Żeby zrozumieć rolę tego obiektu, należy wyjść od roli samego Infrastructure Master w domenie. Jednym z zadań DC, pełniącego tę rolę, jest uaktualnienie na poziomie bazy danych Active Directory informacji o obiektach fantomów (phantom objects) tworzonych w katalogu w celu reprezentowania obiektów z innych domen. O fantomach może jednak kiedyś w przyszłości (w zasadzie nikt się nimi nie interesuje, do czasu gdy nie wygenerują problemu
).
Infrastructure master odpowiedzialny jest za tworzenie, uaktualnianie i, co ważniejsze i usuwanie fantomów z bazy danych AD. Problem z fantomami jest jeden - są to obiekty tworzone na poziomie bazy danych i nie posiadają reprezentacji w ramach katalogu, nie są dla nich też przechowywane dane replikacji. W związku z tym, nie jest możliwe przekazanie informacji o uaktualnieniach fantomu poprzez standardowe mechanizmy replikacji obiektu.
I tutaj wÅ‚aÅ›nie pojawia siÄ™ nasz obiekt Infrastructure. PeÅ‚ni on rolÄ™ transportera dla tego typu zdarzeÅ„ w katalogu. W przypadku, gdy wystÄ™puje potrzeba replikacji zmiany wygenerowanej przez Infrastructure Master, tworzony jest w ramach tego obiektu kolejny obiekt (w AD nie tylko kontener lub OU może być “rodzicem” dla innych obiektów) klasy infrastructureUpdate, który zawiera odpowiednie dane. Å»eby byÅ‚o ciekawiej – obiekt ten jest nastÄ™pnie od razu kasowany. Obiekt ten (a wÅ‚aÅ›ciwie jego “nagrobek”) jest już replikowany w ramach standardowych mechanizmów replikacji katalogu, przenoszÄ…c do kolejnych DC w domenie informacjÄ™ o uaktualnieniu.
I w ten to oto sposób obiekt Infrastructure okazuje siÄ™ być dosyć przydatnym zwierzÄ™ciem w ramach katalogu. A teraz siadam do opisu drugiej sytuacji, w której ten mechanizm jest używany czyli część druga nadchodzi …


Leave a Reply