Tag-Archiv für » ad «

02 | 04 | 2019

AD User mit ausgeschalteter Vererbung der Rechte finden mit PowerShell – revisited

Geschrieben von um 15:15 Uhr

Vor sieben Jahren habe ich mal hier beschrieben, wie man schnell alle User mit ausgeschalteter Rechtevererbung findet. Damals war das Quest AD-Modul (aus ActiveRoles) das Mittel der Wahl, welches mittlerweile nicht mehr (kostenlos) verfügbar ist. Hier ein Code Snippet, um das gleiche mit dem nativen AD-Modul des Windows Servers zu erreichen:

$users = Get-ADUser -LDAPFilter "(mail=*)"
foreach ($user in $users) {
    $adsu = [ADSI]"LDAP://$($user.DistinguishedName)"
    if ($adsu.PSBase.objectSecurity.AreAccessRulesProtected) {
        $user.DistinguishedName
    }
}

Das Zurücksetzen der Vererbung ist etwas komplizierter als bei Quest und benutzt den AD-Provider aus dem Modul:

$users = Get-ADUser -LDAPFilter "(mail=*)"
foreach ($user in $users) {
    $adsu = [ADSI]"LDAP://$($user.DistinguishedName)"
    if ($adsu.PSBase.objectSecurity.AreAccessRulesProtected) {
        $acl = Get-ACL "AD:\$($user.DistinguishedName)"
        $acl.SetAccessRuleProtection($false,$false)
        Set-ACL -ACLObject $acl -Path "AD:\$($user.DistinguishedName)"
    }
}

Man sollte im Hinterkopf behalten, dass bei Mitgliedern in Admin-Gruppen diese Änderung durch AD wieder zurückgerollt werden wird (Stichwort AdminSDHolder), und bei produktivem Einsatz vielleicht eine Prüfung einbauen.

Happy migrating!

Tags » , , , , , «

+

16 | 07 | 2018

PowerShell Quirks: Beware of collections, die N+1.

Geschrieben von um 23:31 Uhr

Ich habe ja schon des öfteren über Eigenarten von Sammlungen aller Art in PowerShell berichtet. Heute ein Beispiel aus der Active Directory-Administration.

Nehmen wir einfach mal an, wir haben ein mehrwertiges Attribut und wollen zu diesem einen zusätzlichen Wert hinzufügen. Für diese Beispiel nehme ich msExchExtensionCustomAttribute1, da kann man nichts kaputt machen.

Set-ADUser john.doe -Replace @{msExchExtensionCustomAttribute1=@("A","B","C")}
$user = Get-ADUser john.doe -Properties msExchExtensionCustomAttribute1
$a1 = $user.msExchExtensionCustomAttribute1
Write-Host "Unser Attribut msExchExtensionCustomAttribute1:"
$a1.GetType()
$a1

Nun wollen wir zu $a1 ein viertes Element hinzufügen. IntelliSense in ISE bietet folgendes an:

Auch wenn’s bei nativen PowerShell-Arrays nicht funktioniert, ist Add doch vielversprechend. Probieren wir’s aus:

$a1.Add("D")
Write-Host "`r`nNach dem Add:"
$a1.GetType()
$a1

liefert

Sieht doch super aus, richtig? Der Typ ist derselbe, alle vier Elemente sind wie erwartet da. Nun bleibt also die neue Sammlung zurück in das Attribut zu schreiben und das Ergebnis zu überprüfen:

Set-ADUser john.doe -Replace @{msExchExtensionCustomAttribute1=$a1}
Get-ADUser john.doe -Properties msExchExtensionCustomAttribute1

Doch das Ergebnis ist leider nicht ganz das, was wir erwartet haben:

Das soeben beschriebene Attribut ist leer. Hmmm.

Machen wir das gleiche Spiel und nehmen statt der Methode .Add das PowerShell-eigene Anfügen:

$a1 += "D"

so ist das Ergebnis wie erwartet:

Der alles entscheidende Unterschied ist anscheinend, dass die Operation += die ADPropertyValueCollection in ein System.Array konvertiert. Und dieses wird offenbar von Set-ADUser korrekt interpretiert, sein nativer Datentyp hingegen nicht!

Happy updating!

Tags » , , , , , «

+