W2K.PL

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).

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.

Z niekończącej się serii przypadków pod wspólnym tutułem "Ruch sieciowy prawdę Ci powie" prezentujemy odcinek #1 … zagadka tajemniczego DHCP.

W życiu konsultant są takie dni, w których rozwiązuje problemy. Problemy są różne … czasami proste, czasami mniej proste. Ostatnio trafił do mnie problem z opisu dziwny, a mianowicie:

• Stacja robocza w sieci znajdująca się uzyskiwała adres IP z serwera DHCP, tak jak być powinno
• Po jakimś czasie, stacja ta zmieniała w swojej konfiguracji IP serwery DNS na inne, zaprzyjaźnione a jednak inne. Zaprzyjaźnione w tym wypadku oznacza, że znajdowały sie one w trochę inne lokalizacji I nazwy rozwiązywały też trochę inaczej.

Problem powodował inne problemy, na przykład takie że nazwy rozwiązywały sie na trochę inne adresy, co powodowało, że aplikacje użytkowników działały trochę inaczej.

Po fazie spekulacji różnych opcji I możliwości (jako że to Win7 to może Direct Access, albo ogólnie IPv6 albo I chochlik … tak, napewno chochlik) przyszedł czas prawdy ostatecznej – zajrzyjmy do ruchu sieciowego. I cóż tam widzimy …

Ruch prawdę Ci powie

… klient DHCP ma to do siebie, że zachłanny jest na adresy.  W celu tychże uzyskania rozsyła po sieci różnorakie żądania (rekłestami zwane). Rzeczony klient nasz takie żądania i  owszem wysyłał w postaci dyskusji:

• DHCP Discover –> DHCP Offer
• DHCP Request –> DHCP Ack.

Wynikiem takiej rozmowy jest uzyskanie przez klienta adresu IP. Nasz klient w tej konwersacji rozmawiała z serwerem lokalnym, nazwijmy go SerwerA (jakże oryginalnie).

Dla osób nie zaznajomionych I zastanawiających się skąd adres 255.255.255.255 przypominam że DHCP działa używając rozgłoszeń, broadcastam zwanych.

Prawem klienta DHCP jest dowiedzenie się więcej o swojej sieci. W tym celu, po uzyskaniu adresu IP może on posłużyć się pakietem DHCP Inform, celem uzyskania dodatkowych informacji. Odpowiedzią na taki pakiet jest DHCP Ack zawierający te dodatkowe opcję. I w przypadku naszego klienta takoż było:

(pełny rozmiar po kliknięciu)

Problem jedynie polegał na tym, że odpowiedzi na zadane pytanie DHCP Inform udzialał już serwer DHCP, który nazwiemy SerweremB, który grzecznie stał w sieci, prawdopodobnie za routerem i na zapytania czekał.

(pełny rozmiar po kliknięciu)

I tajemnica rozwiązana.

Ale wnioski, wnioski …

Wnioski z nauki są conajmniej dwa. Pierwszy to taki, że jeżeli  już w sieci znajdują się dwa serwery DHCP to warto zadbać o to, aby ich konfiguracja była spójna.

Drugia jak w tytule … ruch sieciowy prawdę Ci powie I czasami (w 95% pewnie bym zaryzykował) zamiast zastanawiać się co się dzieje warto sięgnąć po to narzędzie … parafrazując Dr Housa … ruch sieciowy nigdy nie kłamie.

No nic, miłego analizowania …

P.S.#1 Jeżeli ktoś jest zainteresowny co te wszystkie komunikaty znaczą to zapraszam do KB 169289 tudzież do RFC2131.

P.S #2. Co do serwerów DHCP to w Windows 2008 R2 zaszła mała zmiana co do obsługi rezerwacji – opisana w KB 2005980. Też wyszło najaw (dla mnie) przy okazji jakiegoś zapytania.

Mając w perespektywie ponad dwie godziny jazdy z Warszawy do Poznania (polecam IC) mam w końcu chwilę czasu, żeby rozładowac kolejkę tematów … na początek szybki tip dotyczący konsoli ADU&C.

W przypadku, gdy chcemy nadać kontu uprawnienia do delegacji poświadczeń użytkownika z użyciem Kerberos, jednym ze sposobów wykonania tej konfiguracji jest konsola ADU&C. W konsoli tej, we właściwościach użytkownika znajduje się zakładka Delegation. A co gdy jej tam nie ma … ???

Jeżeli jej tam nie ma, to oznacza to tylko tyle, że dla danego konta nie zostały skonfigurowane jeszcze żadne wartości SPN. A w tym wypadku zależność jest prosta – nie ma SPN, nie będzie delegacji. Więc po co ją konfigurować.

Dodajmy więc SPN dla konta usługi I voile … zakładka delegacji pojawiła sie automagicznie we właściwościach użytkownika. 

I to w zasadzie by było na tyle. Uważny czytelnik już wie, że jeden z kolejnych wpisów będzie dotyczył konfiguracji Kerberos właśnie.

PS. IC spóźniło sie w końcu 45 minut … uwzględnijcie przy planowaniu spotkań

Jeżeli ktoś był na mojej sesji o ADFSv2 i nadal zachodzi  w głowę o co chodzi, lub też nie był i też zachodzi w głowę o co chodzi z tym ADFS to polecam wyjaśnienie słowno obrazkowe (podesłane przez Laurę).

(c) Fpweb.net

Celne, I co tutaj dużo mówić … LOL.

Tytuł tego wpisu wymknął mi sie kiedyś w trakcie rozmowy z kolegami z działu zajmującego się ILM \ FIM, raczej w dosyć krytycznym kontekście. A jednak … FIM FIM …. Hurray … FIM 2010 czyli Forefront Identity Manager 2010 (FIM 2010), który uzyskał status RTM.

Dla tych, którzy tematem się interesują jest to wiadomość długo oczekiwana. Przez sceptyków nawet wyczekiwana była wiadomość całkiem inna … Ważne że jest. Teraz czas odświeżyć umiejętności na wersji RTM

Wersje eval FIM2010 można pobrać ze strony Microsoft Downloads.

FIM 2010 został ogłoszony przy okazji odbywającej się właśnie konferencji RSA. Na tej samej konferencji ogłoszona została wersja CTP U-Prove, która jakiś czas temu została przejęta przez Microsoft. Więcej o U-Prove I możliwości zastosowania tej technologii można znaleźć na Identity Element, linki na blogu Vittorio.  Z ciekawych rzeczy to w ramach CTP U-Prove udostępnione zostały dwa SDK  zawierające jak narazie przykłądy kodu dla C# I Javy.

Dla lubiących oficjalne ogłoszenia prasowe link to tegoż.

… człowiek coś chlapnie w niedziele wieczorem w komentarzach do bloga I cóż, chlapnęło się … trzeba pisać. O lokalizacji SYSVOL będzie. Kto był na ostatniej mojej prezentacji na ICL to już trochę słyszał … kto nie był, niech czyta.

SYSVOL jaki jest każdy widzi, wystarczy że zajrzy do udziałów udostępnianych przez kontroler domeny. Rolą SYSVOL jest udostępnianie plików klientom usługi katlaogowej – w szczególności plików szablonów polityk GPO (duży skrót: GPO składa się z GP container (GPC) w katalogu I GP Template (GPT) na SYSVOL), skrytpów startu \ logowania itp. Przed zreplikowaniem I udostępnieniem SYSVOL kontroler domeny nie udostępnia swoich usług, bez SYSVOL klienci nie będą też przetwarzali GPO. To tak w telegraficznym skrócie.

(cc) swingnut

Z czysto technologicznego punktu widzenia SYSVOL to nic innego jak rozproszony system plików (DFS) udostępniany jako domenowa przestrzeń nazw (odwołania do SYSVOL odbywają się poprzez \\<FQDN domeny>\SYSVOL). Jego zawartość jest replikowana przy pomocy FRS w systemach starszych niż Windows 2008 I przy użyciu DFS-R w środowiskach opartych o Windows Server 2008 I wyższych, o ile administrator dokonał migracji tego mechanizmu. Szczerze mówiąc, to w zasadzie zawartość SYSVOL może być replikowana dowolnie, tak długo jak utrzymana jest jej spójność na wszystkich kontrolerach domeny.

Mówiąc o wszystkich kontrolerach domeny – skąd wiemy, z której repliki SYSVOL w skorzysta nasz klient, czyli jak lokalizowana jest ta replika przez klienta? I tutaj dochodzimy do problemu …

Keep reading →

“(…) Pojawiam się I znikam, I znikam I znikam … (…)” – tak by mógł sobie zaśpiewać klasycznie link do ściągnięcia AD LDS dla Windows 7, o którym pisałem niedawno.

(logo by joe)

Tym razem pojawił się ponownie … podobno teraz już na dobre.

Dzisiaj mówiłem na IntelliMirror Community Launch (ICL) zorganizowanym przez chłopaków z WGUiSW. Mówiłem o GPO a że temat szeroki to o kilku wybranych tematach, czyli ogólnie z czym to się je, chwilę o SYSVOL I jego funkcji a na koniec trochę o rozwiązywaniu problemów. Tyle co w 60 minut się zmieściło.

Jako że po takich spotkaniach często pojawia się pytanie o materiał z prezentacji – uprzedzając pytania zamieszczam (PPS).

Tym którzy byli mam nadzieję, że się podobało. Ci którzy byli przez LiveMeeting podobno nic nie słyszeli – tak wyszło że po sali chodziłem. Ale tak czy inaczej mam nadzieję że było pożytecznie. Ewentualne komentarze dobre I krytyczne mile widziane … w komentarzach lub na e-mail.

Dla uspokojenia na początek szybko … nie, nie nawiązałem personalnego związku ze swoją przeglądarką czy też nie podejrzewam o to nikogo innego. Chociaż zapewne część z nas jest mocno przywiązana do swojej konfiguracji, dodatków w przeglądarce itp.  Czy przeglądarka odwzajemnia to przywiązanie (jakkolwiek dziwnie to brzmi) czy też niecnie nas zdradza w sieci z dowolną stroną???

(cc) bored-now

Poprzez blog Kima Camerona trafiłem na stronę projektu Panopticlick uruchomiony przez Electronic Frontier Foundation (EFF).  Projekt ten na podstawie anoniomowo dostępnych danych o przeglądarece użytkownika stara się określić jak łatwo byłoby odróżnić tą konkretną przeglądarkę od innych … a tym samym jak łatwo, na podstawie li tylko informacji o przeglądarce śledzić zachowania użytkownika w sieci.

Przykładowy wynik dla mojej przeglądarki poniżej.

Jak widać wśród ponad 400 tys przeglądarek moja okazała się unikalna w pewien sposób, co oznacza że *TAK* moja przeglądarka mnie zdradza. Nieładnie …

Podejście jest o tyle ciekawe, że z pozoru nieistotny element jak charakterystyczna karta graficzna czy też rzadko używany plugin do przeglądarki staje się w tym kontekście elementem wyróżniającym. I tak nagle nasza sieciowa tożsamość rozciąga się w pewnym kontekście już nie tylko na nasze dane ale również I na narzędzia, którymi się posługujemy.

Czy to faktycznie jest problem ??? Pytanie czy faktycznie jest możliwe zbudowanie mechanizmu, który będzie użytkowników identyfikował (a przynajmniej się starał) w oparciu o te informacje. Pytanie czy należy coś w kierunku uniemożliwienia takiego podejścia zrobić wcześniej … na to pytanie pewnie odpowiedzą sobie ludzie zajmujący się rozwojem przeglądarek itp. Odpowiedzą, jeżeli ktoś je im zada lub sami je postawią. Zobaczymy.

Małe uaktualnienie

Witek po opublikowaniu tej notki podesłał mi link do tej wiadomości. Wiadomość jak wiadomość, kto ekscytuje się fljemami to może poczytać I analizować. To co jest interesujące to:

(…) Nie korzystano ze statystyk sprzedaży (trudne do zanalizowania w przypadku wolnego oprogramowania) ani ankiet, lecz zanalizowano dostępność specyficznych fontów na komputerach łączących się z Internetem. Każdy z pakietów zawiera unikalne fonty niedostępne w innych aplikacjach. Ich analiza pozwala na dość dokładne stwierdzenie czy na danym komputerze zainstalowany jest dany pakiet. (…)

Jak widać informacja udostępniana przez przeglądarkę, na pozór mało istotna, może zostać użyta w różnym kontekście. O podobnej kwestii informuje również Kim Cameron w kolejnym wpisie na swoim blogu:

(…) The authors claim the groups in all major social networks are represented through URLs, so history stealing can be translated into “group membership stealing”.  This brings us to the core of this new work.  The authors have developed a model for the identification characteristics of group memberships – a model that will outlast this particular attack, as dramatic as it is. (…)

Wychodzi więc, że nasza przeglądarka przez swoją charakterystykę I różne jej przypadłości może być użyta do uzyskania całkiem ciekawych informacji. Zadanie dla osób planujących kolejne wersje przeglądarek wydaje się dosyć ciekawe … uwzględnić fakt, że przeglądarka może zostać użyta do identyfikacji użytkownika w sieci w jej mechanizmach. Jak już napisałem wcześniej … zobaczymy.