Windowsy w lesie

Tytułem króciutkiego wstępu- cykl wpisów dotyczył będzie pracy z usługą Active Directory (zamiennie nazywaną domeną) na poziomie podstawowym. Cykl liczyć będzie 3‑4 odcinki, chyba że najdzie mnie wena na więcej. Pierwszy, niniejszy, wpis dotyczył będzie samej teorii na temat AD i wiele się z niego nie będzie można dowiedzieć z praktycznego użytku. Drugi wpis dotyczył będzie GPO i okolic, trzeci samego planowania powstania AD, a na czwarty nie mam jeszcze pomysłu. Zaczynam więc.

Nudna teoria

U samej podstawy powstania usługi Active Directory było rozwiązanie problemu lokalności kont zakładanych w systemach operacyjnych w przedsiębiorstwach. I tutaj dygresja. Stosowanie Active Directory ma sens tylko i wyłącznie w przedsiębiorstwach (szkołach, uczelniach itd.), w których pracuje przynajmniej kilkanaście komputerów i występuje potrzeba zdalnego nimi zarządzania. Wyobraźmy sobie przedsiębiorstwo Przykład, które zatrudnia kilkaset pracowników, w firmie uruchomiono kilka serwerów, dodatkowo rozlokowano przedsiębiorstwo w kilku lokacjach. No i nagle pojawia się potrzeba, by Pani Krysi z kadr, w oddziale leżącym kilkaset kilometrów dalej, nadać uprawnienia do zapisu w folderze Program Files. Pracownik działu IT poszukuje więc informacji o komputerze, używanym przez Panią Krysię, wyciąga z niej informacje o haśle na konto Administrator, podłącza się do jej komputera i nadaje jej uprawnienia. Koszmar. Można oczywiście inaczej. Można na przykład nadać odpowiednie uprawnienia dla konta znajdującego się na innym komputerze, ominiemy konieczność wyszukiwania hasła. Ale i to nie wygodne. Więc może te samo hasło na każdym z komputerów? I cała polityka bezpieczeństwa w kant stołu do roztrzaskania.

Mniej nudna praktyka

Stawiamy więc domenę. Przedsiębiorstwo Przykład decyduje się na zakup komputera wyposażonego w Windows Server 2003 (albo 2008) i stawia na nim usługę Active Directory. Nazywa ją Przyklad.local i od tej pory nie przejmują się ograniczeniami lokalnych kont. To oczywiście tylko zręby domeny. Należy utworzyć odpowiednia konta w domenie dla użytkowników i ewentualnie komputerów by domena mogła spełniać swoje zdania. Dobrym zwyczajem jest również wyłączenie wszystkich kont lokalnych na komputerze z uruchomioną usługa AD. Podstawowa konfiguracja domeny pozwala na zalogowanie się na komputer będącym członkiem domeny wraz ze swoimi uprawnieniami bez konieczności konfigurowania konta lokalnie. Warto podkreślić, że konta tworzone są nie tylko dla użytkowników, ale także dla komputerów. Oznacza więc to, iż możliwe jest takie nadanie uprawnień, iż każdy użytkownik używającego komputera XXX1 będącego członkiem domeny Przyklad.local będzie wyposażony w specjalne uprawnienia na innym komputerze, zasobie lub w samej domenie. Możliwości są nieskończone.

Jak dokładniej wygląda domena? Bez wchodzenia w szczegóły (żeby część 3 cyklu miała sens) przypomina drzewo. U jego podstawy jest/są kontrolery domeny (czyli komputery wyposażone w win srv 2003 i wyższy, skonfigurowane w tym celu) następnie znajdują się foldery (nazywane kontenerami). Domyślnie powstaje ich kilka – m.in. Users, Computers i Domain Controlers. Nic nie stoi jednak na przeszkodzi by tworzyć kolejne. Łatwo możemy sobie wyobrazić, iż rezygnujemy z używania kontenerów Users i Computers, zamiast tego tworzymy własne. Firma Przykład ma swój oddział w Łodzi i Warszawie. Dlatego tworzy kontenery o tych nazwach. W nich tworzone są kontenery dla każdego z działów, a dopiero w nich kontenery dla użytkowników i komputerów. Mamy więc coś na kształt drzewa, na liściach którego wypisane są nazwy użytkowników i komputerów.

Pozostaje ważny element, o którym jeszcze nie wspomniałem. W jaki sposób następuje logowanie? W windowsach XP, Vista i 7 możliwe jest takie skonfigurowanie systemu, by przy uruchamianiu pokazywał wszystkie znane konta lokalne (oczywiście jest możliwość wykluczenia konta z takiej listy). Po wybraniu konta, system sprawdza, czy konto posiada hasło, jeśli posiada, zostanie wyświetlona informacja na ten temat, po wpisaniu poprawnego konta zostaje załadowany odpowiedni klucz rejestru zawierający informacje m.in. %userprofile%. Bardzo podobnie działa komputer będący członkiem domeny. Z dwoma wyjątkami. Po pierwsze nie ma możliwości wybrania konta z listy, zawsze należy ja wpisać (można tak skonfigurować system, by wyświetlała się nazwa ostatniego poprawnie zalogowanego konta), po drugie autentykacja nie odbywa się lokalnie, tylko przez domenę. Obrazowo: Windows przychodzi do kontrolera domeny i mówi mu: tutaj masz moją nazwę konta, tutaj masz moje hasło, co mam zrobić? Kontroler domeny sprawdza, czy konto istnieje (jeśli nie- wyświetl informację), czy konto nie zostało wyłączone (jeśli zostało- wyświetl informację) i na końcu czy hasło jest poprawne (jeśli nie- wyświetl informację). Jeśli wszystko jest ok., następuje zalogowanie. Dodatkowo kontroler domeny przesyła informację o GPO (szczegóły w kolejnej części) oraz przynależności użytkownika do grup. Reszta odbywa się lokalnie (tzn. wczytanie kluczy z rejestru).

Może pojawić się pytanie, co się stanie, jeśli komputer lokalny nie będzie mógł się skomunikować z domeną? System po poprawnym zalogowaniu keszuje informację o użytkowniku (login, hasło, datę wygaśnięcia itd.) i pozwala na jego zalogowanie bez dostępu do domeny. Pozwala to na swobodną pracę przez użytkowników laptopów. Jednak nie zostaną w takiej sytuacji zaktualizowane GPO, a w przypadku pływających pulpitów pliki nie zostaną synchronizowane.

Wreszcie koniec

No i krótko na temat kolejnego wpisu. Czy nie chciałeś, drogi czytelniku, móc skonfigurować odgórnie przeglądarkę dla użytkowników w swojej firmie? Czy nie irytuje cię, że pracownik sobie coś poprzestawiał a teraz mu nie działa? Użytkownik nie rozumie często dlaczego 11 gigowy plik pst nie jest dobrym rozwiązaniem i nie zechce sobie skonfigurować automatycznej archiwizacji maili. Dlatego właśnie powstało GPO. O nim w następnym odcinku.