Zarządzanie serwerem DNS – cz. 3

Witajcie

W dzisiejszym odcinku pora na kilka słów o ciekawych opcjach strefy i serwera DNS. Poniżej pokażemy krótko kilka opcji, o których nie było mowy w poprzednich dwóch odcinkach. Funkcje, które przedstawię dziś pozwalają na precyzyjne “dostrojenie” funkcjonowania serwera i stref do potrzeb wdrożonej w naszej organizacji infrastruktury IT. Pierwszą zakładką do jakiej uzyskujemy dostęp po wybraniu z menu kontekstowego właściwości strefy jest zakładka “ogólne” (rys. 1). Z jej poziomu możliwe jest wstrzymanie funkcjonowania danej strefy, zmiana typu strefy pomiędzy główną, wtórną i skrótową oraz zablokowanie lub włączenie dynamicznych aktualizacji rekordów zasobów.

Rys. 1. Ogólne właściwości strefy DNS. 

Z poziomu tej zakładki możemy również uzyskać dostęp do opcji popularnie zwanych “aging” i “scavenging” (rys. 2). Ich odpowiednie zdefiniowanie umożliwia określenie interwałów czasu w jakich rekordy zasobów będą odświeżane (“aging”), a stare rekordy zasobów (np. takie dla których usunięty został rekord typu A) usuwane (“scavenging”).

 Rys. 2. Definiowanie interwałów czasu odświeżania i usuwania rekordów zasobów. 

Kolejnym istotnym zestawem parametrów, są właściwości rekordu SOA (rys. 3). Wśród nich możliwe jest zdefiniowanie takich zmiennych jak czas “życia” rekordu (TTL), interwał czasu odświeżania, ważności rekordu, a także wskazanie głównego serwera DNS. Jako że pozostałe właściwości strefy DNS były już omawiane w poprzednich odcinkach czas przejść do właściwości serwera, o których jak dotąd nie było mowy.

  Rys. 3. Właściwości rekordu SOA. 

Jedną z najważniejszych opcji serwera jest możliwość wyboru na jakich interfejsach będzie dostępna usługa rozwiązywania nazw (rys. 4). Lista interfejsów obejmuje w tym wypadku wszystkie interfejsy logiczne tak więc wszystkie adresy IP przypisane do pojedynczego fizycznego portu traktowane są niezależnie. 

   Rys. 4. Wybór interfejsów, na których dostępna będzie usługa DNS. 

Kolejną niesłychanie istotną opcją jest zdefiniowanie serwerów DNS, do których nasz serwer będzie przekazywał zapytania w przypadku niemożności rozwiązania nazwy (rys. 5). Praktyka definiowania dodatkowych serwerów DNS jest powszechnie przyjęta w procesie wdrażania usługi Active Directory. Dodatkowy serwer do którego przekazujemy zapytania jest wtedy umieszczany w strefie DMZ w celu uniknięcia widoczności kontrolerów domen naszej organizacji z sieci zewnętrznej.

   Rys. 5. Definicja serwerów DNS, do których będą przekazywane zapytania DNS. 

Kolejnym zestawem właściwości możliwych do zdefiniowania są właściwości ukryte w zakładce zaawansowane (rys. 6). Zakładka ta umożliwi użytkownikowi włączenie automatycznego oczyszczania nieaktualnych rekordów zasobów, wybór trybu ładowania strefy podczas uruchamia serwera i sposób sprawdzania nazw. Wśród pozostałych właściwości dostępne są opcje wyłączenia przesyłania zapytań rekursywnych (czego skutkiem będzie możliwość rozwiązywania nazw tylko ze stref przechowywanych na danym serwerze), wyłączenia przyspieszonego transferu stref w celu zapewnienia kompatybilności z serwerami DNS opartymi o alternatywne systemy operacyjne oraz opcje bezpieczeństwa i równoważenia obciążenia sieciowego szerzej opisane w bibliotece Technet.

    Rys. 6. Zaawansowane właściwości serwera DNS. 

Fundamentalną dla poprawnego działania zakładką jest zakładka “Root Hints” (rys. 7). Za jej pomocą edytować możemy dane 13 głównych autorytatywnych serwerów DNS. Jak można się w tym przypadku domyślić usunięcie danych wszystkich serwerów głównych mogłoby spowodować niemożność rozwiązywania nazw DNS spoza naszej organizacji.

     Rys. 7. Zaawansowane właściwości serwera DNS. 

Ciekawymi opcjami są również możliwości rejestrowania pakietów w celu ich późniejszej analizy (rys. 8) i zdefiniowanie jakiego typu zdarzenia mają być zapisywane w rejestrze zdarzeń (rys. 9). Wymagać można zapisu wszystkich zdarzeń, błędów, lub błędów i ostrzeżeń. Dostępna jest także opcja wyłączenia rejestrowania zdarzeń.

      Rys. 8. Opcje rejestrowania pakietów przesyłanych przez serwer DNS. 

       Rys. 9. Opcje rejestrowania zdarzeń generowanych przez serwer DNS. 

Ważną opcją jest możliwość generowania prostych i rekursywnych zapytań testowych, a także możliwość powtarzania procedury testowej co zadany okres czasu (rys. 10).

       Rys. 10. Procedury autotestowania serwera DNS.

Oczywiście dociekliwym czytelnikom polecam dalszą lekturę, dzięki której będą mogli zgłębić szczegółowo wszystkie dostępne opcje serwerów i stref DNS. W naszym mini cyklu obejmującym zagadnienia związane z serwerem DNS docieramy powoli do odcinka czwartego, w którym opowiem o zaletach integracji usługi DNS z usługą katalogową Active Directory oraz zmianach w sposobie administracji serwerem jakie taka integracja powoduje.

Bartosz Pawłowicz

Zarządzanie serwerem DNS – cz. 2

Witajcie

Po dłuższej przerwie w pisaniu spowodowanej wieloma perypetiami powracamy do naszego mini cyklu o podstawach zarządzania serwerem DNS. Już na wstępie zaznaczę, że gdy sam przyjrzałem się jeszcze raz pierwszemu odcinkowi zamieszczonemu na tym blogu uznałem, że tematyka poświecona konfiguracji serwera DNS pracującego w oparciu o system Windows Server musi być nieco poszerzona. Choć pierwotnie zakładałem, że tematyka DNS zmieści się w 2 odcinkach to jednak dziś po przyjrzeniu się całości stwierdzam, że będzie jeszcze jeden lub dwa dodatkowe odcinki. Dziś przybliżę wszystkim czytelnikom proces tworzenia strefy wtórnej (secondary zone), co umożliwi przede wszystkim zabezpieczenie serwera DNS pracującego w naszej sieci oraz utworzenie dodatkowego węzła, do którego będą kierowane zapytania DNS w razie gdybyśmy wymagali tej funkcjonalności ze względu na duże obciążenie sieci. W tym momencie zakładam, że wszyscy czytelnicy zapoznali się już z treścią wszystkich moich poprzednich wpisów na blogu i wystarczającym będzie jeśli powiem, że dysponujemy już dwoma serwerami (o nazwach DNS1 i DNS2), które mają w pełni skonfigurowaną łączność sieciową i zainstalowane role serwera DNS. Na serwerze DNS1 została dodatkowo utworzona i skonfigurowana strefa główna (primary zone) ita.local. W strefie zdefiniowano rekordy typu A dla obu serwerów DNS i dla dwóch komputerów klienckich (rys.1).

Rys. 1. Strefa DNS utworzona na serwerze głównym.

Aby utworzyć strefę wtórną uruchamiamy na serwerze DNS2 kreatora konfiguracji strefy i w oknie wyboru typu strefy wybieramy opcję “secondary zone” (rys. 2). Należy w tym miejscu zaznaczyć, że mechanizm tworzenia strefy skrótowej (stub zone) jest identyczny jak tworzenia strefy wtórnej. Jedyną różnicą z punku widzenia użytkownika jest konieczność wyboru tej opcji w kreatorze strefy. Warto jednak pamiętać, że po utworzeniu strefy skrótowej nie mamy do czynienia z kopią całej strefy lecz tylko wybranych rekordów.

Rys. 2. Okno wyboru typu strefy.

W kolejnym kroku zdefiniować musimy nazwę strefy. Ponieważ tworzymy kopię strefy głównej przechowywanej na innym serwerze to nazwa tworzonej strefy będzie taka sama jak nazwa zdefiniowanej wcześniej strefy głównej (rys. 3).

Rys. 3. Definicja nazwy strefy.

Konieczne jest też wybranie nadrzędnego serwera DNS przechowującego strefę którą będziemy kopiować (rys. 4). Może to być, ale nie musi serwer przechowujący strefę główną. Jako serwer nadrzędny możemy wskazać serwer, przechowujący tylko strefę wtórną. W takim przypadku tworzona przez nas strefa będzie kopią kopii strefy głównej. Zaznaczyć należy, że wskazać możemy kilka serwerów, które będą serwerami nadrzędnymi będącymi źródłem danych dla konfigurowanego przez nas serwera. Serwery te mogą być serwerami przechowującymi tylko strefy wtórne. Jak można również zauważyć możemy wybrać wersję protokołu IP jaką posłużymy się podczas komunikacji między serwerami DNS. Domyślnie test poprawnego rozwiązania nazwy serwera nadrzędnego wykonywany jest dla protokołu w wersji 4 i w wersji 6.

Rys. 4. Wybór serwera nadrzędnego.

Jeśli wszystkie powyższe kroki wykonaliśmy poprawnie to teoretycznie powinniśmy być w stanie dokonać transferu strefy. Niestety bezpośrednio po zakończeniu powyższych czynności zazwyczaj pojawi się komunikat o odmowie dostępu i niemożności załadowania strefy (rys. 5). Aby umożliwić poprawną replikację strefy DNS należy zezwolić na transfer stref przez nadrzędny serwer DNS.

Rys. 5. Błąd transferu strefy.

Aby tego dokonać należy we właściwościach strefy w zakładce transfery stref (zone transfers) zezwolić na transfery i wybrać jedną z trzech dostępnych opcji. Jeśli strefa wtórna, którą skonfigurowaliśmy jest pierwszą strefą na serwerze DNS wtedy najwygodniej jest wybrać opcję zezwolenia na transfer stref do każdego serwera DNS. Mamy oczywiście również możliwość zezwolenia na transfer tylko do wskazanych serwerów DNS, ale jest to możliwe jeśli serwer, do którego ma zostać skopiowana strefa jest już pełnoprawnym serwerem DNS co oznacza, że jakaś strefa musi być już na nim zdefiniowana. W innym przypadku otrzymamy komunikat (rys. 6) o tym, że serwer nie jest serwerem autorytatywnym dla danej strefy i replikacja stref do danego serwera nie będzie możliwa. Możemy również użyć listy serwerów autorytatywnych zdefiniowanych w zakładce serwery nazw (name servers) ale w naszym przypadku posiadania serwera DNS, który będzie przechowywał tylko jedna strefę wtórną również obowiązuje wspomniane wcześniej ograniczenie.

Rys. 6. Wybór serwerów uprawnionych do transferu stref.

W omawianym przypadku jedynym możliwym wyborem jest wiec zezwolenie na transfer strefy do wszystkich serwerów (rys. 7). Należy tu jednak zaznaczyć, że po wykonaniu pierwszego transferu strefy możliwa i konieczna jest zmiana tego ustawienia bowiem serwer, do którego dokonujemy transferu staje się pełnoprawnym serwerem DNS i możliwe jest wskazanie go jako autorytatywnego serwera DNS dla danej strefy. 

Rys. 7. Zezwolenie na transfer stref do wszystkich serwerów DNS

W kolejnym kroku możliwe jest wykonanie transferu strefy. Dokonujemy tego poprzez wskazanie odpowiedniej opcji w menu kontekstowym utworzonej strefy wtórnej (rys. 8). Po zakończeniu tego procesu konieczne może być odświeżenie zawartości konsoli zarządzania serwerem DNS.

Rys. 8. Transfer strefy z serwera nadrzędnego.

Po pomyślnym wykonaniu transferu możliwe jest “podejrzenie” właściwości zdefiniowanej strefy wtórnej. Jak można się przekonać (rys. 9) większość opcji i właściwości strefy będzie niedostępna co oznacza, że mamy do czynienia ze strefą wtórną i chcąc ją zmodyfikować konieczna jest zmiana ustawień na serwerze przechowującym strefę główną.

Rys. 9. Ograniczenia edycji właściwości strefy wtórnej.

Możliwe jest jednak dokonanie konwersji strefy (rys. 10). Oznacza to, że w razie konieczności możliwe jest przekształcenie strefy wtórnej w strefę główną lub w strefę skrótową.

Rys. 10. Zmiana typu strefy.

Po wykonaniu wcześniejszych kroków możliwe jest wprowadzenie serwera przechowującego strefę wtórną na listę serwerów autorytatywnych dla danej domeny DNS (rys. 11).

Rys. 11. Zdefiniowanie dodatkowego autorytatywnego serwera DNS.

Dzięki temu do zdefiniowanej wcześniej strefy (rys. 12) zostanie dodany rekord autorytatywnego serwera nazw wskazujący na serwer DNS2 przechowujący strefę wtórną. Dodanie tego rekordu jest informacją o tym, że w domenie istnieją dwa autorytatywne serwery i w razie braku odpowiedzi z jednego z nich drugi będzie w stanie rozwiązać każdą nazwę z danej domeny.

Rys. 12. Strefa DNS z dodatkowym rekordem NS.

Jak pamiętamy w pierwszym odcinku uruchomiliśmy serwer DNS. Obecnie wiemy już jak wdrożyć dodatkowy serwer, który zwiększy niezawodność naszej infrastruktury i odpowiednio skonfigurować strefy przechowywane na naszych serwerach. Więcej o możliwościach definiowania ustawień stref i serwerów DNS opowiem już w następnym odcinku.

Bartosz Pawłowicz

Zarządzanie serwerem DNS – cz. 1

Witajcie

Po wielu perypetiach właśnie zamieszczam tekst do rysunków z początku bieżącego miesiąca. Za opóźnienia wszystkich wiernych czytelników bardzo przepraszam. Dzisiejszy (i nie tylko) temat to podstawy zarządzania serwerem DNS. Jak wiemy usługa rozwiązywania nazw jest jedną z najważniejszych usług sieciowych. DNS jest przy tym protokołem dość dobrze opisanym tak więc po informacje szczegółowe na temat tej usługi i samego protokołu odsyłam wszystkich zainteresowanych do jego opisu na wikipedii w wersji polskiej i angielskiej. Teraz zaś do rzeczy – czyli instalacji i podstawowej konfiguracji serwera DNS w oparciu o Windows Server 2008. W celu demonstracji tego zagadnienia posłużymy się trzema maszynami. Pierwszą z nich jest sam serwer, na których zainstalujemy rolę serwera DNS. Pozostałe dwie maszyny to maszyny klienckie oparte o leciwy już (choć wystarczający do celów demonstracji rozwiązywania nazw) system Windows XP. Maszynom zostały przyporządkowane następujące numery IP:

192.168.10.1 – Windows Server 2008 / serwer DNS o nazwie DNS-SRV1

192.168.10.10 – Windows XP / Klient nr 1 o nazwie WXP-CL1

192.168.10.20 –  Windows XP / Klient nr 2 o nazwie WXP-CL2

Nie opisuję na tym etapie szczegółowo konfiguracji adresów IP bowiem proces ten powinien być czytelnikom doskonale znany z poprzednich moich tekstów. Warto natomiast wspomnieć, że wymienione nazwy nie są nazwami FQDN (Fully Qualified Domain Name) poszczególnych maszyn lecz ich nazwami NetBIOS na podstawie, których w dalszym etapie zdefiniujemy nazwy FQDN. W odpowiednim momencie wyłączymy również obsługę protokołu NetBIOS co spowoduje, że rozwiązywanie nazw oparte o ten protokół będzie niemożliwe – pozostanie tylko DNS. Aby mówić o serwerze DNS opartym o system Windows Server 2008 musimy zainstalować wspominaną wcześniej rolę (rys. 1). Warto w tym przypadku wspomnieć, że serwer DNS może tutaj działać w dwóch trybach. Pierwszy z nich, którym zajmiemy się w bieżącym i kolejnym odcinku to niezależny serwer DNS przechowujący zdefiniowane przez administratora strefy DNS. Drugim z trybów pracy serwera DNS jest integracja z usługą Active Directory. Jest to bardzo specyficzny tryb pracy bowiem podczas promocji kontrolera domeny serwer DNS instalowany jest domyślnie. Domyślnie też tworzony jest zestaw stref odpowiadający zdefiniowanej domenie AD. Szczegółowo tym trybem pracy serwera DNS zajmiemy się w kolejnych odcinkach.

 Rys. 1. Instalacja roli serwera DNS. 

Po instalacji roli serwera DNS, która wymaga od administratora jedynie potwierdzenia chęci instalacji wspomnianej roli możemy za pomocą polecenia dnsmgmt.msc wywołać konsolę zarządzania serwerem DNS (rys. 2). Jak możemy zaobserwować kontenery zawierające strefy wyszukiwania w przód i strefy wyszukiwania wstecznego są puste co oznacza ze to na administratorze spoczywa obowiązek zdefiniowania stref i ich nazewnictwa. W przypadku kiedy instalujemy serwer DNS razem z kontrolerem domeny AD odpowiednie strefy i komplet wpisów są tworzone automatycznie.

 Rys. 2. Konsola zarządzania serwerem DNS. 

Kolejnym krokiem mającym na celu zademonstrowanie działania serwera DNS jest wyłączenie rozwiązywania nazw NetBIOS. Należy jednak podkreślić, że w normalnym środowisku nie ma konieczności wyłączania obsługi tego protokołu, gdyż protokoły DNS i NetBIOS mogą ze sobą współistnieć w ramach tej samej infrastruktury sieciowej chyba, że czynimy to ze względów bezpieczeństwa. Co więcej należy podkreślić, że domeny AD również mogą posiadać nazwy NetBIOS, choć stan ten utrzymywany jest raczej z konieczności zapewnienia kompatybilności wstecznej. Wyłączenia obsługi NetBIOS dokonać można przez wywołanie zaawansowanych właściwości protokołu TCPIP we właściwościach połączenia sieciowego. Odpowiednie ustawienie znajdziemy w zakładce WINS (rys. 3).

 Rys. 3. Wyłączenie rozwiązywania nazw za pomocą protokołu NetBIOS i obsługi pliku LMHOSTS. 

Aby sprawdzić efekt naszych działań na dowolnym kliencie wywołujemy konsolę i za pomocą polecenia ping + nazwa klienta testujemy rozwiązywanie nazw NetBIOS (rys. 4). Jeśli inny komputer nie odpowiada oznacza to, że obsługa protokołu NetBIOS została wyłączona. Aby zatrzymać rozwiązywanie nazw NetBIOS w obrębie całej sieci powyższą procedurę należy powtórzyć na wszystkich podłączonych maszynach (klientach i serwerach).

 Rys. 4. Nieudana próba rozwiązania nazwy za pomocą NetBIOS.

Następnie przystąpić możemy do zdefiniowania strefy wyszukiwania w przód. Odbywa się to za pomocą kreatora strefy wywoływanego po rozwinięciu prawym przyciskiem myszy menu kontekstowego dla kontenera przechowującego strefy wyszukiwania do przodu czyli takie które służą do tłumaczenia nazwy na konkretny adres IP. Po wywołaniu kreatora mamy do dyspozycji wybór strefy (rys 5). Możemy zdefiniować strefę jako strefę główną (primary), wtórną (secondary) i skrótowej (stub). Strefa główna jest strefą przeznaczoną do zapisu i odczytu. W przypadku aktualizacji rekordów DNS to właśnie do takiej strefy zapisywane są uaktualnienia. Strefa wtórna jest kopią strefy głównej przeznaczoną do odczytu. Strefy wtórne dla danej strefy głównej mogą być przechowywane na wielu serwerach, a ich zastosowanie ma na celu zwiększenie niezawodności systemu DNS i zapewnienie równoważenia obciążenia serwerów DNS w dużych sieciach. Strefa skrótowa jest zaś specjalnym typem strefy przechowującym tylko wybrane elementy strefy głównej. Jest ona stosowania w dużych sieciach połączonych łączami WAN o niskiej przepustowości. jej zastosowanie ma na celu zmniejszenie obciążenia ruchem łączy typu WAN. Świetny opis systemu DNS po polsku można również znaleźć na technecie. Zauważyć też można, że jedno dodatkowe ustawienie jest niedostępne. Jeśli korzystamy z AD to strefy zdefiniowane na serwerach domenowych mogą być przechowywane w partycjach usługi katalogowej.

 Rys. 5. Tworzenie nowej strefy głównej.

W kolejnym kroku zdefiniować możemy pełną nazwę kwalifikowaną FQDN domeny (rys. 6). Może to być nazwa domeny organizacji albo nazwa poddomeny danej organizacji. Należy też pamiętać, że nasz serwer będzie autorytatywnym serwerem dla zdefiniowanej przez nas przestrzeni nazw lub jej fragmentu. Oznacza, to że serwer ten jest w stanie rozwiązać wszystkie nazwy znajdujące się w domenie ita.local. W przypadku gdybyśmy uruchomili drugi serwer DNS obsługujący poddomenę domeny ita.local o nazwie np hr.ita.local to byłby on serwerem autorytatywnym dla poddomeny hr ale nieautorytatywnym dla ita.local. Taki serwer w przypadku otrzymania zapytania o rozwiązanie nazwy z domeny ita.local musiałby przekazać zapytanie dalej do serwera autorytatywnego dla tej domeny.

 Rys. 6. Nadawanie strefie nazwy FQDN. 

Następnie zdefiniować musimy nazwę pliku, w którym dana strefa będzie przechowywana (rys. 7). Istnieje też możliwość przywrócenia strefy z pliku.

 Rys. 7. Definiowanie nowego pliku przechowującego strefę DNS. 

Niezbędne jest też wybranie sposobu aktualizacji rekordów w strefie. Jeśli serwer DNS nie jest kontrolerem domeny AD ani serwerem członkowskim usługi Active Directory to możliwy jest jedynie wybór jedynie pomiędzy aktualizacjami dynamicznymi i brakiem aktualizacji rekordów zasobów. Do celów prezentacji zablokujemy aktualizacje automatyczne i będziemy tworzyć rekordy zasobów ręcznie. Pod pojęciem rekordów zasobów rozumiemy zestaw rekordów DNS. Listę tych rekordów znaleźć można pod tym adresem.

 Rys. 8. Definiowanie trybu aktualizacji strefy DNS. 

Po dokończeniu inicjalizacji strefy dostępne są w niej dwa rekordy utworzone domyślnie. Są to rekord SOA będący rekordem początkowym danych domeny określającym serwer przechowujący strefę główną, czas odświeżania, czas, życia rekordu, ważność itd. i rekord NS  mówiący o tym, że serwer DNS-SRV1 jest autorytatywny dla domeny ita.local. Pełną informację na temat rekordów SOA i NS można znaleźć pod adresami: http://www.immt.pwr.wroc.pl/tool/node96.html, http://www.immt.pwr.wroc.pl/tool/node97.html i http://www.immt.pwr.wroc.pl/tool/node98.html. Na tym etapie możemy też zdefiniować rekordy typu A odpowiadające translacji nazw FQDN na adresy IPv4 (rys. 9).

 

Rys. 9. Definiowanie rekordów w strefie DNS. 

Po zdefiniowaniu rekordów dla naszych trzech maszyn (rys. 10) możemy przystąpić do przetestowania serwera DNS.

Rys. 10. Zdefiniowane rekordy. 

Po wydaniu polecenia ping + nazwa FQDN maszyny powinniśmy otrzymać adres IP i odpowiedź danej maszyny (rys. 11) . 

Rys. 11. Rozwiązanie nazwy za pomocą serwera DNS. 

W ten sposób uruchomiliśmy samodzielnie nasz pierwszy serwer DNS. Należy jednak zaznaczyć, że to dopiero wstęp do administracji serwerem DNS. O strefach wyszukiwania wstecznego, rekordach zasobów transferach stref, delegacji i innych funkcjach i własnościach serwera DNS opowiem już w następnym odcinku.

Bartosz Pawłowicz

Windows Server w drukarni cz. 3 – serwer plików

Witajcie

Dziś kilka słów o konfiguracji i zarządzaniu podstawowymi funkcjami serwera plików. Udostępnianie plików to jedna z najbardziej obecnie rozpowszechnionych funkcji komputerów. Niejednokrotnie taki serwer jest realizowany w oparciu o kliencki system operacyjny. Nie budzi to już żadnego zdziwienia bowiem takie systemy jak Windows XP, Vista czy Windows 7 w wersjach Professional, Business czy Ultimate są narzędziami całkowicie wystarczającymi przy tworzeniu serwerów plików dla potrzeb domowych. Niestety niejednokrotnie spotykamy się z tym (ja sam miałem takie przygody), że te systemy wykorzystywane są jako serwery plików w przedsiębiorstwach gdzie niestety ich możliwości (choć bardzo duże) bywają niewystarczające. Jest tak dlatego, że udziały udostępnione w przedsiębiorstwach wymagają często precyzyjnego zarządzania przydziałem przestrzeni dyskowej, przydziałem przestrzeni w katalogach użytkownika, czy też wykorzystywania kilku protokołów udostępniania jednocześnie (np. SMB i NFS). Dodatkowo jeśli przechowujemy pliki newralgiczne i musimy uzyskiwać dostęp do udziałów z różnych lokalizacji fizycznych oddalonych geograficznie konieczne staje się wdrożenie systemów replikacji plików jak np. DFS. Oczywiście w bieżącym odcinku nie będziemy korzystać (jeszcze) z systemu DFS, ale już wkrótce będę opisywał zastosowania i konfigurację także tej funkcji systemu Windows Server. W systemie Windows Server 2008 do wszystkich funkcji oferowanych przez serwer plików mamy dostęp z poziomu konsoli zarządzania serwerem plików (rys. 1). W jej gałęzi główne mamy możliwość podglądu wszystkich folderów udostępnionych oraz parametrów z jakimi zostały one udostępnione. Jest to niezaprzeczalne udogodnienie w stosunku do Windows Server 2003, w którym to systemie aby uzyskać pełne możliwości zarządzania serwerem plików konieczne było doinstalowanie kilku różnych konsolek, zaś częścią ustawień zarządzać można był jedynie z poziomu właściwości pliku/folderu.

Rys. 1. Konsola zarządzania serwerem plików. 

W przypadku systemu Windows Server 2008 uzyskujemy natychmiastowy i intuicyjny dostęp do informacji czy mamy do czynienia z udostępnionym dyskiem, czy folderem, jak również do ścieżki logicznej prowadzącej do danego zasobu, informacji o tym, czy udział udostępniony jest do celów administracyjnych (symbol “$” na końcu nazwy udziału), wykorzystywanym protokole, obecności polityce ograniczeń pojemności udziału (Quota), ilości wolnego miejsca na dysku, włączeniu lub wyłączeniu mechanizmu  VSS (Shadow Copies) pozwalającego na dostęp do poprzednich wersji plików jak również informacji o statusie funkcji wykluczania niepożądanych plików lub dopuszczania tylko wybranych typów plików (File screening). Nową funkcjonalnością jest wprowadzenie kreatora udostępniania udziałów (rys. 2), który przeprowadza nas krok po kroku przez wszystkie opcje udostępnienia udziału w sieci.

Rys. 2. Kreator udostępniania udziału.

Pierwszym krokiem jest oczywiście wskazanie ścieżki do folderu lub pliku, który chcemy udostępniać. Możemy także udostępnić całe dyski (opcja “provision storage”).

Rys. 3. Zarządzanie uprawnieniami NTFS.

Następnie konieczna jest decyzja czy modyfikowane będą bezpośrednie uprawnienia do plików (rys. 3). Możemy zdecydować się na ich modyfikację, lub pozostawić je bez zmian. Co do samych uprawnień NTFS to tematykę tą poruszałem już na początku naszego cyklu (odcinki 1 i 2), tak więc zainteresowanych czytelników odsyłam do lektury tamtych tekstów. Po zdefiniowaniu uprawnień do folderów i plików konieczne jest zdefiniowanie nazwy udziału udostępnianego (rys. 4).

Rys. 4. Zdefiniowanie nazwy udziału udostępnianego. 

Wypada tutaj wspomnieć, że udział możemy udostępnić także do celów administracyjnych przez dodanie symbolu “$” na końcu nazwy udziału. do tak udostępnionego folderu lub pliku dostęp ma tylko administrator po wpisaniu ścieżki do pożądanego udziału w linii poleceń np \\nazwa_serwera\nazwa_udziału$ (w przypadku obecności w naszej sieci serwera DNS) lub \\adres_IP_serwera\nazwa_udziału$. Oczywiście do zwykłych folderów udostępnionych też można dostać się w ten sposób ale w przypadku udziałów udostępnionych do celów administracyjnych nie działa np funkcja wyszukiwania – administrator musi po prostu wiedzieć, gdzie chce się dostać. Dodać należy, ze inni użytkownicy nie mają dostępu do tych udziałów nawet jeśli znaliby poprawną ścieżkę dostępu. Na tym etapie możemy też zdecydować, czy udział ma być udostępniony dodatkowo przy użyciu protokołu NFS. Ta funkcja nie jest jednak dostępna domyślnie – aby można było z niej skorzystać konieczne jest doinstalowanie odpowiedniej usługi składowej serwera plików za pomocą menedżera ról serwera.

Rys. 5. Zaawansowane właściwości udostępniania. 

Mamy także możliwość konfiguracji granicznej ilości użytkowników mających jednoczesny dostęp do plików (rys. 5). Istnieje również opcja blokady wyświetlania zasobów udostępnionych dla użytkowników, którzy nie mają do nich dostępu. Na tym etapie mamy również możliwość konfiguracji udostępnienia offline danego udziału. Udostępnienie udziału w ten sposób wiąże się z tym, że po przeprowadzeniu synchronizacji zawartość folderu będzie przechowywana na lokalnych dyskach twardych klientów korzystających z danego zasobu. Jest to wygodne w przypadku, kiedy użytkownicy korzystają z urządzeń przenośnych, często odłączanych od sieci naszej organizacji.

 Rys. 6. Definiowanie uprawnień dostępu do udziału. 

W kolejnym kroku skonfigurować należy uprawnienia do udziału udostępnionego (rys. 6) Czynność ta jest bardzo podobna do konfiguracji uprawnień NTFS i określa kto i w jaki sposób może uzyskiwać dostęp do folderu lub pliku udostępnionego. Do wyboru są w tym przypadku trzy opcje – odczyt, zapis i pełna kontrola. Rola dwóch pierwszych ustawień wyczuwalna jest dość intuicyjne i polega na udostępnieniu uprawnienia do odczytu, lub odczytu i zapisu do danego udziału. Trzecie ustawienie przeznaczone jest dla tych użytkowników, którym powinno przysługiwać prawo do zmiany dwóch wcześniejszych ustawień dla pozostałych użytkowników. Należy podkreślić, że uprawnienia te nie mają wpływu na uprawnienia NTFS, które muszą zostać skonfigurowane niezależnie, żeby zapewnić uprawnionym użytkownikom dostęp do zasobów. 

  Rys. 7. Definiowanie przydziałów przestrzeni dyskowej. 

Ważne przy konfigurowaniu udziału jest też zdefiniowanie przestrzeni dyskowej jaką dany udział może zająć (rys. 7). Domyślnie mamy dostęp do czterech ustawień określających kolejne limity przestrzeni dyskowej i dwóch ustawień sprowadzających się tylko do funkcji monitorowania udziałów przekraczających zadane rozmiary. Aby uzyskać więcej opcji musimy skorzystać, ze specjalnej gałęzi ułatwiającej zarządzanie przydziałami (Quota Management). 

   Rys. 8. Konfiguracja polityki wykluczania plików. 

Przydatna jest również możliwość takiej konfiguracji udziałów, aby pliki o określonych rozszerzeniach były automatycznie odrzucane, a ich kopiowanie do folderu udostępnionego było niemożliwe. W kreatorze udostępniania udziału (rys. 8) mamy dostęp tylko do czterech domyślnych ustawień związanych z blokowaniem plików dźwiękowych i filmów, plików wykonywalnych, obrazów i wiadomości pocztowych oraz jednego umożliwiającego monitorowanie kopiowania plików wykonywalnych i systemowych. Więcej ustawień można uzyskać przy użyciu gałęzi File Screening Management. 

   Rys. 9. Konfiguracja przydziałów przestrzeni dyskowej dla folderów udostępnionych.

Jak wspomniałem wcześniej przy ręcznym definiowaniu przydziałów (rys. 9) możemy znacznie lepiej wycelować daną politykę co oznacza, że możliwe jest precyzyjne określenie przy jaki może być graniczny rozmiar folderu udostępnionego, w jaki sposób o danym zdarzeniu ma być powiadamiany administrator, a co najważniejsze możliwe jest przyporządkowywanie kilku polityk do jednego udziału co oznacza, że przy określonym rozmiarze zapisanych danych można włączyć monitoring i powiadomienie administratora i od razu określić kolejny próg przy, którym nastąpi blokada zapisu na dysk. Aby uprościć tworzenie polityk możliwe jest także tworzenie szablonów (rys. 10).

 Rys. 10. Tworzenie szablonu przydziału. 

Szablony mogą zawierać ręcznie i elastycznie zdefiniowane progi blokady zapisu i metody powiadamiania i ewidencji takich zdarzeń w zależności od potrzeb i ważności udziału do którego polityka zostanie zastosowana.

 Rys. 11. Tworzenie polityki wykluczania plików.

W analogiczny sposób możemy precyzyjnie tworzyć polityki blokowania zapisu określonych typów plików o zadanych rozszerzeniach (rys. 11), tworzyć polityki dla grup plików podlegających wykluczeniu, a także definiować sposób powiadomienia administratora o próbie zapisu takiego pliku na dysk, zapis do rejestru zdarzeń, a nawet wykonanie określonej operacji w odpowiedzi na próbę zapisu.

 Rys. 12. Tworzenie polityki wyjątków w wykluczaniu plików.   

Możliwe jest także utworzenie polityki przeciwnej do wykluczania, a mianowicie dopuszczenie określonych typów plików (rys. 12). Jest to przydatne kiedy na całe drzewo katalogów narzuciliśmy politykę wykluczania np. obrazów, a jeden z użytkowników podfolderów musi do swojego folderu kopiować zdjęcia ponieważ jest fotografem i pracuje nad np. aranżacjami do materiałów reklamowych. 

 Rys. 13. Tworzenie szablonów polityk wykluczania plików.    

Podobnie jak w przypadku przydziałów dysków jest możliwe tworzenie rozmaitych szablonów wykluczających lub dopuszczających kopiowanie określonych typów plików lub ich rozmaitych kombinacji dostosowanych do sytuacji panującej w naszej organizacji (rys. 13).

 Rys. 14. Tworzenie nowej grupy plików. 

Aby uniknąć sytuacji, w której za każdym razem konieczne jest zdefiniowanie w szablonie kilkudziesięciu rozszerzeń plików możliwe jest także zgrupowanie plików o określonych typach rozszerzeń (rys. 14). Ułatwia to tworzenie polityk i szablonów bo tworzenie listy plików do wykluczenia/dopuszczenia nie jest już tak czasochłonne.

 Rys. 15. Konfiguracja raportowania. 

Ciekawą funkcją jest też możliwość tworzenia raportów (rys. 15). Zdefiniować możemy sposób dostarczania raportu czyli np. zapis na dysk twardy lub e-mail, jak również jakie informacje dany raport ma zawierać. Warto wśród nich wymienić takie możliwości jak raportowanie zapisu dużych plików, plików do których najczęściej i najrzadziej uzyskiwano dostęp, możliwość segregacji plików w oparciu o właściciela czy też grupę. Mamy również możliwość ustawienia odstępu czasowego w jakim cyklicznie generowany jest raport i formatów raportu takich jak HTML, XML, CSV i inne.

 Rys. 16. Konfiguracja przydziałów dla partycji. 

Warto również wspomnieć o możliwości ustawiania przydziału na całym dysku logicznym. Funkcję tą konfigurujemy poprzez właściwości danego dysku logicznego (rys. 16). Za jej pomocą ustawić możemy globalny limit objętości danych przypadający na użytkownika danego dysku logicznego. Możemy również wyznaczyć poziom alarmowy objętości danych przypadający na użytkownika. Zdarzenia odpowiadające przekroczeniu poziomu alarmowego i osiągnięcia poziomu maksymalnego mogą być rejestrowane w rejestrze zdarzeń.

Rys. 17. Konfiguracja mechanizmu VSS.

Bardzo ciekawą funkcją o której warto wspomnieć jest funkcja kopiowania woluminów w tle (rys. 17). Ułatwia ona bardzo zarządzanie serwerem plików bowiem umożliwia wykonanie kopii zapasowej woluminu co pewien okres czasu – zdefiniowany przez administratora – dzięki czemu daje dostęp do wcześniejszych wersji plików. Umożliwia to bezproblemowe odzyskanie starszych i zmienionych przypadkowo wersji plików i dokumentów. Na koniec warto również podkreślić, że aby serwer plików działał niezawodnie zawsze należy zastosować przynajmniej macierz dysków aby zapewnić niezawodność i wydajność takiego rozwiązania. W przypadku serwerów w bardzo małych organizacjach macierz RAID 1 może okazać się wystarczająca i zapewni nam ona pełną kopię danych przechowywanych na serwerze. W przypadku bardziej wymagających środowisk pracy konieczne może okazać się zastosowanie macierzy RAID 5 lub RAID 10. Pamiętać jednak musimy że w przypadku awarii procesora bądź płyty głównej serwera utracimy dostęp do naszych danych do momentu wymiany uszkodzonego podzespołu. Jeśli więc nasza organizacja wymaga absolutnie nieprzerwanego dostępu do danych zgromadzonych na serwerze należy rozważyć zastosowanie klastra lub replikacji plików na kilka maszyn fizycznych i zintegrowanie ich w ramach systemu plików DFS, do którego konfiguracji będziemy jeszcze wracać. Abyśmy jednak mogli przejść do bardziej zaawansowanych zagadnień typu drzewa domen, IPv6, DFS i innych najpierw musimy zapoznać się z podstawami systemu DNS i administracją tego rodzaju serwerem. Dotąd jak czytelnicy pewnie zauważyli traktowałem DNS jako coś co w systemie Windows Server skonfiguruje się “samo” i rzeczywiście w prostych przykładach jakie dotąd rozważaliśmy było to możliwe. Jednak chciałbym abyśmy już niedługo zaczęli podchodzić do bardziej zaawansowanych rozwiązań i omawiania bardziej skomplikowanych przykładów. Z tego też powodu zapraszam wszystkich czytelników do mini cyklu, który przybliży nam ideę, zasadę działania i konfigurację serwerów DNS pracujących w oparciu o system operacyjny Windows Server.

Bartosz Pawłowicz

Windows Server w drukarni cz. 2 – DHCP

Witajcie

W tym odcinku przybliżę konfigurację serwera DHCP opartego o Windows Server 2008 R2. Jak już wspominałem w poprzednim odcinku jest to jeden z niezbędnych elementów sieci, którą rozpoczęliśmy tworzyć w drukarni. Muszę też wspomnieć, że na obecnym etapie będziemy posługiwać się adresacją IPv4 tak wiec zostanie omówiona konfiguracja serwera dla protokołu IP w wersji 4. W tym momencie wypada wspomnieć, że postaram się krok po kroku dojść również do opisu konfiguracji i funkcjonowania sieci pracującej w oparciu o protokół IPv6 jednak abym mógł opisywać konfigurację sieci pracującej z wykorzystaniem tego protokołu muszę przybliżyć jeszcze kilka ról serwera … Nie będę też przybliżał samego protokołu DHCP ponieważ jego opis można znaleźć w setkach miejsc w sieci a najszybciej w Wikipedii. Przed nami jednak dość długi tekst z 25 zrzutami ekranu z kolejnych etapów konfiguracji serwera. Zasadniczo po instalacji roli serwera DHCP i konfiguracji domyślnego zakresu możemy zarządzać serwerem z użyciem kilku różnych narzędzi. Pierwszym z nich jest oczywiście menedżer serwera. W przystawce tej możemy dostać się do drzewa zarządzania serwerem DHCP rozwijając gałąź role i potem DHCP. Drugim – moim zdaniem bardzo efektywnym – sposobem zarządzania jest wywołanie autonomicznej przystawki za pomocą polecenia dhcpmgmt.msc z linii poleceń w menu start. Trzecim sposobem jest zarządzanie przez utworzenie spersonalizowanej przystawki mmc. Cała konfiguracja była w omawianym przypadku wykonywana za pomocą narzędzia wywoływanego z linii poleceń. Konsolka wyposażona jest w trzy obszary (rys. 1), w których obserwować możemy rozwijane drzewo ustawień, wykaz możliwych do podjęcia akcji dla danego obiektu w drzewie i obszar informacyjny, z poziomu którego obserwować możemy istniejące dzierżawy adresów, wykluczenia, rezerwacje itd.    

Rys. 1. Konsola zarządzania DHCP.

Konsola udostępnia też możliwość dodawania i zdalnego zarządzania serwerami DHCP znajdującymi się w domenie Active Directory jak również umożliwia zdalną autoryzację i deautoryzację serwerów DHCP domeny AD. Należy jednak podkreślić, że konsola nie ma mechanizmu wykrywania, które serwery są serwerami DHCP. Z tego względu to administrator musi wiedzieć, które obiekty w domenie reprezentują serwery DHCP i które musi wskazać aby móc nimi zarządzać. Do autoryzacji zdalnej niezbędna jest natomiast znajomość adresu IP serwera który ma zostać poddany temu procesowi. Jest to również dobry sposób na wyłączenie niechcianych serwerów DHCP z działania bez zmiany ich konfiguracji ponieważ nieautoryzowane serwery DHCP będące członkami domeny nie rozsyłają adresów. Dostęp do wspomnianych powyżej opcji otrzymujemy po rozwinięciu menu zarządzania konsolą DHCP (rys. 2).

 

Rys. 2. Dostęp do zarządzania i autoryzacji zdalnej.

Kolejnym bardzo ważnym ustawieniami jakie możemy zdefiniować są położenie bazy danych DHCP i pliku kopii zapasowej tej bazy tworzonej na dysku twardym. Ustawienia te definiowane są globalnie w odniesieniu do całego serwera (rys. 3). Jeśli mamy do czynienia z małą organizacją (jak nasza drukarnia) możemy sobie pozwolić na przechowywanie tych plików w lokalizacjach domyślnych, jednak w przypadku dużych organizacji nie jest to dobrym pomysłem. Musimy pamiętać, że w przypadku gdy nasza organizacja wykorzystuje kilka do kilkunastu maszyn posługujących się adresami IP to w przypadku awarii serwera jesteśmy w najgorszym wypadku w stanie ustawić na wszystkich maszynach statyczne adresy i podtrzymać funkcjonalność sieci. W przypadku dużych organizacji to właśnie usługa DHCP jest jedną z newralgicznych usług sieci bo od niej zależy zaistnienie komunikacji – bez niej żadne inne usługi wymagające użycia adresów IP nie będą dostępne – a ustawienie statycznych adresów IP na kilku tysiącach lub dziesiątkach tysięcy maszyn nie wchodzi w grę w przypadku awarii serwerów DHCP. Dodatkowo w dużych środowiskach ustawienia serwera zawierają tysiące rezerwacji, zakresów, wykluczeń itd. Z tych powodów powinniśmy być w stanie szybko odtworzyć bazę danych ustawień serwera i przechowywać ją w bezpiecznej lokalizacji wykonując regularnie kopię zapasową.

Rys. 3. Ustawianie lokalizacji plików bazy danych i kopii zapasowej ustawień DHCP.

W sekcji ustawień dla protokołów IPv4 i IPv6 (rys. 4 i 5) dostępnych jest szereg ustawień umożliwiających precyzyjną współpracę serwerów DHCP i DNS (zakładka DNS), mechanizmu NAP (zakładka Network Access Protection), generowania statystyk (zakładka General), ustawień filtrowania adresów MAC (zakładka Filters), rejestrowania zdarzeń, poświadczeń aktualizacji rekordów DNS i dowiązań (zakładka Advanced). Niestety poszczególnych ustawień jest na tyle dużo, że nie sposób w tym tekście omówić wszystkie z osobna, tak więc rozgryzienie ich wszystkich pozostawiam dociekliwym czytelnikom.

Rys. 4. Okno właściwości protokołu IPv4. 

Rys. 5. Okno właściwości protokołu IPv6.

Zarówno dla protokołu IPv4 jak i IPv6 możemy ustawić szereg opcji serwera (rys. 6 i 7). Należy jednak zaznaczyć, że jest ich zdecydowanie więcej dla protokołu IPv4. Dostępne są oczywiście opcje wskazywania bram, serwerów DNS, serwerów czasu, WINS/NBNS i kilkadziesiąt innych opcji dotyczących protokołu IPv4. Ustawienia są tak rozbudowane dlatego, że protokół IPv4 ewoluował w czasie w nowe rozszerzenia dostarczające nowe funkcjonalności. Obecnie dla protokołu IPv6 dostępnych jest tylko kilka dodatkowych ustawień, w dużej części dzięki temu, że realizuje on domyślne większość funkcji dodatkowych protokołu IPv4. Niestety, ze względu na mnogość dostępnych ustawień muszę prosić o samodzielne zapoznanie się z nimi. Dobrym źródłem informacji jest norma RFC2132.

Rys. 6. Opcje serwera DHCP dla protokołu IPv4. 

Rys. 7. Opcje serwera DHCP dla protokołu IPv6.

Czas więc zabrać sie za konfigurację i uruchomienie naszego serwera DHCP. Pamiętajmy, że w poprzednim odcinku dokonaliśmy domyślnej konfiguracji zakresu podczas instalacji. W takim przypadku zainstalowany serwer DHCP będzie działał domyślnie z tak zdefiniowanym zakresem rozgłaszania adresów IP. Jest jednak druga możliwość, z której skorzystałem przy pisaniu tego artykułu – podczas instalacji roli serwera DHCP konfigurację domyślnego zakresu można pominąć i zainstalować “czysty” serwer. W ten sposób mogę zademonstrować wszystkie kroki prowadzące do uruchomienia serwera DHCP. Pierwszym koniecznym krokiem jest wskazanie protokołu dla którego będziemy tworzyli zakres. W naszym przypadku będzie to IPv4. Z menu kontekstowego dostępnego dla tego protokołu wybieramy “New Scope” (rys. 8). 

Rys. 8. Wybór akcji “Nowy Zakres” dla protokołu IPv4.

Powoduje to uruchomienie kreatora nowego zakresu (rys. 9). Nazwa zakresu jest obowiązkowa, natomiast pole “opis” służy tylko do uzupełnienia informacji o danym zakresie i może pozostać puste.

Rys. 9. Kreator zakresu.

W następnym kroku (rys. 10) musimy podać zakres adresów dostępnych dla klientów i maskę IP

Rys. 10. Definiowanie dostępnego zakresu adresów.

i zakres wykluczonych z dystrybucji adresów IP (rys. 11). Funkcja ta przydatna jest jeśli mamy już serwery pod danymi adresami ze zdefiniowanego zakresu i gwarantuje że nie dojdzie do konfliktu adresów w sieci. Kolejnym parametrem jaki możemy ustawić jest “DHCP Delay”. Ustawienie to przydatne jest w przypadku obecności w sieci więcej niż jednego serwera DHCP i ma na celu zapobieżenie błędom maszyn klienckich podczas identyfikacji serwerów DHCP podczas odbioru wiadomości DHCPOFFER rozsyłanej przez serwery.

Rys. 11. Definiowanie wykluczeń adresów.

Następnym ważnym elementem zdefiniowania zakresu jest zdefiniowanie czasu dzierżawy adresu (rys. 12). Domyślnie w Windows Server wynosi on 8 dni. Należy pamiętać, że jest to ustawienie, które może wpłynąć na wzrost lub obniżenie ruchu w sieci. Jest tak dlatego, że zapytania o przedłużenie dzierżawy są przez klienta wysyłane w połowie czasu trwania dzierżawy i w 87,5 % trwania tego czasu. Jeśli zdefiniujemy krótszy czas dzierżawy spowodujemy wzrost ruchu z powodu częstszych zapytań o odnowienie adresu. Należy też podkreślić, że oczywiście natężenie ruchu jest zależne od ilości maszyn w sieci. W rozbudowanych sieciach korporacyjnych lub operatorskich czas ten musi być niechybnie brany pod uwagę jako ważny czynnik pracy sieci.

 Rys. 12. Definiowanie czasu dzierżawy adresów.

Na koniec czeka nas pytanie o aktywację danego zakresu. Możemy to zrobić od razu (rys. 13) lub później przy wykorzystaniu menu kontekstowego zakresu (rys. 14). Serwer nie rozsyła adresów z zakresów nieaktywnych. Cecha ta umożliwia nam elastyczne dostosowanie konfiguracji serwera do każdych warunków, a potem aktywację i deaktywację kolejnych zakresów zależnie od potrzeb. 

 Rys. 13. Aktywacja zakresu za pomocą kreatora. 

 Rys. 14. Aktywacja zakresu za pomocą menu kontekstowego.

Po poprawnej konfiguracji i aktywacji zakresu powinniśmy zobaczyć przedział dystrybuowanych i wykluczonych adresów (rys. 15), zaś po uruchomieniu komputerów klienckich naszym oczom powinien ukazać sie widok z rysunku 16 – adresy zostały pobrane i mamy dwa komputery klienckie w sieci. Może się zdarzyć, że konieczne będzie odnowienie adresu na komputerze klienckim, co możemy wykonać przy użyciu polecenia ipconfig /renew.

 Rys. 15. Poprawnie skonfigurowany i aktywowany zakres.

  Rys. 16. Dwa komputery klienckie pobrały adresy IP.

Aby jednak sprawnie zarządzać przydziałami dużej ilości adresów nie możemy się ograniczyć tylko do skonfigurowania zakresu. Musimy także wprowadzić jednoznaczne przyporządkowanie danego adresu IP do maszyny. Procedura ta nazywa się rezerwacją adresów i ma na celu przyporządkowanie jednego adresu do danego urządzenia. Oczywiście możemy tego nie robić ale poza bałaganem, który sami sobie stworzymy będziemy w takim przypadku mieli jeszcze jeden, poważniejszy powód do zmartwień. Otóż jeśli pracujemy z użyciem domeny AD lub domeny DNS gdzie każde urządzenie ma przyporządkowaną nazwę FQDN częste i przypadkowe zmiany adresów tych samych urządzeń będą skutkować koniecznością dokonywania aktualizacji wpisów na serwerze DNS. Jeśli wszystkich aktualizacji dokonujemy ręcznie to można teoretycznie zapanować nad niekontrolowanym przyrostem rekordów hostów (A). Jeśli aktualizacje dokonywane są automatycznie baza rekordów może zacząć rozrastać się w sposób niekontrolowany. Dlatego lepiej na początku przyporządkować jednoznacznie adres IP urządzeniu. Wtedy jednemu urządzeniu będzie odpowiadał dokładnie jeden rekord (A) na serwerze DNS.

  Rys. 17. Tworzenie rezerwacji adresu IP.

Rezerwację adresu utworzyć w gałęzi “Reservations” przy użyciu akcji nowa rezerwacja (rys. 17). Aby zdefiniować rezerwację konieczna jest znajomość adresu IP, który przyporządkujemy danemu urządzeniu i adresu MAC tego urządzenia. Podanie nazwy w przypadku tworzenia rezerwacji jest obowiązkowe. Dobrze jest też wiedzieć czy dane urządzenie obsługuje protokół DHCP czy też tylko starszy BOOTP. Nie jest to jednak newralgiczne ustawienie bo możemy wymusić obsługę obydwóch protokołów. Po utworzeniu rezerwacja widoczna jest jako nieaktywna ponieważ dane urządzenie, dla którego ją tworzyliśmy może mieć przyznany inny adres. Dopiero po odnowieniu adresu IP (czyli po zapytaniu o nowy adres w trakcie trwania okresu dzierżawy, restarcie urządzenia lub wymuszeniu odnowienia adresu) rezerwacja staje się aktywna i urządzeniu zostaje przypisany pożądany adres IP (rys. 18).

   Rys. 18. Weryfikacja rezerwacji adresu IP.

Kolejną interesującą funkcją serwera DHCP jest dystrybucja adresów do wielu podsieci. Jak się domyślamy adresy do separowanych fizycznie podsieci można rozprowadzać za pomocą dwóch niezależnie skonfigurowanych Zakresów. Nie jest to procedura trudna i za pomocą zdobytej już wiedzy i chwili zabawy czytelnicy będą niewątpliwie w stanie skonfigurować szybko tą funkcjonalność. Kolejną ciekawą funkcją jest taki przydział adresów aby w jednej fizycznej sieci bądź podsieci adresy były z jednego serwera przydzielane do kilku sieci logicznych. Innym słowy w wyniku naszego działania maszyny podłączone fizycznie do pojedynczego przełącznika będą logicznie w wielu sieciach. Aby skonfigurować tą funkcję posłużymy się tzw. superzakresem (superscope). Superzakres jest tworem logicznym grupującym kilka zakresów skonfigurowanych do przydzielania adresów dla różnych logicznych podsieci w jedną całość. Aby utworzyć funkcjonujący superzakres musimy mieć co najmniej dwa skonfigurowane zakresy. na potrzeby demonstracji utworzyłem drugi zakres dystrybucji dla innej logicznej podsieci w identyczny sposób jak pierwszy tworzony w artykule zakres. Tworzenie superzakresu rozpoczynamy identycznie jak w przypadku tworzenia zakresu poprzez uruchomienie odpowiedniego kreatora (rys. 19).

   Rys. 19. Uruchomienie kreatora tworzenia superzakresu.

W kolejnym kroku (rys. 20) musimy wybrać, które zakresy będą elementami superzakresu. Jeśli mamy więcej niż dwa skonfigurowane zakresy nie musimy wybierać wszystkich. Warto pamiętać, że możemy mieć skonfigurowany więcej niż jeden superzakres. Każdy ze skonfigurowanych przez nas superzakresów może rozprowadzać adresy do innej podsieci fizycznej w ramach, których z kolei wyodrębnione są sieci logiczne.

   Rys. 20. Wybór zakresów członkowskich superzakresu.

Niestety samo utworzenie superzakresu (rys. 21) nie umożliwia jeszcze przydziału różnych adresów w jednej sieci fizycznej.

   Rys. 21. Utworzony superzakres.

Aby superzakres spełniał poprawnie swoją funkcję konieczne jest skonfigurowanie rezerwacji dla maszyn, które mają podłączonych do sieci fizycznej, które mają mieć przydzielone adresy z różnych podsieci logicznych. Warto wspomnieć, że serwer DHCP nie musi mieć adresu z każdej z tych podsieci przyznanego do jednej karty sieciowej. Po skonfigurowaniu rezerwacji do maszyn zostaną przydzielone adresy z odpowiednich zakresów (rys. 22).

   Rys. 22. Skonfigurowany superzakres.

Kiedy już poprawnie skonfigurujemy zakresy i superzakresy pozostaje odpowiednia konfiguracja opcji (rys. 23). Jak już wspominałem skonfigurować możemy bardzo wiele opcji, jednak jedną z najważniejszych informacji, jest to, że możemy ustawić je globalnie do serwera lub też dla każdego zakresu z osobna. Jeśli ustawimy opcje globalnie dla serwera wtedy są one stosowane do wszystkich zakresów, jeśli zaś skonfigurujemy opcje zakresu wtedy nadpisują one ustawienia dla całego serwera. Należy też wspomnieć, że możemy ustawić opcje tylko dla wybranych zakresów pozostawiając resztę bez konfiguracji. Wtedy wszystkie pozostałe będą się posługiwać wartościami ustawionymi w opcjach serwera.

  Rys. 23. Konfiguracja opcji.

Warto też wspomnieć o konfiguracji dowiązań. Dowiązania umożliwiają określenie interfejsów sieciowych związanych z serwerem DHCP (rys. 24).

   Rys. 24. Konfiguracja dowiązań.

Dla całego serwera, jak również dla zakresów i superzakresów można uzyskać dostęp do statystyk (rys. 25), które informują o dostępności adresów, wykorzystaniu liczbowym i procentowym puli, wysłanych ofertach, żądaniach przydzielenia adresów ilości zakresów, superzakresów itd. Statystyki są narzędziem szczególnie przydatnym w dużych środowiskach, gdzie nie jesteśmy w stanie przejrzeć wszystkich i skonfigurowanych zakresów w krótkim czasie.

   Rys. 25. Wyświetlenie statystyk.

Oczywiście zdaję sobie sprawę, że artykuł niniejszy nie wyczerpuje tematyki związanej z serwerem DHCP bo jest to niemożliwe w ramach jednego artykułu, lecz mam nadzieję, że informacje podane tutaj zachęcą czytelników do dalszego zgłębiania tej tematyki. Oczywiście do DHCP jeszcze powrócimy np. przy omawianiu NAP lecz w następnym odcinku zajmiemy się administracją serwerem plików.

Bartosz Pawłowicz

Windows Server w drukarni cz. 1

Witajcie

Zapraszam do lektury kolejnego odcinka z pewnym wyprzedzeniem bowiem na końcu tego bieżącego miesiąca mogę mieć trochę mniej czasu na pisanie. Pewnie zadajecie sobie pytanie dlaczego “Windows Server w drukarni” ? Otóż drukarnia jest już miejscem, w którym musimy zadbać o pewną ciągłość pracy systemu, a wiec o redundancję pewnych elementów systemu IT ponieważ przeważnie maszyna drukująca pracuje bez przerwy, a awaria systemu niewątpliwie spowoduje jej przestój. Dodatkowo drukarnia jest JESZCZE miejscem, które nie wymaga bezwzględnego wdrażania zaawansowanych usług typu szyfrowanie IPsec, Wystarczy domena do zarządzania użytkownikami i politykami, DHCP dla wszystkich maszyn i DHCP. Oczywiście mówię tutaj tylko o usługach dostarczanych przez system Windows. Jak się pewnie domyślacie sam Windows tutaj nie wystarczy. Do sprawnej obróbki obrazów i zapewnienia odpowiedniego przepływu wydruków konieczne są narzędzia firm takich jak Corel, Adobe i inne. Część z Was jest pewnie ciekawa co to za zautomatyzowane cudo o którym mówię. Dla dociekliwych napiszę, że taką zautomatyzowaną maszyną drukującą, do której miałem okazję projektować infrastrukturę sieciową jest Xerox DocuColor™ 5000AP z serwerem wydruków CREO SPIRE CXP50. Piszę o tym celowo tak szczegółowo bo w tym przypadku nie należy serwera wydruków mylić z maszynami na których będzie zainstalowany Windows Server. Serwer wydruków do tej maszyny drukującej to specjalizowany komputer wyposażony w karty sterujące pracą maszyny drukującej i dedykowane oprogramowanie. Serwer wydruków pobiera z serwera plików obrazy przeznaczone do drukowania według zadanej przez operatora kolejki, lecz sam nie przechowuje żadnego z nich. Teraz więc widzimy dlaczego tak ważne jest zapewnienie niezawodności działania infrastruktury sieciowej i serwerowej w tym przypadku. Bez właściwie skonfigurowanych, szybkich i niezawodnych serwerów całość po prostu nie mogłaby działać. Oczywiście w takiej sieci pracują również komputery klienckie na których pracują np. artyści graficy. Tak więc aby całość pracowała niezawodnie konieczna jest instalacja dwóch serwerów. Będą one pełnić role podstawowego i zapasowego kontrolera domeny, serwerów DHCP (z których tylko jeden będzie miał uruchomioną usługę DHCP, drugi będzie skonfigurowany na wypadek awarii) oraz serwerów plików. Oczywiście najlepszym rozwiązaniem jest tutaj zastosowanie systemu plików DFS, ale najpierw musimy nauczyć się instalować i konfigurować zwykły serwer plików. Więc do dzieła 🙂

Na początek dodatkowy kontroler domeny. W opisie założyłem oczywiście, że umiemy już konfigurować podstawowy kontroler dla pojedynczej domeny i dołączyć komputer do domeny. W Windows Server 2008 dołączanie do domeny odbywa się identycznie jak w Windows Vista i 7. Zakładamy więc, że mamy postawiony kontroler domeny i drugi serwer jako serwer członkowski domeny. Tu może się zdarzyć, że kontroler domeny oparty jest o inny system niż Windows Server 2008. Jeśli w Naszej domenie jest kontroler oparty np. o Windows 2003, a dodatkowy kontroler domeny ma być oparty o Windows 2008 to należy najpierw przygotować schemat domeny do dodania kontrolera z nowszym systemem. Dokonujemy tego przy pomocy programu adprep.exe, który znajduje się na płycie instalacyjnej Windows Server 2008 w katalogu support\adprep (rys. 1). W omawianym program ten uruchamiamy z linii poleceń na istniejącym kontrolerze domeny z Windows 2003 (rys. 2). Należy przy tym zwrócić uwagę na ustawienia językowe systemu. Język instalacji systemu Windows 2008 powinien być taki sam jak język instalacji starszego kontrolera domeny – niestety w innym przypadku mogą pojawić się problemy z wykonaniem tego polecenia.

Polecenie adprep.exe uruchamiane jest z przełącznikami /forestprep, /domainprep i /gpprep. Pisząc w ogromnym skrócie przełączniki te służą kolejno do przygotowania lasu, domeny oraz polityk domeny na “przyjęcie” kontrolera domeny opartego o Windows Server 2008. Działanie całego polecenia i przełączników nie jest niestety proste a dociekliwych czytelników odsyłam do zasobów TechNetu (na końcu niniejszego rozdziału wskażę kilka przydatnych linków). 

Rys. 1. Lokalizacja plików programu adprep.exe.

 

Rys. 2. Użycie polecenia adprep.exe.

W przypadku gdy podstawowym kontrolerem domeny jest maszyna w systemem Windows Server 2008 po właściwym skonfigurowaniu połączeń sieciowych, dodaniu serwera do domeny i zainstalowaniu usługi AD DS za pomocą menedżera serwera możemy przejść do przekształcenia serwera członkowskiego w zapasowy kontroler domeny. Początkowo Nasze działania będą podobne do znanych nam już czynności. Z wiersza polecenia uruchamiamy polecenie dcpromo i na ekranie powitalnym wybieramy zaawansowany tryb instalacji. Pierwszą dostrzegalną różnicą jest wybranie w następnym kroku opcji dodania kontrolera domeny do istniejącej domeny w istniejącym lesie (rys. 3).

Rys. 3. Zdefiniowanie funkcji konfigurowanego kontrolera.

W kolejnym kroku wybieramy domenę do której będziemy dodawać kontroler i ustawiamy poświadczenia użytkownika, w którego kontekście operacja dodania kontrolera będzie wykonywana (rys. 4) – w tym przypadku najlepiej oczywiście wybrać administratora domeny – i potwierdzamy dodanie do wskazanej i widzianej przez system domeny (rys. 5)

Rys. 4. wybór nazwy domeny i poświadczeń kontekstu instalacji.

Rys. 5. Wybór domeny do której zostanie dodany kontroler.

Następnym krokiem jest wybranie lokalizacji fizycznej (Site) do której dany kontroler będzie dodany (rys. 6). W Naszym przypadku mamy tylko jedną lokalizację z jej domyślną nazwą. Muszę jednak wspomnieć, że w jednej domenie można utworzyć kilka lokalizacji fizycznych w zależności od tego jak bardzo rozproszona jest Nasza organizacja. Podział ten wprowadzono aby umożliwić precyzyjne definiowanie parametrów replikacji danych pomiędzy kontrolerami domeny, które muszą łączyć się ze sobą za pomocą łączy WAN, w przypadku, których prawie zawsze mamy do czynienia z ograniczeniami przepustowości łącza. Dzięki zdefiniowaniu lokalizacji i grup serwerów, które do nich należą unikamy zapchania łączy tylko jednym typem ruchu. Dodam, że w jednym z kolejnych odcinków postaram się pokazać jak takie lokalizacje definiować.

Rys. 6. Wybór lokalizacji fizycznej.

Następnie zdefiniować można czy dany kontroler ma być również serwerem DNS, czy ma pełnić funkcję wykazu globalnego (Global Catalog) oraz czy ma być kontrolerem domeny tylko do odczytu (rys. 7). Ostatnia z funkcji szczególnie przydatna jest w oddziałach Naszej organizacji, w których nie ma administratorów, a kontrolery domeny mają być zabezpieczone przed dokonaniem wszelkich modyfikacji.

Rys. 7. Wybór funkcji kontrolera domeny.

W kolejnym kroku dokonujemy wyboru sposobu replikacji danych domenowych (rys. 8). W tym przypadku wybrałem replikację za pomocą sieci LAN, ale w przypadku gdy konfigurujemy kontroler domeny w lokalizacji z ograniczoną szybkością transferu danych w sieci lepszym pomysłem jest wykonanie nośnika z kopią partycji domenowej i replikacja danych z podanej lokalizacji. W skrajnych przypadkach takie działanie może oszczędzić kilka dni czekania 🙂

Rys. 8. Wybór sposobu replikacji.

Aby zakończyć proces instalacji wybieramy partnera replikacji (rys. 9) czyli kontroler domeny z którego skopiowana zostanie partycja domenowa. Oczywiście istnieje jeszcze kilka kroków analogicznych do instalacji pierwszego kontrolera domeny jak na przykład wybranie folderu lokalizacji polityk, czy zdefiniowanie lokalizacji partycji domenowej, które pominąłem aby skrócić opis. Po ich wykonaniu dodatkowy kontroler domeny zostanie zainstalowany i skonfigurowany.

Rys. 9. Wybór partnera replikacji

Po ponownym uruchomieniu zapasowego kontrolera i uruchomieniu przystawki zarządzania domeną dsa.msc na którymkolwiek z kontrolerów w gałęzi “kontrolery domeny” powinniśmy zobaczyć dwa obiekty reprezentujące Nasze serwery (rys. 10).

Rys. 10. Weryfikacja dodania drugiego kontrolera domeny.

Kolejnym z niezbędnych kroków jest instalacja wymaganych ról serwera, czyli serwera plików i serwera DHCP. W odróżnieniu od wcześniejszych wersji Windows Server tutaj wstępna konfiguracja odbywa się już na etapie instalowania roli serwera. Początkowa faza instalacji jest bardzo podobna do omawianej wcześniej instalacji usług domenowych Active Directory. W pierwszym etapie wybieramy rolę serwera DHCP (rys. 11).   

Rys. 11. Instalacja roli serwera DHCP.

Po wybraniu roli serwera musimy zdefiniować kartę sieciową, która będzie wykorzystywana do rozgłaszania adresów w sieci (rys. 12). 

Rys. 12. Wybór karty sieciowej na której będą rozgłaszane adresy.

Następnie (jeśli serwer jest w domenie AD) możemy zweryfikować istnienie serwerów DNS i ustawić automatyczne rozgłaszanie ich adresów przez serwer DHCP (rys. 13).

Rys. 13. Weryfikacja serwerów DNS.

W kolejnym kroku określamy czy w sieci wykorzystywany jest serwer WINS (rys. 14).

Rys. 14. Włączenie rozgłaszania adresu serwera WINS.

I wreszcie definiujemy zakres adresów rozgłaszanych przez serwer, oraz parametry dodatkowe, takie jak maska podsieci, czas dzierżawy DHCP, i bramę domyślną (rys. 15)

Rys. 15. Ustawienie podstawowych parametrów zakresu.

W kolejnym kroku określamy tryb działania przyznawania adresów IPv6 w naszej sieci (rys. 16)

Rys. 16. Włączenie serwera adresów IPv6.

i jeśli serwer DHCP jest serwerem członkowskim w domenie AD autoryzujemy go za pomocą domyślnych lub zdefiniowanych poświadczeń (rys 17).

Rys. 17. Ustawienie poświadczeń autoryzacji serwera dhcp w domenie.

Po pomyślnej instalacji roli serwera DHCP, możemy odnowić na naszych systemach klienckich adresy IP (rys. 18). Muszę tutaj zaznaczyć, że nieprzypadkowo piszę dość zdawkowo o tej roli w tym odcinku cyklu (co pewnie zauważyliście). Moim celem na ten odcinek, jest abyśmy wszyscy mieli postawiony funkcjonujący serwer DHCP w swej podstawowej postaci. W kolejnym zaś odcinku będę omawiał szczegółowo konsolę zarządzania serwerem DHCP i na to właśnie poświęcę cały odcinek. W związku z tym nie chcę mieszać informacji i szczegółowy opis konfiguracji z zarządzania usługą DHCP zostawiam na nasze kolejne spotkanie. To samo zresztą tyczy się roli serwera plików, której instalację za chwilę będę omawiał. Tej roli serwera zostanie również poświęcona należyta uwaga i zadedykowany jej zostanie osobny odcinek.

Rys. 18. Automatyczne uzyskanie adresu przez system kliencki.

Po pomyślnym zainstalowaniu serwera DHCP przechodzimy do instalacji roli serwera plików (rys. 19).

Rys. 19. Instalacja usług udostępniania plików.

W tym przypadku zobligowani jesteśmy również do wybrania tzw. usług roli, czyli zakresu funkcjonalności naszego serwera plików. Oprócz roli serwera plików zainstalować możemy system plików DFS, jeśli oczekujemy, że nasz serwer plików będzie jednym z wielu serwerów pracujących z użyciem rozproszonego sieciowego systemu plików (Distributed File System). Kolejnym usługami jakie możemy wybrać w tej roli są usługi przestrzeni nazw DFS i replikacji DFS. Opis tych usług pozwolę sobie na razie pominąć by wrócić do nich szczegółowo w kolejnych odcinkach. Windows Server 2008 R2 wspiera również usługi sieciowego systemu plików NFS używanego przez systemy z rodziny UNIX. Kolejnymi usługami jakie możemy zainstalować są usługi wyszukiwania plików i usługi zgodności z serwerem plików opartym o system Windows 2003. Usługą usprawniającą zarządzanie serwerem jest usługa menedżera zasobów serwera plików (FSRM), umożliwiająca bardzo łatwe zarządzanie przydziałami i ograniczeniami a najnowszym dodatkiem jest funkcjonalność przenoszenia często używanych plików na dyski serwerów i klientów oddziałów zdalnych (tzw. BranchCache). Wybrane w naszym przypadku usługi składowe zaprezentowano na rys. 20.

Rys. 20. Wybór poszczególnych składowych usług udostępniania plików.

W następnym kroku definiujemy ustawienia monitorowania woluminu lubi woluminów na których umieszczone zostaną nasze udziały udostępnione (rys. 21). Zdefiniować możemy graniczną wartość objętości danych da dysku po przekroczeniu której generowany będzie raport, a także dane jakie taki raport ma zawierać np. informacje o właścicielu plików, o plikach zwielokrotnionych itd … 

Rys. 21. Ustawienie parametrów monitorowania zajętości woluminów.

Następnie musimy zdefiniować folder gdzie będzie zapisywany raport, oraz czy będzie wysyłany na maila. Jeśli tak musimy podać docelowy adres e-mail i serwer smtp (rys. 22).

Rys. 22. Ustawienie opcji raportowania.

Jeśli włączamy usługę wyszukiwania musimy zdefiniować też woluminy, które zostaną poddane procesowi indeksowania (rys. 23). Po tym kroku przechodzimy do procesu instalacji.

Rys. 23. Ustawienie funkcji indeksowania plików.

Po ukończeniu instalacji wszystkich ról opisanych w niniejszym odcinku menedżer serwera powinien wyglądać jak na rys. 24.

Rys. 24. Podsumowanie zainstalowanych ról serwera.

Już za miesiąc ciąg dalszy – szczegóły konfiguracji i zarządzania serwerem DHCP.

Bartosz Pawłowicz

Projekt szkolnego laboratorium komputerowego cz. 2

Witajcie

Macie przed sobą lekturę trzeciego odcinka cyklu poświęconego budowaniu infrastruktury IT w oparciu o systemy operacyjne Windows. Nie ukrywam, że lektura ta może być nieco nudna ponieważ dziś nie będzie niestety tak efektownie jak w poprzednim odcinku gdzie „stawialiśmy” domenę AD od zera. Żeby jednak Was nie zanudzić postaram się pokazać kilka przykładów dotyczących polityk w domenie AD.

Jako zachętę do lektury obiecuję też omówienie w kolejnych odcinkach i pokazanie na funkcjonujących przykładach konfiguracji dalszych usług serwera opartego o system Windows 2008. Będą wśród nich: DHCP, usługi terminalowe, aplikacje zdalne, DNS, NAP, IPsec i wiele innych. Oczywiście część z tych usług może być instalowana i konfigurowana poza infrastrukturą AD lecz pełnię swoich możliwości pokazują właśnie w integracji z usługami AD. W kolejnych odcinkach zechcę też pokazać konfigurację drzewa i lasu domen a także zapasowych kontrolerów domeny AD. Aby pokazać te zagadnienia w ujęciu praktycznym musimy niestety przejść małe wprowadzanie teoretyczne opisujące zarządzanie usługą AD.

Usługą AD DS. (Active Directory Domain Services) zarządzamy przy pomocy czterech przystawek. Są to:

– Active Directory Users and Computers (Użytkownicy i komputery usługi Active Directory)

– Active Directory Sites and Services (Lokacje I usługi Active Directory)

– Active Directory Domains and Trusts (Domeny I relacje zaufania Active Directory)

– Active Directory Schema (Schemat usługi Active Directory)

Perwsza z nich (rys. 1) służy do zarządzania pojednynczą domeną AD. Pozostałe służą do zarządzania schematem AD (czyli tym jakie typy obiektów i o jakich atrybutach są dostępne w AD), drzewami domen AD i lasami drzew.

Rys. 1.  Widok przystawki do zarządzania domeną Active Directory 

Dziś zajmiemy się przystawką Użytkownicy i komputery usługi Active Directory. Kolejne przystawki zostaną omówione wraz z przykładami zastosowania w kolejnych odcinkach.

Wspomniana przystawka służy do zarządzania pojedynczą domeną AD. Po instalacji i konfiguracji usługi w domenie jest tworzony szereg domyślnych kontenerów w których przechowywane są domyślne konta użytkowników domeny, domyślne grupy i grupy wbudowane.

Jako domyślne tworzone są następujące kontenery:

– Builtin (rys. 2) zawierający domyślne lokalne domenowe grupy wbudowane.

– Foreign Security Principals – domyślnie pusty – zazwyczaj zawiera obiekty reprezentujące użytkowników lub inne obiekty z innych domen zaufanych mające dostęp do zasobów Naszej domeny.

– Computers gdzie umieszczane są domyślnie konta komputerów podłączanych do Naszej domeny

– Domain Controllers, w którym umieszczane są domyślnie konta kontrolerów Naszej domeny

– Users (rys. 3) gdzie mieszczą się domyślnie tworzone domenowe grupy lokalne i konta użytkowników.

Rys. 2. Wbudowane, domyślne grupy domenowe lokalne. 

Nie zaleca się tworzenia nowych obiektów (grup, kont) w domyślnych kontenerach ze względu na to, że nie można do nich podpinać polityk. Jedynym wyjątkiem jest kontener Kontrolery Domeny (Domain Controllers). Aby sprawnie administrować domeną AD umożliwiono tworzenie własnych kontenerów tzw. Jednostek organizacyjnych. Przykładową hierarchię takich jednostek stworzyliśmy w poprzednim odcinku. Jest ona dla przypomnienia zamieszczona na rys. 1 Zaleca się aby nowe obiekty w AD tworzyć właśnie w jednostkach organizacyjnych. Jednostki mają ta zaletę, że na każdym poziomie hierarchii możemy podpinać do nich polityki. Zostanie to zaprezentowane w dalszej części artykułu.

Czym różnią się grupy wbudowane z kontenera Builtin od grup domyślnie tworzonych w kontenerze Users ? Można stwierdzić że grupy wbudowane są grupami podstawowym ponieważ nie możemy w żaden sposób modyfikować ich atrybutów. Do grup wbudowanych możemy dodawać tylko inne obiekty w celu zapewnienia im dostępu do określonych zasobów lub funkcji. W przypadku grup domyślnych z kontenera Users możemy definiować i zmieniać członkostwo tych grup a także definiować zasięg ich działania (globalne, uniwersalne, domenowe lokalne). Kolejną ważną grupą są grupy systemowe z których część pokazano na rys. 4. W przypadku tych grup nie możemy samodzielnie modyfikować ich parametrów ani zmieniać członkostwa. Członkostwo takich grup ustanawiane jest przez system operacyjny. Jako przykład możemy się posłużyć grupą użytkownicy uwierzytelnieni (Authenticated Users). Po zalogowaniu do domeny członek grupy użytkowników domeny staje się również członkiem grupy Użytkownicy uwierzytelnieni. W momencie wylogowania przestaje On być członkiem tej grupy.

Rys. 3. Domyślnie tworzone grupy domenowe i użytkownicy domeny.

Rys. 4. Częściowy widok wszystkich grup systemowych.  

Ze względu na mnogość grup proszę wszystkich czytelników o samodzielne zapoznanie się ze szczegółami zasięgu działania poszczególnych grup. Teraz natomiast przejdę do omówienia najważniejszych typów grup. Możemy wyróżnić podział grup ze względu na funkcje i ze względu na zasięg. Ze względu na funkcje podzielić je można na grupy zabezpieczeń (czyli takie za pomocą, których definiować można dostęp do zasobów, plików, aplikacji) i dystrybucyjne wprowadzone po to aby zdefiniować np. użytkowników poczty nie będących członkami danej organizacji. Ze względu na zasięg grupy podzielić można na domenowe lokalne, globalne i uniwersalne. Oba atrybuty wybieramy podczas tworzenia grupy (rys. 5).

Rys. 5. Tworzenie nowej grupy.

Grupa domenowa lokalna może gromadzić obiekty (użytkowników, grupy, komputery itd.) z całego lasu lecz administrator może przyznać jej uprawnienia do zasobów (plików, aplikacji) tylko w obrębie domeny, w której grupa została zdefiniowana. Grupa globalna jest w pewnym sensie odwrotnością grupy domenowej lokalnej. Może ona gromadzić obiekty tylko z jednej domeny ale uprawnienia jej mogą być ustawiane w obrębie całego lasu. Najszerszą grupą jest grupa uniwersalna. Może ona gromadzić wszystkie typy obiektów z całego lasu i mieć uzyskiwać uprawnienia do każdego zasobu w lesie domen AD. Można sobie zadać pytanie dlaczego nie stosujemy tylko grup uniwersalnych. Zastosowanie wielu typów grup ma na celu dokładne zdefiniowanie uprawnień do zasobów oraz zminimalizowanie ruchu w sieci bowiem każde zdarzenie logowania czy dostępu do zasobów pociąga za sobą sprawdzanie członkostwa danych grup i wzrost ruchu w sieci. W Active Directory znanych jest kilka strategii organizacji grup i użytkowników. Można określić je za pomocą następujących skrótów.

A G P

A G DL P

A G U DL P

A G L P

A G U DL L P

gdzie A oznacza konto użytkownika, G oznacza grupę globalną, DL domenową lokalną, U uniwersalną, L lokalną na danej maszynie (oczywiście z wyjątkiem kontrolerów domeny gdzie grupy lokalne są usuwane) a P oznacza dostęp do zasobów. Dla skrótu AGDLP oznacza to, że konta umieszczamy w grupach globalnych, te zaś w domenowych lokalnych, którym przyznajemy dostęp do zasobów lub go odmawiamy. Grupy uniwersalne są stosowane w praktyce dla dużych lasów domen dzięki temu, że grupy uniwersalne z całego lasu mogą być przechowywane na specjalnych serwerach przechowująch tak zwane wykazy globalne (Global Catalog). Ma to na celu skrócenie zdarzeń logowania i dostepu do zasobów w sytuacji gdy nasza organizacja ma infrastrukturę AD połączoną łączami WAN w kilku miastach lub państwach. Zastosowanie grupy domenowej lokalnej do przyznania dostępu do pliku zaprezentowano na rys. 6. Grupy DL_Uczniowie nie ma w grupach lokalnych przyłączonego do domeny komputera, ale jest ona zdefiniowana na kontrolerze domeny i widzialna w całej domenie.

 

Rys. 6. Przyznawanie dostępu do zasobów grupie domenowej lokalnej. 

Na podobnej zasadzie odbywa się przyznawanie dostępu do zasobów na wszystkich komputerach i serwerach danej domeny.

Skoro znamy już sposoby sterowania dostępem do zasobów w domenie (tworzenie użytkowników i logowanie omówiliśmy w poprzednim odcinku) kolejnym krokiem jest poznanie mechanizmu, który umożliwi wymuszenie jednolitych ustawień komputerów i serwerów w całej domenie, specjalną konfigurację maszyn dla określonych grup użytkowników lub wymuszanie określonych konfiguracji dla różnych grup maszyn. Takim mechanizmem są polityki.

Bardzo wygodnym edytorem polityk dostępnym domyślnie dostępna konsola zarządzania politykami (rys. 7) uruchamiana po wpisaniu do wiersza polecenia rozkazu gpmc.msc.

Rys. 7. Konsola zarządzania politykami. 

Konsola zarządzania politykami umożliwia łatwy podgląd wszystkich kontenerów do których możemy podpinać polityki. Wszystkie polityki przechowywane są w kontenerze obiektów polityk grup (Group Policy Objects) natomiast pod określone kontenery w AD podpięte są jedynie skróty do nich. W ten sposób możemy raz utworzoną politykę podłączać do wielu kontenerów w domenie. Procedurę tworzenia przykładowej polityki pokazano na rys. 8 natomiast rys. 9 ilustruje utworzoną hierarchię polityk.

Rys. 8. Tworzenie nowej polityki. 

Rys. 9. Rzeczywista lokalizacja polityki. 

Jak widać na rysunku do pracowni został przypięty obiekt GPO blokada IE. Polityki są dziedziczone, co oznacza, że ich działanie odnosi się do każdego podkontenera w kontenerze do którego są podpięte. Jeśli zastosowalibyśmy wspomnianą do administratorów i nauczycieli moglibyśmy zaburzyć istotną funkcjonalność laboratorium. Aby tego uniknąć można zablokować dziedziczenie. Funkcja ta dostępna jest po kliknięciu prawym przyciskiem myszy na dany kontener.

Polityki stosowane są w następującej kolejności. W pierwszej kolejności polityki lokalne znane Nam z pierwszej części cyklu. Następnie polityki dla lokalizacji (Site) AD. Mówimy o nich tylko wtedy kiedy mamy kilka kontrolerów domeny bądź domen rozmieszczonych w zdefiniowanych lokalizacjach. W następnej kolejności stosowane są polityki podpięte do domeny a na końcu do jednostek organizacyjnych. Warto podkreślić, że ustawienia są nadpisywane więc jeśli te same ustawienia były zdefiniowane w różny sposób w kilku politykach będą zastosowane ustawienia z ostatniej stosowanej polityki.

Jeśli mamy rozbudowaną hierarchę jednostek administracyjnych to polityki przetwarzane są z gory do dołu czyli od najwyższej w hierarchii jednostki do najniższej jednostki potomnej. Jeśli do jednej jednostki przypiętych jest kilka polityk to można zdefiniować kolejność ich przetwarzania (rys. 10).

Rys. 10. Kolejność wykonywania polityk. 

Obiekt GPO z najwyższym numerem porządkowym przetwarzany jest jako pierwszy, zaś GPO z najniższym numerem jako ostatni. Jego ustawienia nadpisują wcześniejsze ustawienia. Jak już wiecie z pierwszego odcinka cyklu ustawień dostępnych w GPO jest kilka tysięcy dlatego dobrą praktyką jest nazywanie obiektów zgodnie ze zdefiniowanymi w nich ustawieniami.

Jest jeszcze jeden bardzo ważny aspekt stosowania polityk domenowych. Zazwyczaj w domenach i jednostkach organizacyjnych znajdują się użytkownicy komputery etc. Do nich właśnie stosują się polityki. Aby jeszcze dokładniej wycelować ich działanie można filtrować stosowanie polityk do określonych grup użytkowników (rys. 11) lub do określonych maszyn poprzez filtry WMI.

Rys. 11. Narzucanie polityk określonym grupom użytkowników. 

Edytować dany obiekt możemy poprzez kliknięcie prawym przyciskiem na obiekt GPO i wybranie polecenia Edit. Widzimy że okno edycji jest zbliżone do okna edycji polityk lokalnych. Jeśli w danej jednostce organizacyjnej będą się znajdować konta komputerów to zostanie do nich zastosowana gałąź odpowiadająca za ustawienia komputera. Jeśli będą to użytkownicy to do tych użytkowników zostanie zastosowana gałąź z ustawieniami użytkownika. Jako przykład skonfigurowałem politykę wymuszającą klasyczne menu start dla użytkowników znajdujących się w jednostce uczniowie (rys. 12).

Rys. 12. Edycja polityki.

Efekt tego widoczny jest na rysunku 13. Użytkownik z danej jednostki organizacyjnej nie ma możliwości wyboru menu start.

Rys. 13. Efekt działania polityki.

Po tej nużącej dawce teorii w ramach zachęty do lektury następnego i kolejnych odcinków powiem, że już niedługo wykorzystamy w praktyce przedstawione tu wiadomości do blokady niechcianego oprogramowania, usług NAP i IPsec oraz wielu innych. A w następnych odcinkach stawiamy między innymi zapasowy kontroler domeny, serwer DHCP i serwer plików bowiem będziemy się zajmowali systemem IT w ……. drukarni.

Bartosz Pawłowicz

Projekt szkolnego laboratorium komputerowego cz. 1

Witajcie

Dziś korzystając z wiedzy jaką nabyliście podczas lektury pierwszego odcinka przewodnika po funkcjach klienckich i serwerowych systemów Windows postaram się przybliżyć projekt szkolnego laboratorium komputerowego.

Pełen opis projektu zostanie podzielę na dwie części. Pierwszą zaprezentuję dziś, zaś drugą w kolejnym odcinku.

Dziś postaram się Wam przybliżyć korzyści płynące z zastosowania domen Active Directory, powiedzieć kilka słów o tej technologii oraz pokazać pewne zalety (i wady) wirtualizacji.

Zadanie projektowe z jakim spotkamy się dziś to zaprojektowanie systemu kontroli szkolnej pracowni komputerowej. Pracownia składa się typowo z 16 jednakowych stanowisk komputerowych. Żaden z zastosowanych komputerów nie jest komputerem klasy serwerowej. Najistotniejszą kwestią jest to, że żaden z nich nie jest wyposażony w macierz RAID. Są to jednak komputery dobrej klasy (4GB RAM, procesory Core 2 Duo i dyski twarde 500GB wyposażone w system Windows Vista Business). Wszystkie komputery podłączone są do przełącznika (switch), który podłączony jest do routera DSL. Sieć jest w pełni funkcjonalna. Komputery widzą się w grupe roboczej, a uczniowie mogą korzystać z Internetu. Problemem w tym przypadku jest to, że nauczyciel jest tak naprawdę pozbawiony kontroli nad całą infrastrukturą zainstalowaną w pracowni i aby mieć nadzór np. nad kontami uczniów musi zajmować się nadzorem nad każdym komputerem z osobna. Koszty systemu kontroli muszą być w tym przypadku minimalne – zakup komputera pełniącego funkcję serwera nie wchodzi w tym przypadku w grę.

Rozsądnym wyborem będzie w tym wypadku zastosowanie wirtualnego serwera zarządzającego pracownią. Jako mechanizm zarządzania wykorzystamy technologię Active Directory. Dodatkowo na serwerze wirtualnym umieścimy serwer plików. Jeśli wspominam o wirtualizacji to pewnie wszystkim Wam nasuwa się od razu technologia Hyper-V lecz w tym przypadku mamy do czynienia z maszynami na których nie będziemy instalować systemu Windows Server 2008. Jako oprogramowanie do wirtualizacji posłuży Nam Virtual PC 2007. Mimo, że jest to bardzo proste środowisko wirtualizacji to ma bardzo istotną (poza barkiem kosztów) zaletę – umożliwia systemowi wirtualnemu komunikację za pomocą wielu kart sieciowych co sprawia, że możliwa jest np. realizacja routera czy zapory ogniowej. Na temat samego Virtual PC napisano bardzo wiele artykułów łącznie ze szczegółowymi przewodnikami po tym programie tak więc poproszę Was w tym wypadku o samodzielne przeszukanie zasobów sieci jeśli jakiekolwiek informacje o tym programie są konieczne.

Wykorzystanie Virtual PC umożliwia szybkie przeniesienie serwera w przypadku awarii komputera, którym posługuje się nauczyciel. Oczywiście przeniesienie takie jest możliwe jeśli nauczyciel pamięta o wykonywaniu kopii zapasowej pliku zawierającego dysk wirtualny serwera lub wykonanie automatyczne kopii zapasowej do określonej lokalizacji w sieci (np. na dysk innego komputera w tej samej pracowni). W przypadku instalacji serwerowego systemu operacyjnego na jednym z komputerów fizycznych pracowni awaria tego komputera uniemożliwiłaby efektywną pracę. Oczywiście możliwe jest cykliczne wykonywanie obrazu serwera i przenoszenie go do innej lokalizacji lecz w tym przypadku po awarii konieczny byłby dodatkowy czas poświęcony na naprawę maszyny.

Z tych powodów wirtualizacja serwera jest najlepszym wyjściem jeśli nie dysponujemy maszyną wyposażoną w nadmiarowe dyski abyśmy w przypadku awarii nie utracili wszystkich danych (co wcale nie jest rzadkością).

Aby umożliwić pełną kontrolę nad pracownią wykorzystamy domenę Active Directory.Usługa katalogowa Active Directory jest w istocie hierarchiczną bazą danych odzwierciedlającą w swej strukturze logicznej i fizycznej strukturę organizacji, w której została zaimplementowana. Głównym zadaniem tej technologii jest scentralizowane przechowywanie informacji o urządzeniach w systemie teleinformatycznym danej organizacji i użytkownikach mających prawo do użytkowania zasobów tej organizacji. Active Directory może być więc wdrożone dla pojedynczej pracowni komputerowej (pojedyncza domena najwyższego poziomu) jak i dla firmy (domena najwyższego poziomu jest zazwyczaj domeną pustą a do niej dołączane są domeny przechowujące dane o obiektach i użytkownikach z różnych działów) Możliwe jest również wdrożenie Active Directory np. w skali całego Państwa. Active Directory (w skrócie AD) do funkcjonowania potrzebuje serwerów pracujących w oparciu o Windows Server, które muszą być skonfigurowanie w specyficzny sposób. Serwery takie zwane są kontrolerami domeny. Techniczne do uruchomienia pojedynczej domeny wystarcza jeden serwer – kontroler domeny. W praktyce dla każdej tworzonej domeny powinien być skonfigurowany przynajmniej jeden zapasowy kontroler domeny. Muszę jednak zaznaczyć że iloć kontrolerów zależy od ilości użytkowników i obiektów (komputerów, drukarek) w domenie. Jest tak dlatego, że konta użytkowników są w przypadku tej technologii przechowywane właśnie na kontrolerach domeny i od ilości przesyłanych danych (np. żądań logowania) zależy to ile maszyn należy zastosować. To właśnie na każdej z tych maszyn w specjalnym pliku ntds.dit przechowywana jest baza danych o obiektach znajdujących się w domenie. Wszystkie maszyny podłączone do domeny AD komunikują się ze sobą za pomocą protokołu DNS. Z tego powodu każdy kontroler domeny powinien być jednocześnie serwerem DNS, żeby każda maszyna podłączona do domeny mogła skomunikować się z kontrolerem za pomocą pełnej nazwy kwalifikowanej (FQDN). Serwer DNS jest instalowany automatycznie podczas instalacji usług domenowych AD. Instalacja serwera DNS nie jest wymogiem bezwzględnym ale jest zalecana. Znacznie łatwiej jest skonfigurować delegację do istniejącego serwera DNS aby nazwy spoza Naszej domeny były rozwiązywane poprawnie niż dobrze zintegrować z domeną AD istniejący serwer DNS. Jest tak dlatego, że wszystkie rekordy AD są przechowywane w specjalnej strefie zintegrowanej z baza danych AD. Jeśli chodzi o nazwy domen to mogą być stosowane dowolne nazwy i dowolne rozszerzenia np. laboratorium.lab lub pracownia.local. Należy jednak pamiętać o takiej konfiguracji systemu DNS aby nazwy spoza Naszej domeny AD (np. onet.pl) były również rozwiązywane poprawnie.

Wiem, że zarzuciłem Was wszystkich straszną teorią ale obiecuję, że w tym i kolejnych odcinkach będę wyjaśniał po kolei wszystkie wspomniane tutaj opcje wraz z opisem jak to zrobić w praktyce.

Jest jednak jeszcze jedna sprawa o której muszę wspomnieć. Są to drzewa i lasy domen. Możliwość tworzenia takiej hierarchii jest wielką siłą tej technologii. Wyobraźmy sobie domeną główną uczelni o nazwie uczelnia.org. Jeślibyśmy do jednej domeny wrzucili wszystkie osoby (nauczycieli, studentów, administrację) korzystające z sieci tej uczelni wrzucili do jednej domeny to po jakimś czasie stracilibyśmy orientację w tej strukturze i utracili nad nią kontrolę. Z tego powodu w takim przypadku lepiej zaprojektować i utworzyć drzewo domen. Hipotetycznie można tutaj zaproponować rozwiązanie pokazane na rys. 1.

Rys.1. Schemat logiczny przykładowej struktury domenowej AD.

Są one połączone ze sobą relacjami zaufania i funkcjami administracyjnymi. Oznacza to że użytkownicy tych domen mogą logować się i uzyskiwać dostęp do zasobów zgromadzonych w innych domenach w drzewie. Kolejnym bardzo ważnym aspektem funkcjonowania domen są lasy. Stworzenie lasu oznacza, że do naszej domeny np. uczelnia.org dodajemy domenę nie związaną z nią jawnie nazwą np. dzialbadan.org powiązaną z nią relacjami zaufania podobnie jak było to w przypadku drzewa. Należy zaznaczyć, że relacje zaufania mogą także być tworzone ręcznie np. przy integracji systemów teleinformatycznych dwóch łączących się organizacji.

Myślę że po tym bardzo ciężkostrawnym wstępie teoretycznym możemy przejść do instalacji i konfiguracji naszego wirtualnego kontrolera domeny. Tutaj założę, że na podstawie samodzielnie zdobytych informacji Wszyscy poradzicie sobie z instalacją Windows Server na wirtualnej maszynie. Jeśli chodzi o wersję systemu to minimum konieczne do instalacji usługi Active Directory do Windows 2003 standard lub Windows 2008 standard. Oczywiście musimy pamiętać o poprawnej konfiguracji połączenia sieciowego. W tym przypadku najlepiej wybrać dla serwera statyczny adres IP. Warto też pamiętać o tym, żeby stacje klienckie jako jednego z adresów serwerów DNS używały adresu serwera. Przykładowa konfiguracja połączeń sieciowych klienta i serwera przedstawiona została na rys. 2 i 3 Konfiguracja ta uwzględnia w tym przypadku tylko elementy niezbędne do poprawnego zadziałania usługi Active Directory.

Rys. 2. Konfiguracja karty sieciowej serwera.

Rys. 3. Konfiguracja karty sieciowej klienta.

Kolejnym krokiem jaki musimy wykonać jest instalacja usługi Active Directory. W tym celu musimy w konsoli zarządzania serwerem (server manager) wybrać dodanie nowej roli (rys. 4). Muszę tutaj zaznaczyć, że taka procedura instalacji obowiązuje począwszy od wersji 2008 systemu wzwyż gdyż dokonał się tutaj znaczny postęp jeśli chodzi o technologię AD. Usługa jest instalowana niezależnie i może zostać wyłączona bez zaburzenia konfiguracji innych usług serwera. W systemie Windows 2003 instalacja AD musiała być przeprowadzana na czystym systemie ponieważ usuwała ona wszystkie konta lokalne komputera i informacje użytkowników.

Rys. 4. Kreator Instalacji ról serwera.

Po zakończeniu instalacji dostaniemy kilka komunikatów o błędach informujących o tym, że poszczególne składniki usługi składowe AD są zatrzymane. Jest tak ponieważ zostały składniki AD zostały tylko zainstalowane. Aby kontroler domeny zaczął działać należy go teraz skonfigurować i uruchomić. Aby wywołać kreator konfiguracji AD używamy polecenia dcpromo.exe uruchom w menu start. Należy pamiętać że podanie tego polecenia w systemie Windows 2003 ma inne działanie niż w przypadku systemu Windows 2008. W systemie Windows 2003 po podaniu tego polecenia następu je konfiguracja i instalacja kontrolera domeny. Jak już wspominałem wcześniej w systemie Windows 2008 mamy do czynienia tylko z konfiguracją i inicjalizacją usługi. Po wywołaniu kreatora usługi AD (rys. 5).

Rys. 5. Ekran powitalny kreatora konfiguracji usługi AD.

Musimy skonfigurować szereg parametrów w oparciu o które Nasz kontroler domeny będzie funkcjonował. Konfigurację rozpoczynamy od zdefiniowania czy Nasz kontroler domeny będzie kontrolerem w nowej domenie w nowym lesie, dodatkowym kontrolerem w istniejącej domenie, kontrolerem nowej domeny w istniejącym lesie czy też kontrolerem domeny podrzędnej w istniejącym drzewie (rys. 6). W naszym przypadku wybieramy oczywiście nową domenę w nowym lesie.

Rys. 6. Wybór trybu pracy kontrolera domeny.

Kolejnym krokiem jest wybór nazwy FQDN domeny (rys. 7).

  

Rys. 7. Wybór nazwy FQDN domeny.

Jak już wspominałem wcześniej mamy pełną swobodę wyboru nazwy domeny. W celu demonstracji wybrałem nazwę contoso.local. Możemy oczywiście wybrać inną nazwę (org, net, com) zależnie od wymagań projektu. Jednak jeśli mamy do czynienia z domeną oddzieloną od sieci zewnętrznej nazwa local jest korzystna ze względu na to, że Windows przez podanie takiej nazwy traktuje domenę jako izolowaną i automatycznie konfiguruje serwer DNS na potrzeby np. dołączania kolejnych kontrolerów w danej domenie, tworzenia drzewa, lasu itd. W prapadku zastosowania nazw np. z rozrzeszeniem org system pomija automatyczną konfigurację serwera DNS ze względu na to, że domena org może być częścią większej struktury domenowej i przez konfigurację domyślną system mógłby zaburzyć działanie innych serwerów DNS pracujących w sieci. Z tego powodu w tym przypadku to użytkownik musi prawidłowo skonfigurować serwer DNS bo w innym przypadku nie będzie możliwe dodawanie kolejnych kontrolerów i poprawne rozwiązywanie nazw. Kolejnym krokiem jest wybór nazwy NetBIOS domeny (rys. 8) W tym przypadku pozostawimy ją niezmienioną (jest to dobra praktyka).

Rys. 8. Wybór nazwy NetBIOS domeny.

Kolejnym krokiem jest wybór poziomu funkcjonalności lasu i poziomu funkcjonalności domeny (rys. 9, 10). Tutaj wspomnę tylko że w systemie Windows 2008 mamy do wyboru trzy poziomy funkcjonalności lasu i trzy poziomy funkcjonalności domeny dokładnie przyjrzymy im się w dalszych częściach naszego cyklu, kiedy będziemy tworzyć bardziej skomplikowane hierarchie domen. Warto jednak zaznaczyć, że wybór funkcjonalności ma dość istotny wpływ na możliwości funkcjonalne i administracyjne, zarówno lasu jak i domen go tworzących.

Rys. 9. Wybór poziomu funkcjonalności lasu.

  

Rys. 10. Wybór poziomu funkcjonalności domeny.

W tym przypadku pozostawimy poziom funkcjonalności na domyślnym Windows 2000 gdyż nie będzie to miało znaczącego wpływu na funkcje administracyjne, które będziemy implementować w Naszej pracowni. W następnym kroku (rys. 11) potwierdzamy instalację serwera DNS (jak już wspomniałem można zrezygnować z instalacji DNS ale nie jest to najlepsza praktyka). Jak widać na rys. 11 jest jeszcze kilka innych (tutaj niedostępnych opcji), o których będę mówił w dalszych częściach cyklu.

Rys. 11. Potwierdzenie instalacji serwera DNS.

Dalej możemy wybrać lokalizację pliku bazy danych AD, pliku w którym przechowywane są logi i folderu SYSVOL, w którym przechowywane są polityki zdefiniowane w domenie. W przypadku instalacji kontrolerów domen na urządzeniach fizycznych lepiej umiesić te pliki w lokalizacjach gdzie dane są zabezpieczone za pomocą macierzy RAID lub w pamięciach masowych NAS. Wtedy w przypadku awarii systemu operacyjnego baza danych AD i polityki pozostają nienaruszone. W przypadku projektu Naszej pracowni ich lokalizację lepiej pozostawić niezmieniona. Będą wtedy przechowywane w pliku Naszej wirtualnej maszyny. Następnie po potwierdzeniu wszystkich wyborów przechodzimy do fazy inicjalizacji AD (rys. 12) po, której będzie wymagane powtórne uruchomienie systemu operacyjnego.

Rys. 12. Inicjalizacja usługi AD.

Następnym krokiem, który musimy wykonać jest dołączenie komputerów klienckich do domeny. Na rysunku 13 i 14 przedstawiono czynności jakie należy wykonać by to osiągnąć.

Rys. 13. Dołączanie systemu klienckiego do domeny AD.

Rys. 14. Dołączanie systemu klienckiego do domeny AD.

Po wykonaniu po tych czynności musimy zrestartować maszynę którą dołączaliśmy do domeny. W bazie danych kontrolera domeny zostaje utworzone konto komputera dołączonego właśnie komputera dające logiczne powiązanie tych dwóch komputera z kontrolerem domeny.

Teraz przechodzimy do tego co jest jednym z największych plusów zastosowania domen AD. Jest to scentralizowane zarządzanie wszystkimi obiektami domeny. Na sprawne zarządzanie pozwala Nam konsola Użytkownicy i komputery usługi Active Directory wywoływana za pomocą użycia polecenia dsa.msc z w konsoli. Za pomocą tej konsoli możemy tworzyć hierarchię tzw. Jednostek organizacyjnych (rys. 15) odzwierciedlających np. strukturę użytkowników w Naszej pracowni.

Rys. 15. Tworzenie hierarchii jednostek organizacyjnych

W odpowiednich jednostkach organizacyjnych możemy założyć konta użytkowników (rys. 16, 17).

  

Rys. 16. Zakładanie nowych użytkowników w usłudze AD.

Rys. 17. Zakładanie nowych użytkowników w usłudze AD.

a także gromadzić użytkowników w grupy ułatwiające administrację i przyznawanie dostępu do zasobów. I właśnie tutaj ujawnia się siła AD. Na komputerach podłączonych do domeny nie musimy tworzyć żadnych kont lokalnych. Co więcej można lokalne konta administratora i gościa wyłączyć. Użytkownik niezależnie od lokalizacji w której przebywa i niezależnie od tego jakiej maszyny używa loguje się zawsze za pomocą tych samych poświadczeń. Oznacza to, że w przypadku naszej pracowni użytkownicy, których konta utworzyliśmy na kontrolerze domeny mogą logować się do dowolnej maszyny w pracowni i nie istnieje konieczność tworzenia całego zestawu kont na danej maszynie. Proces uwierzytelniania użytkowników odbywa się za pomocą kontrolera domeny. Teraz pewnie zadajecie sobie pytanie czy np. logujący się użytkownik mógłby mieć wszędzie taki sam pulpit lub ograniczony niezależnie od maszyny dostęp do pewnych aplikacji ? Otóż tak – jest to Możliwe. Jednak aby te bardziej zaawansowane funkcjonalności AD poprawnie skonfigurować będziemy musieli zapoznać się szczegółowo z obiektami takimi jak konta i grupy w Active Directory, politykami AD i wieloma innymi aspektami funkcjonowania domen AD o czym już w następnym i kolejnych odcinkach.

Na koniec jak zwykle parę przydatnych odnośników do zasobów sieciowych.

http://en.wikipedia.org/wiki/Active_Directory – fajny i prosty opis Active Directory (język angielski)

http://support.microsoft.com/kb/310996/PL – opis usługi Active Directory w dwóch częściach (język polski)

http://technet.microsoft.com/pl-pl/library/cc775736(WS.10).aspx – artykuł o typach relacji zaufania w domenach AD (język polski).

http://www.microsoft.com/learning/en/us/book.aspx?ID=9552&locale=en-us – świetna książka, którą mogę z czystym sercem polecić.

Bartosz Pawłowicz

Ograniczanie dostępu dla użytkownika Windows

Witajcie

Tekst który właśnie czytacie rozpoczyna cykl artykułów poświęconych zagadnieniom związanym z serwerowymi i klienckimi systemami Windows. Cały cykl jest tak naprawdę zainspirowany przez pytania moich studentów – często pracujących w firmach gdzie wykorzystywane są te systemy operacyjne, niejednokrotnie zupełnie niezwiązanych z informatyką, a zachodzi potrzeba zaawansowanej ich konfiguracji i moją własną praktyką. Tak więc cykl ten nie będzie kursem jako takim. Będzie to raczej przewodnik objaśniający co można zrobić i gdzie szukać konkretnych informacji jak. Każdy odcinek jest poświęcony jednemu zagadnieniu. Postaram się jednak, żeby żadne z nich nie było wzięte z powietrza. Dzisiejszy jest poświęcony konfiguracji klienckiego systemu Windows.

Więc do rzeczy. Któregoś dnia otrzymałem pytanie od mojego studenta – jak skonfigurować system tak aby użytkownik miał dostęp tylko do jednej aplikacji. Na moje pytanie o istnienie domeny otrzymałem odpowiedź, że nie wchodzi w grę instalacja żadnych serwerów a wszystko musi być skonfigurowane na klienckim systemie Windows. Na moje pytanie co z danymi użytkowników i jaka to aplikacja otrzymałem wreszcie więcej odpowiedzi. Okazało się, że mój student jest pracownikiem firmy zajmującej się wdrażaniem zaawansowanych systemów … alarmowych i nadzoru (czyli czujniki, kamery kurtyny podczerwieni itd.) i z zaawansowaną konfiguracją komputerów ma niewiele do czynienia . Obecnie systemy te oparte są na komunikacji w oparciu o protokół IP, a aplikacja o którą pytałem, to specjalizowany program służący do przechwytywania i zarządzania danymi zebranymi
z kamer IP i czujników alarmowych, dymu itd., a implementacja AD nie wchodzi w grę ze względu na koszty, natomiast pracownicy zatrudnieni do obsługi tego systemu mają w żadnym wypadku „nie grzebać” w komputerach na których oprogramowanie do zarządzania takim systemem jest zainstalowane, a żadne dane użytkowników nie są na nich przechowywane.

Pierwszym krokiem niezbędnym do tego aby zadany problem był w ogóle rozwiązywalny jest wybór odpowiedniego sytemu operacyjnego. W przypadku będących aktualnie na rynku systemów czyli Windows XP i Vista są to wersje XP Professional i Vista Business, Ultimate i Enterprise.

Aby skonfigurować maszynę wedle postawionych warunków posłużymy się konsolą zarządzania kontami użytkowników, konsolą zarządzania MMC i ustawimy odpowiednio dostęp do systemu plików.

Konsolę zarządzania użytkownikami (rys. 1) wywołać można za pomocą linii poleceń poprzez podanie polecenia lusrmgr.msc.

Rys. 1. Okna: a) edytora użytkowników, b) edytora grup.

Konsola pozwala na dodanie nowych użytkowników, a także dodanie ich do istniejących grup lub do stworzonych przez Nas grup zabezpieczeń. W omawianym przypadku należy stworzyć konto każdemu pracownikowi mającemu dostęp do tej komputera. Unikać należy tworzenia kont bez haseł i „dla wszystkich”. Teraz następuje trudniejszy krok czyli wybór grupy do której ma należeć dana osoba.
W postawionym zadaniu osoby mające dostęp do danej maszyny powinny mieć zablokowaną możliwość przechowywania na niej swoich plików osobistych. W takim przypadku pozostaje dodanie pracowników mających dostęp do komputera do grupy Goście. Wybieramy tą grupę ponieważ profil gościa jest tworzony przy każdym logowaniu i kasowany po wylogowaniu. W przypadku wszystkich innych grup zabezpieczeń tworzony przy logowaniu profil pozostawiany jest na stałe na dysku – jak więc nietrudno się domyślić możliwe byłoby zapełnienie całego dysku twardego nie tylko danymi użytkowników pozostającymi w profilach, lecz także samymi profilami użytkowników.

Kolejnym problemem jaki rodzi się przy takim zdefiniowaniu użytkownika jest to jak zapewnić Mu skonfigurowany przez administratora profil (np. na pulpicie logujących się użytkowników ma być tylko skrót do aplikacji, której używają). Można tego dokonać poprzez utworzenie dodatkowego konta użytkownika należącego do grupy Użytkownicy a następnie przez skopiowanie tak skonfigurowanego profilu do profilu domyślnego (rys. 2) na podstawie którego tworzone są przy pierwszym logowaniu pozostałe profile i oczywiście profile gości. Aby mieć możliwość kopiowania profilu musimy być zalogowani jako administrator ponieważ nie jest możliwe kopiowanie danego profilu w momencie kiedy jesteśmy zalogowani jako użytkownik aktualnie z niego korzystający. Dodatkowo ścieżka do profilu domyślnego musi być podana ręcznie a kopiowanie wymaga dodatkowego potwierdzenia (rys. 2). Użytkownika , którego utworzyliśmy w celu zrealizowania pożądanej w tym przypadku konfiguracji pulpitu, menu start itd. oczywiście usuwamy pamiętając również o ręcznym usunięciu jego profilu.

Rys. 2. Przykład kopiowania profilu użytkownika.

Kolejnym krokiem jest skonfigurowanie polityk lokalnych. W przypadku systemu Windows XP wygodnie jest skorzystać bezpośrednio z edytora zasad grup wywoływanego za pomocą polecenia gpedit.msc ponieważ zasady te i tak stosują się do wszystkich użytkowników danej maszyny.
W przypadku Windows Vista wygodniej jest skorzystać z konsoli MMC wywoływanej po prostu za pomocą polecenia mmc. W przypadku tego systemu jest to wygodniejsze rozwiązanie ponieważ możemy definiować wiele obiektów zasad grup lokalnych (w XP tylko jeden) stosujących się selektywnie do rożnych grup użytkowników (rys. 3).

Rys. 3. Graficzna prezentacja konfiguracji obiektu zasad grupy dla określonej grupy użytkowników.

Oznacza to że dla różnych grup użytkowników można tworzyć różne zestawy polityk lokalnych (rys. 4).

Rys. 4. Konsola MMC z dwoma gałęziami polityk dedykowanych administratorom i pozostałym grupom użytkowników.

Tak skonfigurowaną konsolę możemy zapisać i używać do niezależnej konfiguracji zestawów polityk dla różnych grup użytkowników. W omawianym przypadku administrator może wszystko, zaś zwykli użytkownicy komputera mają mieć odmówiony dostep do prawie wszystkich możliwych opcji. Obiekty zasad grup oferują TYSIĄCE ustawień systemu tak więc nie ma tutaj miejsca na omawianie wszystkich. Warto jednak wspomnieć, że za pomocą tego narzędzia możliwa jest konfiguracja systemu operacyjnego w najdrobniejszych detalach począwszy od restrykcji oprogramowania, które może uruchamiać lub nie dany użytkownik lub grupa użytkowników, przez skrypty logowania i wylogowania dla różnych grup, konfigurację ustawień sieciowych, uruchamiania usług aż po takie detale jak np. wymuszenie klasycznego menu start (rys. 5).

Rys. 5. Przykładowa konfiguracja wymuszenia klasycznego menu start dla grup innych niż administratorzy.

Ostatnim z głównych kroków konfiguracji Naszej maszyny jest ustawienie dostępu do dysków. W omawianym przypadku użytkownicy nie mają mieć dostępu do dysków twardych co skutkuje tym, że należy im odmówić wszelkich uprawnień dostępu do dysków możemy to robić zarówno odmawiając dostępu do dysków pojedynczemu użytkownikowi, jak i całej grupie (rys. 6).

Rys. 6. Konfiguracja dostępu do katalogów i plików.

Należy przy tym pamiętać, że systemem plików na komputerze musi być NTFS. Dodatkowo jeśli chcemy konfigurować zabezpieczenia w Windows XP to w opcjach folderów należy WYŁĄCZYĆ opcję prostego udostępniania plików. Dodatkowo jeśli konfigurujemy maszynę do użytku z oprogramowaniem specjalistycznym (w tym wypadku tak właśnie było) aplikacje generują często pliki wynikowe (w omawianym przypadku były to szyfrowane pliki wideo z kamer ochrony) typu wyniki obliczeń i symulacji (np. ANSYS), pliki z zapisanymi danymi o bryłach przestrzennych (np. CATIA) należy pamiętać, że dane oprogramowanie uruchamia się w kontekście danego użytkownika i aby pliki wynikowe w ogóle zostały utworzone musimy przyznać odpowiedni poziom uprawnień do katalogów roboczych danej grupie użytkowników. Najczęściej jest to modyfikacja co oznacza że aplikacja uruchomiona w kontekście danego użytkownika ma uprawnienia do odczytu, zapisu, tworzenia i wykonania plików znajdujących się w danym katalogu. Przyznanie uprawnień do katalogu nie jest tożsame z tym, że użytkownik bądź grupa będą się w stanie do niego dostać ponieważ jeśli rozsądnie skonfigurujemy polityki lokalne nie będą mieć możliwości podania ścieżki do określonej lokalizacji lub w ogóle nie będą mieli możliwości poznania ścieżki do niej prowadzącej.

Na koniec kilka ciekawych odnośników do zasobów w sieci i literatury odnośnie konfiguracji systemu Windows Vista:

http://technet.microsoft.com/en-us/library/cc766291(WS.10).aspx – ciekawy artykuł omawiający polityki lokalne (język angielski)

http://www.microsoft.com/poland/technet/article/vista.mspx – fajne artykuły ekspertów na temat Windows Vista (język polski)

http://207.46.16.252/en-us/magazine/2007.06.acl.aspx – artykuł z „Technet Magazine” przybliżający mechanizmy kontroli dostępu do dysków i plików

http://www.microsoft.com/learning/en/us/book.aspx?ID=9361&locale=en-us – opis i streszczenie świetnej książki „Windows Vista Inside Out”

W kolejnym odcinku w oparciu o informacje z niniejszej publikacji przybliżę projekt małej szkolnej pracowni komputerowej. Na tym przykładzie postaram się również przybliżyć technologię Active Directory i korzyści płynące z wirtualizacji.

Bartosz Pawłowicz