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.

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ęć

Nie można odnaleźć zasobu $(string. * ), do którego odwołuje się atrybut displayName. Plik *.admx

27 kwietnia 2015 at 16:50

Kolejny dzień – kolejne problemy do rozwiązania Tym razem problemy z GPO, a ściślej mówiąc z widocznością ustawień i możliwością ich edycji. Podczas próby podglądu czy edycji ustawień GPO użytkownicy otrzymywali groźnie wyglądające błędy typu: Na szczęście sytuacja nie była zła, bo zasady grup działały, aplikowały zmiany itd. Co ciekawe na kontrolerach domeny problem nie występował – tam można było normalnie przeglądać i edytować ustawienia wszystkich GPO: Gdzie jest więc „pies pogrzebany”? W tym środowisko funkcjonuje Central Store for Group Policy Admin Templates, więc nie była to kwestia poszczególnego kontrolera domeny. Zostały również sprawdzone uprawnienia użytkownika per konkretne GPO i plik ADMX z definicją – wszystko było OK… Podmienione zostały nawet wybrane pliki ADMX – bez efektu… Sprawa niby nie pilna, bo zasadniczy mechanizm GPO działał prawidłowo, natomiast mocno irytująca dla operatorów GPO. Test na spostrzegawczość – czym jeszcze różnią się zrzut działający od tego, który nie działał jak powinien? Bingo – językiem A więc mimo opisu wskazującego na uszkodzenie plików ADMX – w istocie problem stanowiły pliki ADML odpowiadające za „reprezentację” zasad w danym języku. Prawdopodobnie ktoś podczas aktualizacji folderu „PolicyDefinitions” na SYSVOL’u zapomniał o wgraniu aktualnych plików ADML lub podczas odtwarzania/przywracania plików rozjechały się ich tłumaczenia. Jak można […]

Krytyczna podatność Active Directory

16 lutego 2015 at 12:01

Miniony tydzień oferował w wykryte luki bezpieczeństwa systemów Windows a także poprawki mające załatać te podatności. Jedną z najistotniejszych jest możliwość podszycia się pod zasoby udostępniane na kontrolerach domeny i wykonanie w ten sposób dowolnego kodu w kontekście konta systemu… Zostały udostępnione dwie poprawki w ramach biuletynu zabezpieczeń: MS15-011 Konkretnie są to poprawki: kb3004375 oraz kb3000483. Ich instalacja zabezpiecza klientów przed możliwością wykonania ataku, ale mimo wszystko nie zapewnia bezpieczeństwa całej domeny, bo nigdy nie ma pewności, że ktoś nie wyciągnie „gołego” lub nieaktualizowanego rok czasu systemu z szafy i nie wepnie się nim w naszą sieć z Active Directory. Aby temu zaradzi i podnieść poziom bezpieczeństwa należy wykonać następujące akcje: 1. Zainstalować ww. krytyczne poprawki bezpieczeństwa na kontrolerach domeny (wymagany restart serwerów) 2. Włączyć wzajemne uwierzytelnianie dla zasobów udostępnianych na kontrolerach domeny. 3. Włączyć wymaganie integralności SMB Dla domen, w których pracują tylko serwery Windows Server 2012 i wyższe oraz klienci Windows 8 i wyżsi – można dodatkowo włączyć wymaganie prywatności razem z szyfrowaniem żądań ścieżek SMB.   Plan działania wygląda w miarę prosto, ale jak zwykle gdzieś leży haczyk – a właściwie dwa haczyki. Pierwszym z nich jest GPO. Teoretycznie wystarczy dodać ustawienie w GPO: W gałęzi: Computer […]

CPasswords i zmiana haseł w GPO

27 stycznia 2015 at 07:07

Od czasu wprowadzenia GPP (Group Policy Preferences) automatyczna zmiana haseł kont lokalnych stała się prosta łatwa i przyjemna. Niestety przyszedł dzień 13.05.2014 i znaleziona (znana już wcześniej) „luka” bezpieczeństwa spowodowała, że Microsoft całkowicie wycofał się z możliwości zmiany haseł dla kont lokalnych z wykorzystaniem GPP… Co więcej nie dotyczyło to tylko nowych systemów operacyjnych, lecz wraz z zainstalowaniem którejś z kolejnych poprawek – wycięło tą możliwość również z już działających starszych systemów. O co tak naprawdę zrobiono tyle szumu? – Burza w szklance wody Przeanalizujmy z czego wynika zamieszanie: 1. Zarówno GPO jako i GPP są utrzymywane na zasobie SYSVOL w postaci plików konfiguracyjnych XML oraz towarzyszących im metadanych. 2. Aby móc pobrać i przetworzyć GPO lub GPP należy mieć do nich uprawnienia – uprawnienia z GPO są przenoszone na SYSVOL 3. Atrybut CPassword jest szyfrowany 32-bitowym AES’em i w takiej postaci jest zapisywany do pliku XML   Zatem zamiast zmienić szyfrowanie na bezpieczniejsze – Microsoft wyciął możliwość zarządzania hasłami lokalnymi w jakże prosty i intuicyjny sposób… Swoją drogą wystarczyło być świadomym administratorem i do GPO obsługującego hasła lokalne przyciąć uprawnienia jedynie dla stacji domenowych (odebrać uprawnienia odczytu i przetworzenia zasad użytkownikom) – dzięki czemu użytkownik w swoim imieniu nie […]

© Marcin Krzanowicz