Zmiany w Azure AD Connect

Ponad rok w aplikacji Azure AD Connect nie widać było żadnych aktualizacji, ale ostatnie miesiące przyniosły istotne zmiany, na które warto zwrócić uwagę i zaaplikować jak najszybciej, zwłaszcza w konktekście znalezionych podatności oraz wygasającego wsparcia dla poszczególnych komponentów.

Wchodząc na stronę historii wersji Azure AD Connect, zobaczymy, że dostępne są dwie ścieżki:

• Azure AD Connect 2.0, do instalacji na serwerze w wersji Windows Server 2016 lub nowszej,
• Azure AD Connect 1.6, do instalacji na starszych wersjach systemu (które już wyszły ze wsparcia lub za chwilę wyjdą)

Co nowego przynosi wersja 2.0? Jest kilka istotnych zmian, w komponentach, które wykorzystuje nowa wersja (więcej informacji w dokumentacji produktu):

• lokalna baza danych w wersji SQL Server 2019 LocalDB. Instalowany w wersji 1.x SQL Server 2012 wychodzi ze wsparcia w lipcu 2022.
• biblioteka uwierzytelnienia MSAL zamiast ADAL, która będzie wycofana w czerwcu 2022,
• TLS 1.2 jako domyślny i jedyny protokół zabezpieczania transmisji (TLS 1.0 i 1.1 są od dluższego czasu oznaczane jako podatne na ataki) - przed aktualizacją musimy ustawić obsługę protokołu TLS w odpowiedniej wersji,
• Visual C++ Redist 14 jako komponent niezbędny dla SQL 2019

Jak możemy zrobić upgrade? Oczywiście jest możliwy upgrade in-place, jeżeli oczywiście mamy serwer w co najmniej wersji 2016, po zakończeniu aktualizacji musimy pamiętać jednak o odinstalowaniu komponentów SQL 2012. Niestety auto-upgrade nie zadziała, musimy pobrać najnowszą wersję produktu i uruchomić proces instalacji samemu.

Po zweryfikowaniu konfiguracji serwera i instalacji dodatkowych składników, kreator poprosi nas o wprowadzenie poświadczeń administratorskich i przejdzie do kroku finalnego (kolejny rysunek).

Możemy również wykorzystać ścieżkę eksportu i importu konfiguracji, kiedy na przykład musimy zmienić wersję systemu operacyjnego. Proces jest dobrze opisany w dokumentacji.

CLM - Ograniczanie możliwości Powershell w środowisku firmowym

Powershell jest moim ulubionym językiem skryptowym, bardzo popularny na platformie Windows i w chmurze, stopniowo zadomawia się również w środowiskach Linux, stał się również zamiennikiem powłoki systemu operacyjnego Windows. Taka popularność rodzi obawy przed możliwymi zagrożeniami, więc warto zastanowić się jak można poprawić bezpieczeństwo środowiska? Od wersji 3.0 wprowadzono w Powershell możliwość włączenia trybu Constrained Language Mode (CLM), co powoduje znaczące ograniczenie możliwości wywołania bardziej zaawansowanych mechanizmów języka (bardziej szczegółowy opis ograniczeń można znaleźć w artykule https://devblogs.microsoft.com/powershell/powershell-constrained-language-mode).

Cmdlety wykonują się poprawnie, jednak przy wywołaniu skryptu możemy zobaczyć komunikat:

Cannot invoke method. Method invocation is supported only on core types in this language mode.

Czyli włączenie CLM, będzie skutkowało koniecznością zweryfikowania wszystkich skryptów, które są wykonywane w tak chronionym kontekście, a nawet zmodyfikowania pliku profilowego.

No dobrze, ale dobrze jest wiedzieć, jak włączyć CLM w naszym środowisku. W ramach pojedynczej sesji Powershell wystarczy wykonać komendę:

$ExecutionContext.SessionState.LanguageMode = "ConstrainedLanguage"

Oczywiście, jeżeli uruchomimy drugą sesję Powershell to będzie ona działać w trybie standardowym. Możemy również ponownie zmienić tryb pracy na pełny komendą

$ExecutionContext.SessionState.LanguageMode = "FullLanguage"

Możemy również ustawić zmienną środowiskową __PSLockDownPolicy na wartość 4.  Jednak zalecanym rozwiązaniem w środowisku domenowym Active Directory jest użycie polis GPO, włączając odpowiednie polisy - AppLocker dla komputerów Windows 7 lub nowszych, ewentualnie Windows Defender Application Control dla Windows 10.

Przykładowo, dla applockera tworzymy polisę, w której definiujemy reguły dla skryptów (rysunek poniżej), nie możemy również zapomnieć o wymuszeniu stosowania polisy (kolejny rysunek).

Wymuszenie konfiguracji komputera przez GPO jest trudne do obejścia, nawet dla osoby mającej uprawnienia administracyjne. Warto w takim przypadku spojrzeć na szczegóły polisy opisującej konfigurację applockera dla skryptów. Przy włączonym wymuszeniu stosowania polisy na naszym komputerze, będzie działać tryb CLM we wszystkich lokalizacjach oprócz dopuszczonych przez polisę, gdzie będzie działać pełny tryb języka. Przy domyślnych regułach lokalni administratorzy mogą uruchamiać skrypty bez ograniczeń, a pozostali użytkownicy tylko z folderów Windows i Program Files, ale jeżeli domyślne reguły zostały zmienione, to dobrze jest to sprawdzić, chociażby podglądając ustawienia polisy w konsoli Group Policy Management, jak pokazuje rysunek poniżej.