Brak dostępu do VLAN’ów z wykorzystaniem serwera RADIUS/NPS

26 października 2015 at 10:45

Podczas wdrażania rozwiązania dostarczającego funkcjonalności 802.1x, czyli dynamicznego przełączania VLAN’ów w zależności od zdefiniowanych reguł dotyczących użytkownika domenowego Active Directory, gdzie rolę serwera RADIUS pełni Microsoftowe rozwiązanie NPS (Network Policy Server) w przypadku wybranej grupy użytkowników pojawiał się problem. Polegał on na tym, że w logach IAS widoczne były eventy świadczące o prawidłowym żądaniu/przydzielaniu VLAN,a  mimo to stacja lądowała w VLANie Guestowym ze statusem portu (no-response, timeout, not-autorized …). Wyeliminowane zostały wszystkie zmienne takie jaki różnic a w konfiguracji switcha, różnice w polisach sieciowych, inne gniazdka sieciowe, kable, stacja robocza… pozostał tylko i wyłącznie użytkownik. Ale co z nim było nie tak? Dlaczego inne osoby logujące się na tej stacji otrzymywały poprawne VLAN’y? Jedyną „zmienną” pozostała konfiguracja konta użytkownika. Pozostało więc zrzucanie i porównywanie wszystkich atrybutów konta użytkownika, któremu rozwiązanie 802.1x działa prawidłowo oraz takiego dotkniętego problemem. Po kilku minutach analizy znaleziony został winny. Użytkownik miał ustawiony na swoim koncie atrybut: msNPAllowDialin = $false Niektórzy zastanawiają się co uprawnienie „Allow Dial-In” ma wspólnego z niedziałającym dostępem 802,.1x? Wystarczy rozszyfrować nazwę serwera RADIUS = „Remote Authentication Dial In User Service” i wszystko staje się jasne, chociaż przyczyna była dosyć niejasna… Metoda dojścia do rozwiązania dosyć mocno „partyzancka”, ale ważne że skuteczna. […]

Błąd ADMX „‚Microsoft.Policies.Sensors.WindowsLocationProvider’ is already defined”

17 września 2015 at 13:17

Wraz z nadejściem Windows’a 10 (długo potem…) nadeszły szablony ADMX do zarządzania ustawieniami systemu z wykorzystaniem GPO. Zmienił się nieco sposób dystrybucji do SYSVOL’a, który teraz wymaga zainstalowania pakietu na stacji bądź serwerze i wyciągnięcie szablonów z dedykowanego folderu – to wcale nie jest ułatwieniem – ale nie w tym rzecz. Niestety po nadpisaniu starszych ADMX’ów, przy próbie edycji dowolnego GPO oczom ukazują się błędy: W sumie nic istotnego i błąd można śmiało zignorować klikając OK, natomiast pedantyczny i purystyczny admin takiego widoku nie zniesie… Rozwiązaniem są trzy proste kroki 1. Usunięcie plików „LocationProviderADM.admx” oraz „LocationProviderADM.adml” z SYSVOL’a 2. Zmiana nazwy pliku definicji z „Microsoft-Windows-Geolocation-WLPAdm.admx” na „LocationProviderADM.admx” 3. Zmiana nazw plików definicji języków z „Rename Microsoft-Windows-Geolocation-WLPAdm.adml” na „LocationProviderADM.adml”

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 […]

Brak spójności replikacji SYSVOL

26 sierpnia 2015 at 09:43

Podczas debugowania problemów ze środowiskiem Active Directory działającym pod kontrolą systemów Windows Server 2012 R2 w oko wpadł zgłaszany problem z replikacją danych SYSVOL. Mianowicie wykonanie polecenia weryfikującego:

Zwracało błąd informujący, że jeden z kontrolerów domeny nie znajduje się w stanie „ELIMINATED”: DC1 (‚Waiting For Initial Sync’) – Writable DC Hmm.. dziwne – zwłaszcza, że środowisko AD nie pamięta czasów FRS’a i nigdy nie była przeprowadzana migracja z FSR’a na DFS’a… Szybki przegląd dzienników zdarzeń – brak błędów. Próby organoleptyczne zmian zawartości SYSVOL – dane są replikowane na wszystkie kontrolery domeny zarówno zmieniając dane na kontrolerze dotkniętym problemem jak i pozostałych. Co robić? Jak żyć? Wystarczyło wymusić replikację danych:

I wszystkie błędy odeszły w niepamięć

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. […]

© Marcin Krzanowicz