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. To doświadczenie jednak skłoniło mnie do napisania Parsera logów ms-NPS /RADIUS/IAS, dzięki któremu podobne przypadki mogą być widoczne wprost bazując na logach NPS’a

Ale o tym w kolejnych wpisach :)