it-flow.pl

Ostatnimi czasy zdarza mi się doradzać czy też może prowadzić jakieś dłuższe uzasadnienia dlaczego SCCM to jednak przydatne narzędzie. Niestety w przypadku niektórych osób nie jest to łatwe, szczególnie gdy ktoś wydaje sporo na software, przy którym administrator spędza kilka godzin tylko po to by zainstalować jedną paczkę. Niestety jak to zwykle bywa, na konferencjach czy prezentacjach często stykamy się z hasłami:

•  “Pamięta Pan jak administrator tłumaczył się, że nie może zdalnie zainstalować tego oprogramowania na waszych 600 komputerach ponieważ producent nie udostępnił paczki MSI? Od teraz będą Państwo mogli w dowolnej chwili zainstalować dowolne oprogramowanie niezależnie od typu instalatora!”
• “… I teraz widzimy jak  w przeciągu 4 minut stworzyliśmy paczkę, którą możemy w dowolnym czasie rozdystrybuować na wszystkich stacjach w naszej firmie…. Sam użytkownik stacji roboczej nie musi przechodzić przez proces instalacji.”

 

Wszystko fajnie, niestety jak to mówią: Lucyfer tkwi w szczegółach, które często są pomijane przez osoby reklamujące dany produkt. Nie ma w tym nic dziwnego, przecież sprzedawca zawsze chce zarobić na systemie. Niestety w 80% przypadków przedstawiając wady danego produktu lub czas jaki będzie musiał poświęcić administrator na konfiguracje niestandardowych programów, nasz sprzedawca raczej nie utrzymałby się w branży.

W przypadku chęci wykorzystania SCCM do dystrybucji oprogramowania trzeba pamiętać  o tym, że Configuration Manager nie odpowiada za przygotowanie samego instalatora. Ta czynność nadal pozostaje w gestii administratora. Jeśli chcemy zainstalować dowolne oprogramowanie bez ingerencji użytkownika to musimy przygotować odpowiedni skrypt, plik podpowiedzi, zapoznać się z parametrami instalatora. W przypadku większości aplikacji proces ten może trwać od trzech do pięciu minut. Jeśli chcemy przygotować bardziej zaawansowaną instalację musimy się liczyć z faktem, że wymagany czas może drastycznie wzrosnąć.

Po utworzeniu paczki, trzeba ją jeszcze przetestować, sprawdzić czy instalator się nie zawiesza w dowolnym kroku, czy proces instalacji trwa tyle co zakładaliśmy, itd.

Podczas ostatnich potyczek z Windows 7 i Cross realm zauważyłem ciekawą rzecz. W przypadku wykorzystania interfejsu hosta poprzez maszyny wirtualne (Bridged connection) z stacji hosta na którym jest zainstalowany VMware można uruchomić Wiresharka i śledzić ruch przesyłany z maszyn wirtualnych w świta. Jedynie w celu wyczyszczenia zbędnego ruchu warto użyć filtru ip.addr=Adres_IP. Jest to o tyle przydatne, że nie trzeba się bawić w zdalne łapanie ruchu. Niby oczywista rzecz a przez kilka dni męczyłem się w zdalne łapanie ruchu czy przełączanie między kontami na jednej stacji.

Migracje, migracje i jeszcze raz migracje. Od pewnego czasu siedzę i staram się poprawić i udoskonalić stare usługi, zaktualizować systemy, itd.

Jedną z bardziej interesujących rzeczy jest migracja z Windows XP do Windows 7. Jak to zwykle bywa jednym z częstszych problemów jest odpowiednia konfiguracja systemów do współpracy z trustem między REALM-em MIT Kerberos a Active Directory.

W Windows 7 Microsoft wprowadził sporo zmian część z nich dotyczy konfiguracji samego logowania do REALMu.

Główne zmiany to:

• Uproszczenie konfiguracji samego REALMu na stacjach klienckich
• Wyłączenie przestarzałych mechanizmów szyfrowania (DES-CBC-{CRC,MD5})- źródło
• Wprowadzenie odpowiedniego szablonu polis do konfiguracji REALMu

Po instalacji Windows 7 i wpięciu systemu do domeny rozpocząłem konfigurację REALMu. Po małym przeglądnięciu kilku stron amerykańskich uniwersytetów okazało się, że konfiguracji realmu w Windows 7 nie przeprowadza się już za pomocą ksetup.exe:

ksetup.exe /addkdc nazwa_realmu nazwa_serwera_kdc_dla_podanego_realmu

ksetup.exe /domain nazwa_domyslnej _domeny

Dla ułatwienia Microsoft utworzył odpowiedni szablon polis:

Na początku zainteresowałem się tylko dwiema opcjami:

• Define interoperable Kerberos V5 realm settings – opcja odpowiada za odpowiednią konfigurację realmu oraz serwerów KDC, które ma wykorzystać klient. W Windows XP konfiguracja tych ustawień dobywała się za pomocą ksetup.exe
• Require strict KDC validation – sprawdza pewne obostrzenia dotyczące certyfikatu serwera KDC.

Dodatkowo skusiłem się na ustawienie DefaultLogonDomain na nazwę mojego Realmu. Jak większość pamięta od Visty z ekranu logowania zniknęła możliwość wyboru domeny/realmu logowania. Aktualnie użytkownik ma się logować za pomocą User Principal Name (login@nazwadomeny). Ustawnie DefaultLogonDomain pozwala logować się do domyślnej domeny/realmu za pomocą samego loginu

Jeśli, ktoś nie chce konfigurować tych ustawień za pomocą GPO to może wykorzystać odpowiedni wpisy w rejestrze

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
“DefaultLogonDomain”=”Nazwa_Realmu”

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos]
“MitRealms_Enabled”=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\MitRealms]
“Nazwa_Realmu”=”<f>0×00000008</f><k>serwer_kdc_1;serwer_kdc_2</k>”

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters]
“KdcValidation”=dword:00000002

W przypadku trzeciego ustawienia (Define interoperable Kerberos V5 realm settings) między <f></f> podajemy w postaci hex-a listę opcji, które mają być wykorzystane podczas odpytywania serwerów KDC w danym realmie:

• 0×00 None – brak flag
• 0×01 SendAddress – pozwalaj na adresy IP w generowanych ticketach
• 0×02 TcpSupported – serwery kluczy akceptują ruch TCP, wymagany przy dużych pakietach
• 0×04 Delegate – każdy w realmie jest zaufany do delegacji
• 0×08 NcSupported – podany realm wspiera Name Canonicalization

Przepraszam za trochę lakoniczne tłumaczenie, więcej informacji o opcjach w technecie.

Jeśli po konfiguracji nie udaje się zalogować do systemu. Występuje komunikat błędny login lub hasło, to najprawdopodobniej serwery kluczy wykorzystują mechanizmy DES-CBC-CRC lub DES-CBC-MD5, które w Windows 7 i Windows Server 2008 R2 zostały domyślnie wyłączone. Włącznie mechanizmów najlepiej wykonać za pomocą GPO:

Tutaj taka drobna uwaga, którą podał Tomek Onyszko na wss.pl. W niektórych przypadkach warto wyłączyć AES128 i AES256 jeśli nie jest on wykorzystywany.

Po zmianie tych ustawień można się poprawnie zalogować używając MITowskiego realmu. Niestety po zalogowaniu na użytkownika nie zostały nadrzucone polisy oraz sam użytkownik nie miał dostępu do serwerów będących w domenie Windows. Co prawda w logach DC widać, że zaszło mapowanie użytkownika z realmu na użytkownika w AD jednak polecenie klist nie wyświetla wymaganych ticketów.

Po trzech dniach spędzonych przy Wiresharku postanowiłem zapytać na wss i jak zwykle w sprawach związanych z Kerberosem Tomek Onyszko okazał się być bardzo pomocny. Nie wiem jak mu podziękować bo gdyby nie jego pomoc to nadal ślęczałbym nad ekranem z dumpem wiresharka.

Poniżej postaram się krótko opisać gdzie tkwił problem.

W przypadku zaufania między domenami czy realmami, komputer odpytuje odpowiednie serwery kluczy w celu pozyskania odpowiednich ticketów, które później będzie wykorzystywał do uzyskania dostępu do konkretnych serwerów. W tym poście nie będę tego jakoś szczególnie opisywał (dobry materiał na kolejny post). W skrócie jeśli klient nie dostanie ticketu z serwera kluczy z jednej domeny to prosi o odpowiedni ticket Granting Services, który pozwala mu odpytać kolejny serwer kluczy odpowiedniej domeny.

Tak robił XP, który jest aktualnie na stanowiskach:

Powyższy zrzut ekranu obrazuje prośbę klienta o odpowiedni ticket na potrzeby dostępu do miejsca gdzie leża polisy:

1. Klient prosi o TGS serwera KDC w realmie, w którym uwierzytelnił się użytkownik
2. Serwer kluczy dla danego realmu zwraca informacje PRINCIPAL_UNKNOWN – informacja o określonym SPN znajduje się w innym serwerze kluczy ( w moim przypadku kontrolerze domeny z którą zestawiony był trust realm )
3. Klient prosi o TGS (krbtgt/nazwa_realmu) ticket jest wymagany by klient mógł rozmawiać z zaufaną domeną
4. Serwer kluczy w naszym realmie odsyła odpowiedni ticket
5. Klient prosi kontroler domeny o określony ticket dla cifs/nazwa_kontrolera (strzałka 3 na zdjęciu), wykorzystując ticket, który otrzymał w kroku czwartym.
6. Serwer zwraca odpowiedni ticket.
7. Klient przystępuje do komunikacji z serwerem plików.

W przypadku Windows 7 spraw wyglądała trochę gorzej ponieważ, system pomijał prośbę o TGS (krbtgt, oraz o odpowiedni ticket w zaufanej domenie i przeskakiwał na NTLM):

Jak widać na powyższym zrzucie ekranu klient:

1. Pyta serwer kluczy dla wykorzystywanego realmu
2. Serwer zwraca odpowiedź o braku Principala o określonej nazwie (2)
3. Klient próbuje wykorzystać NTLM by dostać się do zasobów.
4. Próba w dalszej części kończy się fiaskiem.

Po pomocy Tomka okazało się że problem ten można rozwiązać poprzez wskazanie systemowi klienckiemu jakie nazwy realmow/lasow ma przeszukiwać. Można to skonfigurować w GPO ( pierwsze zdjęcie w wpisie) Use forest search order. Po dopisaniu tam nazwa_realmu, nazwa_domeny_ad, klient zaczyna odpytywać kontroler. Jedynym minusem który tutaj występuje jest brak zapytania ok określony  TGS (krbt/…) jednak ticket ten zostaje pobrany na samym początku podczas logowania do domeny. Po ostatniej zmianie klient zaczyna poprawnie funkcjonować:

• pobierane są polisy dla użytkownika
• można uzyskać dostęp do określonych zasobów dyskowych w zaufanej domenie.

Przyznam się, że problem jest dość ciekawy i w wolnej chwili trzeba się będzie trochę bardziej w niego zagłębić. Ale wcześniej muszę sobie skonfigurować wirtualnej środowisko by nie bawić się w zamazywanie zrzutów z Wiresharka. Przy okazji może uda mi się opisać proces konfiguracji Cross Realm Trusta.