Ten poradnik adresuję wszystkim osobom, które mówiąc krótko nie znają się dobrze na IT i nie wiedzą jak sobie poradzić z potencjalnym scamem. W tym nie ma nic wstydliwego, że ktoś nie jest dobrze zorientowany, jest tyle dziedzin wiedzy na których można się znać, że jak dla mnie to jest naturalne. Poza tym zdaję sobie z tego sprawę, że niektórzy starzy wyjadacze czasami nawet są w stanie się nabrać na scam. Skupię się nad stronkami do przedmiotów w Team Fortress 2 i Counter Strike: Global Offensive, ale ogólnie wzorzec próby nabrania użytkownika jest mniej więcej ten sam.
Wygląda on tak: ktoś nas dodaje do znajomych i oferuje łatwy zarobek i podsyła nam linka do strony internetowej. Zwykle to jest strona z przedmiotami i łatwym zarobkiem, lecz by dostać jakiś bonus/premię/cokolwiek innego należy się zalogować. Po zalogowaniu często nic się nie dzieje ale strona przenosi użytkownika na główną i tyle z tego było, a po kilku minutach przedmioty znikają. Jesteśmy wściekli, że akurat nam się to przytrafiło, a najgorsze jest to, że to tylko z naszej winy tak jest.
Poniżej lista rzeczy, na którą należy zwracać uwagę. Jeśli strona, na którą wchodzisz spełnia przynajmniej jeden punkt z listy – raczej bym na nią nie wchodził. Kolejność punktów jest przypadkowa – piszę wszystko na bazie własnego doświadczenia i moim zdaniem każdy punkt jest ważny.
1. Brak certyfikatu SSL
Jeśli strona do trade’ów lub jakichś interesów nie posiada certyfikatu SSL w 2020 roku to nie jest bezpieczna. W przypadku takich stron jak logs.tf ze zrzutu ekranu to nie jest problem, poza tym logs.tf obsługuje SSL, ale nie przekierowuje na niego automatycznie. Na logs.tf są prezentowane informacje o meczach, a nie wymienia się przedmioty w grze, które mogą być warte czasem nawet tysiące złotych, więc to nie jest aż tak istotne. Tak czy siak strona bez certyfikatu SSL pozwala na przechwycenie danych w trakcie komunikacji i tutaj nie tylko scammer miałby nasze dane logowania w przypadku ich podania, lecz w sumie każdy, kto chciałby podsłuchać ruch.
W drugą stronę nie można też myśleć, że certyfikat SSL oznacza 100% bezpieczeństwa – w dzisiejszych czasach certyfikat SSL można wygenerować za darmo za pomocą takich usług jak np. Let’s Encrypt. Certyfikat chroni nas przed podsłuchaniem komunikacji pomiędzy pomiędzy naszym komputerem a serwerem, z którym się łączymy, ale nie chroni nas przed tym, co wewnątrz tej komunikacji się dzieje.
2. Krótki czas istnienia domeny
Domena to nazwa strony, na którą wchodzimy. W moim przypadku to jest supra.tf. Ta strona jako it.supra.tf jest subdomeną supra.tf. Tak czy siak, to co może sprawić, że dana domena może być próbą oszustwa to, że strona powstała na przykład kilka dni temu. Nie wiadomo, czy interesy, które oferuje są legalne i czy tą korzyść z interesów będziemy mieć, czy tylko będzie mieć z nich twórca strony 😂
Dzięki stronie z obrazka powyżej możemy sprawdzić jak długo dana domena istnieje. Dzisiaj dostałem linka od kolegi (pozdro MattJ) ze strony, która jest potencjalnie scamem i mam też jeden zapisany adres w zanadrzu, więc zrobimy sobie szybkie dwa testy. Test jest prosty – wpisujemy adres strony i sprawdzamy datę założenia domeny. Po wpisaniu strony klikamy Search, zatwierdzamy CAPTCHA…
Celowo robię zrzut ekranu z zegarkiem – ta domena to oczywisty scam w tym przypadku domeny tf-market.fun:
Jak widać – została założona tego samego dnia, co na zrzucie ekranu. Strony ze scamem są wyłapywane bardzo szybko, czasami to jest kwestia godzin i strona jest globalnie oznaczona jako potencjalny scam. W dodatku, strona została założona na stronie REG.RU. Nie wiem dlaczego, ale z jakiegoś powodu często te strony scamowe są zarejestrowane właśnie u tego rejestratora, co to może być? 🤔
Drugi przykład to domena csgo-inventory.icu. Dostałem ją od innego kolegi (pozdro Stan) i wykonałem taki sam test:
Efekt podobny – stronka, która istnieje cały 1 dzień.
3. Strona oznaczona jako potencjalna próba oszustwa
Może to zabrzmi idiotycznie, ale jeśli przeglądarka wyświetla ekran na czerwono i próbuje Cię uświadomić, by na stronę nie wchodzić – to po prostu nie wchodź. Strona z drugiego przypadku została w ciągu 12 godzin oznaczona jako scam w Google Safe Browsing, co spowodowało, że Firefox po otwarciu strony pokazał mi coś takiego:
Z faktu, że mam ESETa na komputerze to po zignorowaniu komunikatu z Firefoxa dodatkowo zobaczyłem jego komunikat:
Po zignorowaniu komunikatu ESETa dostałem kolejny komunikat (tym razem z Cloudflare (ten przypadek jest dosyć zabawny, bo dzięki Cloudflare także można mieć certyfikaty za darmo + można mieć darmową usługę Anti-DDOS i właściciel domeny ją włączył, co okazało się dla niego zgubne – to ten komunikat wyświetli się każdemu użytkownikowi bez względu na przeglądarkę)):
Chrome też zrobił swoje:
Poza tym możemy sprawdzać listy ze stronami scamerskimi. Na tej stronie znajdziemy dosyć aktualną listę scam stronek do CS:GO. Dosyć wymowne jest to, że jak po pominięciu ostrzeżenia wejdziemy na stronkę to ta jest pusta – to jest coś w stylu akcji damage control, czyli w skrócie im mniej osób zobaczyło jak wygląda strona będąca scamem tym większa szansa, że ktoś się na to nabierze.
4. Strona logowania jest w języku angielskim
To MOŻE tworzyć podejrzenia scamu, ale nie musi. Bo co, jeśli ktoś używa anglojęzycznego systemu operacyjnego? By zrozumieć problem, muszę nieco lepiej wyjaśnić w jaki sposób przeglądarki wyświetlają nam strony internetowe w konkretnym języku.
Ogólnie przeglądarka posiada coś takiego jak user agent. User agent określa język contentu, który pobieramy. Domyślnie przeglądarki sprawdzają jaki język jest ustawiony w systemie operacyjnym, w którym działa i ustawia w user agencie język systemowy – w moim przypadku polski. To powoduje, że jeśli wejdę na jakąś wielojęzyczną stronę, moja przeglądarka w moim imieniu poprosi o zawartość w języku polskim jeśli to jest możliwe. Jeśli jest – dostanę stronę po polsku, jeśli nie, dostanę stronę w domyślnym języku (prawie zawsze angielski). Jesteśmy w stanie sami zmieniać ustawienia user agenta. User agent przesyła także informacje o używanej przeglądarce, dzięki czemu strona wie, że ją przeglądamy za pomocą Opery, Google Chrome, Mozilli czy czegokolwiek innego. Tym też można manipulować za pomocą wtyczek typu User Agent Switcher w Chrome czy User-Agent Switcher w Firefoxie. Bez wtyczek ustawimy sam język i w Chrome można to zrobić tutaj:
W Firefoxie mamy to tutaj:
Stronka ze scamem będzie się wyświetlać w języku angielskim bez względu na wszystko. Strona logowania Steama dopasowuje się do języku, można zobaczyć to tutaj:
Jeśli nie jestem zalogowany efekt jest ten sam:
5. Podrabianie ekranu logowania
Ten punkt moim zdaniem jest najważniejszy ze wszystkich, bo najłatwiej wyczuć tutaj scam. Ten ekran logowania wygląda jak zwykły ekran logowania, ale nim nie jest. Po pierwsze nie ma informacji o tym, że ta strona nie jest powiązana ze Steamem ani Valve (tak jak na zrzucie ekranu wyżej z etf2l.org), po drugie adres strony na stronie logowania to dalej ta strona.
Tak wygląda stronka ze scamem
Tak wygląda prawdziwa stronka
Mechanizm działania jest prosty – po wpisaniu loginu i hasła na scam stronce ta próbuje w Twoim imieniu się zalogować Twoim loginem i hasłem (Ty tego nie widzisz, to się dzieje na serwerze strony internetowej w tle) i jeśli wpisałeś złe dane – dostaniesz na tej stronie taki sam komunikat (świadczący o tym, że po prostu wpisałeś nieprawidłowe dane). W innym przypadku jeśli wpiszesz dobre dane logowania to strona poprosi Cię o kod ze Steam Guarda i jeśli go podasz to tak samo serwer w Twoim imieniu się zaloguje na te konto i jeśli mu się uda – zapisze Twoje dane logowania do bazy danych, a potem spróbuje automatycznie zmienić maila i przenieść Twoje przedmioty na jakieś inne konto, z którego będzie przedmioty przenosić na różne, by potem móc je szybko i tanio sprzedać na rynku.
Logowanie się na stronach poprzez konto Steam opiera się o mechanizm pojedynczego logowania OpenID. Wcześniej logujesz się na swoje konto na Steamie (np. na https://steamcommunity.com/) i potem wchodząc na stronę wystarczy, że klikniesz Zaloguj, jak w przypadku na dole (na scam stronce nigdy takiego przycisku nie będzie nawet jeśli na drugiej karcie jesteś zalogowany na Steamie):
Po zatwierdzeniu Steam wysyła do strony numer ID konta użytkownika, po to, by poświadczyć, że użytkownik o takim ID poprawnie się zalogował. Strona, która korzysta z logowania (np. backpack.tf) dostaje jedynie ID użytkownika i nic więcej. Poza ID może próbować pobierać dane użytkownika z publicznego profilu Steam (o ile jest publiczny). Jeśli nie jest to strona się nie dostanie np. do naszej listy przedmiotów czy statystyk o grach (np. czas spędzony w konkretnej grze). Normalna strona nigdy nie dostaje żadnego loginu ani hasła, dzięki czemu jesteśmy bezpieczniejsi, jeśli logujemy się naprawdę na Steama, a nie spreparowaną stronę.
Ciekawostka: to, co właśnie napisałem jest też napisane na ekranie logowania ze steamcommunity.com:
Ponadto, w przypadku logowania się na Steamie można sprawdzić certyfikat – zawsze będzie pokazywał to, że jest wystawiony na Valve Corp. [US]:
Jeśli tego nie ma lub strona ma wystawiony certyfikat SSL przez Let’s Encrypt – to nie jest strona prawdziwego Steama.
Jest jeszcze jedna opcja scamu i polega ona na tym, że po kliknięciu przycisku Zaloguj przez Steam pojawia nam się nowe okienko z ekranem logowania. W niej adres jest poprawny i ekran wygląda tak samo jak normalny…ale jednak nie do końca. Posiłkując się obrazkami z tej strony można zobaczyć dodatkowe dwie opcje scamu:
Pierwsza to okienko, w którym nie możemy kliknąć na kłódkę certyfikatu, by sprawdzić kto certyfikat wystawił. Druga to jest to, że tym popupem nie jesteśmy w stanie wyjść poza okno przeglądarki, więc na dobrą sprawę ten popup ma imitować takie konto przeglądarki, tyle, że zmniejszone.
Drugi przypadek to stronka, który ma adres about:blank. Myślę, że sprawa tutaj jest oczywista.
Handel z innymi graczami na Steamie – czy ta osoba jest w porządku?
Pod tym kątem polecam wtyczki do przeglądarek, które automatycznie wyświetlają informacje o potencjalnych banach za scam na popularnych stronkach. Tak, każdy zaleca, by zawsze sprawdzać tradera na steamrep.com, ale szczerze czy ktoś to dzisiaj robi? Ja to robiłem ostatni raz w 2014 roku może. Tak czy siak dzięki takim wtyczkom nie musimy na te strony wchodzić, bo wszystko jest na tacy – tutaj widać recydywistę pod kątem scamowania. Wtyczka, o której cały czas mówię to Augumented Steam – jest dostępna na Chrome i Firefoxie. Ten plugin ma wiele innych zalet – ułatwia sprzedaż przedmiotów, od razu dodaje przyciski do sprzedawania przedmiotów na Steam Market o jeden grosz taniej, liczy ilość przedmiotów w trakcie tworzenia oferty wymiany i sprawdza zbliżoną wartość przedmiotów itd. Ogólnie warto z tego korzystać. Co do wymian, wtyczka to Steam Economy Enhancer.
Przepraszam, ale przypadkiem Cię zgłosiłem do moderatorów Steama, musisz pogadać z moderatorem by Ci się nic nie stało.
Moderatorzy Steama są zamiennie z supportem Steama w tej śpiewce.
To jest stara głupia śpiewka, czyli jakaś losowa osoba z Internetu sugeruje, że coś może się stać z Twoim kontem nie mając pojęcia z kim ma się do czynienia. W takiej sytuacji sugeruję od razu zablokować użytkownika na Steamie i się w ogóle nie patyczkować. Support Steama NIGDY nie napisze do Ciebie niczego z prywatnego konta. Support Steam zawsze będzie się kontaktował z Tobą przez specjalny system wiadomości. Ponadto, za każdym razem gdy otrzymujesz wiadomość od supportu możesz ją zobaczyć na swoim mailu oraz Steam wyświetla specjalne powiadomienie, które tego dotyczy. Jeśli nie jesteś osobą, która robi dużo dla społeczności jakiejś gry to szanse na to, że rozmawiasz z osobą będącą pracownikiem Valve na Steamie na czacie prywatnym to prawie 0%.
Ogólnie jedyna forma, w której support Steama może odpowiedzieć jest widoczna tutaj (dostaje się na Steamie specjalne powiadomienie):
Ponadto miejsce dyskusji wygląda zupełnie inaczej niż taki zwykły czat:
Ponadto wysłanie do nas odpowiedzi w zgłoszeniu przez support Steama powoduje informację o tym na mailu:
Dla przykładu ten sam plugin, o którym wspominałem wcześniej (Augumented Steam) wyświetla też informację o tym, że ktoś jest pracownikiem Valve (przydaje się pod kątem podszywania za pracowników):
Chcę, byś promował(a) moją stronę, daję za to kasę/metal, pomożesz mi?
Kolejna próba chamskiego scamu. Sytuacja jest prosta: ktoś zaprasza Cię do znajomych i prosi o reklamę jego „nowej strony”. Często ta strona, która ma być reklamowana jest stronką, w stylu tych, które prezentowałem wcześniej w tym poście, czyli taka udająca jakieś jackpoty, loterie, ruletki itd., gdzie w praktyce jedyne, co jest istotne to dane logowania do Twojego konta. Pod żadnym pozorem nie reklamuj stron, których nie znasz – w ten sposób nie wkopiesz swoich znajomych lub fanów (jeśli ich masz).
Poniżej przykład takiej konwersacji dzięki uprzejmości Nucleone – przy okazji jak widać Nucle nie dał tanio skóry sprzedać:
Potrzebujemy piątego do teamu, gramy w ligach i turniejach. Dołączysz do nas? Zarejestruj się tutaj.
Tutaj scam polega na tym, że po prostu ktoś próbuje nas namówić na to, byśmy się zalogowali przez stronkę pod przykrywką jakiegoś teamu. Fake grupka, gość unika podania prawdziwych linków do teamu i próbuje przekonać za wszelką cenę, bym się zarejestrował. Na stronie była spreparowana stronka do logowania (jak w przykładach wcześniej).
„nie mogę Cię dodać do znajomych, dodasz mnie?”
Odpowiedź powinna być jednoznaczna: NIE. Jeśli ktoś chce Cię zaprosić i ma do Ciebie sprawę to Cię zaprosi. Takie coś jest najczęściej robione po to, by nie budzić podejrzeń gracza, bo ktoś się odezwał w bardziej wymowny sposób niż po prostu same zaproszenie, które normalnie byśmy odrzucili, bo widać, że np. konto jest niedawno utworzone lub jest prywatne.
Jak dokopać takim oszustom?
Krótko – zgłosić ich do Google Safe Browsing. Wchodząc na tą stronę podajemy adres strony z potencjalnym scamem i dodatkowe informacje o stronie (tak jak ja poniżej) i wysyłamy.
Chcąc dobrze wdrażać środowisko serwerowe zawsze staram się dbać o to, by serwisy webowe w sieci lokalnej posiadały wdrożone certyfikaty SSL, które będą się wyświetlały jako zaufane i ze względu na realia środowisk w Polsce wdrażam urząd certyfikacji na Windowsie (Usługi certyfikatów Active Directory). W przypadku środowiska vSphere jeśli używa się hostów ESXi niezależnie (np. używając darmowej licencji) generuje się certyfikaty dla każdego hosta z osobna. Ten proces jest dosyć prosty i nie będę go tutaj opisywać (może kiedyś indziej opiszę). W przypadku, gdy ma się jednak płatną licencję (jakąkolwiek, Essentials wystarczy) mając vCenter i hosty ESXi podpięte do niego vCenter pełni rolę urzędu certyfikacji, który generuje certyfikaty dla swoich hostów ESXi. Aby taki urząd był zaufany w naszej organizacji opcje są dwie:
import domyślnie wygenerowanego certyfikatu vCenter do wszystkich komputerów obsługujących potencjalnie vCenter (najczęściej wszystkie komputery w domenie AD) – kiepskie rozwiązanie ze względu na to, że ta nazwa CA jest po prostu CA, kiepsko to wygląda. Plus jest taki, że po prostu działa bez większych kombinacji.
wykorzystanie AD CS i utworzenie certyfikatu podrzędnego urzędu certyfikacji dla vCenter, dzięki czemu nie trzeba nic dodatkowo importować do magazynu zaufanych urzędów certyfikacji we wszystkich komputerach, a z automatu zarówno vCenter jak i hosty ESXi są zaufane, bo po podmianie certyfikatu CA vCenter te pozwoli na wygenerowanie dla swoich podrzędnych podmiotów (hostów ESXi certyfikaty i je wdroży automatycznie) nowych ceryfikatów.
Z faktu, że ja leniwy nie jestem (albo jestem, ale raczej w ten pozytywny sposób 😉) wolę iść tą drugą ścieżką, więc postaram się pokazać w jaki sposób przeprowadzić cały proces krok po kroku. Początkowo męczyłem się z tym całym procesem kilka dni, bo nie umiałem znaleźć dobrego poradnika, który przedstawiał go krok po kroku w prosty sposób, dzięki czemu byłbym w stanie to zrozumieć, lecz znalazłem ten poradnik do starszej wersji vCenter i szczerze polecam go, bo sporo się z niego nauczyłem. W dużej mierze ten poradnik bazuje na wspomnianym. Różnice między tym poradnikiem, który właśnie wspominam, a tym, który właśnie czytacie są takie, że mój jest po polsku, dotyczy vCenter 7.0, który ma tworzenie CSR poprzez GUI, a nie poprzez SSH i dotyczy scenariusza z pojedynczym urzędem certyfikacji (najczęściej w mniejszych firmach wdraża się tylko główny urząd certyfikacji (pośrednie można spotkać w większych firmach). Scenariusz, który tam był przedstawiony zakłada możliwie najbardziej rozbudowany scenariusz, kiedy jest root CA, enterprise CA, policy CA i dopiero nasze vCenter CA. Twórca też wspomina o tym, że mając same Root CA całość się robi bardzo podobnie, ale pamiętam jak bardzo się irytowałem, że tego nie rozumiem, wiec tak czy siak postaram się to pokazać.
Na początku należy się z poziomu konsoli vCenter i włączyć dostęp poprzez SSH do maszyny (jeśli nie jest już włączony), więc klikamy F2 i wpisujemy poświadczenia konta root.
Następnie należy przejść do Troubleshooting Mode Options.
Następnie należy włączyć SSH poprzez Enable SSH. Po tym można wyjść z konfiguracji w konsoli.
Następnie łączymy się poprzez SSH do naszego serwera vCenter:
Wykonujemy 1 polecenie:
shell.set --enable true
Po tym wykonujemy polecenie shell i dostajemy się do shella bashowego. Tworzymy folder na pliki, które będziemy potrzebowali przenieść, a następnie otwieramy Certificate Managera:
Pojawi się lista opcji, wybieramy opcję 2. Replace VMCA Root certificate with Custom Signing Certificate and replace all Certificates:
root@vcenter [ ~ ]# /usr/lib/vmware-vmca/bin/certificate-manager
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
| |
| *** Welcome to the vSphere 6.8 Certificate Manager *** |
| |
| -- Select Operation -- |
| |
| 1. Replace Machine SSL certificate with Custom Certificate |
| |
| 2. Replace VMCA Root certificate with Custom Signing |
| Certificate and replace all Certificates |
| |
| 3. Replace Machine SSL certificate with VMCA Certificate |
| |
| 4. Regenerate a new VMCA Root Certificate and |
| replace all certificates |
| |
| 5. Replace Solution user certificates with |
| Custom Certificate |
| NOTE: Solution user certs will be deprecated in a future |
| release of vCenter. Refer to release notes for more details.|
| |
| 6. Replace Solution user certificates with VMCA certificates |
| |
| 7. Revert last performed operation by re-publishing old |
| certificates |
| |
| 8. Reset all Certificates |
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|
Note : Use Ctrl-D to exit.
Option[1 to 8]: 2
Następnie zostajemy zapytani, czy chcemy wygenerować wszystkie certyfikaty z użyciem pliku konfiguracyjnego, wybieramy Y (tak) i autoryzujemy się poświadczeniami kontem administratora w naszej domenie SSO (domyślnie [email protected]):
Please provide valid SSO and VC privileged user credential to perform certificate operations.
Enter username [[email protected]]:[email protected]
Enter password:
Po tym jesteśmy proszeni o wypełnienie pól certyfikatu, zdefiniowałem je w następujący sposób:
Please configure certool.cfg with proper values before proceeding to next step.
Press Enter key to skip optional parameters or use Default value.
Enter proper value for 'Country' [Default value : US] : PL
Enter proper value for 'Name' [Default value : CA] : vcenter.serba.local
Enter proper value for 'Organization' [Default value : VMware] : it.supra.tf
Enter proper value for 'OrgUnit' [Default value : VMware Engineering] : IT
Enter proper value for 'State' [Default value : California] : SL
Enter proper value for 'Locality' [Default value : Palo Alto] : Tychy
Enter proper value for 'IPAddress' (Provide comma separated values for multiple IP addresses) [optional] :
Enter proper value for 'Email' [Default value : [email protected]] : [email protected]
Enter proper value for 'Hostname' (Provide comma separated values for multiple Hostname entries) [Enter valid Fully Qualified Domain Name(FQDN), For Example : example.domain.com] : vcenter.serba.local
Enter proper value for VMCA 'Name' :vcenter.serba.local
Następnie jesteśmy pytani, czy chcemy zaimportować istniejący certyfikat, czy jedynie wygenerować żądanie podpisania certyfikatu (CSR). Wybieramy opcję 1. Generate Certificate Signing Request(s) and Key(s) for VMCA Root Signing certificate:
1. Generate Certificate Signing Request(s) and Key(s) for VMCA Root Signing certificate
2. Import custom certificate(s) and key(s) to replace existing VMCA Root Signing certificate
Option [1 or 2]: 1
Jeśli dostaliśmy następujący wynik, nie ma czym się martwić:
Please provide a directory location to write the CSR(s) and PrivateKey(s) to:
Output directory path: /tmp/certs
2020-07-12T15:47:35.454Z Running command: ['/usr/lib/vmware-vmca/bin/certool', '--genkey', '--privkey', '/tmp/certs/vmca_issued_key.key', '--pubkey', '/tmp/pubkey.pub']
2020-07-12T15:47:35.536Z Done running command
2020-07-12T15:47:35.538Z Running command: ['/usr/lib/vmware-vmca/bin/certool', '--gencacsr', '--privkey', '/tmp/certs/vmca_issued_key.key', '--pubkey', '/tmp/pubkey.pub', '--config', '/var/tmp/vmware/certool.cfg', '--csrfile', '/tmp/certs/vmca_issued_csr.csr']
2020-07-12T15:47:35.775Z Done running command
Moim błędem było to, że w regionie wpisałem śląskie.
Po udanej próbie mamy coś takiego:
1. Continue to importing Custom certificate(s) and key(s) for VMCA Root Signing certificate
2. Exit certificate-manager
Option [1 or 2]: 1
Do tego wyboru wrócimy po podpisaniu certyfikatu.
Tak czy siak, do folderu /tmp/certs zostały dodane dwa pliki: vmca_issued_csr.csr oraz vmca_issued_key.key. Musimy te pliki wyciągnąć z vCenter, lecz vCenter 7.0 nie pozwala na włączenie basha jako domyślnego shella, więc posłużymy się innym serwerem z Linuksem i poleceniem scp:
root@vcenter [ /tmp/certs ]# scp * [email protected]:/home/supra/certs
The authenticity of host '192.168.30.44 (192.168.30.44)' can't be established.
ECDSA key fingerprint is SHA256:kNv0X0cEkedHTTxYHDjzWCPVus2OW5Pp1WZ9l3NE8qM.
Are you sure you want to continue connecting (yes/no)? yes
[email protected]'s password:
vmca_issued_csr.csr 100% 1195 175.5KB/s 00:00
vmca_issued_key.key 100% 1703 1.7MB/s 00:00
Na dobrą sprawę wystarczy nam sam plik CSR, ale na wszelki wypadek skopiowaliśmy oba. W ten sposób możemy z poziomu Windowsa takie pliki skopiować choćby przez WinSCP:
Następnie należy się zalogować do usługi Web z AD CS służącej do podpisywania certyfikatów wybierając Żądanie certyfikatu:
Następnie wybieramy zaawansowane żądanie certyfikatu.
Następnie w żądaniu trzeba wkleić zawartość pliku vmca_issued_csr.csr, jak powyżej przedstawiony oraz wybrać Szablon certyfikatu o nazwie Podrzędny urząd certyfikacji, a po tym wybrać Prześlij >.
Na końcu pobieramy certyfikat w formacje Base-64.
Na końcu też należy pobrać certyfikat urzędu (lub urzędów certyfikacji) i należy utworzyć plik składający się z zawartości certyfikatu serwera oraz głównego urzędu (w odpowiedniej kolejności). Na głównej stronie urzędu certyfikacji można kliknąć Pobierz certyfikat urzędu certyfikacji, łańcuch certyfikatów lub listę CRL.
Następnie pobieramy certyfikat głównego urzędu certyfikacji wybierając Pobierz certyfikat urzędu certyfikacji mając wcześniej zaznaczony format Base 64.
W pliku wysyłanym do vCenter musimy posiadać plik łańcucha składający się z certyfikatu i wszystkich powyższych podmiotów, dzięki którym certyfikat jest zaufany, więc w naszym przypadku w pliku muszą być w kolejności umieszczone zawartość certyfikatu serwera oraz głównego CA. To powinno wyglądać tak:
W przypadku, gdybyśmy mieli jeszcze pośredni urząd certyfikacji między certyfikatem serwera vCenter a głównym urzędem, końcowy plik wyglądałby tak strukturalnie:
Nie polecam zostawiać pustej linii na końcu pliku, niekoniecznie przy vCenter, ale przy innym sofcie, który wymagał niestandardowego CA proces stosowania certyfikatu po prostu wysiadał.
Taki plik łańcucha zapisałem w pliku o nazwie vcenter-chain.cer. Następnie umieściłem go na swoim serwerze linuksowym:
Potem dzięki poleceniu SCP skopiowałem plik łańcucha certyfikatu (robiąc to w drugiej, osobnej sesji SSH z vCenter:
Po tym wracam do sesji, w której tworzyłem klucz prywatny oraz CSR.
1. Continue to importing Custom certificate(s) and key(s) for VMCA Root Signing certificate
2. Exit certificate-manager
Option [1 or 2]: 1
Wybieramy opcję 1 i tutaj wybieramy nasz wgrany plik łańcucha certyfikatu oraz plik klucza, który został utworzony przy tworzeniu CSR. Po tym jesteśmy pytani o zatwierdzenie operacji podmiany certyfikatu CA dla vCenter, zatwierdzamy przez Y:
Please provide valid custom certificate for Root.
File : /tmp/certs/vcenter-chain.cer
Please provide valid custom key for Root.
File : /tmp/certs/vmca_issued_key.key
You are going to replace Root Certificate with custom certificate and regenerate all other certificates
Continue operation : Option[Y/N] ? : Y
Następnie musimy poczekać kilka minut, aż import się wykona. Jeśli coś się nie uda na tym etapie (np. źle podamy plik) to zawsze możemy wrócić do tego kreatora ponownie:
root@vcenter [ /tmp/certs ]# /usr/lib/vmware-vmca/bin/certificate-manager
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
| |
| *** Welcome to the vSphere 6.8 Certificate Manager *** |
| |
| -- Select Operation -- |
| |
| 1. Replace Machine SSL certificate with Custom Certificate |
| |
| 2. Replace VMCA Root certificate with Custom Signing |
| Certificate and replace all Certificates |
| |
| 3. Replace Machine SSL certificate with VMCA Certificate |
| |
| 4. Regenerate a new VMCA Root Certificate and |
| replace all certificates |
| |
| 5. Replace Solution user certificates with |
| Custom Certificate |
| NOTE: Solution user certs will be deprecated in a future |
| release of vCenter. Refer to release notes for more details.|
| |
| 6. Replace Solution user certificates with VMCA certificates |
| |
| 7. Revert last performed operation by re-publishing old |
| certificates |
| |
| 8. Reset all Certificates |
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|
Note : Use Ctrl-D to exit.
Option[1 to 8]: 2
Do you wish to generate all certificates using configuration file : Option[Y/N] ? : n
Please provide valid SSO and VC privileged user credential to perform certificate operations.
Enter username [[email protected]]:[email protected]
Enter password:
certool.cfg file exists, Do you wish to reconfigure : Option[Y/N] ? : n
1. Generate Certificate Signing Request(s) and Key(s) for VMCA Root Signing certificate
2. Import custom certificate(s) and key(s) to replace existing VMCA Root Signing certificate
Option [1 or 2]: 2
Efekt końcowy powinien być mniej więcej taki:
Get site nameCompleted [Replacing Machine SSL Cert...]
default-site
Lookup all services
Get service default-site:d5d00e27-79af-4c88-b870-5453e9c3d7f9
Update service default-site:d5d00e27-79af-4c88-b870-5453e9c3d7f9; spec: /tmp/svcspec_tyrcm6al
Get service default-site:cdfe4374-ac38-4080-b986-6d6f2a8758b1
Update service default-site:cdfe4374-ac38-4080-b986-6d6f2a8758b1; spec: /tmp/svcspec_79qh8fqn
Get service default-site:31efcc7b-4f50-41b2-ba2e-601fe26e01c8
Update service default-site:31efcc7b-4f50-41b2-ba2e-601fe26e01c8; spec: /tmp/svcspec_ou4iht4l
Get service 9f8fbc47-b4f0-4fba-8335-fb41536e293f
Update service 9f8fbc47-b4f0-4fba-8335-fb41536e293f; spec: /tmp/svcspec_nvteg0if
Get service 669789b0-a7f4-4f4d-96e2-f18dbabd5735
Update service 669789b0-a7f4-4f4d-96e2-f18dbabd5735; spec: /tmp/svcspec_7ocwx_p3
Get service 5e7ac323-d616-45b8-93ce-b2fab8dd28fa
Update service 5e7ac323-d616-45b8-93ce-b2fab8dd28fa; spec: /tmp/svcspec_fx37gzod
Get service 39d31e11-8874-4568-b988-f9e0118d7e9a
Update service 39d31e11-8874-4568-b988-f9e0118d7e9a; spec: /tmp/svcspec_jb7krv5o
Get service 8c1cfd45-49a6-4431-b5db-0c83fec29e11
Update service 8c1cfd45-49a6-4431-b5db-0c83fec29e11; spec: /tmp/svcspec_mqitxjn3
Get service 17f968a2-b2d6-464e-b926-b2d1cd987fcf
Update service 17f968a2-b2d6-464e-b926-b2d1cd987fcf; spec: /tmp/svcspec_sc48jaa0
Get service 26bbde43-6d16-4891-a112-c4265ca742bb
Update service 26bbde43-6d16-4891-a112-c4265ca742bb; spec: /tmp/svcspec_89l9v8eh
Get service 38ad42e1-47e6-4568-9bb8-be32c2f348ed
Update service 38ad42e1-47e6-4568-9bb8-be32c2f348ed; spec: /tmp/svcspec_ztx6d0_0
Get service eae7c217-3b5e-408c-82e3-1ca0cae142a4_com.vmware.vsphere.client
Don't update service eae7c217-3b5e-408c-82e3-1ca0cae142a4_com.vmware.vsphere.client
Get service 9e99b5cc-2d62-4580-8d48-0cecea345256
Update service 9e99b5cc-2d62-4580-8d48-0cecea345256; spec: /tmp/svcspec_q6s7nxup
Get service 721b5dcd-1456-4b24-80c3-7e8a99402f09
Update service 721b5dcd-1456-4b24-80c3-7e8a99402f09; spec: /tmp/svcspec_pbkfqvuq
Get service eae7c217-3b5e-408c-82e3-1ca0cae142a4
Update service eae7c217-3b5e-408c-82e3-1ca0cae142a4; spec: /tmp/svcspec_0gzk00xv
Get service 04eaa9ed-952d-49af-a3f0-22cdcadc095f
Update service 04eaa9ed-952d-49af-a3f0-22cdcadc095f; spec: /tmp/svcspec_s8lnn1j3
Get service ae78a934-21e6-4db5-b072-e605b429b96e
Update service ae78a934-21e6-4db5-b072-e605b429b96e; spec: /tmp/svcspec_7mq2ig_j
Get service 31c27986-27a6-45da-955a-d9ca4d2bf766
Update service 31c27986-27a6-45da-955a-d9ca4d2bf766; spec: /tmp/svcspec_0bl7a7f8
Get service 3305cc60-3e0b-493b-b38e-0852883e29f4
Update service 3305cc60-3e0b-493b-b38e-0852883e29f4; spec: /tmp/svcspec_3i3epoy2
Get service faeae38c-bc5e-4813-b24e-8545b2ac0751
Update service faeae38c-bc5e-4813-b24e-8545b2ac0751; spec: /tmp/svcspec_g0xu28p8
Get service 8cf2be25-2ece-435e-99af-44f205fb323f
Don't update service 8cf2be25-2ece-435e-99af-44f205fb323f
Get service 11fbce0f-217e-4584-a453-8f8ed495bb42
Update service 11fbce0f-217e-4584-a453-8f8ed495bb42; spec: /tmp/svcspec_k7m05w3a
Get service 218c0ecd-6a10-49d1-b18f-78789b35bf8f
Update service 218c0ecd-6a10-49d1-b18f-78789b35bf8f; spec: /tmp/svcspec_wbobnp_s
Get service 5b8e0240-d496-4560-8f72-7a189fd6699f
Update service 5b8e0240-d496-4560-8f72-7a189fd6699f; spec: /tmp/svcspec_lf2ubwfh
Get service 7d6f91e4-f69e-4a8f-83bc-5ed957c74ab5
Don't update service 7d6f91e4-f69e-4a8f-83bc-5ed957c74ab5
Get service 8cd70ec7-23a4-4576-b5d7-223d54ac5a02
Update service 8cd70ec7-23a4-4576-b5d7-223d54ac5a02; spec: /tmp/svcspec_b88uwq07
Get service e10f925b-e725-4b74-99f8-f34bef4ff052
Update service e10f925b-e725-4b74-99f8-f34bef4ff052; spec: /tmp/svcspec_yr1k9_7l
Get service faeae38c-bc5e-4813-b24e-8545b2ac0751_authz
Update service faeae38c-bc5e-4813-b24e-8545b2ac0751_authz; spec: /tmp/svcspec_enzp0qlk
Get service 6fb28804-98d7-4c6a-8a89-922829d5165e
Update service 6fb28804-98d7-4c6a-8a89-922829d5165e; spec: /tmp/svcspec_1l157oyi
Get service 9f728793-62a6-423f-9d70-636e79ea4aa0
Update service 9f728793-62a6-423f-9d70-636e79ea4aa0; spec: /tmp/svcspec_720uy0_n
Get service 10499cb2-0cf8-4cc7-8a3b-0ce43100d036
Update service 10499cb2-0cf8-4cc7-8a3b-0ce43100d036; spec: /tmp/svcspec_4i8z510h
Get service 11a9a085-0b48-450f-b159-5156c9d91f57
Update service 11a9a085-0b48-450f-b159-5156c9d91f57; spec: /tmp/svcspec_feo5j4kh
Get service 10085641-bf52-4b16-81b1-9638d7cd8cdf
Update service 10085641-bf52-4b16-81b1-9638d7cd8cdf; spec: /tmp/svcspec_mae6cors
Get service b6e8e560-39a0-4078-af01-64c46f127f86
Update service b6e8e560-39a0-4078-af01-64c46f127f86; spec: /tmp/svcspec_o4mydtex
Get service 7506a154-0396-4cfa-b287-b077f84a2efd
Update service 7506a154-0396-4cfa-b287-b077f84a2efd; spec: /tmp/svcspec_jrqlyujd
Get service d0ffd26c-885d-4281-a595-e4fd49f1d82f
Update service d0ffd26c-885d-4281-a595-e4fd49f1d82f; spec: /tmp/svcspec_popllmkc
Get service df186d16-72a3-4e2a-9bdf-2c3fe81ac078
Update service df186d16-72a3-4e2a-9bdf-2c3fe81ac078; spec: /tmp/svcspec_je2ffoce
Get service 61c350a6-c4f0-43a0-bb78-4b4edbe2bea1
Update service 61c350a6-c4f0-43a0-bb78-4b4edbe2bea1; spec: /tmp/svcspec__xypiunv
Get service cf53c746-dec6-4221-ad2f-2714e6117ae6
Update service cf53c746-dec6-4221-ad2f-2714e6117ae6; spec: /tmp/svcspec_x264am44
Get service 8bcbc603-1b01-48e3-b067-343d09205920
Update service 8bcbc603-1b01-48e3-b067-343d09205920; spec: /tmp/svcspec_t4zfj9uu
Get service 3dc80e24-b4bd-4dbb-ac70-9d6ba4b846c5
Update service 3dc80e24-b4bd-4dbb-ac70-9d6ba4b846c5; spec: /tmp/svcspec_jpezzb_q
Get service 98e27670-8c8a-4ce3-9eff-e876c17ad479
Update service 98e27670-8c8a-4ce3-9eff-e876c17ad479; spec: /tmp/svcspec_s3fj_h16
Get service faeae38c-bc5e-4813-b24e-8545b2ac0751_kv
Update service faeae38c-bc5e-4813-b24e-8545b2ac0751_kv; spec: /tmp/svcspec_65sl6505
Get service 8a260877-5991-4e8b-b350-a66b27ca889f
Update service 8a260877-5991-4e8b-b350-a66b27ca889f; spec: /tmp/svcspec_vcl3r4qc
Get service eae7c217-3b5e-408c-82e3-1ca0cae142a4_com.vmware.vcenter.wcp
Don't update service eae7c217-3b5e-408c-82e3-1ca0cae142a4_com.vmware.vcenter.wcp
Get service eae7c217-3b5e-408c-82e3-1ca0cae142a4_com.vmware.lcm.client
Don't update service eae7c217-3b5e-408c-82e3-1ca0cae142a4_com.vmware.lcm.client
Updated 41 service(s)
Status : 60% Completed [Replace vpxd-extension Cert...]
2020-07-12T16:36:36.187Z Updating certificate for "com.vmware.vim.eam" extension
2020-07-12T16:36:36.317Z Successfully updated certificate for "com.vmware.vim.eam" extension
2020-07-12T16:36:37.668Z Updating certificate for "com.vmware.rbd" extension
2020-07-12T16:36:37.790Z Successfully updated certificate for "com.vmware.rbd" extension
2020-07-12T16:36:39.670Z Updating certificate for "com.vmware.imagebuilder" extension
Status : 100% Completed [All tasks completed successfully]
Jak widać, po odświeżeniu strona vCenter jest zaufana:
Pozostaje nam do zaaktualizowania certyfikat ESXi. Należy na nich odświeżyć CA oraz odnowić certyfikat, więc przechodzimy do widoku Hosts and Clusters, wybieramy nasz host, klikamy prawym i wybieramy Certificates > Refresh CA Certificates. Po tym zatwierdzamy operację i robimy to samo z opcją Renew Certificate.
Po tym certyfikat na ESXi też będzie okej:
Pozostają dwie kwestie – nie będzie tak kolorowo z zieloną kłódką na Firefoxie. Wynika to z tego, że hosty ESXi i vCenter przesyłają swój ciąg certyfikacji, który składa się jedynie z vCenter CA i jego własnego certyfikatu. To oznacza, że nie ma w ciągu certyfikatu głównego urzędu certyfikacji:
Szybka analiza przez OpenSSL potwierdziła to:
C:\Users\supra>openssl s_client -showcerts -connect vhost1.serba.local:443
CONNECTED(00000004)
depth=1 C = PL, ST = SL, L = Tychy, O = it.supra.tf, OU = IT, CN = vcenter.serba.local
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = US, ST = California, L = Palo Alto, O = VMware, OU = VMware Engineering, CN = vhost1.serba.local, emailAddress = [email protected]
verify return:1
---
Certificate chain
0 s:C = US, ST = California, L = Palo Alto, O = VMware, OU = VMware Engineering, CN = vhost1.serba.local, emailAddress = [email protected]
i:C = PL, ST = SL, L = Tychy, O = it.supra.tf, OU = IT, CN = vcenter.serba.local
-----BEGIN CERTIFICATE-----
MIIEGTCCAwGgAwIBAgIJAMtSRB4kyvtcMA0GCSqGSIb3DQEBCwUAMGsxCzAJBgNV
BAYTAlBMMQswCQYDVQQIEwJTTDEOMAwGA1UEBxMFVHljaHkxFDASBgNVBAoTC2l0
LnN1cHJhLnRmMQswCQYDVQQLEwJJVDEcMBoGA1UEAxMTdmNlbnRlci5zZXJiYS5s
b2NhbDAeFw0yMDA3MTIxNzAxMjRaFw0yMjA3MTIxNjA1MDBaMIGhMQswCQYDVQQG
EwJVUzETMBEGA1UECAwKQ2FsaWZvcm5pYTESMBAGA1UEBwwJUGFsbyBBbHRvMQ8w
DQYDVQQKDAZWTXdhcmUxGzAZBgNVBAsMElZNd2FyZSBFbmdpbmVlcmluZzEbMBkG
A1UEAwwSdmhvc3QxLnNlcmJhLmxvY2FsMR4wHAYJKoZIhvcNAQkBFg92bWNhQHZt
d2FyZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDDRtdmFj50
2EIbv6DojtoBk3EDE2ZqdJTFPZuti0S2Olil25kaReqQN1Wem/6sF1q6/YyBldKw
zVxsfmnUblts3+sjv5plttzYTcV70Z0XloLOPzGlKZhAM+XS1kJSpjyK93J8+3aM
wwDqEo7WKp3indVdi7dPRSqc7g77RHJgCoNZ49BIn+q2FlTkjUKACa6s/hlPoyi+
1pxfYlbCOsGd8ioYn6MMs5YW3Aib1kkaaFoiPhkFp02V2REIfgaH/vrf66nTMOoc
fwfC+smZaSeIIaVMez8D6v57KTRqCZOrgYRk8FNjLlOvW96JmHELZy8yVEKCufv8
/HVya0RxMyq/AgMBAAGjgYgwgYUwHQYDVR0RBBYwFIISdmhvc3QxLnNlcmJhLmxv
Y2FsMB8GA1UdIwQYMBaAFOLU6p14frk9ZYIzebfcuJhFjwTLMEMGCCsGAQUFBwEB
BDcwNTAzBggrBgEFBQcwAoYnaHR0cHM6Ly92Y2VudGVyLnNlcmJhLmxvY2FsL2Fm
ZC92ZWNzL2NhMA0GCSqGSIb3DQEBCwUAA4IBAQCmWQEGxPYxgBv5rdmazdq0Lvt4
pAOhcP8sQCiKaIaHED93X/9F7JmyqabNfLLsniqyYnZmo49ZmOlD9KoeIRthe4ot
sFj+NzlbtxyTa46dBp3LyVnrmyECjmCUqLLKrsTS0ype02TfwmNVQw94IaufS5JS
giXToHFPulR9UdbDn2NciNjf4MEUBtNg9NySCwISfoJUi3Iwl2lWVVDxPpiwqeCy
kxXuRMLNScZvbZOBlva6qNSKdB48mW150yqMobVR4VITtrPwTR3aTc6iYsvkmXp3
G63KA007kNqmEFF1TPYYTyLBLc0WlMEs4F1gFGXL4st4ZrvOHMEyFwok1iqJ
-----END CERTIFICATE-----
1 s:C = PL, ST = SL, L = Tychy, O = it.supra.tf, OU = IT, CN = vcenter.serba.local
i:DC = local, DC = serba, CN = serba-DC1-CA
-----BEGIN CERTIFICATE-----
MIIGpzCCBI+gAwIBAgITLgAAACmSpTQ5IRDUEwAAAAAAKTANBgkqhkiG9w0BAQsF
ADBFMRUwEwYKCZImiZPyLGQBGRYFbG9jYWwxFTATBgoJkiaJk/IsZAEZFgVzZXJi
YTEVMBMGA1UEAxMMc2VyYmEtREMxLUNBMB4XDTIwMDcxMjE1NTUwMFoXDTIyMDcx
MjE2MDUwMFowazELMAkGA1UEBhMCUEwxCzAJBgNVBAgTAlNMMQ4wDAYDVQQHEwVU
eWNoeTEUMBIGA1UEChMLaXQuc3VwcmEudGYxCzAJBgNVBAsTAklUMRwwGgYDVQQD
ExN2Y2VudGVyLnNlcmJhLmxvY2FsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAyHLNgqLJ7c+/6G657tO/pbdkxsUPvGvIAbCLEY7j7Ug6/0c6mC1rQ8R2
me4upGwhmKrl8moh4BAn5QhQUSM3KJQaTgo+a7vDpUFrs4cHMIPfApGR5tuKLv5B
4Sbr6zW/bZq8pxqpt/tosopXjF1nb3IulrTv6nFMq6sjKXYHTY3Gd3yxgky+tRa3
kFdvbyiMnF0NtJ5RMgfDo07O2ob0JWW/wg/mDeUOX3ofsYh9BQ7jOmGoiOtayA08
pGaIdvaI/15zw8MX7MtBxR1p3Ar0JYdzse/91ODDeUH3CCkt3hJdz+r1JBJS39v+
iuUD4Epx2CDaV8GGewAYTMosUlxZAQIDAQABo4ICaDCCAmQwDwYDVR0TAQH/BAUw
AwEB/zAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0OBBYEFOLU6p14frk9ZYIzebfcuJhF
jwTLMDIGA1UdEQQrMCmBEnJhZG9zbGF3QHNlcmJhLm92aIITdmNlbnRlci5zZXJi
YS5sb2NhbDAfBgNVHSMEGDAWgBS7l5n/TyANX99lWhur0laIl0Ox1DCBxgYDVR0f
BIG+MIG7MIG4oIG1oIGyhoGvbGRhcDovLy9DTj1zZXJiYS1EQzEtQ0EsQ049ZGMx
LENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxD
Tj1Db25maWd1cmF0aW9uLERDPXNlcmJhLERDPWxvY2FsP2NlcnRpZmljYXRlUmV2
b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2lu
dDCB6AYIKwYBBQUHAQEEgdswgdgwgasGCCsGAQUFBzAChoGebGRhcDovLy9DTj1z
ZXJiYS1EQzEtQ0EsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENO
PVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9c2VyYmEsREM9bG9jYWw/Y0FD
ZXJ0aWZpY2F0ZT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3Jp
dHkwKAYIKwYBBQUHMAGGHGh0dHBzOi8vZGMxLnNlcmJhLmxvY2FsL29jc3AwGQYJ
KwYBBAGCNxQCBAweCgBTAHUAYgBDAEEwDQYJKoZIhvcNAQELBQADggIBAIiXoJzn
zgWfaRYu0Syv+dtXgx0HBEbfhGTGaC/cOdU1fH0xnimxf0W0LRskeYuJ+NinbigW
hz1Ld1wmdw4Q00qirE5WGeKqy34bV16HW4UY5WA4JUCWwMxjZdLz5+ecdfXxlBPt
eGt+exJrBMRpiviBhYgEEs+XG7S3BSDRRnUWDXqn1bU0r27OicTt2hUZjNo7qoip
M3s0/xzrI73Bim01VZckFcXp1aR9HZpENZnjxcbNQUtoJ8Tww5sbf9vbotRWpQST
HzqGglofK6v7oV2Vc3AA6aU8dwR4a3eAEgEPO3bjLM0J3iAelWVy91aItt+qK60N
gy7fDIU9xQtDcBB6tJrIQPj4vpPC+5p3aXBxE3RjVELNlcVtGqPZG0dXHPYwiOW/
6+822zkIpAnxnYK9qjEpQ0elq+gZZrS4SemWXoYHqn1pPxat7kFwPo6iOLd8GqbR
/UFLuK+uOfbTYZuUCjQgMdJGJhLKosvyE0ypOOsyAQubdd8CM8cQ8PGykl7DI65B
9yupU7ZL8mezjmFvBXEQ6NpyQDTlp/tLz5M1RvyvLVEl96kt/icIK/Yhbi05Vgbc
Hhp6T8l27qZIIaq1tfHSf03IXwbCKVj8zwl2NIbgpFBA8qswjhzEr2vIIUiWxZDQ
m5ao8O7bT+SX3vHSwgwXHprtI8omTkK7RhPI
-----END CERTIFICATE-----
---
Server certificate
subject=C = US, ST = California, L = Palo Alto, O = VMware, OU = VMware Engineering, CN = vhost1.serba.local, emailAddress = [email protected]
issuer=C = PL, ST = SL, L = Tychy, O = it.supra.tf, OU = IT, CN = vcenter.serba.local
---
No client certificate CA names sent
Peer signing digest: SHA512
Peer signature type: RSA
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3238 bytes and written 446 bytes
Verification error: unable to get local issuer certificate
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID:
Session-ID-ctx:
Master-Key: 9A160CF10EDEF17D1F972D3F2D1C0F5E9653F69C4D02F828EA9E05842945A246993339741750E7B3938CC9491C5A3D1C
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1594575144
Timeout : 7200 (sec)
Verify return code: 20 (unable to get local issuer certificate)
Extended master secret: no
---
Wynika to z błędu, który jest w ESXi chyba nawet w wersji 6.0. Wygląda na to, że nawet w 7.0 jest z tym problem. Ten problem pojawia się zarówno dla vCenter jak i dla hostów ESXi. Na ten moment myślę, że prostszym rozwiązaniem jest rozpropagowanie certyfikatu vCenter po hostach za pomocą polityki GPO. Gdy pojawi się do tego osobny poradnik, postaram się go tutaj podlinkować. Zainstalowałem sobie taki certyfikat lokalnie na maszynie umieszczając certyfikat do folderu Pośrednie urzędy certyfikacji oraz zmieniłem w Firefoxie zmienną security.enterprise_roots.enable na true i wygląda na to, że to rozwiązuje problem:
Drugą kwestią jest to, że możemy zwrócić uwagę na to, że podmiot wystawiający certyfikat ma totalnie inne parametry, niż definiowaliśmy. Wynika to z tego, że w vCenter 7.0 kreator nie pyta nas o te dane i wykorzystuje domyślne ustawienia vCenter. Te wartości można znaleźć w ustawieniach zaawansowanych vCenter:
Z istotnych opcji są:
vpxd.certmgmt.certs.cn.country – państwo podmiotu, ustawiam PL,
Na koniec dodam, że istnieje też odrobinkę prostszy proces generowania (to jest od 7.0) i opisali to państwo w tym poradniku. Jedno jest pewne – to, co jest opisane powyżej na 100% działa, bo wdrażałem to kilka razy. Nie miałem okazji testować jeszcze opcji przez przeglądarkę.
EDIT: jednak da się bezpośrednio wrzucać pliki na vCenter przez WinSCP. Aby to zrobić, należy wcześniej podpiąć się przez SSH do maszyny i wykonać polecenia:
Po zakończeniu można przywrócić domyślny shell poleceniem:
Po raz kolejny będziemy starać się zintegrować logowanie do środowiska vSphere po to, by móc się logować za pomocą kont z Active Directory. Dzięki temu po raz kolejny ograniczamy hasło, które musimy pamiętać. Fakt, można korzystać z menedżera haseł i przechowywałbym w nim hasło do kont lokalnych (np. w przypadku ESXi do konta root, w przypadku vCenter do konta [email protected] (chodzi o domyślne konto administracyjne vCenter, oczywiście zawsze można zmienić przy instalacji nazwę domeny, po prostu ta jest domyślna i często jest w środowiskach produkcyjnych pomimo wszystko).
Integracja SSO z VMware ESXi 7.0
Ogólnie integracja nie różni się w żaden sposób od wersji 6.5 i 6.7 – na początku należy mieć prawidłowo skonfigurowane serwery DNS:
By ustawić je, należy przejść do Networking > TCP/IP stacks, kliknąć na Default TCP/IP stack i wybrać Edit settings.
Zaznaczamy opcję Manually configure the settings for this TCP/IP stack i poniżej ustalamy opcje:
Host name – definiujemy tutaj nazwę hosta ESXi, w moim przypadku vhost1,
Domain name – tutaj wskazujemy domenę, do której ma należeć host, w moim przypadku serba.local. To jest po to, by móc określać FQDN hosta, czyli w tym przypadku vhost1.serba.local,
Primary DNS server – tutaj wstawiamy adres pierwszorzędnego kontrolera domeny,
Secondary DNS server – jeśli mamy drugi kontroler domeny – wstawiamy tutaj.
Search domains – tutaj dodałem serba.local, ta funkcja polega na tym, że jeśli na przykład chcemy się połączyć do serwera dc1 bez podania FQDNa w pełnej formie czyli host + domena to nasz host sam spróbuje dopisać domenę z search domains, czyli będzie wykonana próba połączenia do dc1.serba.local.
Zanim podłączymy hosta do domeny warto zwrócić uwagę na jeden szczegół w ustawieniach zaawansowanych ESXi – po dodaniu do domeny host sprawdza, czy w AD istnieje grupa o nazwie, która jest zdefiniowana w zmiennej Config.HostAgent.plugins.hostsvc.esxAdminsGroup w ustawieniach Manage > System > Advanced Settings. Domyślna wartość to ESX Admins, co oznacza, przy logowaniu do serwera ESXi ten będzie sprawdzał czy taka grupa istnieje oraz czy użytkownik, który się loguje znajduje się w tej grupie (przy czym działa też możliwość dodawania grup jako członków i dziedziczenie obiektów). Zawsze można ją zmienić na Administratorzy domeny lub Domain Admins (jeśli mamy anglojęzyczny Windows Server na którym postawiliśmy pierwszy kontroler domeny), dzięki czemu nie trzeba ustawiać w żaden sposób dodatkowych grup i od razu wszyscy admini w domenie mają możliwość logowania swoimi kontami.
Poniżej przykład rozwiązania kwestii domyślnej grupy, do której można jak wspomniałem dodać adminów domeny (jeśli chcemy zostawić wspomniane ustawienie z wartością domyślną):
Następnie przechodzimy do Manage > Security & Users, wybieramy Authorization i kilkamy Join Domain. Potem zostaje nam podać nazwę domeny w Domain Name oraz login i hasło do konta, które ma uprawnienia do dodawania komputerów do domeny. Po tym klikamy Join domain…
…i w ten sposób można zobaczyć efekt.
W ten sposób zalogowałem się na swoje konto z AD:
Integracja SSO z VMware vCenter 7.0
Pora na vCenter, gdzie podobnie możemy zintegrować logowanie z AD zarówno w interfejsie vCenter jak i w vCenter Server Management (interfejs na porcie 5480 z którego robimy aktualizację i kopie zapasowe vCenter).
Na początku trzeba upewnić się, że serwer DNS, który jest ustawiony w vCenter rozwiąże nazwę naszej domeny, więc do vCenter Server Management pod adresem https://<adres-vcenter>:5480, w moim przypadku: https://vcenter.serba.local:5480/#/login.
Następnie przechodzimy do Networking i klikamy na górze po prawej Edit:
Wybieramy interfejs vCenter i klikamy Next.
Następnie w Hostname and DNS określamy FQDN naszej maszyny (w moim przypadku vcenter.serba.local) i w DNS Settings wybieramy opcję Enter DNS settings manually, i podajemy adresy kontrolerów domeny, które nam rozwiążą nazwę domeny.
Na końcu podajemy poświadczenia administracyjne, dzięki których możemy zatwierdzić zmianę.
Po zmianie vCenter zrestartuje usługi sieciowe, poza tym te zmiany mogą wpłynąć na prawidłowe działanie środowiska, dlatego przed wykonaniem trzeba potwierdzić, że zrobiło się backup przed zmianami (co polecam zrobić!).
Następnie należy zalogować się do zwykłego interfejsu vCenter, przejść do Menu > Administration, następnie do Single Sign on > Configuration.
Tutaj, w zakładce Identity Provider należy wybrać Active Directory Domain i kliknąć Join AD przy wpisie z naszym adresem vCenter:
Potem wystarczy wpisać w Domain naszą nazwę domeny (w moim przypadku serba.local), Organization Unit jest opcjonalne i nie musimy go ustawiać (jest po to, by zmienić domyślny kontener, do którego trafia obiekt komputera vCenter w domenie, określa się go za pomocą DN, np. OU=Serwery,OU=it.supra.tf,DC=serba,DC=local). Ponadto podajemy poświadczenia użytkownika, który ma prawo do dodawania komputerów do domeny i klikamy Join.
Gdy nam się to uda, jesteśmy poproszeni o zrestartowanie vCenter w celu zatwierdzenia zmian:
Restart możemy wykonać za pomocą opcje Restart Guest (opcja wysyła sygnał do systemu operacyjnego zamiast natychmiast restartować maszynę wirtualną) lub możemy skorzystać z tej opcji w vCenter Server Management:
Po restarcie należy wrócić do miejsca, gdzie dodawaliśmy vCenter do domeny i w Identity Sources należy kliknąć Add i szczerze powiedziawszy to od razu można kliknąć Add, ponieważ domyślnie wszystko, co się zaznacza jest tym, co nas interesuje.
Potem można dodatkowo zmienić w tym menu domyślnego dostawcę logowania na AD zaznaczając go na liście oraz klikając Set as default, a następnie zatwierdzić klikając OK. To spowoduje, że logując się do vCenter nie musimy podawać UPN nazwy użytkownika (np. [email protected]), lecz wystarczy nazwa użytkownika (tzw. sAMAccountName, np. rserba):
Następnie w Administration > Access Control > Global Permissions należy dodać grupę, która będzie mogła zarządzać ustawieniami vCenter. Klikamy + i wskazujemy grupę w AD, która ma możliwość logowania i administracji. Ponadto działa tutaj dziedziczenie obiektów, więc można zawsze wskazywać grupy, których członkami są inne grupy, w której są dopiero nasi użytkownicy.
Wygląda to tak:
W ten sposób jestem w stanie się zalogować, ale niestety nie mam uprawnień do niektórych ustawień:
Problem wynika z tego, że nie jesteśmy w lokalnej grupie Administrators, która jest widoczna w vCenter 6.7 na liście, w przypadku vCenter 7.0 trzeba na dole po prawej przejść do następnej strony grup:
Grupy w vCenter 6.7
Poniżej animacja pokazująca jak dodać grupę Administratorzy domeny do grupy Administrators. Na tym etapie muszę zaznaczyć, że taką operację wykonujecie na własną odpowiedzialność, ponieważ VMware takiej opcji nie zaleca.
Po tej zmianie jak widać, mamy dostęp do wszystkich ustawień:
Tak samo możemy się od teraz logować kontami AD w vCenter Server Management, lecz tutaj logujemy się UPNem, czyli na przykład w moim przypadku kontem [email protected].
VMware Enhanced Authentication Plugin
vCenter pozwala na logowanie poprzez konto zalogowanego użytkownika na komputerze poprzez ten plugin. Wystarczy go pobrać, zainstalować i gotowe. Można to zrobić poprzez instalator, który znajdziemy na dole po prawej stronie w ekranie logowania:
Instalatora nie trzeba w żaden sposób konfigurować – idziemy wszędzie dalej i to się zainstaluje. Jedynie na początku dostajemy komunikat świadczący o tym, że po wykonaniu instalacji trzeba otworzyć na nowo przeglądarki, z których się używa.
Potem instalacja wygląda tak:
Koniec pierwszego instalatora odpala drugi, który można tak samo wyklikać.
Gdy mamy to już za sobą, możemy otworzyć na nowo przeglądarkę (w moim przypadku Google Chrome) i otworzyć stronę vCenter. Automatycznie po otwarciu Chrome spyta nas czy chcemy otworzyć program, do którego chce się dostać strona:
Następnie zatwierdzamy i otworzy się plugin, który nas spyta czy ufamy tej stronie. Z faktu, że tak dodatkowo zaznaczamy opcję Always ask before allowing this site i w ten sposób nie będziemy o to pytani ponownie.
Po tym wystarczy, że na ekranie logowania zaznaczymy Use Windows session authentication i nie musimy podawać loginu i hasła – po prostu klikamy Login.
Ten problem niestety jest przy każdym środowisku z Windowsem Server w domyślnej konfiguracji, lecz bez obaw – jest na to rozwiązanie. Problemem są wyłączone domyślne polityki firewalla w Windowsach, więc wystarczy je włączyć. Oczywiście robi się to polityką GPO, bo nie wyobrażam sobie takie coś wklepywać na 100 komputerach.
Należy włączyć następujące polityki firewalla w ruchu przychodzącym:
Instrumentacja zarządzania Windows (ruch przychodzący ASync)
Instrumentacja zarządzania Windows (ruch przychodzący DCOM)
Instrumentacja zarządzania Windows (ruch przychodzący WMI)
Zdalne zarządzanie usługami (RPC)
Zdalne zarządzanie usługami (RPC-EPMAP)
Zdalne zarządzanie zaplanowanymi zadaniami (RPC)
Zdalne zarządzanie Zaporą Windows Defender (RPC-EPMAP)
Na zrzucie ekranu można zobaczyć poniżej jak wyglądają ustawienia:
Oczywiście nie trzeba ich tworzyć ręcznie. Wystarczy otworzyć Zaporę Windows Defender z zabezpieczeniami zaawansowanymi, znaleźć pasujące nazwy i poprzeciągać do GPO. Od razu wszystko się ładnie doda. Po utworzeniu obiektu GPO można go na spokojnie przypiąć do korzenia drzewa AD, dzięki czemu obiekt będzie zmieniał ustawienia firewalla we wszystkich komputerach w domenie – tego chcemy.
Po tym należy odczekać 2 godziny, aż komputery kliencie same spróbują pobrać nową konfigurację GPO z domeny lub można zrestartować maszyny – to da nam ten sam skutek – maszyny będą miały zmienione ustawienia firewalla.
Gdyby ktoś był leniwy – tutaj kopia polityk, którą można sobie zaimportować. Do tego trzeba zrobić nowy obiekt, a potem kliknąć prawym i Importuj ustawienia….
Z istotnych rzeczy należy wybrać folder, w którym jest nasz plik ZIP z polityką.
Często we wdrożeniach SSL deep inspection jest pomijane, bo wdrażanie go jest upierdliwe. Osobiście uważam, że pomijanie wdrażania tej funkcjonalności to głupota. Aktualnie w sieci prawie 80% ruchu jest szyfrowana SSLem, więc bez takiego wdrożenia nie jesteśmy w stanie filtrować tego całego ruchu pod kątem potencjalnych zagrożeń, bo po prostu nie jesteśmy w stanie zaglądać bezinwazyjnie do ruchu użytkownika. Problem nie dotyczy stricte FortiGate, lecz dowolnego urządzenia, które takie filtrowanie robi (dzisiaj robi to każdy normalny UTM na rynku).
Dlaczego wdrożenie tego jest upierdliwe? FortiGate w ramach tej techniki rozszyfrowuje ruch pomiędzy klientem i serwerem, a następnie przed dotarciem do klienta ten ruch musi ponownie zaszyfrować, więc strony, które otwiera klient będą miały podpisane certyfikaty SSL przez FortiGate’a. To powoduje, że musimy mieć certyfikat CA FortiGate’a mieć zainstalowany na każdym komputerze wpadającym w regułę deep inspection.
W przypadku grupy roboczej rzeczywiście to może być piekło, ale w takiej sytuacji raczej większym zmartwieniem jest po prostu brak domeny Active Directory w organizacji. Teoretycznie można taki certyfikat CA FortiGate wysłać użytkownikom przez GPO, ale jest ogólnie lepsze rozwiązanie (można je zastosować tylko w przypadku posiadania wdrożonej domeny Active Directory) – użycie usług certyfikatów Active Directory. Można podpisać certyfikat dla podrzędnego urzędu certyfikacji, dzięki czemu ten z góry jest zaufany w naszych komputerach domenowych, bo główny urząd certyfikacji automatycznie jest dodawany po wdrożeniu do każdego komputera będącego w AD. W ten sposób nie trzeba dogrywać na komputerach klienckich żadnych dodatkowych certyfikatów.
Standardowo nie przedstawiam tutaj sposobu jak wdrażać AD CS, bo zakładam, że to już jest wdrożone (z dodatkową funkcją Rejestracja w sieci Web dla urzędu certyfikacji). Skupiam się tutaj nad samą częścią związaną z certyfikatem dla FortiGate’a. Na początku należy sobie wygenerować klucz prywatny oraz przygotować żądanie podpisania certyfikatu dla naszego nowego urzędu. Opisałem to tutaj, więc zalecam przejrzeć jak to się robi. W stosunku do tej stronki różnica w naszej konfiguracji jest taka, że tutaj moje pole CN i DNS.1 posiada wartość fortigate.serba.local, ponieważ tak się nazywa FQDN mojego urządzenia.
Po utworzeniu CSRki dostaniemy plik z podobną zawartością jak ta:
To jest nasze żądanie i te musimy przesłać do urzędu certyfikacji, by podpisać certyfikat. Wchodzimy na adres http://<adres-ca>/certsrv, w moim przypadku https://dc1.serba.local/certsrv:
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 Podrzędny urząd certyfikacji. Po tym klikamy Prześlij >.
Na końcu pobieramy plik 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.
Mając oba certyfikaty, należy je dodać w FortiGate. Po zalogowaniu się do urządzenia należy przejść do sekcji System > Certificates i tam kliknąć Import > CA Certificate:
Po prawej stronie otworzy nam się menu, w Type wybieramy File i w Upload wskazujemy plik, a następnie zatwierdzamy:
W ten sposób CA jest dodane, więc dodatkowo warto też zmienić nazwę certyfikatu w FortiGate, by móc ją łatwiej w ustawieniach odnajdywać, co opisałem tutaj. Następnie dla certyfikatu podrzędnego CA należy zamiast Import > CA Certificate wybrać Import > Local Certificate. W Type wybieramy Certificate, następnie w Certificate file wybieramy plik certyfikatu, potem w Key file wybieramy klucz prywatny, który był wykorzystywany przy tworzeniu CSR i ewentualnie podajemy hasło do klucza. Ponadto można w Certificate Name z góry przypisać nazwę certyfikatu. Finalnie wygląda to tak:
Jak widać CA zostało dodane:
Dzięki temu możemy wykorzystywać nowy certyfikat podrzędny CA w SSL deep inspection:
Jako część mojej pracy inżynierskiej musiałem skonfigurować mechanizm uwierzytelniania oparty o domenę Active Directory. Założeniem było to, by użytkownicy z podłączonymi komputerami do domeny miały móc się logować bez jakiegokolwiek problemu do dwóch sieci Wi-Fi oraz do portów na switchu. Postaram się opisać jak wszystko skonfigurować od zera.
W każdym przypadku potrzebujemy serwera RADIUS. Są tutaj różne opcje, ponieważ można zainstalować serwer FreeRadius, lecz z faktu, że korzystałem w tym projekcie ze środowiska bazującego na Windowsach skorzystałem z roli Serwera zasad sieciowych (Network Policy Server).
Mechanizm działania jest dosyć prosty: użytkownik wykonuję próbę połączenia się z siecią po czym dostaje odpowiedź od urządzenia (access point lub switch), że musi się dodatkowo autoryzować i ten próbuje dokonać autoryzacji swoim kontem komputera lub aktualnie zalogowanego użytkownika w AD. Access point/switch komunikują się z serwerami RADIUS będąc ich klientami w celu sprawdzenia czy dany użytkownik ma mieć prawo do korzystania z zasobu (definiuje się to na podstawie grup użytkowników/komputerów). W trakcie połączenia klienta RADIUS z serwerem ci wykorzystują klucz współdzielony w celu uwierzytelnienia się. W przypadku, gdy użytkownik jest w grupie zdefiniowanej dla zasady przypisanej do klienta RADIUS – dostaje połączenie. W innym przypadku zostaje odrzucony.
Zanim zaczniemy instalować NPSa musimy mieć wcześniej wdrożony urząd certyfikacji (Usługi certyfikatów Active Directory). Myślę, że wkrótce taki poradnik pojawi się na mojej stronie (jeśli tak się stanie to dodam link tutaj do niego). Tak czy siak, gdy mamy to za sobą to instalujemy tą rolę:
Wybieramy Instalacja oparta na rolach lub oparta na funkcjach. Potem wybieramy serwer z listy, klikamy Dalej > i wybieramy Usługi zasad sieciowych i dostępu sieciowego i Dodaj funkcje. Potem Dalej >, Dalej >, Dalej > i Zainstaluj.
Po tym rola powinna być zainstalowana i powinniśmy zacząć konfigurację serwera.
Konfiguracja RADIUS dla sieci Wi-Fi na FortiGate
W tym scenariuszu będę bazował na urządzeniu FortiWiFi 60E, które ma wbudowaną kartę bezprzewodową. Na początku należy otworzyć okno Serwera zasad sieciowych, po czym zdefiniować nową zasadę poprzez wybranie w oknie Konfiguracja standardowa opcję Serwer usługi RAIDUS na potrzeby bezprzewodowych i przewodowych połączeń 802.1X i klikamy Skonfiguruj połączenia 802.1X.
Na dobrą sprawę nie ma znaczenia czy wybierzemy połączenia bezprzewodowe czy nie, bo i tak będziemy modyfikować zasadę tak, by brała pod uwagę adres IP klienta RADIUS zamiast przeznaczenia, ale z faktu, że to miało być dla Wi-Fi zaznaczamy opcję Bezpieczne połączenia bezprzewodowe i nazywamy jakoś zasadę, np. fortigate wifi.
Na następnej karcie kreatora należy zdefiniować klientów RADIUS, którzy będą się łączyli w ramach zasady RADIUS. Na początku nie ma żadnych, więc należy dodać przyciskiem Dodaj… nowego. Po tym należy zdefiniować pole Przyjazna nazwa, która jest po prostu nazwą klienta, a następnie adres IP lub jego FQDN. Z faktu, że dla moich klientów mam wcześniej przygotowane nazwy DNS, wpisałem po prostu fortigate.serba.local, co w moim przypadku odpowiada adresowi 192.168.30.1. Po tym definiujemy wspólny klucz tajny na dole okienka dwa razy. Powinien być długi i powinniśmy sobie go zapisać, bo taki klucz też trzeba będzie zdefiniować w FortiGate. Po tym zapisujemy i idziemy dalej.
Następnie wybieramy typ protokołu EAP dla tworzonej przez nas zasady i tutaj wybieram opcję Microsoft: Chroniony protokół EAP (PEAP). Gdy klikniemy Konfiguruj…, możemy sprawdzić lub zmienić jaki certyfikat będzie wykorzystywany przy komunikacji z klientem. W moim przypadku certyfikat był już wskazany, a ten się wygenerował po postawieniu AD CS (automatycznie, wystarczyło zrestartować serwer i mogłem się cieszyć certem z własnego urzędu).
Następnie należy dodać grupy, które mogą się autoryzować w ramach tej zasady. W moim założeniu dostęp mają wszyscy użytkownicy i wszystkie komputery będące w domenie, więc dodajemy grupy Użytkownicy domeny oraz Komputery domeny tak jak ja poniżej:
Następny punkt wykonuje się tylko i wyłącznie w przypadku FortiGate’a – definiujemy przesyłany parametr tekstowy, który służy do identyfikacji sieci. To działa tak, że FortiGate jest w stanie szukać polityki z konkretnym parametrem. Jeśli w różnych sieciach autoryzujemy różne grupy, możemy mieć takie ciągi znaków różne w różnych regułach, np. siec-handlowcy i siec-marketing, dzięki czemu dwie grupy mogą być inaczej brane pod uwagę przy logowaniu.
W oknie Konfigurowanie elementów kontroli ruchu w sieci klikamy po prawej Konfiguruj…, następnie wybieramy kartę Atrybuty specyficzne dla dostawcy. Domyślnie jest zdefiniowany jeden o nazwie atrybutu Ventor-Specific, klikamy na niego i Edytuj…. Po tym pojawi się okno Informacje o atrybutach i tutaj klikamy Dodaj…, a następnie otworzy się kolejne okno (szał!) Informacje o atrybutach specyficznych dla dostawcy i tutaj należy podać kod dostawcy 12356, zaznaczyć opcję Tak, jest zgodny pod kątem zgodności z RADIUS RFC i kliknąć Konfiguruj atrybut…. Tutaj zmieniamy Format atrybutu na Ciąg i wpisujemy wartość, którą chcemy określić daną politykę, byśmy mogli ją potem wskazać w FortiGate. W moim przypadku to wifi-fortigate. Ten parametr jest ogólnie opcjonalny; zobaczycie za niedługo dlaczego. Po tym wszędzie klikamy OK i Dalej na końcu.
Okienny rozgardiasz związany z milionem podopcji.
W ten sposób mamy prawie wszystko gotowe po stronie serwera:
Pod koniec trzeba zmienić nieco parametry warunkowe dla naszej zasady. Otwieramy Zasady żądań połączeń, znajdujemy naszą zasadę, klikamy prawym i Właściwości. W karcie Warunki usuwamy wszystko i klikając na dole Dodaj… dodajemy nowy warunek: Adres IPv4 klienta dostępu. Po tym jeszcze raz Dodaj… i tutaj podajemy adres IP naszego FortiGate’a.
Końcowo powinno wyglądać to tak (jeśli u Was też to tak wygląda to można zapisać ustawienia):
Po tym warto zmienić jeszcze 1 rzecz: metody uwierzytelnieniaw w zasadach sieciowych. W Zasady > Zasady sieciowe odnajdujemy naszą zasadę, klikamy na nią prawym i Właściwości. W zakładce Ograniczenia, w opcji Metody uwierzytelnienia odznaczamy opcje uwierzytelnianie z szyfrowaniem firmy Microsoft (MS-CHAP) i zostawiamy zaznaczone Uwierzytelnianie z szyfrowaniem firmy Microsoft wersja 2 (MS-CHAP-v2). Jeśli macie tak, jak na zrzucie ekranu – można zapisać.
Nie można zapomnieć o tym, by odblokować port dla RADIUSa na firewallu. Ruch musi być odblokowany dla portów TCP i UDP 1812, 1813, 1645, 1646 (dwa ostatnie dla starych urządzeń) dla połączeń przychodzących i wychodzących pomiędzy serwerem RADIUS a jego klientami (w naszym przypadku FortiGate, AP i switch z Netgear). Ja akurat zrobiłem na taką potrzebę politykę GPO:
Po zapisaniu wystarczy kliknąć prawym OU, w którym znajdują się serwery NPS (w moim przypadku są postawione na kontrolerze domeny) i wybrać Aktualizacja zasad grupy…, a następnie potwierdzić.
Efekty widać tutaj:
Tak samo odblokowujemy ruch do reguł wychodzących.
W interfejsie FortiGate, w User & Authentication > RADIUS Servers należy kliknąć Create New i zdefiniować profil w przykładzie jak niżej, przy czym w moim przypadku w IP/Name podałem FQDNy serwerów NPS, które posiadam (skonfigurowałem tak samo drugi serwer, by mieć redundancję, na koniec pokażę jak skopiować z serwera drugi wszystkie ustawienia). Do tych serwerów w polu Secret definiujemy klucz tajny, który definiowaliśmy na początku w zasadzie.
Następnie, po zapisaniu tych ustawień należy w User & Authentication > User Groups należy utworzyć grupę klikając Create New oraz w Remote Groups kliknąć Add, potem z listy Remote Server wybieramy wcześniej zdefiniowany profil RADIUSa i w Groups wybieramy Any jeśli nie chcemy określać się co do zasad, które zdefiniowaliśmy lub wybierając Specify możemy określić parametr, który zdefiniowaliśmy wcześniej w polu specyficznym dla dostawcy (w naszym przypadku wifi-fortigate).
Mając to trzeba edytować profil SSID w WiFi & Switch Controller > SSIDs lub stworzyć nowy klikając Create New > SSID. W Name definiujemy nazwę profilu (w moim przypadku (serba-corp-wifi), potem w WiFi Settings, w SSID definiujemy nazwę WiFi (w moim przypadku serba.local), w Security Mode wybieramy WPA2 Enterprise i w Authentication należy wybrać RADIUS Server i wybrać profil, który wcześniej zdefiniowaliśmy (w moim przypadku serba.local_radius). Mając zdefiniowane SSID możemy je przypisać do FortiAPków lub do interfejsu Software Switch, w którym są interfejsy, którym są podłączeni użytkownicy przewodowo. Poniżej przykład:
W ten sposób możemy zalogować się do sieci Wi-Fi nawet przez telefon z Androidem:
Tutaj ustawienia z telefonu. Warto dodać certyfikat CA do telefonu, by móc go wybrać.
I tutaj efekt końcowy.
Efekt końcowy widoczny z komputera, który jest członkiem AD:
Możemy to też przygotować wcześniej dodatkową polityką GPO, która dodaje sieć Wi-Fi o naszym SSID tak jak w zrzucie ekranu poniżej, ponadto niżej też konfiguracja zabezpieczeń dla profilu:
Konfiguracja RADIUS dla sieci Wi-Fi na AP od Netgear
Przykład jest prezentowany na urządzeniu Netgear WAC505. Scenariusz jest prawie taki sam, jak w przypadku definicji zasady dla FortiGate’a z drobną różnicą – nie definiujemy żadnego atrybutu specyficznego dla urządzenia i definiujemy dodatkowego klienta RADIUS na początku kreatora. Tak samo definiujemy inne ustawienia. W mojej konfiguracji klient posiada FQDN wac.serba.local, który odpowiada adresowi IP 192.168.30.253. Ten model, który mamy w przykładzie obsługuje też konfigurację przez chmurę, ja akurat definiuję ustawienia lokalnie. Pewnie jak bym miał takich access pointów 10 to definiowałbym to przez chmurę, bo łatwiej wszystko skonfigurować.
Na początku w w Configuration > Security > RADIUS Settings definiujemy adresy IP serwerów RADIUS, porty wykorzystywane do komunikacji oraz klucze współdzielone.
Potem, w Configuration > Wireless > Basic w karcie WLAN Settings należy wybrać SSID, w którym chcemy umożliwić na autoryzację kontami AD i wybrać w Network Authentication opcję WPA2-enterprise.
Po tym możemy dodać tak samo profil Wi-Fi jak w przypadku FortiGate’a. Jak widać poniżej, sieć działa:
I widok z komputera będącego w AD:
Konfiguracja RADIUS dla sieci przewodowej ze switchem marki Netgear
W tym scenariuszu wdrożenia posługiwałem się przełącznikiem Netgear GS716T.
Scenariusz wygląda bardzo podobnie jak w poprzednich politykach – tworzymy nową zasadę na serwerze zasad sieciowych (NPS) korzystając z opcji Bezpieczne połączenia przewodowe (Ethernet) w oknie Wybieranie typu połączeń 802.1X, usuwamy warunki połączenia klienta dla zasad żądań połączeń i definiujemy adres klienta jako adres switcha (w moim przypadku jest to adres netgear.serba.local (192.168.30.254).
Tak wyglądają warunki dla zasad żądań połączeń:
Tak wyglądają dla zasad sieciowych:
I tak wygląda profil klienta RADIUS dla switcha:
Dalsza część jest do ustawienia na switchu. Zaczynamy od zdefiniowania adresów DNS, które mają być wykorzystywane przez przełącznik (w System > Management > DNS > DNS Configuration) poprzez dodanie wszystkich adresów kontrolerów domeny w naszej sieci. Po wpisaniu wartości w puste pole należy kliknąć na dole Add.
Następnie w System > Management > IP Configuration należy się upewnić, że adres IP switcha się pokrywa z tym, który zdefiniowaliśmy w zasadzie w NPSie. W naszym przypadku jest w porządku.
Następnie w Security > Management Security > RADIUS > Server Configuration należy dodać wpisy adekwatne do środowiska:
Server Address: dc1.serba.local
Authentication Port: 1812
Secret Configured: Yes
Secret: tutaj podajemy klucz współdzielony
Active: Primary/Secondary, wybieramy w zależności tego, który serwer ma być wykorzystywany w autoryzacji w pierwszej kolejności
Message Authenticator: Disable
Po tym klikamy na dole Add i tak samo dodajemy serwer dc2.serba.local. Efekt końcowy wygląda tak:
Następnie w Security > Management Security > Authentication List > Dot1x Authentication List należy ustawić dla pola dot1xList w kolumnie 1 wartość Radius. i zatwierdzić kliknięciem Apply.
Teraz, w Security > Port Authentication > Advanced > Port Authentication należy zdefiniować w kolumnie Port Control odpowiednią opcję. Możliwości to:
Auto – ustawienie zależy od globalnego ustawienia pod kątem autoryzacji (ustawimy je na końcu). W domyślnych ustawieniach przełącznika autoryzacja nie jest wymagana.
Authorized – podłączone urządzenia w tym trybie nie przechodzą żadnej autoryzacji nawet, gdy ta jest włączona globalnie.
Unauthorized – brak możliwości autoryzacji pod wskazanym portem.
MAC Based – ustawienia są bazowane na tym, co jest zdefiniowane w ACL dla adresów MAC.
Dla wykonania testu ustawiłem port 1 i 2 w trybie Auto, resztę w trybie Authorized. Dzięki temu możemy na 2 portach testować czy komunikacja z RADIUS działa poprawnie, by potem móc ja włączyć dla reszty switcha.
Na końcu, w Security > Port Authentication > Advanced > 802.1X Configuration włączamy opcję Port Based Aurthentication State i zapisujemy klikając Apply. W ten sposób wszystko jest skonfigurowane po stronie switcha, więc zobaczmy efekty na urządzeniu, które jest w AD i urządzeniu, które w nim nie jest.
Obsługa 802.1X w Windowsie jest domyślnie wyłączona, więc włączamy ją zmienieniem ustawień usługi Automatyczna konfiguracja sieci przewodowej zmieniając Typ uruchomienia na Automatyczny oraz klikając Uruchom, by zaczęła działać.
Wygodniej jest stworzyć politykę GPO, która to nam ustawi na każdym komputerze, więc ta powinna mniej więcej wyglądać tak (dodam, że w tej polityce zmiana ustawień usługi WlanSvc okazała się niepotrzebna):
Tutaj można zobaczyć efekt końcowy:
Ponadto, w Security > Port Authentication > Advanced > Port Summary można zobaczyć, że na porcie 1 Port Status to Authorized:
W przypadku komputera, który nie jest członkiem AD akcja wygląda tak:
Niedawno się tym zajmowałem i w sumie dobrze by było się podzielić takim skryptem. Jest on nieco zmodyfikowany w stosunku, do tego co znalazłem na tej stronie.
Na początku próbka danych, która powinna być zapisana w pliku CSV:
firstname;lastname;username;email;streetaddress;city;zipcode;state;country;department;password;telephone;jobtitle;company;ou
Miron;Trawiński;mtrawinski;[email protected];aleja Niepodległości 49;Tychy;43-100;śląskie;PL;Handlowy;Zaq12wsx!;32 776 33 33;Specjalista ds. handlowych;it.supra.tf;OU=Handlowy,OU=it.supra.tf,DC=serba,DC=local
Mikołaj;Staszewski;mstaszewski;[email protected];aleja Niepodległości 49;Tychy;43-100;śląskie;PL;Handlowy;Zaq12wsx!;32 776 33 33;Specjalista ds. handlowych;it.supra.tf;OU=Handlowy,OU=it.supra.tf,DC=serba,DC=local
Adam;Rekowski;arekowski;[email protected];aleja Niepodległości 49;Tychy;43-100;śląskie;PL;Handlowy;Zaq12wsx!;32 776 33 33;Specjalista ds. handlowych;it.supra.tf;OU=Handlowy,OU=it.supra.tf,DC=serba,DC=local
Joachim;Grabiński;jgrabinski;[email protected];aleja Niepodległości 49;Tychy;43-100;śląskie;PL;Handlowy;Zaq12wsx!;32 776 33 33;Specjalista ds. handlowych;it.supra.tf;OU=Handlowy,OU=it.supra.tf,DC=serba,DC=local
Norbert;Ewertowski;newertowski;[email protected];aleja Niepodległości 49;Tychy;43-100;śląskie;PL;Handlowy;Zaq12wsx!;32 776 33 33;Specjalista ds. handlowych;it.supra.tf;OU=Handlowy,OU=it.supra.tf,DC=serba,DC=local
Aureliusz;Wręczycki;awreczycki;[email protected];aleja Niepodległości 49;Tychy;43-100;śląskie;PL;Handlowy;Zaq12wsx!;32 776 33 33;Specjalista ds. handlowych;it.supra.tf;OU=Handlowy,OU=it.supra.tf,DC=serba,DC=local
Heronim;Ambroży;hambrozy;[email protected];aleja Niepodległości 49;Tychy;43-100;śląskie;PL;Handlowy;Zaq12wsx!;32 776 33 33;Specjalista ds. handlowych;it.supra.tf;OU=Handlowy,OU=it.supra.tf,DC=serba,DC=local
Piotr;Jaroszek;pjaroszek;[email protected];aleja Niepodległości 49;Tychy;43-100;śląskie;PL;Handlowy;Zaq12wsx!;32 776 33 33;Specjalista ds. handlowych;it.supra.tf;OU=Handlowy,OU=it.supra.tf,DC=serba,DC=local
Miłosz;Szcześniak;mszesniak;[email protected];aleja Niepodległości 49;Tychy;43-100;śląskie;PL;Handlowy;Zaq12wsx!;32 776 33 33;Specjalista ds. handlowych;it.supra.tf;OU=Handlowy,OU=it.supra.tf,DC=serba,DC=local
Eustachy;Kowalewski;ekowalewski;[email protected];aleja Niepodległości 49;Tychy;43-100;śląskie;PL;Handlowy;Zaq12wsx!;32 776 33 33;Specjalista ds. handlowych;it.supra.tf;OU=Handlowy,OU=it.supra.tf,DC=serba,DC=local
Dorian;Kłopotowski;dklopotowski;[email protected];aleja Niepodległości 49;Tychy;43-100;śląskie;PL;Handlowy;Zaq12wsx!;32 776 33 33;Specjalista ds. handlowych;it.supra.tf;OU=Handlowy,OU=it.supra.tf,DC=serba,DC=local
Olgierd;Zaniewski;ozaniewski;[email protected];aleja Niepodległości 49;Tychy;43-100;śląskie;PL;Handlowy;Zaq12wsx!;32 776 33 33;Specjalista ds. handlowych;it.supra.tf;OU=Handlowy,OU=it.supra.tf,DC=serba,DC=local
Gracjan;Zambrzycki;gzambrzycki;[email protected];aleja Niepodległości 49;Tychy;43-100;śląskie;PL;Handlowy;Zaq12wsx!;32 776 33 33;Specjalista ds. handlowych;it.supra.tf;OU=Handlowy,OU=it.supra.tf,DC=serba,DC=local
Fabian;Ciura;fciura;[email protected];aleja Niepodległości 49;Tychy;43-100;śląskie;PL;Handlowy;Zaq12wsx!;32 776 33 33;Specjalista ds. handlowych;it.supra.tf;OU=Handlowy,OU=it.supra.tf,DC=serba,DC=local
Piotr;Skonieczny;pskonieczny;[email protected];aleja Niepodległości 49;Tychy;43-100;śląskie;PL;Handlowy;Zaq12wsx!;32 776 33 33;Specjalista ds. handlowych;it.supra.tf;OU=Handlowy,OU=it.supra.tf,DC=serba,DC=local
Poniżej tworzenie OU oraz użytkowników w CSV (warto zwrócić uwagę, że pozycja Państwo jest zdefiniowana jako PL, a nie Polska ze względu na to, że w tym polu daje się Country Code.
<#Import active directory module for running AD cmdlets#>
Import-Module activedirectory
<#Create main OU#>
$baseDN = "DC=SERBA,DC=LOCAL"
$baseOU = "OU=it.supra.tf"
$baseOUstring = $baseOU + "," + $baseDN
<#New-ADOrganizationalUnit -Name "SUPRA" -Path $baseOU#>
if (Get-ADOrganizationalUnit -Filter "distinguishedName -eq '$baseOUstring'") {
Write-Host "$baseOUstring already exists."
} else {
New-ADOrganizationalUnit -Name $baseOU -Path $baseDN
}
<#Create OU's#>
$OUs = @("Dyrekcja","Handlowy","Marketing","Ksiegowosc","Rozwojowy","Prawny","Logistyczny","Techniczny")
<#Loop through each name of the OU to create them#>
foreach ($OUcreate in $OUs) {
$fullOUstring = "OU=" + $OUCreate + "," + $baseOUstring
Write-Output $fullOUstring
if (Get-ADOrganizationalUnit -Filter "distinguishedName -eq '$fullOUstring'") {
Write-Host "$OUcreate already exists."
} else {
New-ADOrganizationalUnit -Name $OUcreate -Path $baseOUstring
}
}
<#Store the data from ADUsers.csv in the $ADUsers variable#>
$ADUsers = Import-csv -Delimiter ";" -Path .\bulk-users-polska.csv
<#Loop through each row containing user details in the CSV file#>
foreach ($User in $ADUsers)
{
<#Read user data from each field in each row and assign the data to a variable as below#>
$Username = $User.username
$Password = $User.password
$Firstname = $User.firstname
$Lastname = $User.lastname
$OU = $User.ou <#This field refers to the OU the user account is to be created in#>
$email = $User.email
$streetaddress = $User.streetaddress
$city = $User.city
$zipcode = $User.zipcode
$state = $User.state
$country = $User.country
$telephone = $User.telephone
$jobtitle = $User.jobtitle
$company = $User.company
$department = $User.department
$Password = $User.Password
<#Check to see if the user already exists in AD#>
if (Get-ADUser -F {SamAccountName -eq $Username})
{
<#If user does exist, give a warning#>
Write-Warning "A user account with username $Username already exist in Active Directory."
}
else
{
<#User does not exist then proceed to create the new user account
Account will be created in the OU provided by the $OU variable read from the CSV file#>
New-ADUser `
-SamAccountName $Username `
-UserPrincipalName "[email protected]" `
-Name "$Firstname $Lastname" `
-GivenName "$Firstname" `
-Surname "$Lastname" `
-Enabled $True `
-DisplayName "$Firstname $Lastname" `
-Path "$OU" `
-City "$city" `
-Company "$company" `
-State "$state" `
-StreetAddress "$streetaddress" `
-Country "$country" `
-PostalCode "$zipcode" `
-OfficePhone "$telephone" `
-EmailAddress "$email" `
-Title "$jobtitle" `
-Department "$department" `
-AccountPassword (convertto-securestring $Password -AsPlainText -Force) -ChangePasswordAtLogon $False -PasswordNeverExpires $True -CannotChangePassword $True
}
}
Get-ADUser -Filter 'Name -like "*"' -SearchBase 'OU=it.supra.tf,DC=SERBA,DC=LOCAL' -Properties DisplayName | ForEach-Object {Set-ADUser $_ -Office 'SERBA Downtown'}
Get-ADUser -Filter 'Name -like "*"' -SearchBase 'OU=Techniczny,OU=it.supra.tf,DC=SERBA,DC=LOCAL' -Properties DisplayName | ForEach-Object {Set-ADUser $_ -Office 'SERBA Headquarters'}
Get-ADUser -Filter 'Name -like "*"' -SearchBase 'OU=Dyrekcja,OU=it.supra.tf,DC=SERBA,DC=LOCAL' -Properties DisplayName | ForEach-Object {Set-ADUser $_ -Office 'SERBA Headquarters'}
I na koniec tworzenie kont w Exchange dla tych użytkowników (istotne – ten skrypt musi być odpalony przez Exchange Management Shell):
Import-Module activedirectory
Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn
<#adding everyone in that specified company#>
$users = Get-ADUser -Filter {company -eq "it.supra.tf"}
Write-Output $users
foreach($user in $users)
{
Enable-Mailbox -Identity $user.SamAccountName
}
