FIM: Wenn Produkte nicht gut zusammenpassen...

As a consultant, one of the primary responsibilities is to deal with strange problems or issues that arise. And inevitably some obscure issue will come to the surface during a demo… Since I specialize in Microsoft’s Forefront Identity Manager combined with a previous life as a Windows Server Engineer, I run a fairly comprehensive virtual development and demo lab with about every mainstream Microsoft Server product deployed across an average of 80 virtual servers. Given the right set of circumstances you’ll find products that just don’t play nice together.

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

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 - Updates WMI Permissions for MicrosoftIdentityIntegrationServer object"
Write-Host "`tWritten by Terry Phillips ([email protected])"
Write-Host "`tBlog: https://www.css-security.com/category/blog/"

function 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 Permission - Execute Methods, Provider Write, Enable Account, Remote Enable for This namespace only
$WMISDDL = "A;;CCDCRPWP;;;$sid"

#PartialMatch
$WMISDDLPartialMatch = "A;;w+;;;$sid"

foreach ($strcomputer in $computers)
{
write-host "`nWorking on $strcomputer adding $strprincipal..."
$security = Get-WmiObject -ComputerName $strcomputer -Namespace root/MicrosoftIdentityIntegrationServer -Class __SystemSecurity
$binarySD = @($null)
$result = $security.PsBase.InvokeMethod("GetSD",$binarySD)

# Convert the current permissions to SDDL
write-host "`tConverting current permissions to SDDL format..."
$converter = new-object system.management.ManagementClass Win32_SecurityDescriptorHelper
$CurrentWMISDDL = $converter.BinarySDToSDDL($binarySD[0])

# Build the new permissions
write-host "`tBuilding the new permissions..."
if (($CurrentWMISDDL.SDDL -match $WMISDDLPartialMatch) -and ($CurrentWMISDDL.SDDL -notmatch $WMISDDL))
{
write-host "`tperforming SID Update"
}
else
{
$NewWMISDDL = $CurrentWMISDDL.SDDL + "(" + $WMISDDL + ")"
}

# Convert SDDL back to Binary
write-host "`tConverting SDDL back into binary form..."
$WMIbinarySD = $converter.SDDLToBinarySD($NewWMISDDL)
$WMIconvertedPermissions = ,$WMIbinarySD.BinarySD

# Apply the changes
write-host "`tApplying changes..."
if ($CurrentWMISDDL.SDDL -match $WMISDDL)
{
write-host "`tCurrent WMI Permissions matches desired value."
}
else
{
$result = $security.PsBase.InvokeMethod("SetSD",$WMIconvertedPermissions)
if($result='0'){write-host "`tApplied WMI Security complete."}
}
}
}

With all things FIM/WMI related fixed, that leaves me to wonder how many other installed products had their WMI configs “rinsed clean” in the storm? And as a reminder: Always check everything in your demo environment the day before…