June 21st, 2010

O grupach w tokenach

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 …

June 1st, 2010

Federacja w praktyce

Kontynuując poniedziałkową serię luźniejszych wpisów … z życia jusera.

Jeżeli chodzi o federację i podobne usługi to ja tutaj piszę dużo teoretycznie i o zastosowaniach i o samej technologii a jak to wygląda w praktyce?? W Polsce nie znam zbyt wielu przypadków zastosowania tego typu rozwiązań (mam nadzieję że to się zmieni niedługo) ale już moja matka korporacja obecna korzysta z nich całkiem szeroko. I jakoś przez to, że po prostu się z tego korzysta samego mnie zaskoczyła ostatnio łatwość użycia tych rozwiazań dla przeciętnego użytkownika (w którego rolę się wcielam). A więc …

… będąc ostatnio zwykłym użytkownikiem chciałem uzyskać dostęp do raportu jednej z firm analitycznych na temat FIM 2010 – to co zwykli użytkownicy robią na codzień. W tym celu:

  • Udałem się na stronę tejże organizacji, gdzie zauważyłem że należy się zalogowac lub zarejestrować. O profil kolejny myślę sobie …
  • Klikam “First time user i grzecznie proszony jestem o podanie e-mail, rzeczony podaję.
  • Po podaniu e-mail strona wita mnie miłym komunikatem:

    Good News!
    Your organization has a federation agreement with (…), which makes it possible for You to use single sign-on.
    In future You do not need to register or use username and password to access services. All You need to login is Your email address on the main login page.

Dowód rzeczowy poniżej:

I życie stało się prostsze :) … i oby tylko takich przypadków było więcej.

May 31st, 2010

Zatańczyłem

Przybyłem, zatańczyłem, sądząc po wynikach podobało się …

Szczerze powiem, że doświadczenie było dla mnie nowe. Pierwszy raz prowadziłem sesję z kimś i w zasadzie wykonywałem tylko demo.
Jak widać demo się podobało jak to demo zazwyczaj. Wiem, że całość wystąpienia będzie dostępna na VirtualStudy.pl ja jednak ze swojej strony testuję właśnie Community Clips, więc pewnie do końca tego tygodnia wrzucę tutaj link do nagrania samego demo z tej sesji.
O claims (dzisiaj zobaczyłem, że tłumaczenie polskie w produkcie to oświadczenie – o zgrozo), ADFS i SPS 2010 niedługo tutaj więcej.

May 20th, 2010

Zaśpiewam i zatańczę

Ogłoszenia parafialne … jakoś tak wyszło, że nadchodzi lato, ale zanim nadejdzie szykuje się całkiem intensywny sezon rozrywkowy. O ile oczywiście ktoś traktuje prezentacje i spotkania jako rozrywkę. I tak …

W najbliższym czasie, czyli w przyszłym tygodniu wystąpię gościnnie na imprezie dla mnie mało „macierzystej” pod tytułem Sharepoint Community Launch w Warszawie.

Jako że tak jak wspomniałem impreza ta raczej pośrednio jest związana z moim głównym nurtem zainteresowań (ale powoli to się zmienia) występ będzie gościnny w ramach sesji kolegi (powstań) Architekta (spocznij) Radka Szymczaka w roli jego małpki do wykonania demo. Temat: Claim based authentication w SharePoint 2010. To jest właśnie ta część „zatańczę” z tytułu wpisu.

Idąc dalej – wystąpię na Forefront Community Launch w Warszawie tudzież i opowiedzieć o Forefront Identity Manager 2010.

Uff … 19 czerwca będzie można mnie posłuchać w ramach Virtual Study Conference 2010. Tematy jeszcze się dogrywają – w ramach ścieżki angielskojęzycznej prawdopodobnie powtórzę sesję z MTS 2009 dotyczącą Kerberos.

W ramach ścieżki IT Pro … to na razie jeszcze jest niespodzianka, również dla mnie, ale niedługo się wyjaśni. Najchętniej opowiedziałbym o ADFS v2 ale …

… wstępnie o ADFS v2 prawdopodobnie będę opowiadał w lipcu na spotkaniu jednej z grup w Warszawie. Ale szczegóły tego spotkania opublikuję jak tylko zostaną dograne.
I jeszcze w tym wszystkim nie zaniedbać bloga … hmmm, to jest wyzwanie.

May 5th, 2010

I nastał ADFSv2

(…) Nadejszła wiekopomna chwila (…) i jest. ADFSv2 został opublikowany w sieci.

(cc) bobafred

Ci którzy planowali wdrażać w końcu mogą myśleć o produkcji. Ci którzy planowali testować nie muszą już borykać się z wersjami RC. Ci którzy testowali … muszą przebudować lab, co też właśnie zaczynam czynić.

May 4th, 2010

Hop, hop, hop po farmie

W serii Ruch sieciowy prawdę Ci powie nadszedł czas na odcinek #2 … tym razem w roli głównej Kerberos, farma aplikacji wielowarstwowa i niekończące się problemy z uwierzytelnieniem. Przeważnie o tej samej lub podobnej przyczynie.

W życiu niemłodego już konsultanta, zdarzają się jak już wspominałem dni, w których wezwany zostaje w charakterze kawalerii do rozwiązywania problemów. I tym razem tak było, a problem był całkiem typowy czyli uwierzytelnienie Kerberos nie działa. Może i samo uwierzytelnienie działa, ale skakać po farmie już nie chce. Ale nie uprzedzajmy faktów …

… i od początku

Konfiguracja, o której mowa, a w której występowały problemy była całkiem typowa jak na aplikacje wdrażane w instytucjach. Per-analogia do pewnego systemu uprawy rolnej nazwijmy ją „trójwarstwówką”. Składała się ona z:

  • Warstwy prezentacji, ogólnie front-end zwanej, w tym konkretnym wypadku był to MOSS 2007 działający w ramach farmy
  • Warstwa raportowa po środku (często warstwą logiki zwaną), w tym wypadku konkretnie realizowana przez SQL Reporting Services 2008
  • Warstwa baz danych, zawierająca dane ważne i pożądane, aby w tych raportach uczestniczących, tutaj na SQL 2008 składowane (OLAP dokładniej).

Całość miała być dostępna z poziomu warstwy inteligentnej zwanej użytkownikiem w jego kontekście bezpieczeństwa, czyli użytkownik dostając się do MOSS widzi te raporty i te dane w ramach raportów, do których dostęp ma na podstawie swojego konta z usługi katalogowej. Zadanie lekkie, łatwe i przyjemne dla protokołu Kerberos i mechanizmu delegacji w nim działającego. Który jak to zwykle bywa działać nie chciał. Przypadek typowy, ale z małymi przypadłościami i dlatego ciekawy …

… warstwa prezentacji

MOSS 2007 jest typowym przykładem aplikacji, która potrafi skorzystać z mechanizmów uwierzytelnienie Kerberos o ile zostanie do tego skonfigurowana. Wymagana konfiguracja opisana jest w szczegółach na stronach Technet: Configure Kerberos authentication (Office SharePoint Server). Jedna rzecz o której warto wiedzieć i pamiętać – artykuł ten, wspomina o konieczności konfiguracji SPN dla adresów z odpowiednimi portami, co jest rozwiązaniem problemy związanego z domyślnym zachowaniem IE o którym już kiedyś pisałem. To o czym dokument ten nie wspomina, to fakt że IE ma jeszcze jedno „domyślne zachowanie” wpływające na działanie mechanizmów uwierzytelnienia, czyli w przypadku odwołania do adresu serwera z użyciem rekordu CNAME (popularnie mówiąc aliasu) konstruuje zapytanie o SPN używając rekordu podstawowego (A) dla tego aliasu. Problem jest znany i opisany w artykule KB 911149. Pomimo że nie jest to napisane wprost w tym artykule KB to zachowanie takie jest identyczne dla IE 7 i 8, tyle że nie jest potrzebny hotfix a tylko wpis w rejestrze.

I to był pierwszy problem, jaki był do wyprostowania w opisywanym przykładzie. Wszystko jak na dłoni widać w ruchu sieciowym, ale dla tego akurat przykładu nie mam – pozostawiam dla własnego przetestowania.

… warstwa raportowania

Następnym elementem układanki jest dostanie się do warstwy raportowej. W tym celu, MOSS rzeczony musi przejąć poświadczenia użytkownika, wystąpić o odpowiedni bilet dostępu do usługi i uwierzytelnić się w imieniu użytkownika względem usługi Reporting Services. Schemat delegacji omawiałem w swojej prezentacji na MTS, zainteresowanych odsyłam do materiałów (a i video jest na stronie MTS 2009).

Reporting Services muszą zostać również skonfigurowana do użycia uwierzytelnienia Windows – można tego dokonać przy instalacji lub później poprzez plik konfiguracyjny usługi. Oczywiście wiąże się to z koniecznością zarejestrowania w AD odpowiednich SPN dla tej usługi dla odpowiedniego konta, jednak poprawnie wykonuje to sama usługa przy starcie po skonfigurowaniu jej do działania z uwierzytelnieniem Windows (i o ile posiada takie uprawnienia). Odnotować należy również, że Reporting Services domyślnie uruchamiają swój web service na porcie innym niż 80, w związku z tym rejestrują też SPN dla odpowiedniego portu.

Wracając do naszej aplikacji … pomimo, że użytkownik poprawnie uwierzytelniał się do portalu MOSS to nie miał dostępu do raportów udostępnianych przez Reporting services. Wniosek … delegacja nie działa. Szybkie uruchomienie Network Monitor (chociaż ostatnio odnowiłem swoją znajomość z Wireshark odkąd da się go uruchomić na Win7 x64) i obserwujemy co poniżej:

Jak widać na zrzucie z ruchu sieciowego klient (farma MOSS) próbuje wykonać uwierzytelnienie z użyciem Kerberos (ramki 424, 428), niestety nie udaje się to i ponawia próbę używając NTLM (NLMP to błąd w paserach Network Monitor, oznacza NTLM), co również się nie udaje (co jednak było oczekiwane bo w takim kontekście próba ta wykonywana w kontekście użytkownika anoniomowego, NTLM nie umożliwia bowiem delegacji).
Kluczem do zagadki jest to, że Reporting Services udostępnia swoje usługi na porcie innym niż domyślny TCP/80. Wiąże się z tym to, że SPN zarejestrowane dla odpowiedniego konta, również zarejestrowane są z odpowiednim numerem portu.

Następny element układanki to wiedza trochę wyciągnięta z placu boju, czyli to że problemy z Kerberos opisane w KB w kontekście IE obejmują nie tylko samego IE ale również komponenty z niego korzystające lub korzystające z tych samych mechanizmów (bibliotek). W związku z tym, MOSS który wykonuje w naszej przykładowej aplikacji delegację do usługi reporting services konstruuje(zgodnie z opisywanym zachowaniem) SPN do usługi bez podania portu, czyli:

http/<nazwa serwera>

zamiast:

http/<nazwa serwera>:<numer portu>

Możliwe rozwiązania w danej sytuacji są co najmniej trzy:

  • Uruchomienie usługi Reporting Services na porcie 80
  • Wykonanie dla odpowiedniego procesu MOSS konfiguracji opisanej w KB
  • O ile to jest możliwe i nie konfliktuje z innymi usługami dodanie do konta serwisowego Reporting Services SPN dla usługi HTTP bez podanego portu .

W wypadku naszej aplikacji zastosowane zostało rozwiązanie trzecie (bardziej obejście niż rozwiązanie) i w wyniku tego działania delegacja pomiędzy MOSS a Reporting Services zaczęła działać poprawnie:

Takie zachowanie nie dotyczy tylko usługi MOSS. Innym przykładem, gdy warto pamiętać o obsłudze portu przy generowaniu SPN to scenariusze, w których ISA używana jest do publikowania usług, które wewnątrz sieci działają na portach innych niż standardowe. W takim wypadku, ISA przekazując zapytanie do usługi gdy wymaga to uwierzytelnienia z użyciem Kerberos również może generować zapytania używając SPN bez numeru portu.

… warstwa bazy danych

Dalej, w przypadku naszej aplikacji wymagana jeszcze była delegacja Kerberos z poziomu Reporting Services do bazy danych SQL. W tym wypadku była to już standardowa konfiguracja wymagająca zarejestrowania odpowiednich SPN dla usług dla odpowiednich konta, na których one działały.

… i po farmie

Jak widać nasz scenariusz do bardzo skomplikowanych nie należał, jednak jest ciekawy ze względu na:

  • Przekazanie uwierzytelnienia Kerberos pomiędzy trzema warstwami aplikacji,
  • Uwzględnienie niestandardowego zachowania zarówno IE jak i innego oprogramowania w zakresie obsługi protokołu Kerberos.

Jak zwykle w takich wypadkach najszybszym i najbardziej efektywnym narzędziem diagnostycznym okazuje się sniffer ruchu sieciowego … który jak to mówią … prawdę Ci powie.
I kolejny problem rozwiązany.

April 22nd, 2010

Programy antywirusowe są ZŁE !!!

Teza w tytule celowo kontrowersyjna i przejaskrawiona … to na początek, tak żeby nie iść w niepotrzebne dyskusje.

Pamiętacie awanturę wywołaną przez producentów oprogramowania antywirusowego przed wypuszczeniem Visty? Chociażby McAffee domagał się wtedy od Microsoft dostępu do jądra systemu, aby móc zapewnić najlepszą ochronę:

We urge MS to give security vendors this access as quickly as possible and not wait until the eleventh hour so that we can offer our customers the best protection.

Cóż, każdy miecz ma dwa ognie – jeżeli chcesz się bawić ogniem to musisz pamiętać że możesz się oparzyć, i takie inne … podsumowując. Oprogramowanie AV sięga głęboko w system, niekoniecznie zawsze używając udokumentowanych API. Powoduje to różnorakie problemu, a w sytuacji krytycznej może spowodować i problemy, któe spowodował (o ironio !!!) patch McAfee na Windows XP. W tym wypadku AV zadziałał na system jak wirus. I co gorsza nie było już antywirusa na antywirusa, który by go powstrzymał, ponieważ to ten program miał być właśnie ostatnią linią obrony użytkownika.

Co prawda nie było to spowodowane ingerencją w system jako taką a po prostu fałszywym rozpoznaniem pliku systemowego jako niebezpiecznego, ale pokazuje to, że i do programów AV zaufanie ograniczone trzeba mieć. I testwoanie uaktualnień definicji przez ich dystrybucją może mieć sens.

Artykuł CNET jest pełen przykładów problemów jakie ten patch wywołał, ale jeden z bardziej obrazowych to przykład ćwiczeń systuacji kryzysowej prowadzonych przez SANS, w ramach któych nie można było skorzystać z systemu dostępnego pod 911 (nasz odpowiednik to 112) ponieważ system padł … od antywirusa.

Taka poranna prasówka …

Uaktualnienie: wyszedł na ten temat szybki artykuł KB.

April 9th, 2010

Piątkowo …

Za Bpuhl

LOL … a jednak takie prawdziwe :) . Miłego weekendu.

April 9th, 2010

Logowanie diagnostyczne AD WS

Obiecałem do tematu AD WS powrócić tak więc obiecanki cacanki … i jestem. Ostatnio pisałem o tym jak ADWS jest lokalizowany przez klienta. A gdy klient już taką usługę zlokalizuje to przeważnie jest w potrzebie wykonania jakiś zapytań czy operacji. A gdybyśmy mieli ochotę takie działania klienta w celach diagnostycznych przejrzeć, ponieważ kończą się one jakiś magicznym problemem? Lub gdybyśmy chcieli mieć log z błędami ADWS jako usługi? I tutaj przydaje nam się mechanizm logowania diagnostycznego … jak go włączyć?

(cc) ehpien

AD WS to web service napisany w oparciu o WCF zainstalowana na każdym kontrolerze Windows Server 2008 R2 i na wybranych przez administratora kontrolerach W2003 / 2008. Usługa jak usługa – ma swoją konfigurację. W przypadku ADWS konfiguracja tejże leży w pliku Microsoft.ActiveDirectory.WebServices.exe.config w folderze instalacyjnym AD WS (%WINDIR%\ADWS).

Parametry konfiguracyjne opisane są na stronie TechNET, jednak tych związanych z logowaniem diagnostycznym na tej stronie nie ma. W celu włączenia logowania diagnostycznego AD WS należy w pliku konfiguracyjnym, w sekcji <appSettings> dodać następujące klucze:

<add key="DebugLevel" Value="<log_level>" />

gdzie log_level może być jedna z wartości: None, Error, Warn oraz Info. Info to najwyższy poziom logowania, gdzie oprócz komunikatów o błędach zapisywane są w pliku logu również wykonywane operacje i przesyłane komunikaty pomiędzy klientem a usługą. Plik logu natomiast wskazuje się poprzez następny wpis w pliku konfiguracyjnym:

<add key="DebugLogFile" value="<ścieżka do pliku logu>" />

Tutaj większych wyjaśnień raczej nie trzeba. Całość może wyglądać mniej więcej tak:

<add key="DebugLevel" Value="Info" />

<add key="DebugLogFile" value="C:\ADWSLog\Adws_trace_log.txt" />

Po wprowadzeniu zmian w pliku konfiguracyjnym należy zatrzymać i ponownie uruchomić usługę.

Wada rozwiązania jest taka, że konfigurację taką w razie potrzeby należy wykonać na każdym z DC osobno. W zasadzie wystarczy skopiować odpowiedni plik.

I jak przy każdym mechanizmie logowania diagnostycznego należy pamiętać, że nie ma czegoś takiego jak darmowy obiad – logowanie kosztuje. Więc bez potrzeby go nie nadużywajmy, w szczególności w najbardziej rozwiniętej opcji (Info).

March 25th, 2010

Gdzie jest web service?

Windows 2008 R2 pomiędzy innymi zmianami wprowadza również nowy interfejs dostępu do danych usługi Active Directory – Active Directory Web Service (ADWS). W ramach przenoszenia tej funkcjonalności na starsze systemy udostępniona została również wersja dla systemów 2003/2008 pod nazwą Active Directory Management Gateway.

 

(cc) paprikaOptic

To tyle jeżeli chodzi o fakty … częściowo o nich mówiłem zresztą też na mojej sesji na WCL dotyczącej nowości w Windows 2008 R2 (właśnie zobaczyłem że nie umieściłem na blogu materiałów chyba … nadrobi się).

ADWS używana jest przez kilka produktów w chwili obecnej, między innymi AD Administrative Center i moduł Powershell dla AD w Windows 2008 R2. I o tym ostatnim w tym wpisie poniekąd będzie. Próbując bowiem z niego skorzystać jeden z użytkownikow (pozdrawiam bo wiem że poczytuje ;) ) napotkał na problem objawiający sie komunikatem:

Windows PowerShell

Copyright (C) 2009 Microsoft Corporation. All rights reserved.

WARNING: Error initializing default drive: ‘Unable to find a default server

with Active Directory Web Services running.’.

PS C:\Windows>

Pytanie więc … gdzie szukać przyczyn, czyli jak serwer z ADWS znajdowany jest przez klienta, w tym wypdku modu Powershell.

Odpowiedź jak to w wypadku AD jest prawie że standardowa, czyli – DC Locator. DC locator to proces lokalizacji kontrolera domeny przez klienta, pozwalający na wybór najbardziej optymalnego kontrolera domeny w ramach danej konfiguracji. Oprócz uwzględnienia położenia klienta w ramach infrastruktury usługi  katalogowej (podsieci, lokacje) klient może przekazać do tego procesu dodatkowe parametry – na przykład że dany DC ma być GC lub że nie może to być RODC. Te same informacje są też zwracane klientowi, jako część informcji o kontrolerach domeny w procesie ich wyszukiwania. Całość zawarta jest w strukturze DS_FLAGS.

W ramach implementacji rzeczonej ADWS do DS_FLAGS dodany został dodatkowy bit opisany jako:

DS_WS_FLAG, The Active Directory Web Service, as specified in [MS-ADDM], is present on the server.

I tenże bit jest używany przez klienta do tego, aby serwer z instancją ADWS namierzyć i z usług jego skorzystać. Klient w tym celu specyfikuje przy zapytaniu o DC dodatkowy parametr DS_WEB_SERVICE_REQUIRED.

I w zasadzie to by było na tyle. Problem w tym jednak, że środowiska nie są jeszcze monolityczne i w rzeczywistości (okres migracji) często mamy do czynienie ze środowiskiem gdzie mamy kontrolery w wersji 2008R2 jak i starsze 2003/2008. Te zaś tej nowej flagi nie rozumieją, i aby ją zrozumiały potrzebna im jest tak zwana poprawka, odpowiednio KB969249 (2003) i KB967574 (2008).

Planując więc wdrożenie W2008R2 i mechanizmów korzystających z ADWS (lub ADMG) warto pamiętać o tym, żeby odpowiednie poprawki wdrożyć. W dużych środowiskach, powiedzmy z kilkudziesięcioma DC warto też zadbać o to, aby ADWS był wdrożony na odpowiedniej liczbie serwerów. Zresztą o tym zawsze warto pamiętać, aby się nie okazało, że nasz świeżo stworzony skrypt Powershell po wyłączeniu jednego DC przestaje działać.

To tyle na dzisiaj w zasadzie … o diagnozowaniu problemów z ADWS trochę jeszcze będzie wkrótce.