it-flow.pl

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.

W Siódemce wprowadzono natywne wsparcie dla obrazów VHD i dodatkowo całkiem ładnie zintegrowano VirtualPC z Explorerem. Niestety domyślnie Windows 7 nie wspiera Virtual Server 2k5 R2:/ Innymi słowy nie za bardzo mamy jak uruchomić nowy laucher dla kursów MOC:/ Podczas instalacji VS2k5 dostaniemy komunikat typu:

Mimo komunikatu instalacja zakończy się sukcesem. Niestety po ponownym uruchomieniu komputera system nie będzie mógł podnieść usługi vssrvc.exe, ponieważ zostanie ona uznana za niekompatybilną. Rozwiązanie problemu, które udało mi się znaleźć polega na wyłączeniu, na czas instalacji, części opcji mechanizmu zgodności.

Szybkie Now how:

1. Na starcie instalujemy IIS, jest do jeden z dodatków systemu, który możemy doinstalować przez dodaj usuń programy.
2. Po zainstalowaniu IIS odpalamy jako administrator gpedit.msc.
3. W drzewie polis przechodzimy do Konfiguracja komputera –> Składniki Systemu Windows –> Zgodność aplikacji.
4. Następnie włączamy odpowiednie ustawienia, nie wszystkie z ustawień są wymagane. Obecnie nie miałem czasu dochodzić, które poza widocznymi na zdjęciu mogą być nie skonfigurowane:
5. Po konfiguracji w/w opcji przechodzimy dalej do gałęzi  Konfiguracja komputera –> System –> Rozwiązywanie Problemów i diagnostyka –> Diagnostyka zgodności aplikacji.
6. Wyłączamy klucze zgodnie z poniższym rysunkiem:
7. Zamykamy gpedit.msc
8. Uruchamiamy wiersz poleceń jako administrator i wpisujemy: gpupdate /force
9. Restartujemy komputer, czasami gdy komputer nie zostanie zrestartowany Asystent zgodności aplikacji uruchomi się podczas instalacji.
10. Uruchamiamy instalator Virtual Server 2k5 R2
11. Po zakończeniu instalacji przechodzimy do katalogu gdzie zainstalowaliśmy VServer (Domyślnie: C:\Program Files\Microsoft Virtual Server\
12. Zmieniamy nazwę pliku vssrvc.exe na np. vssrvc7.exe
13. Za pomocą Run As uruchamiamy regedit i modyfikujemy wszystkie klucze rejestru, które zawierają wpis vssrvc.exe na  vssrvc7.exe.
14. Uruchamiamy ponownie komputer
15. Cofamy wszystkie zmiany z kroku 4-6

Czy Virtual Server 2005 będzie jeszcze w pełni wspierany przez Windows 7 tego nie wiadomo. Osobiście wydaje mi się, że nie. Wynika to z faktu, że nie jest to usługa dedykowana na desktopy. Poza tym V Server nie posiada niektórych dodatków, które pojawiły się w nowym Virtual PC.

Producenci płyt głównych coraz częściej implementują w swoich płytach możliwość tworzenia FakeRaidu. Ostatnio zaopatrzyłem się w komputer stacjonarny i przez pewnie okres czasu udało mi się przetestować FakeRaid, szczególnie jego niezawodność.

Na początku po zakupie pierwszej płyty głównej spiąłem wszystko w Raid1. W celach testowych zainstalowałem system, oprogramowanie, etc. Po kilku dniach zapragnąłem zmienić układ chłodzenia procesora. Niestety nowy wentylator wymagał wykręcenia płyty głównej. Po zmianie mocowania chłodzenia do procesora włożyłem płytę główną, złożyłem komputer w całość i uruchomiłem. Jak się okazało płyta Asusa po wyjęciu z obudowy jakimś cudem stwierdziła, że jest nowa i wróciła do domyślnych ustawień. Jeszcze przed startem biosu wiedziałem, że trzeba zmienić tryb w jakim działają złącza SATA na Raid. Niestety po ponownym uruchomieniu raid1 został poprawnie wykryty przez komputer, tzn. występowała  odbudowa. Niestety system nie wstał:( Szybkie próby naprawy systemu za pomocą bootrec i kreatora naprawy nie przyniosły pozytywnego skutku.

Po  tygodniu z kilku powodów zmieniłem płytę główną z Asusa na Gygabita. Po zmianie płyty wymagana była budowa nowego mirrora i instalacja nowego systemu. Oczywiście nawet przez myśl mi nie przeszło, że wszystko zadziała bez reinstalacji systemu :] Przez kolejny tydzień często zmieniałem dyski między różnymi portami SATA co często kończyło się ponowną instalacją całego systemu.

Po dwutygodniowej zabawie postanowiłem zrobić te same roszady za pomocą raidu systemowego. Po zainstalowaniu Windows 7 przyłączyłem jeden wolumin raid0 i jeden raid1 na tych samych dyskach.  Po tygodniu użytkowania nie zauważam żadnej różnicy między raidem realizowanym tylko przez system a fakeRaidem, który też częściowo jest wykonywany przez system. Tzn. właściwie jest jedna różnica:)  W przypadku stripingu wydajność spadła jednak jest to spowodowane dołożeniem kilku innych partycji w innej konfiguracji:]

Podczas ostatniego tygodnia zdarzyło mi się przepiąć oba dyski na zupełnie inną płytę, zmieniać porty do których były podpięte. Jak na razie nie zdarzyła się sytuacja, w której system powiedziałby “Przepraszam ale nie mogę się uruchomić” :> Raz wymagana była odbudowa mirrora jednak sytuacja ta nie uszkodziła systemu. Chodził on wolniej przez klika godzin jednak potem wrócił do siebie.

Zatem jeśli planujesz instalacje FakeRaidu to warto się nad tym zastanowić, szczególnie gdy często zmieniasz konfiguracje sprzętową komputera.

Cztery lata używania systemów innych niż Windows odbijają dość mocne znamię Szczególnie gdy ktoś przez spory okres czasu bardziej zaprzyjaźniał się z konsolą niż z X-ami. Mimo iż od około trzech lat cały czas zaprzyjaźniam się z “oknami” to nadal zdarza mi się korzystać z wiersza poleceń.

Tak, w systemach Windows jest coś takiego jak wiersz poleceń. Microsoft wypuszczał i wypuszcza masę narzędzi ułatwiających pracę w konsoli. Cześć z tych narzędzi nie jest domyślnie instalowana w systemie dlatego wiele osób nie wie o ich istnieniu.

Ostatnimi czasy spotkałem się z kilkoma pytaniami od studentów i znajomych, które dotyczyły  odpowiednika unixowej komendy tail. W przypadku systemów Windows Server do 2003 i systemów klienckich do Windows XP sprawa była dość prosta. Wystarczyło pobrać  Windows Resource Kit Tools. Po zainstalowaniu i uaktualnieniu ścieżki Path o odpowiednie wpisy można było korzystać z komendy tail.

Jedynym minusem tej komendy jest brak możliwości definiowania ilości wierszy, które mają zostać wyświetlone.  Opcja –f działa bardzo dobrze i poprawnie wyświetla informacje dopisywane do pliku.

A co z Windows Server 2008, Vista i 7?

W tych systemach te same czynności możemy wykonać za pomocą powłoki Powershell.

Odpowiednikiem komendy tail –f nazwa_pliku jest Get-Content nazwa_pliku –wait.

Co ciekawe da się też wyświetlać określoną ilość linii: Get-Content nazwa_pliku | select -last 2.

Jak widać osoby które lubią konsole wcale nie mogą narzekać na brak poleceń i możliwości jej wykorzystania. Owszem bazowy asortyment poleceń nie jest duży jednak można go rozszerzyć za pomocą dodatkowych paczek, powłok i programików z rożnych stron.

Kilka dni temu skusiłem się na zakup uaktualnienia VMware workstation z 6.5 do 7. Na stronie vmware jest opis nowych dodatków, które zostały zaimplementowane w Workstation 7. Mnie najbardziej interesowało wsparcie dla Windows 7 jako systemu hosta i gościa.

Sama aktualizacja przeszła dość szybko. Niestety co pewien czas przytrafiały mi się różne problemy z siecią, które często ignorowałem. Pewnego dnia okazało się, że połączenie się do nowej sieci czy zestawienie VPN na systemie hosta potrafiło całkowicie zawiesić system.  Po kilku godzinach wpadłem na pomysł by powyłączać mechanizmy mostka, które dorzuca VMware do połączeń sieciowych. Jak się okazało wyłączenie tej funkcji spowodowało usunięcie problemu z zawieszającym sie systemem jednak uniemożliwiło wykorzystanie mostkowanego połączenia w maszynach wirtualnych.  Niestety mam kilka maszyn, które po prostu muszą być podpięte bezpośrednio do tej samej siec co host.

W niedzielny wieczór (hmm w sumie to już była 4 nad ranem) okazało się, że po instalacji VMware i restarcie systemu należy się zalogować na konto administratora i poczekać, aż workstation7 doinstaluje niezbędne komponenty.  Jeśli pominiemy ten krok to może się okazać, że co pewien czas mogą się pojawiać dziwne problemy z maszynami wirtualnymi.

PS

Aktualnie przymieszam się napisać coś więcej o tym problemie na community VMware by utwierdzić się w przekonaniu, że faktycznie problem wygenerowałem sobie sam wykorzystując do instalacji zwykłe konto i UAC:(

Co pewien czas zdarza mi się przespać więcej niż 3-4h. Ba nawet udaje mi się położyć przed dwunastą i obudzić przed budzikiem. Wszystko to dzieję się tylko wtedy gdy śpię równe 6h i sprawcą tego nie jest mój biologiczny zegar a Windows 7 i jego zbalansowany plan zasilania:) Tak, tak domyślnie zbalansowany plan zasilania ma za zadanie przejść z trybu wstrzymania w tryb hibernacji po 6 godzinach:)

Tak więc co pewien czas mój notebook uruchamiał się po 6h wstrzymania i nagle przechodził w stan hibernacji. Przyznam się, że takie zachowanie było bardzo denerwujące jeśli dzień wcześniej mój uptime sięgał 48h i chciałem pospać trochę dłużej.

PS.

Zdarzenie przejścia z jednego stanu w drugi jest sygnalizowane w logach za pomocą komunikatu o numerze 1 od Power-Troubleshooter o treści:” … Wake Source: S4 Doze to Hibernate”

Wstyd się przyznać ale dopiero po pół roku użytkowania W7 znalazłem jak wyświetlić klasyczny panel sterowania (spis wszystkich ikon).

Czasem zdarza się, że podczas próby usunięcia lub skopiowania pliku, katalogu  pojawia się komunikat:

 

W Internecie jest dostępna masa programów, które potrafią usunąć taki problem w przeciągu kilku minut. Niestety większość z nich musi zostać zainstalowana na naszym komputerze i czasem wymaga restartu systemu:( Tymczasem z strony Sysinterlnals możemy pobrać sobie darmowe narzędzie Process Explorer, które ma masę ciekawych funkcji (taki zaawansowany menadżer zadań).  Jedną z ciekawszych funkcji jest wyszukiwanie procesów, które wykorzystują nasz plik lub katalog:) Pod spodem prosty sposób odblokowania pliku, który jest aktualnie zablokowany przed usunięciem lub kopiowaniem.

Małe HowTo:

1. Z komunikatu, który został pokazany wyżej zapisujemy sobie nazwę pliku lub katalogu, którego nie możemy zmienić. W naszym przypadku jest to folder Plik.
2. Uruchamiamy Process Explorer.
3. Przed rozpoczęciem pracy warto sobie włączyć dolny panel (Ctrl+L lub View->Show Lower Panel).
4. Z górnego menu wybieramy Find –> Find Handle or DLL… (lub szybciej Ctrl+F).

   
    

5. W nowo otwartym oknie wpisujemy nazwę szukanego pliku (1) lub katalogu, klikamy Search (2) i w liście wyszukujemy proces, który wykorzystuje nasz plik lub jeden z plików w naszym folderze (3).

   

6. Następnie klikamy dwukrotnie na dany proces i wracamy do okna Process Explorera. W tym momencie możemy albo zamknąć nasz wskaźnik do katalogu czy pliku (1) albo po prostu zamknąć odpowiedni program ( w naszym przypadku notepad).

   

7. Po odblokowaniu naszego pliku lub folderu możemy go spokojnie usunąć.

Po instalacji nowego VMware na win7 mogą wystąpić problemy łączności maszyn wirtualnych z światem za pośrednictwem połączenia mostkowanego z automatycznym wykrywaniem odpowiedniego interfejsu. Aby rozwiązać ten problem wystarczy wejść na hoście w Network and Sharing Center –> Change adapter settings i w właściwościach wykorzystanego połączenia odznaczyć i zaznaczyć  VMware Bridge Protocol (1).

Tak przy okazji nie wiem czy ktoś zauważył ale zapewnienie maszyną wirtualnym wyjścia na świat sprawia chyba najwięcej problemów niezależnie od wirtualizatora. Jeszcze pół biedy jak próbujemy wyjść z tej samej rodziny systemów. Jednak jak  się komuś zamarzy Linux na Windows lub odwrotnie to zawsze występują mniejsze lub większe problemy z połączeniem sieciowym.