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

Hurtowe przywracanie maili z Dumpster’a – Exchange

12 października 2015 at 19:16

W pracy każdego Sys-admin’a zdarzają się użytkownicy, którzy przez nieuwagę/pośpiech wykonują rzeczy niesamowite Niektórzy jednak mają do tego wrodzone uzdolnienia… Tym razem sytuacja związana z Outlookiem, pocztą, Exchange’m i właśnie „uzdolnioną inaczej” osobą. W wyniku bliżej nieokreślonych czynności wykonanych przez naszego zdolniachę – wszystkie wiadomości ze skrzynki ‚X’ został usunięte (również z kosza). Ot niby nic nadzwyczajnego. Zawsze można przywrócić manualnie maile z poziomu Outlooka, czy OWA. Przyjmujemy przy tym że Single-Item-Recovery jest wyłączone. Problem stanowi jednak ilość maili do przywrócenia. Jeśli przywraca się kilka-kilkanaście maili na raz to nie ma problemu. Przy większej ilości interfejs ma tendencję do zawieszania. Co jednak zrobić, gdy nasz zdolniacha usunął kilka(naście) tysięcy wiadomości? Zostawić go z GUI na dwie noce – niech sobie zapamięta żeby tego więcej nie robić? Zasadniczo to byłoby pouczające i zapamiętałby lekcję do końca życia… ale nie można być aż tak okrutnym. OK pomóżmy naszemu uzdolnionemu użytkownikowi: 1. Nadajemy sobie pełne uprawnienia do skrzynki „Discovery Search Mailbox” 2. Nadajemy sobie rolę/grupę „Discovery Management” 3. Nadajemy sobie uprawnienia do skrzynki, którą uzdolniony użytkownik wykastrował z maili. 4. Wykonujemy przeszukiwanie usuniętych maili ze skrzynki np uzdolniony.uzytkownik@mkrzanowicz.pl

5. Podpinamy skrzynkę użytkownika oraz skrzynkę „Discovery Search Mailbox” do Swojego Outlooka 6. Kopiujemy […]

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

Brakujące Template’y Certyfikatów

27 sierpnia 2015 at 14:21

Po reinstalacji/wykonaniu upgrade’u/ zastąpieniu urzędu certyfikatów CA wszystkie usługi są świadczone poprawnie, ale większość szablonów certyfikatów jest niewidoczna z poziomu konsolek do zarządzania usługami. Nie pomagają restarty usług, serwerów itp. Należy wykonać polecenie:

Podając jako parametr „templatename” nazwę „zaginionego” template’u. Należy powtórzyć kolejno dla wszystkich szablonów. Po wykonaniu powyższych komend wszystkie szablony są dostępne i widoczne

© Marcin Krzanowicz