Als Berater ist es eine der Hauptaufgaben, sich mit seltsamen Problemen oder Fragen zu befassen, die auftreten. Da ich mich auf Microsofts Forefront Identity Manager spezialisiert habe und zuvor als Windows Server Engineer tätig war, betreibe ich ein ziemlich umfassendes virtuelles Entwicklungs- und Demolabor, in dem so ziemlich jedes gängige Microsoft Server-Produkt auf durchschnittlich 80 virtuellen Servern eingesetzt wird. Unter den richtigen Umständen werden Sie Produkte finden, die einfach nicht zusammenpassen.
Nach meiner fehlgeschlagenen SSPR-Kennwortrücksetzungsdemo ging ich die Standard-Checkliste zur Fehlerbehebung durch, einschließlich der Überprüfung der Konfiguration. Das erste Problem, das ich feststellte, waren fehlende Berechtigungen für das FIM-Service-Konto im WMI-Namensraum Root/CIMV2. Da es sich um eine funktionierende SSPR-Umgebung handelte, weiß ich, dass diese Rechte zuvor gesetzt worden waren. Außerdem fehlte auch der Namensraum Root/MicrosoftIdentityIntegrationServer in der Baumstruktur. Mein Zeitplan ließ genug Zeit, um das Problem zu beheben, aber nicht, um eine vollständige Ursachenanalyse der Situation durchzuführen.
Nach ein paar Tagen treten nun Probleme auf, wenn ich FIM WMI-Aufrufe an eine ganz andere FIM-Umgebung tätige. Ich habe sofort einen Blick auf den WMI-Namensraum geworfen und die gleichen Probleme wie zuvor gefunden. Um meine aktuellen Projekte und meine persönliche Neugier zu unterstützen, habe ich derzeit 4 verschiedene FIM-Umgebungen eingerichtet, R1 oder R2, All-in-One bis hin zu skalierten Implementierungen. Wenn ich mir die zusätzlichen Umgebungen ansehe, habe ich festgestellt, dass sie alle mit denselben Problemen mit fehlendem WMI zu kämpfen haben. Dies gilt auch für den Server, den ich erst vor wenigen Tagen repariert habe.
Jetzt ist es also an der Zeit, das Problem an der Wurzel zu packen. Wenn Sie jemals den Prozess "How to register the FIM WMI Provider" (Registrierung des FIM WMI-Providers), wie im Microsoft TechNet beschrieben, ausgeführt haben, werden Sie unter anderem die Warnung bezüglich des #PARGMA AUTORECOVER bemerken. Dies führte mich zu dem Schluss, dass die WMI-Konfiguration für diese Server neu erstellt werden musste. In Kombination mit einer übermäßigen Menge an Ereignisprotokollen in Bezug auf tägliche Neuinstallationen des SCCM-Clients und WMI-Fehlern konzentrierte ich mich auf die Suche nach einem SCCM-bezogenen Problem. Dabei stieß ich auf KB2796086 mit dem Titel Configuration Manager Management Points collocated with clients fail after installing Windows Management Framework 3.0 and running Client Health Evaluation".
Wie ich eingangs sagte, gibt es manchmal Produkte, die nicht gut zusammenpassen. In meiner Laborumgebung neige ich dazu, alles überall zu installieren, einschließlich SCCM-Clients auf allen Servern und alle Windows-Updates, sobald sie veröffentlicht werden, was den perfekten Sturm für FIM, SCCM 2012 und WMF 3.0 darstellt. Glücklicherweise beschreibt der KB-Artikel eine Registry-Einstellung, die eine Warnung erzeugt, anstatt das WMI jedes Mal neu zu erstellen, was nachweislich meine verschiedenen FIM-WMI-Probleme gelöst hat. Außerdem besagt der KB-Artikel, dass SCCM SP1 die Kompatibilitätsprobleme zwischen SCCM und WMF beheben wird.
Fehler, die Sie möglicherweise sehen, helfen Ihnen, das Problem zu identifizieren:
- SSPR erzeugt einen clientseitigen Fehler: "PWReset activity returned status code PWUnrecoverableError" bei Übermittlung des neuen Passworts.
- PowerShell-Skriptfehler: "get-wmiobject: Ungültiger Namespace root\MicrosoftIdentityIntegrationServer"
Ein positives Ergebnis ist eine einzige Quelle für Reparaturanweisungen, die auf einer Kombination aus früheren Dokumentenprozessen und einem zusätzlichen PowerShell-Skript zum Festlegen von Berechtigungen für Root/MicrosoftIdentityIntegrationServer basiert.
- Aktualisieren Sie die Registrierung des Servers wie in KB2796086 beschrieben.
- Folgen Sie FIM-REFERENCE: Registrierung des FIM WMI Providers zur Reparatur von WMI.
- Folgen Sie Brad Turners Beitrag How to Use PowerShell to Set WMI Permissions for FIM Self-Service Password Reset (en-US)
- Und das folgende Skript, um die Berechtigungen auf dem Root/MicrosoftIdentityIntegrationServer zurückzusetzen
[sourcecode language="powershell"]
PARAM(
$Principals = $(throw "`nMissing -Principals ('DOMAIN\FIMSyncAdmins','DOMAIN\FIMSyncBrowse','DOMAIN\FIMSyncOperators','DOMAIN\FIMSyncPasswordSet')"),
$Computers = $(throw "`nMissing -Computers ('fimnode01′,'fimnode02')"))
# USAGE:
#
# .\Set-FIM-WMI.ps1 -Principal (‘<FIM admin group>’,'<FIM browse group>’,'<FIM operators group>’,'<FIM password group>’) -Computers (‘<server1>’, ‘<server2>’,…)
#
# EXAMPLE:
# .\Set-FIM-WMI.ps1 -Principal (‘DOMAIN\FIMSyncAdmins’,’DOMAIN\FIMSyncBrowse’,’DOMAIN\FIMSyncOperators’,’DOMAIN\FIMSyncPasswordSet’) -Computers (‘fimsyncprimary’, ‘fimsyncstandby’)
#
# Inspired by Brad Turner’s post:
# https://social.technet.microsoft.com/wiki/contents/articles/2261.how-to-use-powershell-to-set-wmi-permissions-for-fim-self-service-password-reset-en-us.aspx
# Which was inspired by Karl Mitschke’s post:
# https://unlockpowershell.wordpress.com/2009/11/20/script-remote-dcom-wmi-access-for-a-domain-user/
Write-Host "Set-MIIS-WMI - Aktualisiert WMI-Berechtigungen für MicrosoftIdentityIntegrationServer-Objekt"
Write-Host "`tGeschrieben von Terry Phillips ([email protected])"
Write-Host "`tBlog: https://www.css-security.com/category/blog/"
Funktion get-sid
{
PARAM ($DSIdentity)
$ID = new-object System.Security.Principal.NTAccount($DSIdentity)
return $ID.Translate( [System.Security.Principal.SecurityIdentifier] ).toString()
}
foreach ($strprincipal in $Principals)
{
$sid = get-sid $strPrincipal
#WMI-Berechtigung - Methoden ausführen, Provider schreiben, Konto aktivieren, Remoteaktivierung nur für diesen Namespace
$WMISDDL = "A;;CCDCRPWP;;;;$sid"
#PartialMatch
$WMISDDLPartialMatch = "A;;w+;;;;$sid"
foreach ($strcomputer in $computer)
{
write-host "`nWorking on $strcomputer adding $strprincipal..."
$security = Get-WmiObject -ComputerName $strcomputer -Namespace root/MicrosoftIdentityIntegrationServer -Class __SystemSecurity
$binarySD = @($null)
$Ergebnis = $security.PsBase.InvokeMethod("GetSD",$binarySD)
# Konvertiert die aktuellen Berechtigungen in SDDL
write-host "`tConverting current permissions to SDDL format..."
$converter = new-object system.management.ManagementClass Win32_SecurityDescriptorHelper
$CurrentWMISDDL = $converter.BinarySDToSDDL($binarySD[0])
# Erstellen der neuen Berechtigungen
write-host "`tBuilding the new permissions..."
if (($CurrentWMISDDL.SDDL -match $WMISDDLPartialMatch) -und ($CurrentWMISDDL.SDDL -notmatch $WMISDDL))
{
write-host "`tperforming SID Update"
}
sonst
{
$NewWMISDDL = $CurrentWMISDDL.SDDL + "(" + $WMISDDL + ")"
}
# SDDL zurück nach Binär konvertieren
write-host "`tConverting SDDL back into binary form..."
$WMIbinarySD = $converter.SDDLToBinarySD($NewWMISDDL)
$WMIconvertedPermissions = ,$WMIbinarySD.BinarySD
# Die Änderungen anwenden
write-host "`tÄnderungen anwenden..."
if ($CurrentWMISDDL.SDDL -match $WMISDDL)
{
write-host "`tCurrent WMI Permissions matches desired value."
}
sonst
{
$result = $security.PsBase.InvokeMethod("SetSD",$WMIconvertedPermissions)
if($result='0′){write-host "`tApplied WMI Security complete."}
}
}
}
[/sourcecode]
Da nun alles, was mit FIM/WMI zu tun hat, behoben ist, frage ich mich, bei wie vielen anderen installierten Produkten die WMI-Konfigurationen durch den Sturm "freigespült" wurden? Und zur Erinnerung: Überprüfen Sie immer alles in Ihrer Demo-Umgebung am Tag zuvor...
