AADConnect Objekte ausschliessen (z.B. Einen Benutzer nicht synchronisieren)

Manchmal muss der Admin genau ein einziges Objekt, oder nur wenige ganz bestimmte Objekte von der Synchronisation vom lokalen AD in das Microsoft 365 Azure AD ausschließen.

Das geht überraschend einfach, mann kann exclude-Regeln einfach im „Synchronization Rule Editor“ hinzufügen.

Schritt für Schritt Anleitung um ein Objekt nicht mehr zu synchroniseren

  1. Zeitplan für die Synchronisation abschalten, damit keine automatischen Aufgaben die Änderungen durcheinander bringen:
Set-ADSyncScheduler -SyncCycleEnabled $False

Der Status des ADSyncSchedulers lässt sich jeder überprüfen mittels:

Get-ADSyncScheduler | Format-List SyncCycleEnabled

2. „Synchronization Rules Editor“ starten (als Administrator)

3. In der „View and manage …“ Liste die „Direction“ auf „Inbound“ stellen und eine freie Nummer unterhalb der bestehenden „Precedence“ Regeln finden (und merken). In der Regel ist das irgendetwas <100.

4. Oben rechts „Add New rule“

5. Den „Create inbound synchronization rule“ Assistenten nun ausfüllen:

  • Name: Ein beschreibender Name, z.B. „In from AD – Bernd auslassen“
  • Connected System: Der lokale AD Forest
  • Connected System Object Type: user
  • Metaverse Object Type: Person
  • Link Type: join
  • Precedence: Die gemerkte Nummer von oben (z.B. „90“)
  • „Tag“, „Enable Password Sync“ oder „Disabled“ nicht verändern
  • Next > …

6. „Add group“ > dann > „Add clause“

7. Als „Attribut“ ein zu filterned Attribut wählen, zum Beispiel den „name“ oder ein anderes Attribut. Bei größeren Mengen an Objekten nutzen wir hier gerne die „Extended Attributes“, die normalerweise solange ungenutzt und leer sind. Der Operator ist im Beispiel „equal“, der „Value“ der zu matchende Inhalt.

8. „Next >“, an den nun angezeigten „Add join Rules“ nichts ändern > „Next >“

9. Bei den „Add join rules“ eine Transformation hinzufügen:

  • „Add transformation“ >
  • FlowType: Constant
  • Target Attribute: cloudFiltered
  • Source: True
  • Apply Once: leer lassen
  • Merge Type: Update
  • Unten auf „Add“

10. „Synchronization Rules Editor“ schliessen, „Synchronization Service“ öffnen

11. „Connectors“ > Actions > Run > Full Synchronization > OK

12. „Operations“ Den Zyklus abwarten, Full dauert immer einen Moment …

13. Den Synchronization Schedule wieder einschalten:

Set-ADSyncScheduler -SyncCycleEnabled $True

14. Und einmal die Initial-Synchronisation laufen lassen:

Start-ADSyncSyncCycle -PolicyType Initial 

Microsoft SQL Server (MSSQL) Msg 15150 Cannot Alter The User ‘dbo’

Wenn man einen SQL Benutzer nicht vom SQL-Server entfernen kann, weil dieser Fehler auftritt („Error: 15150“), hat der Benutzer vermutlich noch ein Datenbankschema im Besitz.

Lösung

Der Besitz der Datenbank (des Schemas) muss einfach wieder „mit Gewalt“ übergeben werden. Wir machen das in aller Regel für den SA und vergeben dann als dieser neue Berechtigungen.

Use <DATENBANK>
GO
sp_changedbowner 'sa'
GO

Alle deaktivierten Benutzer aus (bestimmten) ActiveDirectory Gruppen entfernen

Ich musste grade eine ganze Menge deaktivierter ActiveDirectory Benutzer aus allen Gruppen entfernen. Andernfalls hätten diese im AADConnect Synchronisationsfehler ausgelöst, da hier deaktivierte Benutzer-Objekte nicht synchronisiert werden.

Mein PowerShell Script das das sehr erfolgreich übernommen hat sieht so aus:

# Durch die OU laufen und deaktivierte User einsammeln ...
foreach ($username in (Get-ADUser -Filter {enabled -eq $false} -SearchBase "OU=<HIER SUCHEN>,DC=<DOMAIN>,DC=<TLD>")) {
 
# ... deren Group-Memberships holen ...
$groups = Get-ADPrincipalGroupMembership $username;
 
# ... durch die Gruppen laufen ...
foreach ($group in $groups) {
 
    # ... wenn Gruppenname stimmt (z.B. "VPN*") ...
    if ($group.name -Like "<NAME>") {
 
        # ... User entfernen
        Remove-ADGroupMember -Identity $group.name -Member $username.SamAccountName -Confirm:$false;
 
        # Ausgabe
        write-host "Habe" $username "von" $group.name "entfernt";
    }
}
}

Das funktioniert natürlich nicht nur mit Sicherheitsgruppen, sondern auch mit Verteilerlisten.

Die Suche nach dem/den Gruppennamen kann man in der Zeile $group.name -Like "Domänen-*" anpassen; hier tun es natürlich auch die anderen Operatoren wie -eq oder -neq.

SSTP Fehler 0×80092013 „Die Sperrfunktion konnte die Sperrung nicht überprüfen, da der Sperrserver offline war“

Manche Windows 10 VPN-Clients mit SSTP-Verbindungen scheinen nach langem problemlosem arbeiten plötzlich ihre Zertifikatsanbieterlistensperrfunktion zu „verlieren“. Die Ursache kennen wir noch nicht.

Die VPN-Einwahl via SSTP Endet mit der Meldung „Die Sperrfunktion konnte die Sperrung nicht überprüfen, da der Sperrserver offline war“.

Lösung

Eine wirkliche Lösung ist das hier nicht, aber wenn man die Verbindung dringend benötigt, kann man Windows 10 dazu überreden, die CRL nicht abzufragen:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SstpSvc\Parameters]
"NoCertRevocationCheck"=dword:00000001

Dann funktioniert die Verbindung in aller Regel sofort wieder.

Install-Module fehlt: Die Benennung „Install-Module“ wurde nicht als Name eines Cmdlet, einer Funktion, einer Skriptdatei …

Als Admin ist man es gewohnt, mit dem PowerShell Cmdlet Install-Module erforderliche Module nachzuinstallieren. Doch das schlägt auf älteren Systemene mit PowerShell 4 mit fehl:

install-module : Die Benennung "install-module" wurde nicht als Name eines Cmdlet, einer Funktion, einer Skriptdateio der eines ausführbaren Programms erkannt. Überprüfen Sie die Schreibweise des Namens, oder ob der Pfad korrekt ist (sofern enthalten), und wiederholen Sie den Vorgang.
 install-module
CategoryInfo : ObjectNotFound: (install-module:String) [], CommandNotFoundException: FullyQualifiedErrorId : CommandNotFoundException 

Die PowerShell Version lässt sich schnell prüfen:

PS C:\> $PSVersionTable.PSVersion
PS C:\Users\.admin> $PSVersionTable.PSVersion

Major  Minor  Build  Revision
-----  -----  -----  --------
4      0      -1     -1

Lösung

Unter Server 2012R2 gibt es die PowerShell 5, die NuGet als Paketprovider mitbringt, noch nicht automatisch. Also muss man beides manuell installieren.

  1. Download und Installation „Windows Management Framework 5.1“: https://www.microsoft.com/en-us/download/details.aspx?id=54616 (Für „meinen“ Server 2012R2 war das das Paket Win8.1AndW2K12R2-KB3191564-x64.msu)
  2. TLS 1.2 als „Strong Crypto“ aktivieren (nein, 2012R2 kannte das noch nicht, das sprach noch SSL3). Reboot nicht vergessen!
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord

… und am besten auch direkt für 64bit:

Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord
  1. NuGet Paketprovider installieren:
[PS] C:\>Install-Module PowershellGet -Force