O domenie Windows (AD), usługach DNS i DHCP, oraz konfiguracji sieci wirtualnych

Wstęp

Jako że przykład będzie przedstawiony w środowisku Windows, należy poruszyć w osobnym wpisie kwestię kontrolera domeny , który jest niezbędny w większości takich środowisk (szczególnie w popularnych hypervisorach jak Hyper-V, czy VMware ESX).

Po przejściu przez ten tekst powinieneś: [item]potrafić zainstalować podstawowy kontroler domeny w środowisku Windows Server 2012 R2, [/item][item]zainstalować i skonfigurować usługi DNS i DHCP, [/item][item]dołączyć testową stację roboczą do domeny,[/item][item]rozumieć podstawową konfigurację sieci wirtualnych w VMware Worksation. [/item]Tutaj mała uwaga: wpis przeznaczony jest dla osób zaawansowanych (lub pretendujących), chcących sprawnie poruszać się w środowisku Windowsowym. Osatnio zarzucono mi zbyt techniczne podejście - tym razem postanowiłem ponownie linkować do Wikipedii i tam należy doczytać. Jeżeli znasz powyższe zagadnienia, lub nie chcesz ich znać, albo wpis jest zbyt trudny - wpis nie jest po prostu dla Ciebie, nic na to nie poradzę.

Active Directory

Nie chciałem kopiować/tłumaczyć jednego z dziesiątek tysięcy wpisów w internecie i tłumaczyć co to jest Active Directory, jednak trzeba o tym wspomnieć. AD to potężne narzędzie, które pomino pewnych wad udało się firmie Microsoft. Zacytuję może Dominika Modliszewskiego z WSS.pl:

Korzyści z wprowadzenia Active Directory można podsumować w następujący sposób:

[item]scentralizowanie zarządzania infrastrukturą informatyczną,[/item][item]automatyczna instalacja i aktualizacja oprogramowania w firmie,[/item][item]jednokrotne uwierzytelnianie, czyli pracownik podczas logowania wprowadzając tylko raz swoją nazwę użytkownika oraz hasło otrzymuje dostęp do wszystkich danych (do których ma uprawnienia) bez konieczności podawania za każdym razem poświadczeń, dzięki czemu możliwe jest zwiększenie produktywności pracowników,[/item][item]redukcja kosztów zarządzania kontami,[/item][item]ograniczenie liczby zgłoszeń o awarii / problemach.[/item]Zanim przejdziesz dalej, przeczytaj proszę ten oto wpis Dominika.

Sieci wirtualne w VMware Workstation

Jak już ostatnio kilka razy pisałem, używam VMware Worksation i korzystam z kilku szablonów ("template"). Zanim przystąpię do omówienia zagadnienia podstawowej konfiguracji Active Directory / domeny Windows kilka słów o środowisku w którym będzie to zrobione.

Warto na tym etapie zdecydować w jakiej podsieci będziemy uruchamiać nasz LAB. W większości sytuacji lepszym rozwiązaniem jest nowa podsieć - dodatkowa domena rozgłoszeniowa, dająca możliwość uruchomienia osobnego serwera DHCP, który nie "walczy" z tym uruchomionym na domowym routerze. Po instalacji VMWare i podobnych hypervisorów może zdziwić, że pojawiają się dodatkowe interfejsy sieciowe:

Zaglądając w ustawienia sieciowe, mają one nadane IP:

Ustawienia interfejsów wirtualnych znajdują się w zakładce "Edit -> Virtual Network Editor..."

W celu dokonywania zmian i zobaczenia dodatkowej sieci (VMnet0) należy nacisnąć "Change Settings":

Pierwsza sieć wirtualna (domyślnie instalowana przez VMware Worksation) to VMnet0. Jest ona bezpośrednio "zmostowana" z główną siecią na domyślnym interfejsie - w mojej sieci domowej to 192.168.10.0 /24. Każda maszyna wirtualna podpięta pod VMNet0 będzie widziana w otoczeniu sieciowym domowych komputerów jak pełnoprawny komputer - uzyska adres IP z domyślnego serwera DHCP (w większości sytuacji uruchomionego pewnie na routerze na IP 192.168.0.1, lub podobnym), będzie widzoczna w tablicy ARP itd. Tutaj bardzo ważna uwaga - często na forach (w tym na Dobre Programy) pojawia się błędne założenie, że

Wyjątkowo mylne podejście - ustawienia sieci wirtualnej w trybie "bridge" działają w pierwszej (fizycznej) i drugiej (łącza danych) warstwie modelu OSI. Firewall natomiast zaczyna się w warstwie 3 (adresy IP), potem już porty (warstwa 4) aż do głębokiej inspekcji pakietów (warstwa 7).

Ja na "na wypadek" zawsze ręcznie ustawiam na odpowiednią kartę sieciową - czasem mam dodatkowe intefejsy bezprzewodowe, karty sieciowe, czy inne wirtualne sieci, VPNy (w tym Hamachi ) i przy domyślnych ustawieniach zdarzyły mi się problemy, gdzie VMWare próbował "bindować" do nich:

Drugi typ sieci to "Host-only" - maszyny wirtualne przypisane do tego vNET mogą komunikować się tylko między sobą, nie będą np. mogły skomunikować się np. z internetem. Opcja wygodna, gdy robimy testy aplikacji typu wirusy, lub innych, które powinny być izolowane od wyjścia na zewnątrz. W VMware Workstation 10‑12 sieci typu "host-only" z tego co pamiętam można mieć 17, ale nie dam sobie ręki uciąć i jestem za leniwy, żeby grzebać teraz po dokumentacji w celu sprawdzenia szczegółów...

Dochodzimy do ostatniej sieci, czyli typu "NAT".

Sieć taką możemy mieć jedną z prostego względu - VMware robi za "natownicę ". Maszyny w tej sieci mogą więc kierując się na odpowiedni adres bramy wydostać się do internetu. Mogą też komunikować się z siecią hosta, ponieważ VMware zapewnia routing. Plus rozwiązania jest taki, że nie wychodzą poza tą sieć np. zapytania DHCP (najprościej mówiąc: system operacyjny maszyny wirtualnej nie uzyska adresu IP z serwera DHCP uruchomionego np. na domowym routerze). Jedna z wad to więcej zabawy w przypadku serwera wirtualnego, który chcemy "wystawić" na zewnątrz (np. usługa WWW) - trzeba wykonać podwójne przekierowanie portów (najpierw na głównym routerze w sieci do komputera hosta, potem na wirtualnym routerze VMware przerutowanie do vLAN).

Przejdźmy na chwilę do ustawień ("NAT Settings"): w powyższym przykładzie sieć to: [item]192.168.228.0 /24 (192.168.228.1 - 192.168.224),[/item][item] maska sieci: 255.255.255.0,[/item][item]Gateway (brama domyślna): 192.168.228.2.[/item]Warto przyjrzeć się zakładce "DHCP Settings" - DHCP oferuje adresy IP z zakresu: 192.168.228.128 - 192.168.228.254

Ja zawsze wyłączam serwer DHCP oferowany przez VMware - głównie przez to, że w większości sytuacji uruchamiam wewnątrz takiej sieci swój DHCP zachowujący się według moich ustawień, głównie chodzi o DNS (o tym za chwilę).

Trzeba więc jedynie pamiętać zakres sieci i adres bramy domyślnej (192.168.228.2).

Active Directory w praktyce

Rozpisałem się za dużo o VMware - ale chciałem, żeby chociaż trochę coś skorzystały osoby mniej zaawansowane w sieciach. Wracamy do naszego serwera domenowego. Osatnim razem opisałem jak korzystać z szablonów ("template") i "linked clone". Zakładam, że potrafisz zainstalować wirtualną maszynę z Windows 2012 Server R2, Windows 7, lub Windows 10. Przykład domeny pokażę na wyżej wspomnianym Windows 2012 R2. Nie różni się to bardzo od 2008/2008R2 (może poza tym, że na 2008 czasem z "palca" trzeba promować domenę). Doskonale rozumiem, że Windows Server 2008/2008R2 jest nadal bardzo popularnym system produkcyjnym, jednak jak ktoś zaczyna swoją przygodę z AD - Windows 2012 R2 jest dobrym wyborem (na horyzoncie widać już 2016, nie ma co się ładować w starsze wersje serwerowe). Maszynę wirtualną pod kontroler domeny należy skonfigurować z podstawowymi parametrami opisywanymi w poprzednim wpiście. Na czas instalacji ustawiam jednak trochę więcej RAM - w przypadku deficytu pamięci w komputerze-hoście spokojnie można później w środowisku testowym zmniejszyć na 1‑1.5GB (kontroler domeny nie ma aż tak dużo zadań i to mu wystarczy). WMware radzi też sobie całkiem sprawnie z dynamicznym alokowaniem zasobów, jedynie należy pamiętać o instalacji VMware Tools.

Tutaj też należy wskazać karcie sieciowej z której sieci (vLAN) ma korzystać - VMnet8, czyli "NATowana" podsieć. Po pierwszym uruchomieniu serwera należy ustawić statyczny adres IP:

DNS wskazujemy na localhost (127.0.0.1) - usługa za chwilę zostanie zainstalowana. Ustawienia można sprawdzić za pomocą polecenia ping:

Poprawna odpowiedź z 192.168.228.2 oznacza, że mamy dostęp do bramy udostępnianej przez wirtualny router VMware, natomiast odpowiedź z 8.8.8.8, że mamy "wyjście" (routing) do internetu. Pierwszą usługą jaką powinniśmy zainstalować to lokalny serwer DNS. Większość problemów w środowisku AD (brak możliwości dołączenia do kontrolera, albo np. kilkuminutowe logowanie stacji roboczych) wynika właśnie ze złych ustawień DNS. Na tym etapie można zmienić nazwę serwera. Z racji tego, że czasem łączę 'laby', ustalam powiązania między serwerami itd. warto ustawić nazwę zależną od danego środowiska testowego: np. LAB10_DC. Nic jednak nie stoi na przeskodzie, aby serwer nazywał się "DC", "SERVER", albo "TADEUSZ".

Możemy przystąpić do instalacji serwera DNS i serwera DHCP - z przystawki "Server Manager" wybieramy opcję "Add roles and features" (Next->Next-Next), zaznaczany "DHCP server" i "DNS server" :

Cztery razy "Next" i na końcu "Install". Instalacja potrwa bardzo krótko, serwera nie trzeba restartować. W "Dashboard" powinny pojawić się dwie zakładki (DNS i DHCP), które ułatwiają dostęp do przystawek zarządzania usługami:

DNS nie potrzebuje zbyt wielu zabiegów, skonfigurujmy jednak dodatkowe "forwardery" - żeby serwer Windows wiedział gdzie szukać zapytań do hostów w internecie, np. do strony http://dobreprogramy.pl - jak nie znajdzie ich na lokalnym serwerze DNS (192.168.228.2), niech sprawdzi na serwerze DNS Google.

W przystawce DNS należy prawym klawiszem kliknąć na nazwie serwera, następnie na ustawienia ("Properties"):

W zakładce "Forwarders" klikając na "Edit" należy dopisać dowolny zewnętrzny serwer DNS: może to być np. 8.8.8.8

Wynik konfiguracji powinien być następujący:

Teraz czas na DHCP. Sam "Dashboard" podpowiada, że potrzebna jest jest konfiguracja i zalecane jest uruchomienie "czarodzeja" ("Wizard"):

Po wykonaniu tego, należy uruchomić przystawkę DHCP. Tam dla IPv4 tworzymy nowy zakres DHCP ("New Scope..."). W pierwszej kolejności kreator zapyta nas o nazwę (można podać dowolną, np. LAB10).

W kolejnym oknie ustalamy zares DHCP.

Nie jest dobrą praktyką ustalanie wszystkich możliwych adresów IP jako dostępne z adresu DHCP. Dobra praktyka mówi o zostawieniu kikunastu adresów poza tym zakresem - unika się wtedy dodatkowych rezerwacji, wykluczeń itd. W średniej wielkości sieci takich adresów poza DHCP powinno być chociaż 10‑20 dla celów innych serwerów, urządzeń sieciowych, drukarek, NASów (dysków sieciowych), AP (urządzeń dostępu bezprzewodowego).

W przypadku, gdy chcemy, aby pierwszy adres uzyskiwany z serwera DHCP był 192.168.228.50 a ostatni 192.168.228.99, konfiguracja jest następująca:

Kolejne okno konfiguracji pozwala skonfigurować "wykluczenia" - jeżeli wiemy, że np. adres 192.168.228.65 jest już używany przez drukarkę sieciową można dopisać ją właśnie tutaj - serwer DHCP powinie ten adres przy nadawaniu urządzeniom proszącym o IP:

"Lease Duration" oznacza jak długo serwer DHCP będzie pamiętać IP i przypisywać je do tego samego komputera - komputer (lub inne urządzenie) nawet po wyłączeniu z sieci, jeżeli w ciągu przykładowo 8 dni pojawi się w sieci, dostanie dokładnie ten sam adres IP (sprawdzane jest to na podstawie fizycznego adresu karty sieciowej ):

Router (Default Gateway): wpisujemy adres IP bramy domyślnej (192.168.228.2).

Należy pamiętać o naciśnięciu "Add" (ja o tym zawsze zapominam...):

Na koniec pozostaje aktywować nowy zakres DHCP:

Jeżeli wszystko zostało wykonane poprawnie, pojawił się nowy zakres ("Scope"). Wszystkie opcje, przez które przeprowadził nas "wizard" można przekonfigurować bardzo prosto w poszczególnych opcjach. Ja zawsze sprawdzam "Scope Options": zawsze zapominam dodać "003 Router". Nas najbardziej właśnie interesuje to, oraz co najważniejsze serwer DNS kierujący na kontroler domeny:

Konfiguracja serwera DHCP nie jest niezbędna, ale ułatwi nam późniejszą pracę i nie będzie trzeba "ręcznie" ustawiać adresów IP dla poszczególnych komputerów klienckich.

Promocja serwera do roli kontrolera domeny

Możemy przystąpić do dodania usługi Active Directory (ADDS). Podobnie, jak instalowany był serwer DNS i DHCP, należy zaznaczyć usługę AD:

Po instalacji usługi należy ją skonfigurować - czyli wypromować kontroler domeny:

W pierwszej kolejności należy ustalić rolę serwera domenowego, oraz nazwę domeny:

Z racji tego, że jest to nowe środowisko, wybieramy opcję trzecią (nowy "las"), oraz nazwę domeny Windows. Tu zaczynają się często schody... "Domena Windows" i "domena internetowa" (np. wykupiona u jakiegoś popularnego dostawcy) to dwie zupełnie inne sprawy - często brak zrozumienia tej kwesti budzi później wiele problemów. Kilka zasad:

[item]nazwy nie można zmienić,[/item][item]nie należy tworzyć zbyt długiej nazwy domeny (im krócej, tym łatwiej potem np. dołączać komputery do domeny, przelogowywać się między kontami domenowymi itd.),[/item][item]musi być "coś po kropce" - najczęściej można się spotkać z .local (LAB10.local).[/item] Dobre praktyki Microsoftu podpowiadają, że powinna być to nazwa domenowa np. strony internetowej firmy (np. dobreprogramy.pl). Jak jednak do końca nie rozumiesz działania DNS i tworzenia dodatkowych wpisów w lokalnym serwerze DNS (np. CNAME autodiscover dla Outlooka, czy www dla strony internetowej), to jednak polecam wpisać .local

W kolejnym oknie ustala się poziom funkcjonalny lasu i domeny - w naszym przypadku zostawiany domyślny (Windows Server 2012 R2).

Ustalamy też hasło dostępu do trybu awaryjnego AD (odzyskiwania/naprawy) DSRM - obyś nie musiał nigdy z niego korzystać... W tej chwili nie musimy się skupiać na ostrzeżeniu o braku możliwości utworzenia delegacji DNS:

Więcej o tym komunikacie i promowaniu kontrolera można doczytać na Technecie. W kolejnym oknie konfigurator powinien sam zaproponować "The NetBIOS domain name" jako LAB10. Katalogi "Database folder", "Log files folder" i "SYSVOL folder" należy pozostawić wg. ustawień domyślnych.

Ostatnie okno to podsumowanie konfiguracji - można przeglądnąć jeszcze raz ustalone parametry. Zachęcam do kliknięcia "View Script" aby przekonać się, że GUI nowszych wersji serwera Windows to nakładka na Power Shell. Skrypt taki warto sobie skopiować i przy budowaniu nowego labu zaoszczędzi to kilku minut kilkania:

[code=] # # Windows PowerShell script for AD DS Deployment # Import-Module ADDSDeployment Install-ADDSForest ` -CreateDnsDelegation:$false ` -DatabasePath "C:\Windows\NTDS" ` -DomainMode "Win2012R2" ` -DomainName "LAB10.local" ` -DomainNetbiosName "LAB10" ` -ForestMode "Win2012R2" ` -InstallDns:$true ` -LogPath "C:\Windows\NTDS" ` -NoRebootOnCompletion:$false ` -SysvolPath "C:\Windows\SYSVOL" ` -Force:$true [/code]

Po naciśnięciu "Install" serwer zostanie wypromowany i zrestartowany. Przy pierwszym logowaniu należy zwrócić uwagę, że nie logujemy już się na konto lokalnego administratora serwera (LAB10_DC\administrator), ale na konto domenowe (LAB10\administrator):

Serwer więc ma według nomenklatury Microsoft pełną jednoznaczą nazwę domenową (FQDN): LAB10_DC.LAB10.local

[img=41_AD2] .

Klient

Pora przystąpić do podłączenia testowej maszyny klienckiej - będzie to Windows 7 Professional Przypominam tylko, że nie da się podłączyć (w pełnym wymiarze) do domeny stacji roboczej z zainstalowanym Windows Home, lub innym "Starterem" - musi być to edycja Professional, lub wyższa. Przy konfiguracji maszyny wirtualnej ponownie przypominam o przypisaniu wirtualnego interfejsu do odpowiedniej wirtualnej sieci:

Komputer wirtualny należy w miarę "przyjaźnie" nazwać, np. "PC1" - nazwę też można później bez problemu zmienić. Tutaj zapomniałem o jednej rzeczy... Po uruchomieniu klienta (PC1) nadal nie będzie mieć poprawnych ustawień sieciowych:

Po przejściu do ustawień serwera DHCP (na maszynie Windows 2012) ustalony zakres ma prawdopodobnie status "czerwony" - nie jest aktywny. Po wypromowaniu serwera do poziomu kontrolera domeny należy zakres ponownie autoryzować - prawy klawisz myszy na serwerze i "Authorize".

Po chwili można odświeżyć widok (klawisz "F5"), status zmieni się na zielono. Wracamy do komputera klienckiego - uzyskanie adresu z serwera DHCP najprościej wymusić za pomocną polecenia:

[code=]ipconfig /renew[/code]

Dla pewności można wykonać szybką diagnostykę ustawień za pomocą trzech różnych "pingów":

[item]na adres IP serwera (kontrolera domeny),[/item][item]na nazwę serwera (test serwera DNS),[/item][item]na zewnętrzny adres IP (potwierdzenie routingu do internetu):[/item][img=57_PC6_testustawien]

Teraz możemy podpiąć komputer kliencki do domeny:

Jako nazwę domeny należy wpisać "LAB10.local" - w większości sytuacji wystarczy wpisać samo "LAB10", jednak dla pewności polecam podawać pełną nazwę. W przypadku, gdy poprawnie został skonfigurowany serwer DNS i ustawienia komputera klienckiego, pojawi się zapytanie o login i hasło administratora:

Stacja robocza została dołączona do domeny i można go zrestartować:

Teraz na komputerze klienckim możemy zalogować się jako administrator domeny. Tutaj też często pojawiają się problemy - Windows działa w ten sposób, że przy wpisywaniu loginu na komputerze dołączonym do domeny po 6‑tym znaku będzie chciał logować jako lokalny użytkownik (np. PC1\administrator):

W celu poprawnego zalogowania jako login należy podać LAB10\administrator:

W przypadku udanego logowania oznacza to, że poprawnie dołączyliśmy stację roboczą do domeny.

Podsumowanie

Wyszedł trochę przydługi ten tekst ze względu na "liźnięcie" kilku tematów. Zrozumienie jednak podstaw działania serwera Windows i Active Directory jest niezbędne do ruszenia dalej w "uniwersum" Microsoftu. W następnym wpiscie będzie już więcej konkretów dla prawdziwych hardkorów.

źródła: ---‑--- Fragment opisujący czym jest domena Windows jest żywcem skopiowany z  z wpisu blogowego Dominika Modliszewskiego, zamieszczonego w portalu wss.geekclub.pl