Powoli Startujemy

PS powoli staje się podstawą całego zarządzania serwerami Microsoft. Wszystkie większe produkty dostarczają już commandlety, a większość w ogóle jest pisana na bazie PS – okienka zarządzania to zwykłe formatki uruchamiające skrypty. To oznacza, iż bez znajomości PS będzie ciężko – dużo ciężej niż kiedyś, bez znajomości CMD. Zgodnie z powiedzeniem “jak sobie
pościelisz - tak się wyśpisz” [bardziej wolę tę drugą wersję - “to mnie zawołaj”, ale tutaj nie pasuje (; ] – jak sobie skonfigurujesz środowisko PS, tak Ci się będzie pracowało. ‘Z pudełka’ niestety[?] nie powala na kolana – standardowe kolory i kłopoty z fontami utrudniają pracę, skryptów nie da się uruchamiać, nie da się również nigdzie połączyć zdalnie. Jak już się doda możliwość zdalnego połączenia, to jest się zsandboxowanym do lokalnego środowiska.

Pomijając filozoficzne rozterki dotyczące decyzji takich a nie innych ustawień standardowych [większość tłumaczona jest bezpieczeństwem], pozostaje je zmienić po swojemu. Uczynić środowisko przyjaznym. Oto podstawowe kroki, które postaram się opisać w tej części:

  • włączenie skryptów
  • uruchomienie zdalnych połączeń

Tylko dwa punkty – te najważniejsze, bez których środowisko jest praktycznie nie-do-użytku dla administratora.

Żeby nie przepisywać Internetu, wszystkie informacje są w bardzo podstawowej formie – zakładam, że chodzi o automatyzację i globalną konfigurację, a nie pojedynczy serwer. Dla tych, którzy potrzebują więcej szczegółów, na końcu znajdują się linki do dalszej lektury.

Powłączaj Skrypty

Aby obronić system przed administratorem, zakłada się, że jest on ... niemądry. Biorąc pod uwagę statystyki, to wcale nie jest złe założenie (; Aby zatem
przekonać system, że wiesz, co robisz, musisz zmienić politykę uruchamiania skryptów, która standardowo nie pozwala na ich uruchamianie. Opcję można
włączyć dla wszystkich serwerów via GPO:

  • Computer Configuration (lub User Configuration) | Administrative Templates | Windows Components | Windows PowerShell | Turn On Script Execution

Trochę smutne, że to jest jedyna opcja dla PS, jaką można skonfigurować bezpośrednio w GPO ): Mam nadzieję, że za jakiś czas w tej części pojawią się dodatki, ułatwiające życie administratorom. Do wyboru są 3 poziomy bezpieczeństwa:

  • Allow only signed: to niewątpliwie najbezpieczniejsze ustawienie i jak to z bezpiecznymi rozwiązaniami bywa, tak i tutaj, nie jest przyjazne w codziennej pracy. Aby korzystać ze skryptów, należy wygenerować certyfikat z użyciem ‘code signing’ i każdy skrypt podpisać. Aby przy każdej drobnej zmianie nie musieć w kółko podpisywać skryptu – co zwłaszcza w procesie tworzenia jest co najmniej uciążliwe – prawidłowo, powinno się skonfigurować ‘serwer roboczy’. Na takim serwerze skrypty można tworzyć i testować, na koniec
    podpisać i umieścić w repozytorium. Na pozostałych serwerach korzystać z owego repozytorium. Piękne, ale bardzo wymagające.
  • Allow local scripts and remote signed scripts: skrypty napisane lokalnie uruchamiają się, natomiast te ściągnięte z Internetu tylko, jeśli są podpisane zaufanym certyfikatem. To IMHO najbardziej ‘ludzkie’ podejście [jeśli ufa się samemu sobie (; ] i wygodne. Trzeba oczywiście wziąć pod uwagę również zaufanie do współpracowników. Jeśli skrypty mają wymóg podpisywania, możemy zdefiniować, kto je tworzy, wydając lub nie odpowiedni certyfikat. Natomiast przy tej opcji nie mamy już kontroli nad źródłem skryptu.
  • Allow all scripts: niezalecane nawet przy poluzowanej polityce bezpieczeństwa. Każdy zassany skrypt, zawsze warto najpierw przejrzeć.

#Pomocne Skróty

  • aby dowiedzieć się więcej o podpisywaniu: get-help About_Signing
  • konfiguracja podpisywania certyfikatem: scripting guy

Połączenia Sdalne

Możliwość korzystania z PS tak, jak z SSH, wymaga trochę więcej wysiłku. Do zdalnej sesji wykorzystywany jest winRM. Aby móc zestawić zdalną sesję PS trzeba włączyć tzw. listener dla usługi - czyli usługa musi w ogóle oczekiwać na połączenia. Operacja jest tak samo prosta jak w przypadku polityki podpisywania, z tą jednak różnicą, że w tym przypadku warto [wręcz trzeba!] zainwestować chwilę w konfigurację certyfikatów tak, aby sesje były szyfrowane. Windows Remote Shell (winRS) wykorzystuje połączenie HTTP:5985 lub HTTPS:5986. W celu zestawienia kanału szyfrowanego niezbędny jest certyfikat SSL oraz konfiguracja przy pomocy skryptów - to opiszę w przyszłości. Należy:

  • włączyć listenera:
    • Computer Configuration | Administrative Templates | Windows Components | Windows Remote Management (WinRM) | WinRM Service | Allow automatic configuration of listeners
    • Computer Configuration | Administrative Templates | Windows Components | Windows Remote Management (WinRM) | WinRM Service | Turn On Compatibility HTTP Listener - DISABLED
  • zrobić wyjątek dla Firewall w
    • Computer Configuration | Windows Settings | Security Setting | Windows Firewall with Advanced Security
    • jest predefiniowana reguła dla winRM podczas konfiguracji polisy Firewall, więc nie trzeba ręcznie wpisywać portów.

Kolejnym krokiem jest konfiguracja wymiany uwierzytelnień credSSP. CredSSP to provider uwierzytelniający, wprowadzony wraz z Vista, który zastąpił starą GINA. Standardowo delegacja uprawnień jest wyłączona i po zdalnym zalogowaniu nie da się np, skopiować czegoś na zdalny serwer. Jest się uwięzionym lokalnie na zdalnym serwerze. To mocno utrudnia pracę,  warto zatem ułatwić sobie życie i włączyć delegację. Opcję trzeba włączyć dla obu końców - klient musi ich używać, a serwer musi je akceptować:

  • Computer Configuration | Administrative Templates | Windows Components | Windows Remote Management (WinRM) | WinRM Client | Allow CredSSP authentication
  • Computer Configuration | Administrative Templates | Windows Components | Windows Remote Management (WinRM) | WinRM Service | Allow CredSSP authentication

Post Scriptum

Tyle na początek. W kolejnej części chciałbym przekazać kilka wskazówek jak skonfigurować samo środowisko – czyli kolory, aliasy itd. Oczywiście centralnie – tak, żeby czas
poświęcić raz i pracować wygodnie w całym środowisku.

#Pomocne Skróty

eN.

autor: nExoR