Posts Tagged by Active Directory
Managed Service Accounts
| 2012-02-20 | Posted by TechNet Polska under Grzegorz Tworek, IT Pro blogerzy, konfiguracja, Polskie blogi IT, procesy i usługi, Zarządzanie środowiskiem |
|
Jednym z najważniejszych pojęć w przypadku bezpieczeństwa systemów Windows jest "kontekst". Pojęcie to ma podstawy w obowiązującym w całym systemie założeniu, że jeżeli coś się dzieje, to musi istnieć możliwość określenia kto to zrobił i dlaczego. Dlatego proces zawsze ma "swojego" użytkownika, dzięki któremu wiadomo ile mu wolno i na którego rachunek zapisywane są wykonane działania.
Dla procesów użytkownika sprawa jest dość oczywista. Użytkownik X uruchamia notepad.exe i proces ten może otworzyć te pliki, do których użytkownik X ma dostęp. Jeżeli włączone jest rejestrowanie dostępu do plików – do dziennika zdarzeń trafi informacja, że do pliku sięgnął użytkownik X. Ciekawiej jednak robi się w sytuacji, gdy w systemie coś "dzieje się samo" i to system a nie żywy użytkownik inicjuje działania. Przykładem mogą być usługi systemowe (services). Tam, gdzie mają one postać procesu muszą mieć swojego użytkownika. Zazwyczaj jest to specjalny użytkownik "SYSTEM", który ma ogromne uprawnienia na danym komputerze, ale sięgając gdzieś przez sieć – już niekoniecznie. Fakt, że konto SYSTEM jest równocześnie potężne i ograniczone sprawia, że nie zawsze nadaje się ono do usług systemowych mających mniej standardowe zadania. Dobra praktyka w takim przypadku nakazywała utworzenie specjalnego, serwisowego użytkownika w Active Directory i uruchamianie usługi w kontekście jego konta. Mimo, że podejście to wielu lat jest powszechnie stosowane, ma jedną bardzo istotną wadę: konto serwisowe jest tak naprawdę zwykłym kontem użytkownika, a jego hasło ma kluczowe znaczenie dla działania usługi.
- Po pierwsze: niezgodność hasła na komputerze z hasłem w AD uniemożliwi działanie usługi.
- Po drugie: odczytanie hasła usługi jest technicznie możliwe (polecam doskonały artykuł Michała Grzegorzewskiego).
- Po trzecie: hasła powinny być okresowo zmieniane, aby zapewnić ich skuteczność.
W efekcie, poprawne zarządzanie kontami usług wymaga ogromnej dyscypliny a ewentualne pomyłki mogą spowodować niedostępność ważnych usług zapewnianych przez system informatyczny przedsiębiorstwa.
Dlatego, w Windows Server 2008 R2 wprowadzony został nowy mechanizm Managed Service Accounts. Z punktu widzenia komputera uruchamiającego usługę jest to możliwe do wykorzystania konto, podczas gdy po stronie Active Directory zamiast użytkownika (obiektu User) przechowywany jest obiekt typu msDS-ManagedServiceAccount.
Aby wszystko działało, koniecznie jest poinformowanie komputera, że ma używać takiego konta dla swoich usług oraz utworzenie samego obiektu w Active Directory. Od strony komputera uruchamiającego usługę wymagania są proste: Windows 7 / 2008 R2 lub nowszy. Od strony domeny można niby użyć nawet poziomu funkcjonalnego 2003, ale dopiero na 2008 R2 cały mechanizm rozwija skrzydła i w pełni automatycznie zarządza hasłami i SPNami.
Zakładam, że usługę już mamy. Teraz, żeby użyć MSA, należy wykonać następujące działania:
- Założyć MSA w Active Directory. Najlepiej przez PowerShella z modułem do zarządzania Active Directory, używając cmdlet New-ADServiceAccount. Nazwa obiektu powinna być taka jak nazwa serwisu, czyli w moim przypadku GTSvc. Domyślny kontener to specjalnie w tym celu istniejący "Managed Service Accounts".
- Przygotować hostujący usługę serwer do użycia MSA. PowerShellem można to zrobić instalując moduły do AD i używając cmdletu Install-ADServiceAccount. Pominięcie tego kroku uniemożliwi start usługi.
- Skonfigurować serwis tak, aby używał konta nazwa_domeny\nazwa_msa$ i nie podawać żadnego hasła.
Gotowe. Można uruchomić serwis i podejrzeć na przykład Process Explorerem, że nie jest związany z żadnym użytkownikiem. 
Na koniec jedna ważna uwaga dotycząca ogólnie serwisów a nie samego mechanizmu MSA. Jeżeli użytkownik ma prawa zapisu do folderu, w którym znajdują się binaria serwisu (plik exe), może zmienić nazwę oryginalnego pliku i wgrać swój. Przy najbliższym restarcie serwisu (najpóźniej przy okazji restartu systemu) zostanie uruchomiony plik użytkownika i może narobić sporo złych rzeczy łącznie z przejęciem pełnej kontroli nad serwerem. Dlatego, przechowując binaria serwisów w niestandardowych miejscach należy bardzo dokładnie zweryfikować uprawnienia do folderów. MSA może pozwolić na ograniczenie skutków ataku (na pewno jest bezpieczniej niż z kontem SYSTEM) ale to dalej może być więcej niż prawowity administrator ma ochotę pozwolić.
Autor: Grzegorz Tworek [MVP]
Adobe Flash Player – instalacja przez GPO, wyłaczenie aktualizacji, potencjalne błedy przy wdrożeniu
| 2012-01-05 | Posted by losiak under Adobe Flash Player, GPP, installax.exe, mms.cfg, Polskie blogi IT, Windows 2008 R2 |
|
Adobe Flash Player (AFP) – mały dodatek do przeglądarki pozwalający odtworzyć w niej elementy strony napisane w technologii Flash. Mały, ale denerwujący w momencie uaktualnienia – po pierwsze dość natarczywie sygnalizuje dostępność aktualizacji a po drugie do instalacji nowej wersji wymagane są uprawnienia administratora – co w większej sieci jest już sporym problemem.
Artykuł zakłada wykorzystanie domeny Active Directory opartej o system Windows 2008 R2 (poziom domeny i lasu Win 2008 R2) oraz stacji roboczych Windows 7 Professional w wersjach 32 i 64 bitowych. Aktualizacja obejmuje Flash Playera z wersji 10.3 do w wersji 11.1.
1. Instalacja za pomocą GPO
Od wersji 11.1 wtyczki Adobe Flash Playera podzielone są te dedykowane do wersji 32-bitowej systemu i te do wersji 64-bitowej systemu. W konsekwencji daje nam to 4 pakiety instalacyjne (wtyczka dla IE – ActiveX oraz dla innych przeglądarek – plugin).
Przygotowane paczki instalacyjne (pakiety .msi) możemy ściągnąć ze strony Adobe http://www.adobe.com/special/products/flashplayer/fp_distribution3.html
Pliki te umieszczamy na wcześniej przygotowanym zasobie sieciowym (punkt dystrybucyjny, z którego komputery klienckie pobiorą instalacje pakietów) z nadanymi prawami do odczytu na poziomie sieci (w zupełności wystarczą) dla Użytkowników Domeny oraz Komputerów Domeny.
Podział pakietów na wersje 32 i 64-bitowe zmusza nas do przygotowania dwóch polityk – każda do konkretnej wersji systemu. Gwarancję zastosowanie GPO tylko dla przeznaczonej do tego wersji systemu zapewniają nam nałożone na nie filtry WMI (filtrujące pod względem architektury systemu Windows 7 – do znalezienia tu).
Utworzenie każdego z tych dwóch GPO polega na konfiguracji gałęzi: Konfiguracja komputera > Zasady > Ustawienia oprogramowania > Instalacja oprogramowania. Wybierając z menu Akcja > Nowy > Pakiet (lub wybierając Nowy pod prawym klawiszem myszy) wybieramy pakiet, który chcemy zainstalować czyli przygotowany przez nas plik .msi. Ścieżkę do niego zawsze podajemy jako ścieżkę UNC (czyli sieciową). Pakiet ma być zainstalowany obowiązkowo na wszystkich komputerach (wszystkich objętych polityką) dlatego konfigurujemy go jako Przypisany. W opcjach zaawansowanych możemy zaznaczyć Ignoruj język w czasie rozmieszczania pakietu.
Tak skonfigurowane politykę linkujemy z OU, w którym znajdują się komputery klienckie, na których Adobe Flash Player ma się zainstalować . Wykonujemy to za pomocą np. przystawki GPMC.
2. Wyłączenie autoupdate Adobe Flash Player
Możliwość wyłączenia auto update FlashPlayera opisana jest tu http://kb2.adobe.com/cps/167/16701594.html. Opis ten jest dość stary i na potrzeby Windows 7 należy go poprawić.
Po pierwsze przygotowujemy plik mms.cfg. Jest to zwykły plik tekstowy, zakodowany w UTF-8 z następującym wpisem (jedna linijka tekstu, bez żadnych spacji).
AutoUpdateDisable=1
Plik taki musimy mieścić w:
- Windows 7 32-bit – C:\Windows\System32\Macromed\Flash\
- Windows 7 64-bit – C:\Windows\SysWOW64\Macromed\Flash\
Operacje taką możemy przeprowadzić za pomocą „preferencji” zasad grupy czyli Group Policy Preferences http://technet.microsoft.com/pl-pl/library/group-policy-preferences—cz-3.aspx.
Utworzony plik umieszczamy na identycznie przygotowanym (lub tym samym) zasobie jak w pkt.1 i konfigurujemy politykę, która umieści go w odpowiedniej ścieżce na dysku lokalnym stacji klienckiej.
Utworzenie polityki polega na konfiguracji gałęzi Konfiguracja komputera > Preferencje > Ustawienia systemu Windows > Pliki.
Wybierając z menu Akcja > Nowy > Plik na karcie Ogólne ustawiamy:
Akcja: Aktualizuj
Pliki źródłowe: \\serwer\zasob\mms.cfg
Plik docelowy: C:\Windows\System32\Macromed\Flash\
oraz drugi wpis
Akcja: Aktualizuj
Pliki źródłowe: \\serwer\zasob\mms.cfg
Plik docelowy: C:\Windows\SysWOW64\Macromed\Flash\
Bardzo pomocną opcją jest zaznaczenie na karcie Właściwości:mms.cfg > Wspólne zaznaczenie elementu Usuń ten element, jeśli nie jest stosowany. Konfiguracja taka pomaga utrzymać porządek ponieważ w momencie kiedy polisa przestaje być stosowana (np zostanie skasowana lub użytkownik zostanie przeniesiony do innego OU, do którego dana polisa nie jest podpięta) plik zostaje usunięty z dysku lokalnego. Zaznaczenie tej opcji skutkuje zmianą pola Akcja na Zamień.
UWAGA – wpisy możemy (podobnie jak GPO z instalacja Flash Playera) rozbić na dwie polityki przeznaczone dla odpowiednich edycji systemu Windows. Natomiast połączenie ich – w przeciwieństwie do polityk instalacyjnych – nie będzie skutkowało żadnymi błędami.
Sprawdzenie czy polityki wykonały się poprawnie czyli zainstalował się Adobe Flash Player oraz zostało wyłączone powiadomienie o auto aktualizacji możemy wykonać wchodząc na stronę http://www.adobe.com/software/flash/about/ gdzie zobaczymy jaką wersję AFP mamy zainstalowaną. Klikając prawym klawiszem myszy na element Flash otworzy nam się menu gdzie poprzez Ustawienia globalne > Zaawansowane możemy sprawdzić harmonogram aktualizacji. Jeżeli opcje są wyszarzone oznacza to ze poprawnie wyłączyliśmy auto aktualizację.
3. Błędy przy wdrożeniu
Czasami przy aktualizacji Adobe Flash Playera występują błędy uniemożliwiające zainstalowanie nowej wersji.
Błędy głównie objawiają się następującym komunikatem (lub wpisem w logach)
"The file 'installax.exe' is not marked for installation"
Wynika to niepoprawnego odinstalowania poprzedniej wersji Adobe Flash Reader (w przystawce Odinstaluj Programy go nie ma) i pozostawieniem wpisów w rejestrze.
Rozwiązanie jest proste. Trzeba te wpisy usunąć.
Dla Windows 7 (i 32 i 64 bitowych) oraz wersji 10.3 Adobe Flash Playera są to następujące klucze.
[HKEY_CLASSES_ROOT\Installer\Features\13186D9F09478444CA54B7FB3B93F2F8]
[HKEY_CLASSES_ROOT\Installer\Features\4195BD842778D2748BFD2E90B25E896F]
[HKEY_CLASSES_ROOT\Installer\Products\4195BD842778D2748BFD2E90B25E896F]
[HKEY_CLASSES_ROOT\Installer\Products\13186D9F09478444CA54B7FB3B93F2F8]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Features\13186D9F09478444CA54B7FB3B93F2F8]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Features\4195BD842778D2748BFD2E90B25E896F]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Products\13186D9F09478444CA54B7FB3B93F2F8]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Products\4195BD842778D2748BFD2E90B25E896F]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\13186D9F09478444CA54B7FB3B93F2F8]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\4195BD842778D2748BFD2E90B25E896F]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{48DB5914-8772-472D-B8DF-E2092BE598F6}]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{F9D68131-7490-4448-AC45-7BBFB3392F8F}]
Można to zrobić poprzez uruchomienie pliku .reg na stacji klienckiej lub w większym środowisku za pomocą GPP.
Utworzenie polityki polega na konfiguracji gałęzi Konfiguracja komputera > Preferencje > Ustawienia systemu Windows > Rejestr. Wybierając z menu Akcja > Nowy > Element Rejestru ustawiamy:
Akcja: Usuń
Gałąź : HKEY_CLASSES_ROOT
Ścieżka klucza: Installer\Features\13186D9F09478444CA54B7FB3B93F2F8
W analogiczny sposób dodajemy do tej polityki następne klucze.
Po jej zastosowaniu Adobe Flash Player w nowej wersji powinien sie zainstalować bez przeszkód.
UWAGA – Identyfikatory są unikalne dla danej wersji Adobe Flash Playera dlatego w przypadku innych niż 10.3 trzeba je sobie znaleźć samemu. Najlepiej instalując Flasha w danej wersji na maszynie testowej i przeszukując rejestr.
Przydatne linki
| 2012-01-05 | Posted by losiak under linki, Polskie blogi IT, Przydatne linki, Windows Firewall |
|
- http://blogs.technet.com/b/askds/archive/2011/04/12/you-probably-don-t-need-acctinfo2-dll.aspx – jak wykorzystać przystawki MMC do zebrania informacji o zaawansowanych atrybutach użytkownika – np czas ostatniego logowania, blokadę konta itd
- http://technet.microsoft.com/en-us/library/cc780637%28WS.10%29.aspx – Managing Antivirus Software on Domain Controllers
- wdrażanie zasad Windows Firewall with Advanced Security – http://technet.microsoft.com/pl-pl/library/poradnik-krok-po-kroku-instalowania-zasad-dla-programu-windows-firewall-with-advanced-security-cz-i.aspx
- http://technet.microsoft.com/pl-pl/library/obsluga-zapory-sieciowej-windows-firewall-with-advanced-security-w-systemach-windows-vista-i-windows-server-2008—cz-2.aspx
GPP, mapowany dysk i skrót do pliku – błąd 0×8007002, ID 4098
| 2011-12-21 | Posted by losiak under 0x8007002, disk mapping, GPP, Group policy preferences, ID 4098, mapowanie dysku, Polskie blogi IT, shortcut, skrót, Windows 2008 R2 |
|
Jedną z podstawowych potrzeb w firmowej sieci jest udostępnienie wspólnego, dla grupy użytkowników, zasobu.
Często taki zasób zawierający jakąś aplikację musimy zaprezentować stacjom klienckim jako kolejny dysk (np ze względu na specyficzne dla danej aplikacji zmienne środowiskowe, chociażby ścieżki do plików definiowane w plikach .ini). Dodatkowo chcielibyśmy ułatwić użytkownikom prace dodając skrót do takiej aplikacji np. na Pulpicie.
Do tego zadania, w środowisku domenowym, możemy wykorzystać mechanizm Group Policy Preferences.
W dalszej procedurze nie zagłębiam się w kwestie bezpieczeństwa (czyli ACLki położone na zasobie serwerowym) oraz linkowanie polis do odpowiednich OU.
1. Podmapowanie zasobu na stacji klienckiej jako kolejny dysk
Mając przygotowany zasób na serwerze ( \\serwer\zasob ) tworzymy nowy element preferencji w: Konfiguracja użytkownika > Preferencje > Ustawienia systemu Windows > Mapowania dysków
Prawym klawiszem wywołujemy menu gdzie klikamy Nowy > Dysk zamapowany
Na karcie Nowe właściwości dysku > Ogólne ustawiamy:
Akcja: Aktualizuj
Lokalizacja: \\serwer\zasob
Połącz ponownie
Oznacz jako: ZASOB (tu wpisujemy dowolną nazwę zamapowanego dysku)
Litera dysku> istniejąca: Z (tu wpisujemy literę pod jaką ma być widoczny zamapowany dysk)
Pokaż ten dysk
Na karcie Nowe właściwości dysku > Wspólne możemy zaznaczyć Uruchom w kontekście zabezpieczeń zalogowanego użytkownika
Od tej pory na stacji klienckiej powinien pojawić sie w Mój komputer dysk Z o nazwie ZASOB z zawartością folderu udostępnionego \\serwer\zasob .
2. Utworzenie skrótu na pulpicie użytkownika.
Na podmapowanym w poprzednim punkcie dysku Z mamy aplikację aplikacja.exe, do której chcielibyśmy zrobić skrót na Pulpicie. W tym celu tworzymy nowy element preferencji w : Konfiguracja użytkownika > Preferencje > Ustawienia systemu Windows > Skróty
Na karcie Nowe właściwości skrótu > Ogólne ustawiamy:
Akcja: Aktualizuj (ścieżka przykładowa – oczywiście możemy wybrać ikonę dowolną z pliku .ico lub innego zawierającego ikony umieszczonego lokalnie na zasobie sieciowym)
Nazwa: APLIKACJA
Typ docelowy: adres URL
Lokalizacja: file://z:/aplikacja.exe
Ścieżka pliku ikony: %SystemRoot%\system32\SHELL32.dll
Na karcie Nowe właściwości dysku > Wspólne możemy zaznaczyć Uruchom w kontekście zabezpieczeń zalogowanego użytkownika
Po odświeżeniu polityk na Pulpicie powinien nam się pokazać wcześniej zdefiniowany skrót.
UWAGI:
Skrót do pliku można utworzyć z parametrami
Typ docelowy: Obiekt systemu plików
Ścieżka: C:\folder\aplikacja.exe
O ile w przypadku skrótu do pliku na dysku lokalnym nie zauważyłem problemów o tyle w przypadku skrótu do pliku na dysku zamapowanym możemy sie spotkać z sytuacją braku skrótu na Pulpicie (lub miejscu gdzie chcieliśmy go utworzyć) oraz błędem w Podglądzie zdarzeń > Aplikacja:
Zródło: Group Policy Shortcuts
Identyfikator: 4098
Opis: Element preferencji "nazwa" użytkownik w obiekcie zasada grupy "nazwa_polisy {SID polisy}" nie ma zastosowania z powodu błędu o kodzie "0x80070002 Nie mozna odnaleźć określonego pliku" ten bład został pominięty.
Z doświadczenia mogę powiedzieć, że rozwiązaniem jest zdefiniowanie docelowego typu obiektu jako adres URL.
Bardzo pomocną opcją jest zaznaczenie na karcie Nowe właściwości dysku > Wspólne zaznaczenie elementu Usuń ten element, jeśli nie jest stosowany. Konfiguracja taka pomaga utrzymać porządek ponieważ w momencie kiedy polisa przestaje byc stosowana (np zostanie skasowana lub użytkownik zostanie przeniesiony do innego OU, do którego dana polisa nie jest podpięta) skrót zostaje z pulpitu usunięty.
Problemy z replikacją AD pomiędzy SBS 2003 i Windows 2000 – ERROR_DOMAIN_CONTROLLER_NOT_FOUND
| 2011-11-29 | Posted by pawp81 under Polskie blogi IT |
|
Ostatnio zmagałem się z problemem dotyczącym replikacji AD Inter-Site pomiędzy serwerami Small Business Server 2003 i Windows 2000 SP4. Łącze między lokalizacjami było bardzo słabe. Serwer SBS 2003 był pierwszym kontrolerem w domenie i posiadał wszystkie role FSMO. Przy promocji serwera Windows 2000 do roli kontrolera domeny w logu dcpromo.log znalazłem następujące ostrzeżenie: [WARNING] Non critical replication returned 1908
Błąd 1908 oznacza: ERROR_DOMAIN_CONTROLLER_NOT_FOUND
dcdiag /v uruchomiony na serwerze Windows 2000 zwracał poniższy komunikat:
The directory service on DC002 has not finished initializing. In order for the directory service to consider itself synchronized, it must attempt an initial synchronization with at least one replica of this server's writeable domain. It must also obtain Rid information from the Rid FSMO holder. The directory service has not signalled the event which lets other services know that it is ready to accept requests. Services such as the Key Distribution Center, Intersite Messaging Service, and NetLogon will not consider this system as an eligible domain controller. * Active Directory RPC Services Check
Za pomocą replmon sprawdziłem, że nie działa replikacja z SBS 2003 do Windows 2000 (błąd: Nie można odnaleźć kontrolera tej domeny). W drugą stronę replikacja działa poprawnie.
Wymuszając replikację za pomocą replmon i analizując pakiety zauwyżyłem, że serwer Windows 2000 wysyłał pakiety TGS-REQ do SBSa używając protokołu UDP, ale serwer SBS nie wysyłał odpowiedzi. Postanowiłem wymusić korzystanie z protokołu TCP dla Keberosa ponieważ uważałem, że na słabym łączu pakiety TCP mają większe szanse na dotarcie. 
Stworzyłem odpowiedni wpis w rejestrze: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\ Kerberos\Parameters
DWORD MaxPacketSize=1 opierając się na artykule http://support.microsoft.com/kb/244474 Zrestartowałem serwer. Po restarcie replikacja zaczęła działać również w kierunku z SBS 2003 do Windows 2000. Po kilku minutach dcdiag przestał pokazywać błędy dotyczące braku początkowej synchronizacji AD.
Enrollment agent i ‘Żądaj w imieniu’ – No certificate available. No certificates meet the application criteria
| 2011-11-28 | Posted by marcinbojko under ca, certyfikat, Polskie blogi IT |
|
Tymże dwoma frazami w zupełnie różnych językach opisuję problem nad jakim przesiedziałem ostatnio trochę czasu. Otóż historia wygląda tak.
Istnieje w domenie AD serwer spełniający rolę CA – nazwijmy go roboczo ‘ca’ (popis, nie?). Mamy rozrzucone po świecie stacje robocze, na których wskazani przez nas użytkownicy mogą przeprowadzać operację generowania certyfikatów dla kolejnych użytkowników naszej domeny. Stacje robocze pracują pod kontrolą W7/Visty/XP.
Błąd:
Cyklicznie, co pewien czas osobnik wskazany jako EA (Enrollment Agent – Agent rejestracji) tracił możliwość wystawiania w imieniu – stacja nie była w stanie odnaleźć w lokalnym kontenerze certów, żadnego certyfikatu o tej właśnie roli. Skutkowało to tym, iż pilne certyfikaty, które wygasły – były niemożliwe do wystawienia.
Rozwiązanie:
Stacja uruchomiona, użytkownik o roli EA zalogowany do domeny.
a) uruchamiamy regedit i sprawdzamy czy istnieją wpisy w
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EnterpriseCertificates\NTAuth\Certificates\
Jeżeli ‘Certificates’ są puste należy
b) uruchomić certmgr.msc. Z sekcji Trusted Sites odnaleźć certyfikat naszego CA (ca). Wyeksportować ca do pliku cer np. ca.cer
c) uruchomić zażądaj certyfikatu ‘Agent rejestracji’ – Enrollment Agent, przejść do końca procesu
d) wyeksportować tak utworzonego agenta do pliku nazwisko.cer
e) certutil -enterprise -addstore NTAuth nazwisko.cer
f) certutil -enterprise -addstore NTAuth ca.cer
We wskazanym kluczu możemy zaobserwować 2 bloby. Koniec. Działa.
Tagged: active directory, ca, certyfikat, windows 
Instalacja pakietu Java w środowisku Active Directory oraz wyłączenie Java Auto Update
| 2011-11-10 | Posted by losiak under EneblaJavaUpdate, GPMC, Java, Polskie blogi IT, Windows 2008 R2 |
|
Aby poprawnie obsługiwać aplikacje (czy tez aplety na stronach internetowych) napisane w oparciu o technologię Java stacja kliencka musi posiadać zainstalowane oprogramowanie umożliwiające korzystanie z tej technologii. Sama instalacja pakietu nie jest niczym skomplikowanym przy założeniu, że mamy kilka stacji. Przy większej ilości dystrybucja oprogramowania staje się już dość czasochłonna. W środowiskach z wdrożonymi i działającymi usługami katalogowymi Active Directory możemy do tego wykorzystać usługę Software Distribution. Przy okazji możemy tak skonfigurować pakiet aby nie męczył użytkowników irytującym komunikatem o dostępności nowej wersji (którą nota bene musimy zainstalować z prawami administracyjnymi na danej stacji).
Do zrobienia mamy:
- 1. przygotowanie pakietu instalacyjnego Java
- 2. przygotowanie i wdrożenie GPO instalującej pakiet Java
- 3. przygotowanie i wdrożenie GPO wyłączającej Auto Update Java
1. Przygotowanie pakietu instalacyjnego
Aby zainstalować oprogramowania Java używając do tego GPO musimy przygotować właściwy pakiet .msi. W tym celu posłużymy się procedura opisaną tu: http://www.java.com/en/download/help/msi_install.xml. Oczywiście nazwa pakietu przedstawiona w procedurze jest przykładowa, w rzeczywistości nazwa ta jest właściwa dla wersji Java , która instalujemy. Potrzebne będą nam pliki jre1.6.0_29.msi oraz Data1.cab (nazwa pliku .cab jest, w odróżnieniu od .msi, zawsze taka sama).
2. Przygotowanie i wdrożenie GPO instalującej pakiet Java
Na początek musimy przygotować zasób, punkt dystrybucyjny, z którego komputery klienckie pobiorą instalacje pakietu. Zasób taki przygotowujemy na serwerze z zainstalowaną rolą serwera plików i nadajemy mu prawa do odczytu na poziomie sieci (w zupełności wystarczą) dla Użytkowników Domeny oraz Komputerów Domeny. W nim umieszczamy dwa w/w pliki.
Utworzenie GPO polega na konfiguracji gałęzi: Konfiguracja komputera > Zasady > Ustawienia oprogramowania > Instalacja oprogramowania. Wybierając z menu Akcja > Nowy > Pakiet (lub wybierając Nowy pod prawym klawiszem myszy) wybieramy pakiet, który chcemy zainstalować czyli przygotowany przez nas plik .msi. Ścieżkę do niego zawsze podajemy jako ścieżkę UNC (czyli sieciową). Pakiet ma byc zainstalowany obowiązkowo na wszystkich komputerach (wszystkich objętych polityką) dlatego konfigurujemy go jako Przypisany. W opcjach zaawansowanych możemy zaznaczyć Ignoruj język w czasie rozmieszczania pakietu oraz Udostępnij tę 32-bitowa aplikacje X86 komputerom Win64
Tak skonfigurowaną politykę linkujemy z OU, w którym znajdują sie komputery klienckie , na których pakiet Java ma się zainstalować. Wykonujemy to za pomocą przystawki GPMC.
3. Przygotowanie i wdrożenie GPO wyłączającej Auto Update Java
Aby wyłączyć automatyczne aktualizacje pakietu Java na stacji klienckiej musimy zmienić wartość rejestru (dla 32-bitowego systemu operacyjnego) HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Update\Policy\EnableJavaUpdate z 1 na 0.
W wersji 64-bitowej systemu operacyjnego będzie to wartość w kluczu HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\JavaSoft\Java Update\Policy\EnableJavaUpdate.
Mając do dyspozycji domenę oparta o Windows 2008 R2 (lub 2008) możemy wykorzystać do tego “preferencje” zasad grupy czyli Group Policy Preferences http://technet.microsoft.com/pl-pl/library/group-policy-preferences—cz-3.aspx. Aby GPP prawidłowo działało po stronie systemów klienckich Windows XP oraz Vista wymaga zainstalowania specjalnego rozszerzenia Group Policy.
Przykładowo dla Windows XP 32-bit stosowne rozszerzenie można znaleźć tu Group Policy Preference Client Side Extensions for Windows.
Utworzenie polityki polega na konfiguracji gałęzi Konfiguracja komputera > Preferencje > Ustawienia systemu Windows > Rejestr. Wybierając z menu Akcja > Nowy > Element Rejestru ustawiamy:
Akcja: Aktualizuj
Gałąź : HKEY_LOCAL_MACHINE
Ścieżka klucza: SOFTWARE\JavaSoft\Java Update\Policy
Nazwa wartości: EnableJavaUpdate
Typ wartości: REG_DWORD
Dane wartości: 00000000
Dla 64-bitowych wersji systemów operacyjnych tworzymy analogiczną politykę z następującymi wartościami.
Akcja: Aktualizuj
Gałąź : HKEY_LOCAL_MACHINE
Ścieżka klucza: SOFTWARE\Wow6432Node\JavaSoft\Java Update\Policy
Nazwa wartości: EnableJavaUpdate
Typ wartości: REG_DWORD
Dane wartości: 00000000
Obie polityki linkujemy do OU, w których znajdują sie komputery, na których chcemy zastosować dane ustawienia. To, która polityka zostanie zastosowana na konkretnej maszynie klienckiej wymuszamy poprzez zastosowanie do danych GPO filtrów WMI, rozróżniających architekturę systemu operacyjnego (czy jest on 32- czy 64-bitowy).
Rozbicie instalacji pakietu Java oraz wyłączenie jego automatycznych aktualizacji można zrobić w jednej polityce. Jednak moim zdaniem warto rozbić te zadania na oddzielne GPO. Spowodowane jest to tym, że co jakiś czas warto rozdystrybuować nowa wersje pakietu (chociażby ze względów łatania luk bezpieczeństwa) tworząc nową politykę dystrybucji. A GPO z wpisem do rejestru pozostaje niezmienne.
EDIT
Instalacja, którą wykonamy z rozpakowanego pakietu instalacyjnego ma domyślnie wyłączony AutoUpdate. Czyli nie ma fiszki Update w Java Control Panel oraz nie ma klucza EnableJavaUpdate (a nawet całej gałęzi SOFTWARE\JavaSoft\Java Update\Policy) w rejestrze. Żeby je włączyć musimy przeprowadzić operacje podobną do wcześniejszej z tym, że wartość klucza EnableJavaUpdate musi byc równa 1.
Usuwanie Active Directory w Windows Server 2008
| 2011-10-12 | Posted by soisk under Polskie blogi IT |
|
Usługa Active Directory w serwerach z rodziny Microsoft odpowiedzialna jest za autentykacje użytkowników i komputerów w domenie, zarządzanie i wdrażanie zasad grup oraz kontrolę dostępu do zasobów sieciowych. W poprzednich artykułach opisałem instalację kontrolera domeny. W tym przybliżę jego deinstalację.
New MP – Active Directory Management Pack 6.0.7670.0
| 2011-10-06 | Posted by rem8 under Polskie blogi IT |
|
As new Operations Manager is coming, Microsoft decided to revamp and update whole bunch of main Management Packs to comply with new architecture of OpsMgr 2012 and fixing bugs reported by users. So at the end of the day in Europe, MS team has just released an updated version of Active Directory Management Pack 6.0.7670.0.
Is it worth?
Yes, although you have to be sure that Marnix Wolf, Kevin Holman or other popular MVPs will post bugs found in that one (as it happened in OS MP – details here). Let’s check what’s new inside. Below is an outtake from official AD MP Documentation:
- Fixes to problems reported by customers:
- Active Directory databases larger than 4 GB reported incorrectly.
- 20% of the alerts are not triggered due to wrong event ID mapping.
- Performance data is not collected due to wrong event ID mapping.
- Performance counter selected by default is wrong.
- Time skew alert is not triggered due to script defect.
- Operation master monitor is broken due to script defect.
- Frequent operation master alert description misspelled.
Fixes to architectural issues to facilitate future System Center Operations Manager releases:
- Discovery interval for client perspectives set to larger values.
- Discovery scheduler class is used on several discoveries.
- Views target a custom AD DS MP class instead of System.Entity.
- Reports target a custom AD DS MP class instead of System.Entity.
- Some discovery targets will not change Properties.
| Fix | Impact |
| Active Directory databases larger than 4 GB reported incorrectly | This prevents incorrect logging of Event ID 333 with the following text:AD Database and Log : Free space (KB) on drive is lower than the required reserved space for AD Log file. It should be at least 200000 KBytes. |
| 20% of the alerts are not triggered due to wrong event ID mapping | This prevents several event-driven rules from breaking due to using the old event sources from Windows Server 2003 in their event rules rather than the new event sources for Windows Server 2008 and Windows Server 2008 R2. |
| Performance data is not collected due to wrong event ID mapping | Prevents the following alert caused by rules that fail to collect performance data on domain controllers that run Windows Server 2008:In PerfDataSource, could not find counter NTDS, DRA Inbound Bytes Not Compressed (Within Site)/sec, in Snapshot. Unable to submit Performance value. Module will not be unloaded. |
| Performance counter selected by default is wrong | Fixes problems that prevented Replication Latency Performance data from appearing. |
| Time skew alert is not triggered due to script defect | Matches the names of arguments in a function in AD_Time_Skew.vbs to variables passed to LogScriptEvent to enable events related to time skew to be created as designed. |
| Operation master monitor is broken due to script defect | Corrected a variable name in the Discovery script so the DNS Naming Master property is discovered correctly for proper Operations Master Consistency monitoring. |
| Frequent operation master alert description misspelled | Corrected misspelling of “inconsistent.” |
| Discovery interval for client perspectives set to larger values | Discovery interval for client perspectives had an interval set too high, which could cause performance issues that could block installation of an updated management pack. |
| Discovery scheduler class is not used on several discoveries | Some workflows use System.Scheduler instead of System.Discovery.Scheduler. |
| Views target a custom AD DS MP class instead of System.Entity | This could have blocked installation of an updated management pack. |
| Reports target a custom AD DS MP class instead of System.Entity | This could have blocked installation of an updated management pack. |
| Some discovery targets will not change Properties | This problem could cause bad performance for organizations with many domain controllers. |
So as the console was still open, I’ve decided to check, how is it going. You can import it via Management Pack Catalog from Import Management Pack wizard.
As you see… [ekhm]… misspellings where corrected 
There are more changes to scripts, monitor roll-ups and there are some undocumented overrides for Read-Only Domain Controllers, so please check the whole documentation. After importing the MP – nothing happened. My console is still alive, alerts are ok, performance is ok. Going to look for mistakes now 
Download the NEW AD Management Pack!
Usuwanie Active Directory w Windows Server 2003
| 2011-10-01 | Posted by soisk under Polskie blogi IT |
|
Usługa Active Directory w serwerach z rodziny Microsoft odpowiedzialna jest za autentykacje użytkowników i komputerów w domenie, zarządzanie i wdrażanie zasad grup oraz kontrolę dostępu do zasobów sieciowych. W poprzednich artykułach opisałem instalację kontrolera domeny. W tym przybliżę jego deinstalację.
Dodawanie użytkowników z odpowiednimi parametrami przez PowerShell
| 2011-09-06 | Posted by kicekpicek under Komputery i Internet, Polskie blogi IT |
|
Ostatnio przyszło mi postawić stronę internetową, która udostępnia interfejs do tego, aby dodać użytkownika do Active Directory, wrzucić do odpowiedniego (wcześniej ustalonego) kontenera OU, włączyć konto i uniemożliwić zmianę hasła użytkownikowi.
Skrypt, jaki to umożliwia (bazujący na cmdletach Quest):
Add-PSSnapin Quest.ActiveRoles.ADManagement
New-QADUser -name NAZWAUSERA -ParentContainer ‘CN=Users,DC=moja,DC=domena,DC=pl’ -samAccountName NAZWAUSERA -UserPrincipalName NAZWAUSERA -UserPassword ‘HASŁOUSERA’ | Enable-QADUser | Set-QADUser -PasswordNeverExpires $true -UserMustChangePassword $false | Add-QADPermission -Account SELF,Everyone -ExtendedRight "User-Change-Password" -Deny -ApplyTo ThisObjectOnly
Takie wpisy tworzą użytkownika NAZWAUSERA z hasłem HASŁOUSERA, włączają to konto oraz wyłączają możliwość zmiany hasła, ustawiając hasło na trwałe (niewygasające).
Do zmiany hasła użytkownik dostaje inny interfejs, gdzie wpisuje tylko swój login i nowe hasło. Skrypt “z tyłu”:
Add-PSSnapin Quest.ActiveRoles.ADManagement
Get-QADUser -sAMAccountName ‘NAZWAUSERA‘ | Set-QADUser -userPassword ‘HASŁOUSERA‘
W moim przypadku inny mechanizm chroni dostęp do tej witryny (wcześniej) – dla użytkownika pojawia się tylko miejsce na wpisanie nowego hasła.
Co, jeśli potrzeba zresetować hasła wszystkim w ramach danego OU? Zresetować – ustawić to samo dla wszystkich i wymusić zmianę przy najbliższym logowaniu albo tylko wymusić zmianę przy najbliższej okazji?
Wykorzystując cmdlety Quest:
Add-PSSnapin Quest.ActiveRoles.ADManagement
$OU = "DOMENA.COM/OUZmianyHasla"
get-QADUser -SearchRoot $OU | set-QADUser -userpassword "tYmcz4sow3Has!0"
ForEach-Object { get-QADUser -searchroot $OU | Set-QADUser -UserMustChangePassword $true}
Powyższe linie w PowerShell: aktywują cmdlety Quest, ustawiają zmienną OU, wszystkim użytkownikom z OU zmieniają hasło a następnie wymuszają zmianę hasła przy najbliższym logowaniu.
Jeśli z jakichś powodów musimy wymusić tylko zmianę haseł, z powyższego usuwamy linię trzecią.
Bez wykorzystania cmdletów Quest, za to w CMD a nie w powershell:
dsquery user OU=OUZmianyHasla,DC=DOMENA,DC=COM | dsmod user -pwd tYmcz4sow3Has!0 -mustchpwd yes
Na podstawie:
http://wss.pl/frmThread.aspx?tid=111070&pid=616149#616149
+ Własna walka (zakładanie i zmiana hasła pojedynczej osoby)
10 to dla wszystkich o wiele za dużo…
| 2011-08-19 | Posted by MKr under Polskie blogi IT |
|
Problem Jest administrator, który wymyślił sobie aby podłączać komputery do domeny mogła tylko wybrana grupa administratorów, nazwijmy ich umownie – lokalnymi (CN=LocalAdmins). Nikt poza nimi, tzn. tak zwany End User tego prawa mieć nie powinien. Można zapytać dlaczego? Np. dlatego, że pomysł zezwolenia każdemu na wpięcie komputerów do domeny może średnio przypaść do gustu np, [...]
PowerShell – przydatne narzędzia
| 2011-08-10 | Posted by JeZZoo under Narzędzia, plugin, Polskie blogi IT, PowerGUI, PowerShell ISE, PowerShell-jak zacząć?, PowerWF, produkty Microsoft, Quest Software, Skrypty |
|
Do pracy z PowerShell wystarczy konsola. Dodając do tego Notatnik możemy już pisać skrypty. Wykorzystując możliwość korzystania z bibliotek i odwoływania się do .NET możemy z PowerShellem zrobić już prawie wszystko. Jednak nakłąd pracy będzie spory. Dodatkowo sporo drzwi zostało … Czytaj dalej
Losowe hasła w Microsoft Excel
| 2010-12-30 | Posted by Łukasz Zięba under dodatek, hasła, Polskie blogi IT, użytkownicy |
|
Jakiś czas temu, tworząc nowe konta w domenie Active Directory dla użytkowników, chcialem jak najbardziej ułatwić sobie pracę. W takiej sytuacji oczywistym rozwiązaniem bylo przygotowanie pliku skryptu, który całą pracę wykona za mnie. :)
Założenie bylo dość standardowe – nowo utworzeni użytkownicy mieli przy pomocy jednorazowego hasla zalogować się do swoich stacji roboczych i zmienić je przy pierwszym logowaniu.
Do utworzenia kont, a raczej przygotowania skryptu, który owe konta utworzy skorzystalem z Microsoft Excel 2010. Dokładnie opisal to Przemek Kuczyński na swoim blogu (ja co prawda nie użylem VB…).
Problemem okazalo się stworzenie kolumny z hasłami użytkowników. Chcialem, żeby hasla byly unikalne dla poszczególnych kont, a jednocześnie spełnialy wszystkie zasady co do złożoności. Z powodu sporej ilości kont do utworzenia, ręczne wpisywanie haseł nie wchodzilo w grę…
Wybawieniem okazal się dodatek do programu Microsoft Excel, który można pobrać z tej strony.
Umożliwia on w prosty sposób (=RandomPassword) stworzenie dużej ilości haseł.
Jedynym problemem może być fakt, że hasla czasem się powtarzają. W moim przypadku nie mialo to aż takiego znaczenia – prawdopodobieństwo, że ktoś będzie próbował zalogować się do cudzego konta ze swoim hasłem i trafi bylo bardzo małe. Co nie zmienia faktu, że i tak hasła wygenerowałem ponownie, żeby każdy mial unikalne. :P
CrossRealm troubleshooting – Negocjacja wykorzystywanych typów szyfrowania.
| 2010-10-01 | Posted by kaarol under Polskie blogi IT |
|
Jak ja kocham sieci heterogeniczne, gdyby nie one to życie byłoby takie nudne. A może wreszcie miałbym więcej czasu dla siebie?
Co nowego w AD Domain Services?
| 2010-03-23 | Posted by Kamil Skalski under Polskie blogi IT |
|
Zapraszam do lektury najnowszego artykułu „Nowości w Active Directory Domain Services Windows Server 2008 R2„.
„Usługi katalogowe Active Directory są jednym z kluczowych zasobów współczesnych przedsiębiorstw. Od czasu wydania Windows Server 2008 zaczęły w nich zachodzić zmiany (np. AD stało się usługą systemową) niezwykle istotne z punktu widzenia administratora. Najnowsza wersja R2 wniosła kilka interesujących funkcji, o których powinien wiedzieć każdy specjalista IT.”
Modyfikacja czasu przechowywania usuniętych obiektów Active Directory
| 2010-03-10 | Posted by Kamil Skalski under Polskie blogi IT |
|
Usunięcie obiektu z domeny nie powoduje jego natychmiastowego usunięcia, jest on wciąż przechowywany przez określony czas (lecz nie może być już używany) w celu replikacji zmian do pozostałych kontrolerów domeny. W zależności od posiadanej wersji systemu Windows Server czas ten trwa od 60 dni (WS2003) do 180 dni (WS2008/R2). Dodatkowo w Windows Server 2008 R2 czas ten wydłuża się o kolejne 180 dni przechowywania obiektu w koszu Active Directory – o czym wspominałem we wcześniejszym wpisie.
Czas przechowywania skasowanych obiektów jest trwale zapisany w systemie, jednak może zostać nadpisany poprzez modyfikację atrybutów kontenera CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration. Akcje należy podjąć na atrybutach:
- tombstoneLifetime – dla czasu przechowywania obiektów przekazanych do usunięcia bez użycia kosza lub po upływie okresu przechowywania w AD Recycle Bin
- msDS-DeletedObjectLifeTime – w przypadku WS2008 R2, który korzytsa z funkcji kosza
Domyślnie każdy z powyższych atrybutów ma wartość „null” i odwołuje się do domyślnych wartości systemu operacyjnego. W celu modyfikacji tych wartości należy skorzystać z ldp.exe lub modułu active driectory dla Windows PowerShell.
Modyfikacja z użyciem PowerShell (WS2008 R2)
Należy wykonać poniższe polecenia z poziomu konsoli PowerShell z aktywnym modułem AD.
Set-ADObject -Identity “CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=skalski,DC=info” –Partition “CN=Configuration,DC=skalski,DC=info” –Replace:@{“tombstoneLifetime” = 365}
Set-ADObject -Identity “CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=skalski,DC=info” –Partition “CN=Configuration,DC=skalski,DC=info” –Replace:@{“msDS-DeletedObjectLifetime” = 365}
Modyfikacja z użyciem ldp.exe (WS2003 – 2008 R2)
1. Uruchomić z wiesza poleceń ldp.exe
2. Podłączyć się do domeny wybierając Connections -> Connect w polu server name podać nazwę kontrolera domeny, po czym wybrać przycisk Bind
3. W drzwie przejść do kontenera wybierając View -> Tree i podając ścieżkę CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=skalski,DC=info, po zatwierdzeniu wybrać opcję Modify na kontenerze
4. W oknie modyfikacji podać parametry:
Edit Entry Attribute: tombstoneLifetime
Value: 365
dla modyfikacji czasu obowiązywania tabliczki nagrobnej lub…
Edit Entry Attribute: msDS-DeletedObjectLifeTime
Value: 365
dla modyfikacji czasu przechowywania obiektu w koszu Acitive Directory
5. Zatwierdzić zmiany wybierając opcję Replace, przycisk Enter w celu zatwierdzenia operacji, a następnie przycisk Run by wykonać modyfikację
Sprawdź zgodność konfiguracji z najlepszymi praktykami
| 2010-03-04 | Posted by Kamil Skalski under Polskie blogi IT |
|
W poprzednich wpisach pokazałem kilka nowości wprowadzonych w Windows Server 2008 R2, dzisiaj przyszła kolej na Best Practices Analyzer (BPA). Jak sama nazwa wskazuje dzięki temu narzędziu można sprawdzić czy konfiguracja serwera jest zgodna z najlepszymi praktykami. Narzędzie to jest instalowane razem z każdą obsługiwaną rolą (warunkiem jest posiadanie odpowiedniego modelu roli dla BPA), a jego uruchomienie odbywa się poprzez wybór opcji w sekcji podsumowania roli (konsola Server Manager). Wcześniejsze wersje tego narzędzia były oddzielnymi aplikacjami, a pierwsza wersja została udostępniona w roku 2006.
Uruchomienie analizy odbywa się poprzez wybór polecenia „Scan This Role”, która po kilku sekundach jest gotowa do weryfikacji. Dla każdej rekomendacji tworzony jest dokładny raport przyczyny nie spełnienia wymogów, ewentualne konsekwencje awarii oraz zalecane rozwiązanie problemu. Warto zwrócić uwagę, że obecnie obsługiwane są następujące role:
- Active Directory Certificate Services
- Active Directory Domain Services
- Domain Name System (DNS)
- Dynamic Host Configuration Protocol (DHCP)
- Internet Information Services (IIS)
- Remote Desktop Services (RDS)
- Network Policy and Access Services
Warto pamiętać, że podobne narzędzia dla różnych aplikacji są dostępne w Centrum Pobierania na stronach Microsoft.
Offline Domain Joining, Wirtualne maszyny i DATA_BLOB
| 2010-03-02 | Posted by Kamil Skalski under Polskie blogi IT |
|
Kontynuując cykl przedstawiający nowe rozwiązania Windows Server 2008 R2 dzisiaj przyszła kolej na bezpołączeniowe przyłączenie komputera do domeny (offline domain joining). Jest to nowe rozwiązanie pozwalające na utworzenie konta komputera w Active Directory i przeniesienie informacji o domenie do komputera, który ma stać się członkiem domeny.
Pierwszym etapem jest zarejestrowanie konta w domenie i jednocześnie utworzenie pliku odpowiedzi, za pomocą którego zostaną przekazane informacje do nie podłączonego do sieci komputera (z systemem operacyjnym Windows 7 lub Windows Server 2008 R2). Wykonuje się to poleceniem: DJOIN /PROVISION /DOMAIN skalski.info /MACHINEOU „OU=Test Lab,DC=skalski,DC=info” /MACHINE off-client1 /SAVEFILE c:\off-client1.djoin
Polecenie djoin pozwala zarówno na utworzenie pliku odpowiedzi jak i jego wykorzystanie do bezpołączeniowego przyłączenia stacji do domeny. Najważniejszymi parametrami są:
- PROVISION - określa rezerwacje dla konta komputera w domenie według podanych dalej parametrów
- DOMAIN – wskazuje na domenę do jakiej zostanie przyłączony komputer
- MACHINEOU – definiuje położenie konta komputera w strukturze jednostek organizacyjnych
- MACHINE – nadaje nazwę komputerowi, który zostanie podłączony. Uwaga: przyłączany komputer zmieni swoją nazwę na podaną w tym parametrze
- SAVEFILE – określa ścieżkę w jakiej zostanie utworzony plik odpowiedzi służący dalej do podłączenia komputera docelowego
Kolejnym krokiem jest przeniesienie utworzonego wcześniej pliku odpowiedzi (w tym przypadku off-client1.djoin) do komputera docelowego oraz jego użycie. Wykonuje się to poleceniem: DJOIN /REQUESTODJ /LOADFILE c:\off-client1.djoin /LOCALOS /WINDOWSPATH C:\Windows
Wynikiem wykonania ww. polecenia jest przekazanie stacji informacji o jej członkostwie w domenie. By zakończyć ten proces należy ponownie uruchomić komputer. Parametry zastosowane w poleceniu oznaczają:
- REQUESTODJ – wykonuje żądanie bezpołączeniowego przyłączenia do domeny
- LOADFILE – wskazuje ścieżkę do pliku odpowiedzi
- LOCALOS - pozwala na wskazanie jako cel obecnie uruchomiony system operacyjny
- WINDOWSPATH – wskazuje ścieżkę do folderu systemowego podłączanej stacji
Warto zwrócić uwagę na scenariusz przygotowania maszyn wirtualnych z wykorzystaniem tej metody:
- Przygotowujemy plik odpowiedzi
- Podłączamy dysk wirtualny maszyny, która ma zostać członkiem domeny
- Wykonujemy przyłączenie podając jako WINDOWSPATH ścieżkę do folderu systemu zainstalowanego na wirtualnym dysku
Ostatnią kwestią jaką należy poruszyć jest bezpieczeństwo tego rozwiązania. Plik odpowiedzi zwiera w sobie liczne informacje, które powinny być odpowiednio chronione. Matthieu Suiche stworzył narzędzie (dinfo.exe), które dekoduje plik odpowiedzi i ujawnia informacje zawarte w DATA_BLOB.
Warto zwrócić szczególną uwagę na hasło w polu lpMachinePassword, nazwy domeny i lasu oraz liczne informacje o polisach i identyfikatorach.
Przywracanie usuniętych obiektów w Active Directory
| 2010-02-25 | Posted by Kamil Skalski under Polskie blogi IT |
|
Przyszedł czas na opisanie kilku nowych funkcjonalności Windows Server 2008 R2. Dzisiaj pierwsza z nich czyli kosz w usłudze katalogowej AD czyli Active Directory Recycled Bin. Jego zadaniem jest uproszczenie przywracania skasowanych obiektów, które dotychczas wykonywało się poprzez modyfikację atrybutu isDeleted lub z kopi zapasowej.
Pierwszym krokiem jest włączenie funkcji AD Recycled Bin poprzez wykonanie polecenia (dla przykładowej domeny skalski.info):
Enable-ADOptionalFeature -Identity ‘CN=Recycle Bin Feature,CN=Optional Features,CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration, DC=skalski,DC=info’ -Scope ForestOrConfigurationSet -Target ‘skalski.info’
Dalsza praca z koszem to wyszukanie usuniętego obiektu i wydanie polecenia jego przywrócenia:
Get-ADObject -Filter {displayName -eq „Kamil Skalski”} -IncludeDeletedObjects | Restore-ADObject
