Skip to Content

IT nieuczesane.
category

Category: tips’n’tricks

jak przeczytać ACL po SIDach a nie nazwach?

przy próbie wyszukania okazuje się, że wszyscy szukają zupełnie odwrotnej akcji… a ponieważ znalazłem bardzo fajny wpis szczegółowo opisujący tematykę:

http://blogs.technet.com/b/ashleymcglone/archive/2011/08/29/powershell-sid-walker-texas-ranger-part-1.aspx

eN.

migracja, FSP i ogólnie bałagan

przejąłem projekt migracji – konsolidacja struktury domen do nowej, pojedynczej domeny. „wszystko już praktycznie zrobione, będziesz się nudził” – z taką optymistyczną informacją zaczynałem pracę nad zadaniem. z bardzo wielu krzaków, które wyszły, sqpię się nad jedną ciekawostką.

po przejrzeniu zmigrowanych grup okazało się, że część kont jest pokazywana jako konta external. listing członkostwa w grupie ujawniał wpisy typu:

CN=S-1-5-21-2096504233-xxxxxxxxx-944726268-2633,CN=ForeignSecurityPrincipals,DC=target,DC=domain

CN=S-1-5-21-2096504233-xxxxxxxxx-944726268-3498,CN=ForeignSecurityPrincipals,DC=target,DC=domain

Tak są właśnie przechowywane referencje do kont z lasów ztrustowanych. zacząłem więc szukać co to za domena. sprawa prosta, ponieważ zasada jest taka sama jak przy zwykłych SIDach – pierwsza część SID to domainSID. sprawdziłem więc ID wszystkich domen źródłowych [zwykły (Get-ADDomain).domainsid.value] … i okazało się, że takiej domeny nie ma /:

śledztwo. „taaaaakk…hmmm… była kiedyś migracja parę lat temu, tej domeny już nie ma”. tia. ostatnim etapem migracji jest cleanup SIDhistory, którego ktoś nie zrobił. sprawdzam grupy w domenie źródłowej – sweet, tam też członkowie pododawani są przez SIDHistory.

po dalszym przeglądzie okazało się, że w grupach były również konta z domen połączonych trustem nieprzechodnim z domeną źródłową, czyli nierozwiązywalne – kolejna grupa dziwnych FSP. tych niestety nie da się w żaden sposób przenieść chyba, że utworzy się trust z tymi externalami. poznajdywały się również konta CNF [w nowej domenie!] i inne wynalazki. i tak to właśnie się nudziłem…

po pierwsze wniosek/porada: migrację zaczyna się od czyszczenia. nawet jak klient mówi „przenosimy 1:1” – trzeba zweryfikować jak bardzo jest naśmiecone i poczyścić.

po drugie – skrypt, czyszczący FSP

z ciekawostek: do usunięcia usera z grupy korzystając z CN, musiałem użyć ADSI – nie potrafiłem zmusić koszernych cmdletów do obsłużenia CNa.

eN.

Azure PS Remoting

z wersji na wersję, maszyny dostarczane z szablonu w Azure sa coraz bardziej przygotowane do pracy od pierwszego startu. podobnie jest w przypadq PS Remoting – czyli zdalnego łączenia się z maszynami via PowerShell. automatycznie tworzony jest endpoint dla PSR a sama maszyna ma włączoną usługę i zrobione odpowiednie wyjątki. smacznie. pozostaje się po prostu połączyć.

jedyny problem, na jaki natknie się przeważająca większość osób, to certyfikat – na maszynkach jest oczywiście jakiś self-signed, więc standardowo połączenie zostanie odrzucone. aby połączyć się bezproblemowo należy wyłączyć opcje weryfikacji certów:

 

et voilá!

eN.

Postaw ptaszka

Od wersji Windows Server 2008 mamy dostępną w AD opcję „ProtectedFromAccidentalDeletion”. Generalnie nigdy bym nie pomyślał, żeby kiedykolwiek miało by sens używanie tej opcji, ale od niedawna dodaję ją jako wymaganą i  k_r_ y_t_y_c_z_n_ą  praktycznie w każdej mojej dokumentacji, która zawiera opis obiektów AD.

Generalnie nie ma większego problem gdy skasujemy obiekt komputera czy użytkownika. Nawet jeśli jest to konto serwisowe, po kilku minutach możemy sytuacje  naprawić. Ja jednak byłem świadkiem sytuacji w której jakiś durny program, lub admin … a generalnie admin nawet jak był to program …skasował obiekt serwisu klastra (hosta Cluster Service). To spowodowało, że przestała działać cała instancja SQL oparta na tym klastrze i inne usługi (np.. MSDTC). Obiekt nie jest prosty, więc od tak nie można go sobie stworzyć. Cały klaster SQL oparty na MSCS w zasadzie byłby do przeinstalowania a dokładniej każdy node musiał by być wyciągnięty z clustra, następnie trzeba by było usunąć wszystkie ślady po cluster service i poinstalować wszystko od początku. Roboty, przy kilku nodach na około 8 godzin (a produkcja leży!). Na szczęście jest na to myk .. Ale o tym w kolejnych wpisach.

Generalnie myślałem, że problem był wyjątkowy i że już nic gorszego się stać nie może. Środowisko bez  SPoF. Cały sprzęt nadmiarowy, urządzenia sieciowe dobrej klasy, load balancery, macierze itp. … Ale nie doceniłem adminów.

Po kilku dniach kolejna awaria. Ktoś dopatrzył że są 3 podobne do siebie nazwy komputerów… SuperProdDB1, SuperProdDB2 i SuperProdDB. Popingał, popatrzył na listy VMwareów i postanowił zrobić porządek. Skasował wpisy DNS SuperProdDB. Był to host name dla instancji klastra SQL  składającego się z w/w nodów.

Naprawa tego poszła już znacznie sprawniej.

Generalnie … postaw ptaszka!

We can’t verify who created this file

dość standardowy komunikat podczas uruchamiania skryptów z dysq sieciowego. powód – ścieżka nie jest rozpoznawana jako ‚local Intranet’ i nie jest zaufana – czyli rozwiązaniem jest dodanie adresu do odpowiedniej strefy w Internet Settings Zones. o ile same strefy koncepcyjnie są dobrym pomysłem, o tyle ich realizacja, działanie i zarządzanie prosi się o złożenie krwawych ofiar z IE team na ołtarzu Wielkiego Admina. kilka zebranych ciekawostek dotyczących tego tematu…

1. zarządzanie strefami via GPO…

tak najlepiej – bo globalnie. to rozwiązanie ma jednak sporo ograniczeń przez co traci na przydatności. najlepiej zerknąć jak strefy są zapisywane w rejestrze. ustawienia mogą być per user [HKCU] lub per komputer [HKLM] w kluczu:

HKxx\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap

w nim są dwie gałęzie – Domains oraz EscDomains, które będą używane zależnie od tego czy IE odpalony jest w trybie ESC czy pełnym. dalej są już wpisy z wartością DWORD przypisującą do odpowiedniej strefy. podobnie jest to widoczne w GPO – gdzie podaje się listę stron i definiuje odpowiednią wartość przypisania. co z tego wynika? ponieważ lista jest płaska:

  • wpisy w żadnym scenariuszu nie są sumowane! zawsze wygrywa jedna lista, i ta jest traktowana jako całość. a więc nie ma możliwości ‚dodania wpisu’ dla danej grupy czy usera – trzeba zawsze podawać pełną listę.
  • wpisy dla komputera zawsze wygrywają – to aqrat standard dla GPO
  • pozostaje kwestia metody dodania wpisów – czy będzie to IE Maintenance Mode, czy GPP. w GPP można na dwa sposoby – przez konfigurację IE oraz przez dodanie wpisu bezpośrednio do rejestru

brak granularności jest koszmarnym utrudnieniem i generuje muliplikowanie polis i wpisów – różnica w pojedynczym wpisie wymaga przepisania całości. jakimś obejściem problemu jest dodawanie wpisów poprzez dodanie klucza w rejestrze.

2. IE Maintenance Mode – czyli zgroza. szczęśliwie został wycofany w IE1o, nieszczęśliwie wiele firm nadal korzysta [i pewnie długo będzie] z IE8/IE9. edytor polis – GPEdit – wspiera się kontrolkami systemowymi. i tak też jest w przypadq IEMM. oznacza to, że wszystko zasysane jest z komputera, na którym wykonywana jest operacja. to z kolei oznacza, że trzeba mieć tyle komputerów bazowych, ile różnych wersji OS i przeglądarek. optymalnie x2 [z ESC i bez]. przy modyfikacji istniejącej polisy trzeba przenieść stację do OU w którym jest polisa, zassać ją, otworzyć GPMC – dopiero teraz GPedit, otwierając IEMM zassie wartości, które można modyfikować. w innym wypadq trzeba będzie wszystko wpisywać od początq.

3. Słowo o GPP. niewątpliwie jest nieporównywalnie lepszym rozwiązaniem, zastępującym IEMM. najlepiej zmigrować polisy do GPP ASAP, chociaż i tutaj nie jest bez niespodzianek – znów, są oddzielne ‚szablony’ w GPP dla różnych wersji IE, i zależnie od tego jaka jest kombinacja wersji OS/IE – niektóre będą widoczne, a niektóre nie /:

4. We Can’t Verify Who Created This File… czyli skąd w ogóle ten temat. taki komunikat zaczął pojawiać się na stacjach klienckich podczas logowania użytkowników. okazało się, że jest uruchamiany przy logowaniu skrypt… jako admin lokalny komputera. no i zaczyna się babol, ponieważ nie da się utworzyć polisy na użytkownika lokalnego. klient ma windows7 z IE8 i polisy robione IEMM. teoretycznie w sukurs może przyjść fakt, że IEMM jest dla usera i komputera, a polisy komputera nadpisują użytkownika – również lokalnego. hura!… ale zaraz.. jeśli doda się pojedynczy link – to nadpisze wszystkie dodane użytkonikowi, bo się nie sumują. kto podejmie się przepisywania wszystkich polis w dużej firmie, przewidzenia konsekwencji zmiany logiki itp itd… a czasu nie ma. trzeba zrobić.

i tu rozwiązaniem okazało się wstrzyknięcie tego pojedynczego wpisu do rejestru:

  • GPEdit/Computer Configuration/Preferences/Windows Settings/Registry
  • i tutaj dodane „Update” dla:
    • Hive: HKLM
    • KeyPath: SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\<server.with.domain.ad>
    • Value: *

 

 PODSUMOWUJĄC

jeśli jesteś adminem i nie masz zapędów samobójczych – rób wszystko żeby utrzymać jeden standard – tutaj OS+IE, ale generalnie ustandaryzowane środowisko jest łatwiej zarządzalne.

druga porada – staraj się korzystać z dobrodziejstw nowych metod – GPP zamiast skryptów czy IEMM, folder redirection a nie jakieś roaming profiles i tak dalej…

eN.

Alternate Data Stream

o ADS już kiedyś pisałem – oj dawno. dziś tylko małe uzupełnienie dot. PowerShell:

do tej pory jedynym sensownym sposobem usunięcia ADS było zassanie streams.exe z sysinternalsów. ale lepiej znać narzędzia które w systemie są od razy – czyli PS. scenariusz: zassany skrypcik z netu na jednym z kompów ciągle jest klasyfikowany jako ‚zone.identifier 3’ czyli z Internetu. i choćbym klikał na ‚unblock’ 1ooo razy – ni huhu. z jakiegoś powodu nie kasuje tej informacji. z PS proste jak drut:

 

et voila!

eN.

operacje na sesjach użytkownika z linii poleceń

nie trudno się domyślić, że w PS dodane jest sporo poleceń pozwalających na zarządzanie sesjami userów. niestety można to potraktować bardziej jako ciekawostkę ponieważ znaczenie ‚uniwersalny’ nie ma żadnego przełożenia – dodane są w w12/w8 ale gorszą wiadomością jest fakt, że działają tylko na serwerach z rolą RDS. w skrócie: korzystając z PS nie da się tego zrobić.

są za to stare-dobre toole linii poleceń, które warto sobie odświeżyć:

  • QUSER (tylko użytkownicy) i QWINSTA (wszystkie sesje) wyświetlające obecne sesje. QWINSTA ma łatwiejszy do zapamiętania odpowiednik QUERY.
  • mając ID sesji możemy ją wylogować korzystając albo z LOGOFF <SessionID> albo z RWINSTA <SessionID>. RWINSTA ma łatwiejszy do zapamiętania alias RESET <SessionID>.

narzędzia są w systemie od dawna i pozwalają na szybkie pozbycie się duchów (;

eN.

skrypt audytujący

zadanie – jak zaudytować komputery poza domeną tak, aby stwierdzić jakie są na nich aplikacje i jakie licencje? prostym zapytaniem WMI można dowiedzieć się, że wersja systemu to np. WinXP pro – ale OEM czy VLK?

nie udało mi się dotrzeć do samych linków na MSDN ale udało mi się zebrać te informacje. kilka ogólnych:

  • MAP toola nie da się użyć często ze względu na niedostępność komputerów a czasem credentiali. niestety takie środowiska są i to wcale nie tak rzadkie jakby się mogło wydawać…
  • wersję licencji OEM/VLK/MAK można wyciągnąć np. przy pomocy slmgr.vbs … ale tego nie ma na XP. poza tym lepiej mieć to we własnym skrypcie. kluczem jest „HKLM\SYSTEM\Setup\Pid”. w skrypcie poniżej pokazuję konkretne wartości.
  • można nawet dowiedzieć się jaka to wersja na podstawie innego klucza – ale pełnej listy nie mam.
  • korzystanie z metody Win32_product nie jest wskazane ponieważ każde takie odpytanie automatycznie uruchamia proces weryfikacji. trwa długo i może doprowadzić do dziwnych komunikatów – ogólnie wysypać się. dodatkowo – klasa PRODUCT nie jest standardowo instalowana na wersji XP /: trzeba ją oddzielnie dodać. lepiej skorzystać z zapytania do rejestru.
  • odpytując rejestr na 64 bitowej maszynie musimy zrobić dwa zapytania, zmieniając providera – inaczej dostaniemy tylko małą część aplikacji zainstalowanych.
  • do bardziej skomplikowanych operacji oraz bardziej wymyślny skrypt -> open audit

a poniżej kod. oczywiście w VBS ponieważ to jedyny ‚standard’ który zadziała na każdej wersji od w2k aż po dzisiejsze w8.1

eN.

Przenieś/Kopiuj do folderu…

Opcja bardzo przydatna i niedostępna domyślnie w windowsach.

przen

Ku pamięci zapisuję, może ktoś jeszcze skorzysta :)

W drzewie HKEY_CLASSES_ROOT\AllFilesystemObjects\shellex\ContextMenuHandlers

Dla „kopiowania” dodajemy klucz o nazwie „kopiuj do” i wartości domyślnej

{C2FBB630-2971-11D1-A18C-00C04FD75D13}

Dla „przenoszenia dodajemy klucz o nazwie „przenies do” i wartości domyślnej

{C2FBB631-2971-11D1-A18C-00C04FD75D13}

Wartości przepisujemy/kopiujemy razem z nawiasami klamrowymi jako jeden ciąg znaków!

Załączam gotowe pliki .reg dla leniwych lub nietechnicznych -> copyto_moveto

Po rozpakowaniu wystarczy je uruchomić i zatwierdzić.

 

 

 

inplace upgrage DPM 2010 -> 2012 SP1

przy próbie podniesienia wersji DPM 2o1o do 2o12 SP1 dostaję informację, iż nie jest wspierana i należy postawić DPM2o12 SP1 obok. taką migrację da się jednak zrobić, z krokiem pośrednim, którym jest DPM 2o12 bez SP1:

DPM2o1o -> DPM2o12 -> DPM2o12 SP1

czemu tak? ze względu na ograniczenia w ilości sprzętu, żeby nie przenosić potem konfiguracji i zachować całą historię backupów.

in-place upgrade nie jest specjalnie skomplikowany ale interfejs jest na tyle niejasny, że można się obawiać, co się tak na prawdę robi i jak to się zakończy. że się w ogóle da i żeby się nie bać przeczytałem sobie tutaj, jednak to koniec wartości tego wpisu. zabrakło kilq ważnych informacji.

  • za artykułem zrobiłem upgrade wszystkich komponentów DPM i agentów [w arcie mowa o starych poprawkach więc lepiej wyszukać najnowszych]. i tu się pojawia pierwszy problem – jeśli backup dotyczy również stacji mobilnych, to pewnie nie będzie ich aqrat w okolicy ergo nie zostaną podniesione wersje.
  • art sugeruje zrobienie backupu z SQL managera… ja bym raczej polecił /DPM/bin/DMPbackup.exe -db
  • instalator cały czas sugeruje, że to będzie nowa instalacja – w pewnym sensie będzie, ale należy nie zwracać na to uwagi – konfiguracja będzie przeniesiona. najdziwniejszy jest moment, w którym należy wybrać bazę danych [w moim przypadq baza była na tym samym kompie]. należy wybrać ‚use dedicated instance’.
  • kolejnym dziwnym krokiem jest hasło dla kont DPMowych – podać stare hasło czy jakieś nowe? odpowiedź: nie ma to znaczenia. zostanie zmienione.
  • każda faza upgrade’u wymaga restartu. co więcej – pomimo opcji ‚czek apdejts’ przy instalacji, nie warto tego od razu robić, ponieważ nawet po znalezieniu poprawek dla DPM ich instalacja nie powiedzie się. trzeba zrestartować, wyszukać, zainstalować, zrestartować, dalej wykonywać upgrade.
  • po instalacji DPM 2012 pozostaje działająca baza 2o1o oraz stary SQL. kiedy już się upewni, że wszystko działa – można je usunąć. o dziwo instalator nawet nie ustawia starej bazy w tryb ręczny, więc standardowo działać będą obie.
  • nie znalazłem czegoś takiego jak „SP1 dla DPM 2o12”. instalacja SP1 sprowadza się de facto do zrobienie in-place upgrade z DPM2o12 -> DPM2o12 SP1 /:
  • największym problemem przy każdym przejściu jest upgrade agentów na końcówkach. DPM sam z siebie nie ma możliwości automatycznej instalacji wersji. po prostu nie będzie robił backupów. jeśli chodzi o serwery – jest to dość proste, ponieważ z panelu ‚management’ można po prostu zaznaczyć wszystkie serwery i zrobić ‚update’. jeśli chodzi o laptopy – pozostaje przygotowanie paczki SCCM. serwery poza domeną – instalacja skryptowa.

sporo drobiazgów, a stresik jest.

eN.