Listowanie atrybutów i typów atrybutów obiektów Active Directory

25 lutego 2016 at 11:23

Dla potrzeb dokumentacji systemu pojawiła się konieczność wy-listowania wszystkich atrybutów przypisanych do danej klasy obiektów Active Directory oraz typów danych, które mogą być wprowadzane jako wartości tych atrybutów. Zadanie niby proste, ale jednak mało oczywiste… Próbując odpytać o atrybuty konkretnego użytkownika w następujący sposób:

Otrzymamy co prawda wszystkie (albo prawie wszystkie) atrybuty obiektu, jednak otrzymamy również część nieistniejących w schemacie atrybutów. Są to atrybuty interpretowane przez polecenie typu „AccountIsDisabled”, „AccountIsLockedOut” , które nie występują jako atrybuty obiektu klasy użytkownik w Active Directory, lecz wynikają z wartości atrybutu „userAccountControl”. Podejście drugie – natywny powershell do AD

I znowu kicha… tym razem mamy mniej interpretowanego przez Powershella Outputu, ale wyświetliły się tylko parametry, które mają jakąś wartość Jak więc rozwiązać ten problem? Na przykład w następujący sposób:

W ten sposób uzyskamy ładny widok wszystkich atrybutów z informacjami o ich GUID’ach o tym czy są indeksowane etc. Dane będą wyglądać mniej więcej tak: Jedyną niedogodnością jest fakt, że musimy odpytać niejako 2 razy o atrybuty dla danej klasy (raz o atrybuty obowiązkowe, raz o atrybuty opcjonalne) aby mieć komplet danych. Enjoy

DNS Cache – cóż to za „zwierz”? :)

14 stycznia 2016 at 19:35

W ostatnim czasie kilka razy miałem okazję rozwiązywać problemy (lub brać udział w konsultacjach) związanych bezpośrednio lub pośrednio z rozwiązywaniem nazw. Mechanizmy związane z rozwiązywaniem nazw (m.in. DNS) wydaj się być proste i przejrzyste, jednak okazuje się, że często panują „miejskie legendy” i ogromne kłopoty z namierzeniem źródeł niepoprawnego/nieoczekiwanego działania usług. Słowem wstępu rozwińmy kilka definicji, żeby uniknąć niedomówień i wątpliwości: DNS (ang. Domain Name System) – System nazw domenowych lub jak kto woli system rozwiązywania nazw. Strefa wyszukiwania do przodu (ang. Forward Lookup Zone) –  strefa DNS, która służy do rozwiązywania nazw DNS typu: mkrzanowicz.it na adresy IP: 185.38.248.202Strefa wyszukiwania do tyłu (ang. Reverse Lookup Zone) – strefa DNS, która służy do rozwiązywania adresów IP na nazwy DNS. I tutaj uwaga, w zależności od tego czy mamy zarejestrowane rekordy PTR, czy nie (oraz ile mamy ich zarejestrowanych dla podanego adresu IP) wyniki mogą być nieoczekiwane. Posłużmy się przykładem mojego bloga: Chcieliśmy się dowiedzieć co kryje się pod adresem IP: 185.38.248.202 i oczekiwaliśmy, że zwróci odpowiedź mkrzanowicz.it a zwrócił… nazwę serwera hostingującego… W moim przypadku nie ma z tym problemu – na pytanie, czy tak ma wyglądać Wasz wewnętrzny DNS musicie odpowiedzieć sobie sami, aczkolwiek cytując klasyka „nie wydaje mnie […]

Obszar nazw Microsoft.Policies.WindowsStore jest już zdefiniowany…

23 listopada 2015 at 13:27

Niechlubna seria związana z pomyłkami, niedopatrzeniami, niedoróbkami, błędnym tłumaczeniem oraz innymi błędami w definicjach ADMX/ADML, które zostały udostępnione wraz z Windowsem 10 niestety trwa w najlepsze… Pierwszy problem: http://mkrzanowicz.pl/?p=491 Drugi problem: http://mkrzanowicz.pl/?p=328 Trzeci problem: http://mkrzanowicz.pl/?p=479 Więc być może do czterech razy sztuka? Oby… Tym razem kolejny problem dotyczy definicji Office’a: https://www.microsoft.com/en-us/download/details.aspx?id=49030 Po ich wgraniu na SYSVOL pojawia się znajomy (ale inny) błąd: Co zrobić? Rozwiązanie jak zwykle jest podobne, z tym że dotyczy innej definicji. Tym razem padło na „parę” WindowsStore.admx/WindowsStore.adml oraz WinStoreUI.admx/WinStoreUI.adml Czyli sprowadza się do usunięcia plików: 1. \\Twoja.domena\sysvol\Twoja.domena\Policies\PolicyDefinitions\WinStoreUI.admx 2. \\Twoja.domena\sysvol\Twoja.domena\Policies\PolicyDefinitions\pl-pl\WinStoreUI.adml 3.  \\Twoja.domena\sysvol\Twoja.domena\Policies\PolicyDefinitions\en-US\WinStoreUI.adml Zmian nazw plików: 4. \\Twoja.domena\sysvol\Twoja.domena\Policies\PolicyDefinitions\WindowsStore.admx na \\Twoja.domena\sysvol\Twoja.domena\Policies\PolicyDefinitions\WinStoreUI.admx 5. \\Twoja.domena\sysvol\Twoja.domena\Policies\PolicyDefinitions\pl-pl\WindowsStore.amdl na \\Twoja.domena\sysvol\Twoja.domena\Policies\PolicyDefinitions\pl-pl\WinStoreUI.adml 6. \\Twoja.domena\sysvol\Twoja.domena\Policies\PolicyDefinitions\en-US\WindowsStore.amdl na \\Twoja.domena\sysvol\Twoja.domena\Policies\PolicyDefinitions\en-US\WinStoreUI.adml   Rozpropagowania zmian w AD:

i cieszenia się, że znowu (na jakiś czas, do kolejnej wersji definicji… 😉 ) wszystko działa poprawnie bez irytujących komunikatów o błędach.

Powiadomienia replikacyjne Active Directory między lokacjami

12 listopada 2015 at 12:24

Jak zapewne wiadomo replikacja danych w środowisku Active Directory dzieli się w najprostszym ujęciu na replikację: Wewnątrz-lokacyjną – (Intra-Site) Między-lokacyjną – (Inter-Site) O ile z tą pierwszą zazwyczaj nie występują problemy ze względu na świetnie działający mechanizm KCC (Key Consistency Checker) oraz ze względu na fakt, że replikacja danych w obrębie lokacji odbywa się niemalże natychmiast. Więcej problemów sprawia natomiast drugi rodzaj replikacji danych. Przykład: http://mkrzanowicz.pl/?p=417 W tym wpisie chciałbym się jednak skupić na czasie a dokładniej mówiąc interwale replikacji danych pomiędzy lokacjami. Gdy pada (moje ulubione pytanie 😉 ) „Jaki jest najkrótszy czas replikacji danych między lokacjami AD” – 90% ludzi odpowiada „15 minut”… Patrząc na pobieżne artykuły dla początkujących administratorów, czy przeklikując się przez GUI, które informuje administratora o dozwolonych wartościach: Czy jest to jednak prawdą? I tak i nie Jeśli mamy świadomość tego jak replikacja danych Active Directory działa na niższych warstwach to wiemy, że prawdą to nie jest. Jeśli natomiast trzymamy się „płytkiej wiedzy” to będzie to prawdą – i w sumie niech tak pozostanie, bo administratorzy bez świadomości i znajomości mechanizmów replikacji danych nie powinni dotykać ustawień opisywanych niżej. Wracając jednak do „niższych warstw”. Oprócz replikacji „standardowej” czyli obejmującej zwykłe zakładanie kont, zmiany parametrów, maili […]

Nie można odnaleźć zasobu $(string.SUPPORTED_Vista_through_Win7) …

3 listopada 2015 at 12:47

Od czasu wprowadzenia Windowsa 10 do środowisk produkcyjnych aż po dzień dzisiejszy widoczne są niedoróbki związane z development’em tego systemu operacyjnego czy jego poszczególnych komponentów a także wspieralności i kompatybilności z wcześniejszymi wersjami systemów. Tym razem kolejny problem z szablonami zasad grup (pierwszy opisywany: http://mkrzanowicz.pl/?p=328 ) Oczywiście można te błędy zignorować i klikać za każdym razem „OK” ale nie jest to zbyt profesjonalne. Dzisiaj na tapetę bierzemy kolejny błąd tj: Źródło błędów jest podobne jak w poprzednim artykule o błędach, natomiast poprzednie rozwiązanie w tym wypadku nie zadziała… Co robić? Jak żyć? Ano trzeba poprawić developerów/tłumaczy Microsoftu i dopisać jedną linijkę do pliku z definicjami językowymi (adml). Co prawda błąd ewidentnie odwołuje się do definicji ADMX, konkretnie do linijki, która wygląda tak” „          <definition name=”SUPPORTED_Vista_through_Win7″ displayName=”$(string.SUPPORTED_Vista_through_Win7)”>„ Ale w rzeczywistości problemem jest brak wpisu w definicji językowej, która przetłumaczy czym jest „SUPPORTED_Vista_through_Win7„. Poprawmy więc developerów/tłumaczy Należy przejść do edycji pliku znajdującego się na SYSVOL’u w ścieżce: „\\Nazwa_Domeny\SYSVOL\Nazwa_Domeny\Policies\PolicyDefinitions\pl-pl\PreviousVersions.adml” I dopisać: „<string id=”SUPPORTED_Vista_through_Win7″>Vista i 7</string>” Np. w tym miejscu przed końcem pliku: Oczywiście zreplikować dane na wszystkie kontrolery domeny i cieszyć się brakiem denerwujących błędów 😉

© Marcin Krzanowicz