Hasło DSRM powiązane z użytkownikiem domenowym

2 września 2015 at 08:02

Hasło DSRM (Directory Services Restore Mode) przez wielu administratorów jest (NIESTETY) traktowane po macoszemu. Często sprowadza się to do jego wpisania przy promowaniu kontrolera domeny i zapomnieniu. W niektórych wypadkach wynika to z przekonania, że przecież zawsze owe hasło można zmienić poceniem:

– Zawsze – pod warunkiem, że usługi katalogowe działają prawidłowo i możesz je wystartować! O tym już mało kto pamięta… W pozostałych przypadkach wynika z przekonania, że AD zawsze będzie działać prawidłowo, że to przecież prosta usługa i nic się z nią złego nie dzieje, a w razie czego odtworzy się z backupu – taa jasne… powodzenia Na szczęście już jakiś czas temu Microsoft pomyślał o takich Kamikaze i wydał Hotfix’a umożliwiającego synchronizację hasła DSRM z kontem użytkownika domenowego. (Poprawka dla systemów Windows Server 2008; nowsze mają ją już wbudowaną). Poprawkę można znaleźć pod linkiem: https://support.microsoft.com/en-us/kb/961320 Jak działa ta funkcjonalność? 1. Należy utworzyć dowolnego użytkownika domenowego (bez dodawania do żadnych grup typu Domain Admins, Enterprise Admis etc.) 2. Zainstalować ww. Hotfix’a na kontrolerach domeny po czym je zrestartować. (Jeśli mamy nowsze niż 2008 ten krok pomijamy). 3. Zalogować się interaktywnie na kontrolerze domeny i wprowadzić następujące polecenia:

I gotowe. Nie ma konieczności wprowadzania starego ani nowego hasła […]

GPO – Filtr WMI uwzględniający Windows 10

10 sierpnia 2015 at 16:41

Jako, że Windows 10 jest już oficjalnie wydany – czas najwyższy na przygotowanie swoich środowisk do poprawnej współpracy z najnowszym dzieckiem Microsoftu. Ostatnio przygotowaliśmy WSUS’a – tym razem zaktualizujemy swoje filtry WMI wykorzystywane w GPO tak aby uwzględniały  również Windows’a 10. Większość z nas pewnie w swoich środowiskach dla wybranych ustawień korzysta z filtru WMI wyodrębniającego z grupy komputerów jedynie stacje z systemem świeższym niż (Windows Vista, Windows 7), które wyglądają następująco: Świeższe niż Vista:

Świeższe niż Windows 7:

Puryści natomiast dorzucą jeszcze do zapytania „ProductType” określający, czy system jest kliencki (=”1″) czy serwerowy (=”3″) i w efekcie zapytanie wygląda:

I na pierwszy rzut oka wydaje się, że zasadniczo obecne filtru będą działać poprawnie, bo przecież Windows 10 ma wyższą wersję systemu operacyjnego – pozory… Spójrzmy na Tabelkę z wersjami systemów operacyjnych: System Operacyjny Numer wydania Windows XP/ Windows Server 2003 5.1 lub 5.2 Windows Vista/ Windows Server 2008 6.0 Windows 7 / Windows Server 2008 R2 6.1 Windows 8 / Windows Server 2012 6.2 Windows 8.1 / Windows Server 2012 R2 6.3 Windows 10 / Windows Server 2016 10.0 Z naszego punktu widzenia jest OK – nowszy system, wyższy numer. Niestety z punktu widzenia WMI jest zupełnie inaczej. […]

Nie można odnaleźć zasobu $(string. * ), do którego odwołuje się atrybut displayName. Plik *.admx

27 kwietnia 2015 at 16:50

Kolejny dzień – kolejne problemy do rozwiązania Tym razem problemy z GPO, a ściślej mówiąc z widocznością ustawień i możliwością ich edycji. Podczas próby podglądu czy edycji ustawień GPO użytkownicy otrzymywali groźnie wyglądające błędy typu: Na szczęście sytuacja nie była zła, bo zasady grup działały, aplikowały zmiany itd. Co ciekawe na kontrolerach domeny problem nie występował – tam można było normalnie przeglądać i edytować ustawienia wszystkich GPO: Gdzie jest więc „pies pogrzebany”? W tym środowisko funkcjonuje Central Store for Group Policy Admin Templates, więc nie była to kwestia poszczególnego kontrolera domeny. Zostały również sprawdzone uprawnienia użytkownika per konkretne GPO i plik ADMX z definicją – wszystko było OK… Podmienione zostały nawet wybrane pliki ADMX – bez efektu… Sprawa niby nie pilna, bo zasadniczy mechanizm GPO działał prawidłowo, natomiast mocno irytująca dla operatorów GPO. Test na spostrzegawczość – czym jeszcze różnią się zrzut działający od tego, który nie działał jak powinien? Bingo – językiem A więc mimo opisu wskazującego na uszkodzenie plików ADMX – w istocie problem stanowiły pliki ADML odpowiadające za „reprezentację” zasad w danym języku. Prawdopodobnie ktoś podczas aktualizacji folderu „PolicyDefinitions” na SYSVOL’u zapomniał o wgraniu aktualnych plików ADML lub podczas odtwarzania/przywracania plików rozjechały się ich tłumaczenia. Jak można […]

Krytyczna podatność Active Directory

16 lutego 2015 at 12:01

Miniony tydzień oferował w wykryte luki bezpieczeństwa systemów Windows a także poprawki mające załatać te podatności. Jedną z najistotniejszych jest możliwość podszycia się pod zasoby udostępniane na kontrolerach domeny i wykonanie w ten sposób dowolnego kodu w kontekście konta systemu… Zostały udostępnione dwie poprawki w ramach biuletynu zabezpieczeń: MS15-011 Konkretnie są to poprawki: kb3004375 oraz kb3000483. Ich instalacja zabezpiecza klientów przed możliwością wykonania ataku, ale mimo wszystko nie zapewnia bezpieczeństwa całej domeny, bo nigdy nie ma pewności, że ktoś nie wyciągnie „gołego” lub nieaktualizowanego rok czasu systemu z szafy i nie wepnie się nim w naszą sieć z Active Directory. Aby temu zaradzi i podnieść poziom bezpieczeństwa należy wykonać następujące akcje: 1. Zainstalować ww. krytyczne poprawki bezpieczeństwa na kontrolerach domeny (wymagany restart serwerów) 2. Włączyć wzajemne uwierzytelnianie dla zasobów udostępnianych na kontrolerach domeny. 3. Włączyć wymaganie integralności SMB Dla domen, w których pracują tylko serwery Windows Server 2012 i wyższe oraz klienci Windows 8 i wyżsi – można dodatkowo włączyć wymaganie prywatności razem z szyfrowaniem żądań ścieżek SMB.   Plan działania wygląda w miarę prosto, ale jak zwykle gdzieś leży haczyk – a właściwie dwa haczyki. Pierwszym z nich jest GPO. Teoretycznie wystarczy dodać ustawienie w GPO: W gałęzi: Computer […]

Stacja nie przetwarza poprawnie GPO

9 lutego 2015 at 13:04

W przypadku, gdy stacja robocza z uporem maniaka nie chce przetwarzać w poprawny sposób obiektów zasad grup (GPO) – mimo, że wszystkie znaki na niebie i ziemi wskazują na to, że stacja powinna GPO przetworzyć (poprawna jednostka, uprawnienia, WMi itd..) OK. Zaczynamy od samej stacji roboczej: 1. uruchamiamy cmd 2. wykonujemy polecenie:

I otrzymujemy piękny błąd: Oczywiście można klikać linki i szukać rozwiązania w raportach ale… zależy nam na czasie, więc: Przechodzimy do katalogu:C:\ProgramData\Microsoft\Group Policy\History\ (Pod warunkiem, że dysk ‚C:\’ jest dyskiem systemowym ) Usuwamy całą zawartość ww. katalogu. Wykonujemy kolejny raz polecenie:

I wszystko działa jak należy: Świat uratowany

© Marcin Krzanowicz