FIM : Quand les produits ne font pas bon ménage...

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.

Après l'échec de ma démonstration de réinitialisation du mot de passe SSPR, j'ai procédé à la liste de contrôle standard de dépannage, y compris la vérification de la configuration. La première chose que j'ai constatée était l'absence de permissions pour le compte du service FIM sur l'espace de noms Root/CIMV2 de WMI. Comme il s'agissait d'un environnement SSPR fonctionnel, je sais qu'elles avaient été définies auparavant. En outre, l'espace de noms Root/MicrosoftIdentityIntegrationServer était également absent de l'arborescence. Mon emploi du temps me laissait suffisamment de temps pour réparer le problème, mais pas pour effectuer une analyse complète de la cause première de la situation.

Quelques jours plus tard, je suis confronté à des problèmes lorsque j'effectue des appels WMI vers un environnement FIM complètement différent. J'ai immédiatement jeté un coup d'œil à l'espace de noms WMI et j'ai constaté les mêmes problèmes que précédemment. Dans le cadre de mes projets actuels et de ma curiosité personnelle, je dispose actuellement de quatre environnements FIM différents, R1 ou R2, tout-en-un ou mis en œuvre à l'échelle. En examinant les environnements supplémentaires, j'ai constaté qu'ils étaient tous confrontés aux mêmes problèmes d'absence de WMI. Cela inclut le serveur que j'ai réparé il y a quelques jours.

Il est donc temps de s'attaquer à la racine du problème. Si vous avez déjà exécuté le processus How to register the FIM WMI Provider (Comment enregistrer le fournisseur WMI de FIM) tel qu'il est décrit sur le site TechNet de Microsoft, l'une des choses que vous remarquerez est l'avertissement concernant le #PARGMA AUTORECOVER. En gardant cela à l'esprit, j'en ai conclu que quelque chose provoquait une reconstruction de la configuration WMI pour ces serveurs. En combinant cela avec une quantité excessive de journaux d'événements concernant les réinstallations quotidiennes du client SCCM et les erreurs WMI, je me suis concentré sur la recherche d'un problème lié à SCCM. C'est alors que je suis tombé sur la KB2796086 intitulée "Configuration Manager Management Points collocated with clients fail after installing Windows Management Framework 3.0 and running Client Health Evaluation" (Les points de gestion de Configuration Manager situés avec des clients échouent après l'installation de Windows Management Framework 3.0 et l'exécution de Client Health Evaluation).

Comme je l'ai dit au début, on trouve parfois des produits qui ne fonctionnent pas bien ensemble. Dans mon environnement de laboratoire, j'ai tendance à tout installer partout, y compris les clients SCCM sur tous les serveurs et toutes les mises à jour Windows au fur et à mesure qu'elles sont publiées, ce qui constitue une tempête parfaite pour FIM, SCCM 2012 et WMF 3.0. Heureusement, l'article de la base de données décrit un paramètre de registre permettant de produire un avertissement plutôt que de reconstruire la WMI à chaque fois, ce qui, je peux le vérifier, a résolu mes divers problèmes de WMI FIM. De plus, l'article du KB indique que SCCM SP1 corrigera les problèmes de compatibilité entre SCCM et WMF.

Les erreurs que vous pourriez rencontrer vous aideront à identifier le problème :

• SSPR produit une erreur côté client : "L'activité PWReset a renvoyé le code d'état PWUnrecoverableError" lors de la soumission du nouveau mot de passe.
• Erreur de script PowerShell : "get-wmiobject : Invalid namespace root\MicrosoftIdentityIntegrationServer"

L'un des points positifs est qu'il existe une source unique d'instructions de réparation basées sur une combinaison des processus des documents précédents et un script PowerShell supplémentaire pour définir les autorisations sur Root/MicrosoftIdentityIntegrationServer.

• Mettre à jour le registre du serveur comme indiqué dans KB2796086
• Suivez FIM-REFERENCE : Comment enregistrer le fournisseur WMI de la FIM pour réparer WMI.
• Suivez le post de Brad Turner How to Use PowerShell to Set WMI Permissions for FIM Self-Service Password Reset (en-US)
• Et le script suivant pour réinitialiser les autorisations sur le serveur Root/MicrosoftIdentityIntegrationServer

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…