Interpreter/Parser logów NPS(RADIUS)

28 października 2015 at 22:38

Kontynuując wątek rozpoczęty w poprzednik wpisie (http://mkrzanowicz.pl/?p=485) pozostajemy w tematyce sieci komputerowych, VLANów, 802.1x, RADIUS’a, NPS’a… We wcześniejszym wątku opisałem krótko zmagania z dziwnym przypadkiem użytkownika nieobsługiwanego poprawnie przez polityki sieciowe na serwerze MS NPS (Network Policy Server). Metoda dojścia do rozwiązania była dosyć partyzancka, bo polegała na porównywaniu wszystkich parametrów kont użytkownika, któremu wszystko działało poprawnie oraz tego, którego dotyczył problem. Oczywiście najważniejsze że udało się rozwiązać problem, jednak mimo wszystko istotny jest czas rozwiązywania podobnych przypadków. To skłoniło mnie do głębszego sięgnięcia w dokumentację oraz zapisy standardów. Okazuje się że logi NPS/IAS/RADIUS w wydaniu Microsoftu są bardzo ciekawie skomponowane. W relatywnie niewielkim rozmiarze zawartych jest ogrom informacji potrzebnych do weryfikacji ewentualnych problemów, raportowania, statystyk etc. Chociaż będąc uczciwym trzeba przyznać że pierwszy kontakt z tą formą logowania informacji powoduje reakcję typu „WTF?” albo skłania do domysłów o co chodzi. Potem następuje przegrzebywanie dokumentacji w poszukiwaniu informacji i manualne rozszyfrowywanie poszczególnych pozycji… Aż w końcu rodzi się myśl czy nie można tego zrobić lepiej, szybciej, automatycznie? Zacznijmy od składni takiego loga. Przykładowy wpis wygląda tak: „10.10.10.4,anonymous,10/12/2015,13:06:10,IAS,RADIUS1,6,2,12,1500,30,50-50-A8-D3-C1-EE,38,5C-97-0E-DD-F2-55,61,15,5,50130,87,GigabitEthernet1/4,4,10.10.10.4,4108,10.10.10.4,4116,9,4128,switch1,4154,NAP 802.1X (Wired),4155,1,4129,MKrzanowicz\anonymous,4130,MKrzanowicz\anonymous,4132,,25,311 1 10.10.10.11 09/11/2015 06:09:17 39763,4127,5,4136,1,4142,0” Trochę adresów IP, trochę adresów MAC, trochę kont domenowych, data i godzina i „jakieś cyferki” Po zagłębieniu się […]

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

© Marcin Krzanowicz