FIM: Cuando los productos no se integran bien…

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.

Después de mi demostración fallida de restablecimiento de contraseña SSPR, fui a través de la lista de verificación de solución de problemas estándar, incluyendo la verificación de la configuración. Lo primero que encontré fue que faltaban permisos para la cuenta de servicio FIM en el espacio de nombres Root/CIMV2 de WMI. Dado que se trataba de un entorno SSPR funcionamiento, Sé que se habían establecido previamente. Además, el espacio de nombres Root/MicrosoftIdentityIntegrationServer faltaba en el árbol también. Mi horario me dio tiempo suficiente para reparar el problema, pero no para realizar un análisis completo de la causa raíz de la situación.

Un avance rápido de unos días más y ahora estoy enfrentando problemas al hacer llamadas FIM WMI a un entorno FIM totalmente diferente. Inmediatamente eché un vistazo al espacio de nombres WMI para encontrar los mismos problemas que antes. Para ayudar con mis proyectos actuales y curiosidad personal, actualmente tengo 4 entornos FIM diferentes construidos, R1 o R2, todo en uno a implementaciones escaladas. Mirando a los entornos adicionales, todos ellos también se enfrentaron a los mismos problemas de WMI faltante. Esto incluye el servidor que acababa de reparar hace unos días.

Así que ahora es el momento de ir a la raíz del problema. Si alguna vez ha ejecutado el proceso Cómo registrar el proveedor WMI de FIM tal como se indica en TechNet de Microsoft, una de las cosas que notará es la advertencia con respecto al #PARGMA AUTORECOVER. Con esto en mente, esto me llevó a la conclusión de que algo estaba causando una reconstrucción en la configuración de WMI para estos servidores. Combinando eso con una cantidad excesiva de registro de eventos con respecto a las reinstalaciones diarias de clientes SCCM y errores WMI, me centré en la búsqueda de un problema relacionado con SCCM. Fue entonces cuando me encontré con KB2796086 titulado "Configuration Manager Management Points collocated with clients fail after installing Windows Management Framework 3.0 and running Client Health Evaluation".

Como dije al principio, a veces encuentras productos que no juegan bien juntos. En mi entorno de laboratorio tiendo a instalar todo en todas partes, incluyendo clientes SCCM en todos los servidores y todas las actualizaciones de Windows a medida que se liberan, proporcionando así la tormenta perfecta para FIM, SCCM 2012 y WMF 3.0. Afortunadamente, el artículo de KB esboza una configuración de registro para producir una advertencia en lugar de reconstruir el WMI cada vez, lo que puedo verificar que ha resuelto mis diversos problemas de FIM WMI. Además, el artículo KB establece SCCM SP1 solucionará los problemas de compatibilidad entre SCCM y WMF.

Errores que puede ver para ayudar a identificar el problema:

• SSPR produce error del lado del cliente: "PWReset activity returned status code PWUnrecoverableError" al enviar la nueva contraseña.
• Error de secuencia de comandos PowerShell: "get-wmiobject: Invalid namespace root\MicrosoftIdentityIntegrationServer"

Una cosa positiva que sale de esto es una única fuente de instrucciones de reparación basada en una combinación de procesos de documentos anteriores y un script PowerShell adicional para establecer permisos en Root/MicrosoftIdentityIntegrationServer.

• Actualice el registro del servidor como se indica en KB2796086
• Siga FIM-REFERENCE: Cómo registrar el Proveedor WMI FIM para reparar WMI.
• Siga el artículo de Brad Turner Cómo utilizar PowerShell para establecer permisos de WMI para el restablecimiento de contraseñas de autoservicio de FIM (en-US)
• Y el siguiente script para restablecer los permisos en el 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…