Konfiguracja DHCP w Windows 2008 R2 Core

Serwer DHCP jest doskonałym kandydatem do instalacji na systemie w wersji core. Instalacja, konfiguracja i już. W zasadzie czynności związane z utrzymaniem ograniczają się do rzadkiego backupu i reakcji na zmiany w infrastrukturze sieciowej. A te nie zachodzą zbyt często. Więc warto zaoszczędzić zasobów na serwerze wirtualizacji i zainstalować Windows Core.
Jednakże, jak zazwyczaj w przypadku wersji Core, zetknięcie się z „gołą” linią poleceń cmd potrafi zabić entuzjazm. Postaram się go rozdmuchać na nowo tym prostym Step-by-Step guide’m.

Przypominając podstawowe sprawy (o które się dzisiaj rozbiłem) musimy pamiętać o kilku czynnościach. Po zmianie hasła, którą wymusza sam system operacyjny pierwszą czynnością (bo potem się zapomni) jest zmiana nazwy komputera. Do tego służy polecenie

1
 netdom <nazwa obecna> renamecomputer /newName:<nowa nazwa>

Bieżącą nazwę (wygenerowaną przez instalatora) poznamy dzięki poleceniu

1
 hostname

Drugą irytującą czynnością jest aktywacja systemu. Do tego potrzebujemy skonfigurować adresację IP oraz dokonać procesu aktywacji.
Tak więc, aby przypisać właściwe adresy właściwym interface’om potrzebujemy najpierw ich listę:

1
2
3
4
5
6
netsh interface ipv4 show interfaces

Idx     Met         MTU          State                Name
---  ----------  ----------  ------------  ---------------------------
  3          10        1500  connected     Local Area Connection
  1          50  4294967295  connected     Loopback Pseudo-Interface 1

Zapisujemy wartość Idx właściwego interface’u. Następnie możemy przypisać adres IP, maskę podsieci oraz bramę domyślną:

1
netsh interface ipv4 set address name=<Idx> source=static address=<IP> mask=<netmask> gateway=<Domyślna brama>

Teraz jeszcze tylko serwer dns i mamy pełny ruch sieciowy:

1
netsh interface ipv4 add dnsservers [name=]<string> [address=]<IPv4 address> [[index=]<integer>] [[validate=]yes|no]

Aktywacji dokonujemy poprzez dwie komendy:

1
2
slmgr.vbs -ipk <klucz produktu>
slmgr.vbs -ato

W tym momencie nasz serwer jest gotowy do instalacji i konfguracji roli. Przedstawiony wstęp jest w zasadzie dostępny wszędzie, jednak warto mieć go pod ręką (a piszę to przecież także dla siebie).

Rolę serwera dhcp instalujemy poleceniem

1
Dism /online /enable-feature /featurename:DHCPServerCore

Stan w jakim nasz serwer DHCP się znajduje zaraz po instalacji jest co najmniej interesujący. Wszystkie binaria są co prawda zainstalowane w systemie, jednakże usługa nie jest uruchomiona, a jej profil uruchamiania ustawiony jest na „Wyłączona”.
Żeby to zmienić należy wydać polecenia:

1
2
sc config dhcp start=auto
sc start dhcp

W tym momencie posiadamy sprawną usługę dhcp na serwerze. Jedyne, czego jej brakuje to konfiguracji. Tę możemy wprowadzić ręcznie, lub odtworzyć z kopii zapasowej. Ani jedno, ani drugie zadanie nie jest proste z linii poleceń. Jednak, zanim uruchomimy dostęp za pomocą narzędzi zdalnych, omówmy kwestię dodania naszego serwera do domeny:

1
netdom join <nazwaHosta> /Domain:<FQDN> /UserD:Username /passwordd:*

Po wykonaniu powyższej komendy konieczny jest restart maszyny. Zwróćmy uwagę, że w tej chwili nasz serwer DHCP zostanie uruchomiony wraz ze startem systemu operacyjnego.
Jedną z ostatnich akcji wykonywanych wprost z linii komend serwera jest (uwaga – w tej kolejności!) instalacja PowerShell’a oraz konfiguracja zdalnego dostępu przez konsolę zarządzającą Windows Server Manager. Należy wywołać polecenie

1
 sconfig

i przejść do sekcji 4. Configure remote management. Następnie wybieramy opcję 2. Install Power Shell. Po tej operacji należy zrestartować maszynę. Następnie uruchamiamy ponownie skrypt sconfig i wywołujemy opcję 4.3 Allow server remote management.

Po wykonaniu tej akcji następuje aktywacja odpowiednich cmdlet’ów Powershella a także właściwa konfiguracja niektórych przestrzeni nazw WMI.
W tym momencie posiadamy dostęp do naszego serwera przez konsolę Windows Server Manager. Jeżeli chcemy skonfigurować nasz serwer od podstaw, to wystarczy otworzyć węzeł usługi w naszej przystawce MMC i wyklikać odpowiednie opcje (zakres przydzielanych adresów, maskę podsieci, bramę domyślną, DNS, wins) dla każdego z konfigurowanych zakresów.

Jednakże gdy chcemy odtworzyć nasz serwer z wykonanej wcześniej kopii zapasowej należy zachować szczególną ostrożność z dwóch powodów. Po pierwsze konsola pokaże nam okno wyboru katalogu zawierającego kopię zapasową. I jest to pewne ułatwienie, gdyż nie trzeba całej ścieżki wpisywać ręcznie. Jednakże jest to utrudnienie o tyle, że wskazujemy katalog lokalny, wcale nie mając na uwadze, że usługa DHCP będzie poszukiwać dokładnie tego katalogu na serwerze zdalnym. Nie należy się zastanawiać, dlaczego akurat to okno ma wyłączoną opcję pokazywania dysków sieciowych. Należy zadbać o to, żeby ścieżka wskazywana na dysku lokalnym istniała dokładnie taka sama na dysku konfigurowanego właśnie serwera typu Core. Drugą pułapką jest kwestia uprawnień. Nie zawsze usługa dhcp prawidłowo zdiagnozuje fakt, że danych plików nie ma i wyświetli błąd „Access denied”. Drugim możliwym błędem jest fakt, że konsola skoryguje uprawnienia na dysku lokalnym, a nie zdalnym (co jest dość logiczne – nie istnieje żadne powiązanie pomiędzy tymi strukturami katalogów). Należy pamietać o nadaniu uprawnień odczytu i zapisu do katalogu z kopią zapasową na serwerze DHCP dla konta builtin\DHCPService.

Przy zachowaniu opisanych wyżej procedur nasza usługa DHCP będzie długo i bez konieczności konserweracji działać na systemie typu Core.

Instalacja Usług Certyfikacji (CA) na Windows 2008 R2 Core

Dzisiaj o czymś zupełnie nowym, ponieważ CA zostało dodane do Windows Core dopiero w wersji R2. Sama opcja instalacji tylko części komponentów nazwana „Core Installation” została udostępniona w wersji 2008.
Na temat Core Installation jest już dość dużo materiałów, na przykład ten artykuł Nataniela Zielińskiego, więc nie będę opisywał go szerzej. Dość powiedzieć że w wersji tej nie ma większości interface’ów graficznych, system zaś obsługuje się z lini poleceń. Istnieje też dobre opracowanie pozwalające ogarnąć Core Installation, jednakże część usług wprowadzonych dopiero w R2 jest nieomal pozbawiona dokumentacji.
Instalacja serwera CA na zwykłym Windows 2008 wymaga użycia kreatora dodawania roli, którego brak w wersji Core. Tak więc pierwszym krokiem jest zainstalowanie binariów usługi. Wykonuje się to poleceniem

1
start /w ocsetup.exe CertificateServices /norestart /quiet

Następnie warto dokonać sprawdzenia poprawności instalacji

1
oclist find /i "CertificateServices"

Po upewnieniu się o tym, że mamy w systemie pakiet usługi, musimy ją skonfigurować. Można to wykonać za pomocą skryptu automatycznej instalacji dostępnego tutaj. Jest to skrypt VBScript który pozwala bez problemowo zainstalować CA. Na stronie podany jest pełen zestaw parametrów koniecznych do ukończenia procesu instalacji pomyślnie. Należy tutaj zwrócić uwagę na fakt, że parametry

1
/interactive

oraz

1
/iw

są nie obsługiwane w Core installation.
Ponaddto przed przystąpieniem do instalacji CA, zarówno w wersji Core jak i zwykłej warto przygotować plik CApolicy.inf który należy umieścić w katalogu %SYSTEMROOT%. Przykład takiego pliku poniżej:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
[Version]
Signature="$Windows NT$

[PolicyStatementExtension]
Policies=LegalPolicy

[LegalPolicy]
OID=1.1.1.1.1.1.1.121

NOTICE=Certyfikat wystawiony zgodnie z dokumentem Kodeks_Postepowania_Certyfikacyjnego_Testowe_Domeny
URL="http://pki.testowa.domena.lab/repozytorium/cps.html"

[certsrv_server]
renewalkeylength=2048
RenewalValidityPeriodUnits=5
RenewalValidityPeriod=years
CRLPeriod=days
CRLPeriodUnits=14
CRLOverlapPeriod=days
CRlOverlapUnits=7
CRLDeltaPeriod=hours
CRLDeltaPeriodUnits=0

Po instalacji warto ustawić parametry CDP (CRL Distribution Point) na przykład tak:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
certutil -setreg CA\DSConfigDN CN=Configuration,DC=CCKNF,DC=AD
certutil -setreg CA\CRLPeriodUnits 14
certutil -setreg CA\CRLPeriod "Days"
certutil -setreg CA\CRLOverlapPeriod "Days"
certutil -setreg CA\CRLOverlapUnits 7
certutil -setreg CA\CRLDeltaPeriodUnits 0
certutil -setreg CA\CRLDeltaPeriod "Hours"
certutil -setreg CA\CRLPublicationURLs "65:%windir%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl\n79:http://pki.testowa.domena.lab/repozytorium/%%3%%8%%9.crl\n65:file://\\%%1\CertEnroll/%%3%%8%%9.crl"
certutil -setreg CA\CACertPublicationURLs "1:%windir%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n3:http://pki.testowa.domena.lab/repozytorium/%%1_%%3%%4.crt\n1:file://\\%%1\CertEnroll/%%1_%%3%%4.crt"
certutil -setreg CA\AuditFilter 127
certutil -setreg CA\ValidityPeriodUnits 2
certutil -setreg CA\ValidityPeriod "Years"
net stop certsvc & net start certsvc
certutil -crl

Utworzenie takiego, lub podobnego skryptu pozwoli ominięcie „wyklikiwania” za pomocą zdalnie podpiętej konsoli mmc parametrów umieszczanych w certyfikatach.
Na koniec dodam, że pierwszym artykułem który pozwolił rozpocząć pracę z CA na systemie W2K8R2 Core Installation był artykuł Eyalestrin’a.