En tant que consultant, l'une des principales responsabilités est de traiter les problèmes étranges ou les questions qui se posent. Comme je suis spécialisé dans Forefront Identity Manager de Microsoft et que j'ai été ingénieur Windows Server, je dispose d'un laboratoire virtuel de développement et de démonstration assez complet, dans lequel presque tous les produits Microsoft Server courants sont déployés sur une moyenne de 80 serveurs virtuels. Si les circonstances s'y prêtent, vous trouverez des produits qui ne s'accordent pas entre eux.
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
[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 - Met à jour les permissions WMI pour l'objet MicrosoftIdentityIntegrationServer"
Write-Host "`tÉcrit par Terry Phillips ([email protected])"
Write-Host "`tBlog : https://www.css-security.com/category/blog/"
fonction 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 (Permission WMI - Exécuter des méthodes, écrire au fournisseur, activer un compte, activer à distance)
$WMISDDL = "A;;CCDCRPWP;;;$sid"
#PartialMatch
$WMISDDLPartialMatch = "A;;w+;;;$sid"
foreach ($strcomputer in $computers)
{
write-host "`nWorking on $strcomputer adding $strprincipal..." (Travail sur $strcomputer ajoutant $strprincipal...)
$security = Get-WmiObject -ComputerName $strcomputer -Namespace root/MicrosoftIdentityIntegrationServer -Class __SystemSecurity
$binarySD = @($null)
$result = $security.PsBase.InvokeMethod("GetSD",$binarySD)
# Convertir les permissions actuelles au format SDDL
write-host "`tConversion des autorisations actuelles au format SDDL..."
$converter = new-object system.management.ManagementClass Win32_SecurityDescriptorHelper
$CurrentWMISDDL = $converter.BinarySDToSDDL($binarySD[0])
# Construire les nouvelles permissions
write-host "`Construction des nouvelles permissions..."
if (($CurrentWMISDDL.SDDL -match $WMISDDLPartialMatch) -and ($CurrentWMISDDL.SDDL -notmatch $WMISDDL)))
{
write-host "`mise à jour du SID en cours"
}
else
{
$NewWMISDDL = $CurrentWMISDDL.SDDL + "(" + $WMISDDL + ")"
}
# Convert SDDL back to Binary
write-host "`tConversion de SDDL en binaire..."
$WMIbinarySD = $converter.SDDLToBinarySD($NewWMISDDL)
$WMIconvertedPermissions = ,$WMIbinarySD.BinarySD
# Appliquer les changements
write-host "`Application des modifications..."
if ($CurrentWMISDDL.SDDL -match $WMISDDL)
{
write-host "`Les autorisations WMI actuelles correspondent à la valeur souhaitée.
}
else
{
$result = $security.PsBase.InvokeMethod("SetSD",$WMIconvertedPermissions)
if($result='0′){write-host "`tApplied WMI Security complete."}
}
}
}
[/sourcecode]
Tous les problèmes liés à FIM/WMI étant résolus, je me demande combien d'autres produits installés ont vu leurs configurations WMI "rincées" dans la tempête ? Et pour rappel : Vérifiez toujours tout dans votre environnement de démonstration la veille...