Tym razem postaram się opisać pokrótce jak krok po kroku sprawić, że możemy logować się kontami z AD do interfejsu konsoli do zdalnego zarządzania serwerem iRMC. iRMC jest narzędziem out-of-band management serwera, dzięki czemu możemy z poziomu takiej witryny sprawdzić, czy serwer jest włączony, czy jego wszystkie komponenty są sprawne lub też nie czy też zdalnie zainstalować system operacyjny lub też zdalnie go obsługiwać. Co ważne, taki interfejs daje nam taką przewagę nad RDP/VNC, że możemy mieć dostęp do serwera będąc np. w ustawieniach BIOS serwera, więc te rozwiązanie pracuje niezależnie od systemu operacyjnego, który pracuje na hoście.
EDIT: Zdecydowałem się rozszerzyć nieco ten post o certyfikat SSL i wykorzystanie LDAP over SSL. Staram się to teraz wdrażać wszędzie, więc tutaj też powiem o tym więcej.
Certyfikat SSL
Zanim zaczniemy, musimy mieć wcześniej wdrożony urząd certyfikacji (na przykład dzięki usłudze certyfikatów Active Directory) i to jest coś, czego tutaj nie będę omawiał. Zanim wygenerujemy żądanie podpisania certyfikatu, warto się zastanowić jaka będzie nasza nazwa hosta. W moim przypadku jest to irmc-vhost1.serba.local ze względu na to, że mogę zawsze mieć wiele serwerów z iRMC, przez co same irmc.serba.local mogłoby być kiepskim rozwiązaniem po kupnie drugiej maszyny. Na początku zdefiniowałem w DNS przypisany do adresu iRMC, by można go było potem używać zamiast adresu IP. Efekt widać poniżej:
Następnie za pomocą OpenSSL stworzyłem klucz oraz wygenerowałem żądanie certyfikatu. Nie będę się o tym rozpisywał – opisałem cały proces tutaj. W stosunku, co jest w podlinkowanym poradniku należy zmienić jedynie CN oraz DNS.1 na irmc-vhost1.serba.local. Po wygenerowaniu CSRki można bić do serwera i wygenerować certyfikat SSL. Jeśli mamy zainstalowaną funkcję urzędu certyfikacji o nazwie Rejestracja w sieci Web dla urzędu certyfikacji, możemy podpisać żądanie przez stronkę urzędu, co zalecam robić, bo jest po po prostu proste i przyjemne. Adres takiej strony to http://<adres-ca>/certsrv. W moim przypadku jest to https://dc1.serba.local/certsrv (zmieniłem kilka ustawień w IIS, by mieć połączenie po HTTPS ;))
Na początku należy się zalogować swoim kontem administracyjnym w AD:
Następnie należy wybrać Żądanie certyfikatu.
Następnie wybieramy zaawansowane żądanie certyfikatu.
Na tym etapie musimy otworzyć nasz plik CSR w jakimś edytorze tekstu, skopiować zawartość i wkleić w pole żądania. Ponadto, musimy wybrać szablon certyfikatu, dzięki czemu określamy przeznaczenie certyfikatu, który generujemy. To, co nasz interesuje to Serwer sieci Web. Po tym klikamy Prześlij >.
Po tym pobieramy certyfikat w formacie Base-64.
Ponadto, musimy pobrać certyfikat urzędu certyfikacji, co możemy zrobić na stronie głównej urzędu poprzez opcję Pobierz certyfikat urzędu certyfikacji, łańcuch certyfikatów lub listę CRL, a następnie mając zaznaczoną metodę kodowania Base 64, następnie klikając Pobierz certyfikat urzędu certyfikacji.
Następnie musimy się zalogować do interfejsu iRMC i wgrać certyfikaty urzędu certyfikacji oraz certyfikatu SSL wraz z kluczem prywatnym, który wykorzystaliśmy przy wygenerowaniu CSRki. W Tools > Certificates > Current CA Certificate for CAS and SMTP należy kliknąć Load from File (stronę trzeba rozwinąć i znajdziemy przycisk w dolnej części karty po prawej stronie.
Następnie należy kliknąć Select…, wybrać plik CA i po tym kliknąć Upload. W ten sposób mamy zainstalowany certyfikat CA. Następnie wrzucamy certyfikat w Certification Authorities for eLCM rozwijając opcje, klikając Add, następnie w From file wybierając plik i zatwierdzając przyciskiem Add:
Efekt końcowy wygląda tak:
Na końcu rozwijając Current SSL/TLS Certificate należy kliknąć Load from File, a następnie w polu SSL/TLS public key dodać plik wygenerowanego certyfikatu SSL, a w SSL/TLS private key należy umieścić klucz prywatny, którym wygenerowaliśmy CSRkę, to wygląda tak:
Po tym klikamy Upload. Jesteśmy ponadto informowani, że należy wykonać restart iRMC w celu zastosowania zmian, więc klikamy Reboot iRMC.
No i czekamy.
Przed restartem systemu strona była wyświetlana jako niezaufana:
Po restarcie mamy wynik osiągnięty:
Teraz można przejść do integracji.
Integracja SSO
Do integracji należy skorzystać z drugiej płyty ServerView, którą można ściągnąć na stronie producenta po wybraniu swojego modelu urządzenia pod tym linkiem.
Następnie po otwarciu pliku .iso znajdującego się w Archiwum należy odnaleźć plik SVS_LdapDeployer.zip w ścieżce <litera-obrazu>:\SVSSoftware\Software\RemoteView\iRMC_Tools\SVS_LdapDeployer. Kopiujemy go na komputer, na którym:
- Jesteśmy zalogowani na konto administracyjne w domenie i mamy do niej dostęp (najlepiej nie logować się bezpośrednio na kontrolerze domeny),
- Mamy zainstalowane Java Runtime w wersji co najmniej 1.5 (można je ściągnąć stąd).
Po rozpakowaniu archiwum otwieramy zawartość i kopiujemy plik Configuration_InitialDeploy_ActiveDirectory.xml do katalogu, w którym znajduje się plik SVS_LdapDeployer.jar.
Następnie edytujemy wspomniany plik .xml. W następującej linii poprawiamy adres na adres naszego kontrolera domeny. Jeśli na serwerze nie używa się SSLa do szyfrowania komunikacji, powinno się zmienić port na 389 i zmienić wpis SSLEnabled na false:
<DirectoryService>ldap://192.168.10.156:636</DirectoryService>
Po zmianie:
<DirectoryService>ldap://dc1.serba.local:389</DirectoryService>
<SSLEnabled>false</SSLEnabled>
Następnie zmieniamy DN w tej linii na DN naszej domeny (w moim przypadku serba.local):
<root>dc=mycompany,dc=net</root>
Po zmianie:
<root>dc=serba,dc=local</root>
Zmieniamy konto administracyjne, z którego korzystamy do autoryzacji (opcjonalne), na pewno trzeba poprawić domenę na właściwą:
<username>administrator@mycompany.net</username>
Po zmianie:
<username>administrator@serba.local</username>
Następnie najlepiej usunąć ten wpis:
<password>encrypted_user_password</password>
Dzięki temu programik do tworzenia drzewa OU ServerView spyta nas o hasło przed rozpoczęciem pracy.
Następnie w sekcji Data mamy do zdefiniowania role:
<Roles>
<Role name ="Administrator" >
<Privilege name ="IpmiLanOem" />
<Privilege name ="IpmiSerialOem" />
<Privilege name ="iRMCsettings" />
<Privilege name ="RemoteStorage" />
<Privilege name ="UserAccounts" />
<Privilege name ="VideoRedirection" />
<Privilege name ="CfgConnectionBlade" />
<Privilege name ="RedfishAdmin"/>
</Role>
<Role name ="Maintenance">
<Privilege name ="IpmiLanOem" />
<Privilege name ="IpmiSerialOem" />
<Privilege name ="iRMCsettings" />
<Privilege name ="VideoRedirection" />
<Privilege name ="RedfishOperator"/>
</Role>
<Role name ="Operator">
<Privilege name ="IpmiLanOperator" />
<Privilege name ="IpmiSerialOperator" />
<Privilege name ="VideoRedirection" />
<Privilege name ="RedfishOperator"/>
</Role>
<Role name ="Monitor">
<Privilege name ="IpmiLanUser" />
<Privilege name ="IpmiSerialUser" />
<Privilege name ="RedfishReadOnly"/>
</Role>
<Role name ="CustomRole">
<Privilege name ="IpmiLanUser" />
<Privilege name ="IpmiSerialUser" />
<Privilege name ="VideoRedirection" />
</Role>
</Roles>
Z reguły nie ma potrzeby posiadania tylu ról, dlatego usuwam wszystkie poza adminem, docelowo wygląda to tak:
<Roles>
<Role name ="Administrator" >
<Privilege name ="IpmiLanOem" />
<Privilege name ="IpmiSerialOem" />
<Privilege name ="iRMCsettings" />
<Privilege name ="RemoteStorage" />
<Privilege name ="UserAccounts" />
<Privilege name ="VideoRedirection" />
<Privilege name ="CfgConnectionBlade" />
<Privilege name ="RedfishAdmin"/>
</Role>
</Roles>
Potem, w sekcji Departments zmienam w Department name na nazwę domeny bez końcówki, więc w tym przypadku ustawiłbym serba, poza tym wyrzucam usunięte role poniżej:
<Departments>
<!--
# any number of departments possible
# !!! Name of Department and associated roles need to be changed !!!
-->
<Department name ="DeptX">
<!--
# List of associated roles.
# any number of roles, but only from roles defined above
-->
<Role name ="Administrator" />
<Role name ="Maintenance" />
<Role name ="Monitor" />
<Role name ="CustomRole" />
</Department>
</Departments>
Po zmianie:
<Departments>
<!--
# any number of departments possible
# !!! Name of Department and associated roles need to be changed !!!
-->
<Department name ="serba">
<!--
# List of associated roles.
# any number of roles, but only from roles defined above
-->
<Role name ="Administrator" />
</Department>
</Departments>
Po wykonaniu zmian zapisuję plik i otwieram konsolę PowerShell lub Wiersz poleceń z uprawnieniami administracyjnymi:
Po tym przechodzę do ścieżki z programem SVS_LdapDeployer i odpalam polecenie:
java -jar SVS_LdapDeployer.jar -deploy Configuration_InitialDeploy_ActiveDirectory.xml
Zostaniemy zapytani o hasło i podczas wpisywania jest ono widoczne.
Po wykonaniu tej czynności powinniśmy mieć gotowe drzewko w AD.
Teraz należy utworzyć konto, które będzie wykorzystywane w iRMC w celu sprawdzania kto jest członkiem tej grupy Administrator, a następnie należy dodać je do tej grupy wraz ze wszystkimi kontami użytkowników, które mają mieć dostęp do iRMC. Należy dodać konta użytkowników, a nie grupy ze względu na to, że iRMC nie obsługuje z jakiegoś powodu dziedziczenia członkostwa w grupach. Na potrzeby usługi utworzyłem konto serviceacc:
Nastęonie zanim zacznie się konfigurować profil domeny należy skonfigurować serwery DNS dla naszej domeny w Settings > Network Management > DNS:
- Enable DNS: zaznaczone
- DNS Configuration: Obtain from DHCP odznaczone
- DNS Domain: po prostu nazwa naszej domeny
- DNS Search Path: możemy też podać nazwę naszej domeny, dzięki temu dc1.serba.local == dc1. Nie wiem w sumie jak można to wykorzystać, ale ogólnie to jest najlepsza opcja konfiguracji.
- DNS Server 1, 2 i 3: tutaj podajemy adresy DNS, z których korzystamy.
W moim przypadku efekt wygląda tak:
Po dodaniu kont do grupy musimy zdefiniować ustawienia w iRMC, dzięki któremu iRMC będzie wiedziało jak komunikować się z AD. Po zalogowaniu się do iRMC otwieramy u góry kartę Settings, następnie User Management po lewej stronie i z niej rozwijamy ustawienia Lightweight Directory Access Protocol (LDAP).
Następnie wpisujemy tutaj dane (Backup LDAP Server jest opcjonalny, jeśli posiadasz drugi kontroler domeny to warto go tu wpisać):
- Global Configuration
- Enable LDAP: zaznaczone
- Enable LDAP SSL/TLS: wedle preferencji, w moim przypadku zaznaczone
- Disable Local Login: ta opcja wyłącza możliwość logowania się z kont lokalnych, odradzam zaznaczanie jej
- Directory Server Type: Active Directory
- Primary LDAP Server
- Server: dc1.serba.local
- Network Port: 389
- SSL/TLS Network Port: 636
- Backup LDAP Server
- Server: dc2.serba.local
- Network Port: 389
- SSL/TLS Network Port: 636
- Directory Configuration
- Authorization Type: ServerView LDAP Groups with Authorization Settings on LDAP Server
- Department Name: serba
- Domain Name: serba.local
- Groups Directory as Sub-tree from Base DN: (puste)
W tej konfiguracji wyżej korzystam z FQDN serwerów – warto o tym pamiętać, by ustawić w konfiguracji serwer DNS tak, by wskazywał na nasze kontrolery domeny, dzięki czemu nazwy będą rozwiązywały się poprawnie. Potem przechodzimy do sekcji, w której określamy użytkownika, z którego korzystamy do komunikacji z AD i pole obiektu AD, z którego korzystamy:
Tutaj definiujemy:
- Access Configuration
- Authentication LDAP Username: serviceacc
- Authentication LDAP Password: *********
- Confirm Password: *********
- Principal User DN: (puste)
- Append Base DN to Principal User DN: odznaczone
- Enable Enhanced User Login: zaznaczone (opcjonalne)
- User Login Search filter: (&(objectClass=person)(sAMAccountName=%s))
Pole obiektu AD, po którym iRMC wyszukuje użytkownika domyślnie to cn, dlatego ja to zmieniam na sAMAccountName, bo wtedy korzystamy z takiego samego loginu jak do Windowsa. Takie pole można sobie sprawdzić w przystawce Użytkownicy i komputery usługi Active Directory mając zaznaczoną opcje Widok > Opcje zaawansowane. Poniżej przykład z zaznaczonym polem userPrincipalName:
W ten sposób można się logować na konta z Active Directory. Warto sobie w takiej sytuacji zmienić hasło dla konta lokalnego admin na długie ze względów bezpieczeństwa.
Efekt końcowy wygląda następująco:
UPDATE: Dzisiaj w trakcie wdrożenia na Windowsie Server 2019 Essentials miałem taki problem, że po wykonaniu instrukcji powyżej nie byłem w stanie stworzyć sobie drzewka w AD i otrzymywałem błąd:
- The keystore location is not accessible.
- The keystore's password is not correct.
- The keystore you specified is not the one generated during encryption.
Please try again or reset the password.
Rozwiązanie jest takie, by podać login i hasło do konta, którym się autoryzujemy w parametrach w plaintext:
java -jar SVS_LdapDeployer.jar -deploy Configuration_InitialDeploy_ActiveDirectory.xml -username administrator@serba.local -password Zaq12wsx!
Zawsze polecam zmieniać hasło na takie, które można pokazać przed innymi, a potem zmienić z powrotem na bezpieczne; w innym wypadku róbmy takie operacje będąc w zaufanym gronie osób (to znaczy często w osobności).
Druga rzecz to jest to, że w katalogu z szablonami są pliki Configuration_InitialDeploy_ActiveDirectory.xml i Configuration_InitialDeploy_AD.xml. W tym poradniku korzystałem z tego pierwszego.