OT:czemu ludzie wierzą w dziwne rzeczy?
polecam dwie fajne prezentacje TED (:
eN.
przenoszenie uprawnień między domenami
jakiś czas temu pisałem o fajnym narzędziu do sprawdzenia uprawnień w AD – AD ACL Scanner. chciałem użyć go do przeniesienia uprawnień między domenami… i okazało się, że nie jest to wcale takie proste:
- plik csv, który jest generowany jako raport, nie zawiera nagłówka – a więc nie wiadomo co oznaczają poszczególne wartości
- wartości w raporcie HTML mają nagłówki… ale nie wszystkie i nie takie same
- no i nawet jeśli znam nagłówek – to jak to przenieść?
oto szkic skryptu, który potrafi zaciągnąć plik z ADADCLscan i przenieść do innej domeny. to, co trzeba zrobić przed jego użyciem to:
- zmienić w pliku raportu nazwę domeny źródłowej na docelową we wszystkich rekordach
- wyciąć przedrostki z nazw grup [np. DOMAIN\mygroup -> mygroup]
param(
[parameter(ParameterSetName="FILE",Mandatory=$true,Position=0)][string]$fileName
)
import-module ActiveDirectory
$AD_ACLS=import-csv $fileName -delimiter ';' -header "OU","Trustee","Right","inheritance","objectTypeGUID","InheritedObjectTypeGUID","objectACEFlags","AccessControlType","isInherited","inheritanceFlag","propagationFlags"
foreach($ACLentry in $AD_ACLS) {
$grpSID=new-object System.Security.Principal.SecurityIdentifier (get-adgroup $ACLentry.trustee).SID
$objTypeGUID=New-Object guid $ACLentry.objectTypeGUID
$inheritedOTGUID=New-Object guid $ACLentry.InheritedObjectTypeGUID
$ace=New-Object System.DirectoryServices.ActiveDirectoryAccessRule(
$grpSID,
$ACLentry.right,
$ACLentry.AccessControlType,
$objTypeGUID,
$ACLentry.inheritance,
$inheritedOTGUID
)
$acl=get-acl AD:$($ACLentry.OU)
$acl.AddAccessRule($ace)
set-acl -AclObject $acl AD:$($ACLentry.OU)
}
skrypt jest bardzo prymitywny – np. zakłada, że uprawnienia są tylko dla grup a nie dla użytkowników czy komputerów, nie ma obsługi błędów, etc – niemniej pokazuje kilka ważnych elementów: jak wygląda pełny nagłówek, w jaki sposób korzysta się z cmdletów ACL.
eN.
jak rozpoznać kartę WiFi?
scenariusz: trzeba napisać skrypt, który będzie wyłączał rejestrację DNS dla interfejsów LANowych. służy do tego metoda SetDynamicDNSRegistration klasy Win32_NetworkAdapterConfiguration. pozostaje problem – jak znaleźć owe interfejsy LANowe, bo zwykłe wylistowanie interfejsów pokaże ich multum… są dwa warunki, które trzeba sprawdzić – odfiltrować te, które nie są IPEnabled oraz te, które nie są Wired. i tu się zaczynają schody – IPEnabled to parametr klasy Win32_NetworkAdapterConfiguration a typ interfejsu pokazuje atrybut AdapterTypeID klasy Win32_NetworkAdapter.
sprawdzenie obu tych warunków byłoby niemożliwe [mega-złożone] gdyby nie klasy asocjacyjne – w tym przypadku Win32_NetworkAdapterSetting, która łączy obie wcześniej wymienione. klasy asocjacyjne pobierają atrybuty dla obu klas dla danego urządzenia i publikują je w dwóch gałęziach – element oraz setting. skrypt finalnie wygląda tak:
function setDNSdynamicReg{ gwmi -Class win32_networkAdapterSetting|%{ #adaptertypeid = 0 - wired card #ipenabled - filter out non-ip shit if( (([wmi]$_.element).adaptertypeid -eq 0) -and (([wmi]$_.setting).ipenabled -eq $true) ) { echo "[debug] adapter type: $($([wmi]$_.element).adaptertype)" echo "[debug] zmieniam parametr dla: $($([wmi]$_.setting).caption)" $err=([wmi]$_.setting).SetDynamicDNSRegistration($false) $err.ReturnValue } } return "done" } setDNSdynamicRegproste, nie? a teraz ciekawostka na koniec. na MSDN wyraźnie i jasno opisane są 'adaptertype’ oraz 'adaptertypeid’.. a oto jak przedstawia się moja karta WiFi /:
PS C:\_ScriptZ> .\setDynDNSReg.ps1
[debug] adapter type: Ethernet 802.3
[debug] zmieniam parametr dla: [00000000] Karta Intel(R) Centrino(R) Wireless-N 1000
eN.