właściciel plików: administrators

UAC_insigniaprodukty eMeSa wykazują się niesamowitą inkoherencją. z jednej strony  genialnością i pomysłowością, po czym trafia się na opcje [lub ich brak] lub mechanizmy, które zaburzają cały obraz. jednym z najbardziej niedopracowanych i kontrowersyjnych mechanizmów jest UAC – User Account Control. dość często na niego przeklinam i trafiłem na kolejny argument, świadczący o tym, że był wymyślany na złość administratorom. a tak na prawdę będzie to połączenie kilq bezsensownych i niewyjaśnialnych zachować systemu.

chodzi konkretnie o własność [ownership] plików zakładanych przez użytkownika, który należy do grupy administratorów lokalnych. czyli praktycznie zawsze – bo któż inny zarządza serwerem? pliki w takim przypadq mają jako właściciela wpisywane… 'Administrators’ – zamiast konkretnej osoby. dla windows 2oo3 dało się to wyregulować polisą GPO:

„Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\System objects: Default owner for objects created by members of the Administrators group”

problem polega na tym, że takiego ustawienia nie ma dla systemów w2k8+. w taki czy inny sposób polisę można przywrócić w interfejsie, ale nie ma to znaczenia, ponieważ systemy jej nie respektują. a jest tak ponieważ zespół wdrażający UAC uważał, że jest tak samo genialny i nieomylny jak ten, który zarządził, że metrointerfejs będzie standardem wszędzie, zawsze i bezwzględnie, łącznie z serwerami. można znaleźć KB, które opisuje, że to właśnie ten wspaniały mechanizm zapewnia, że uprawnienia będą automatycznie nadawane na konkretną osobę, ponieważ nie ma tokena administratora.

wszystko by się nawet kleiło, gdyby nie jeden podstawowy fakt – ktoś, kto to wymyślał raczej nigdy nie administrował serwerem pliqw, pozostając w jakiejś sferze teorii. w ogóle poruszanie się po zarządzanym serwerze jest mało wykonalne bez uprawnień admina, więc nie ma innego wyjścia jak UAC obejść – czy to odpalając jakiegoś file managera w trybie 'run as administrator’, czy to po prostu wyłączając cały mechanizm. pozostaje jeszcze jeden opisywany radośnie przypadek – UAC nie działa przy operacjach zdalnych, przez sieć, więc tu też zawsze będzie 'owner:administrators’.

jak to obejść? jedyny sposób jaki znam, to utworzenie grupy, która będzie miała pełne uprawnienia do wszystkich pliqw, ale nie będzie w grupie adminów. takie to trochę naciągane, mało wygodne i zastanawiam się, czy kiedykolwiek widziałem zastosowane w praktyce? uważam, że to jest poważne niedociągnięcie w bezpieczeństwie, ponieważ nie daje łatwej metody sprawdzenia kto dany plik/katalog założył. oczywiście, że ownera da się zmienić, więc można polemizować 'jakież to tam zabezpieczenie’, jednak z doświadczenia mogę powiedzieć – w większości przypadqw poziom wiedzy, ignorancja i lenistwo są na tyle powszechne, że bardzo podstawowe mechanizmy wystarczają aby odpowiedzieć na podstawowe pytania. a przeciw tym na prawdę dobrym, działającym z premedytacją i tak ciężko coś przeciwdziałać. wielokrotnie też miałem przypadek, kiedy nie chodziło o bezpieczeństwo sensus stricte a po prostu zwykłe wyjaśnienie – 'kto ten katalog/plik utworzył?’.

eN.

 

System Center Data Protection Manager 2012 R2 – VSS Failed, Replica inconsistent

Sytuacja prosta, System Center Data Protection Manager 2012 R2 robi backup dysków, udziałów, ale nie potrafi poradzić sobie ze zrobieniem Bare Metal Recovery oraz System State.

DPM error

Server Backup na maszynie, którą chcemy backupować wypisuje „VSS – Failed” i dalej: „there is not enough disk space to create the volume shadow copy on the storage location”. Jak to nie ma miejsca, jak na macierzy mam go od groma.

Na koniec jeszcze Event Viewer po stronie backupowanego klienta:

“The backup operation that started at '‎2014‎-‎08‎-‎25T13:22:49.633000000Z’ has failed because the Volume Shadow Copy Service operation to create a shadow copy of the volumes being backed up failed with following error code '0x80780119′. Please review the event details for a solution, and then rerun the backup operation once the issue is resolved.”

Prawdopodobnie problem leży w partycji Recovery Point o pojemności 300MB. VSS potrzebuje przynajmniej 50MB wolnego miejsca. Jeżeli go nie ma Backup, nawet nie ruszy.

Wolne miejsce w prosty sposób sprawdzimy używając polecenia PowerShell’owego po stronie maszyny, którą chcemy backup’ować.

Get-Volume

W wyniku, którego widzimy, że nasza partycja Recovery ma 300 MB, z czego tylko 29,99MB wolnego.

dpm_2

Upssss, niecałe 30MB to trochę za mało, do 50 kawałek brakuje…

Ponieważ problem leży w przestrzeni dyskowej po stronie klienta, rozwiązaniem będzie zwolnienie go, poprzez przeniesienie „shadowcopy storage” dla tego wolumenu („recovery partition volume”) na inny dysk.

Przy wykorzystaniu starego vssadmin pozostając w PS:

vssadmin list volumes

Zaznaczamy interesującą nas partycję Recovery (nie ma dopisanej żadnej litery)

Przyjmując, że korzystamy z PowerShell’a w wersji 3 zadziała poniższe polecenie(dzięki wykorzystaniu –% PS nie będzie analizował pozostałej linii kodu)  przy wersjach wcześniejszych możemy, żeby było najprościej użyć cmd.exe /c lub powalczyć ze znakami specjalnymi PowerShell (więcej info tutaj)

vssadmin --% add shadowstorage /for=\\?\Volume{7497305d-c678-4907-8274-e2f21de66bae}\ /on=c: /maxsize=500MB

Wracamy na nasz serwer do konsoli System Center Data Protection Manager, prawym na Protection Group z naszym serwerem i  wykonujemy Perform consistency check…
Wszystko powinno wykonać się poprawnie.

Ozz.

jak sprawdzić przypisania wirtualnych kart sieciowych

klaster ma swoje wymagania co do sieci – potrzebuje kilku interfejsów do LM, HB, iSCSI, VLANy i tak dalej. jeśli tylu sieciówek nie ma, a zdarza się, że po prostu braqje portów na switchu (; i w kilq innych scenariuszach – czasem warto jest utworzyć wirtualne interfejsy. na stronach technetu można znaleźć ładną instrukcję więc nie będę kopiował. tutaj chciałem podać tylko mały trik. po założeniu owych wirtualnych interfejsów chciałoby się podejrzeć który jest dowiązany do którego wirtualnego switcha. trzeba przyznać, że konstrukcja wirtualnych switchy jest nieco zamota, a w połączeniu z VMM gdzie dochodzą jeszcze sieci logiczne staje się to na prawdę nieprzyjemne przy rozwiązywaniu problemów.

  • teoretycznie switche widać w hyper-v managerze… ale nie widać tak wirtualnych interfejsów.
  • interfejsy – czy to fizyczne czy wirtualne, widać w systemie – czy to z GUI 'ncpa.cpl’ czy z powershell 'get-netAdapter’. ale nawet wyświetlając wszystkie właściwości konkretnego interfejsu nie widać ich powiązań z VMSwitch
  • standardowo polecenie get-VMNetworkAdapter pokazuje powiązania z maszynami wirtualnymi……

..ale to już bardzo blisko rozwiązania. jest jeden magiczny przełącznik, który stanowi rozwiązanie:

get-VMNetworkAdapter -ManagementOS

po wykonaniu tej komendy pokazywane są nazwy switchy wirtualnych. teraz wystarczy sprawdzić który switch powiązany jest z która kartą fizyczną i voila:

 Get-VMNetworkAdapter -ManagementOS|%{echo "$($_.name) -> $((get-vmswitch -name $_.switchname).NetAdapterInterfaceDescription)"}

idąc jeszcze krok dalej: nazwy kart z poziomu systemu znów są inne.. kolejna warstwa. więc jeszcze informacja jaka jest nazwa interfejsu z poziomu systemu:

Get-VMNetworkAdapter -ManagementOS|%{
    $iDesc=(get-vmswitch -name $_.switchname).NetAdapterInterfaceDescription;
    $adapterName=(Get-NetAdapter -InterfaceDescription $iDesc).name;
    echo "$($_.name) -> $iDesc -> $adapterName"
}

eN.