Como consultor, una de las principales responsabilidades es hacer frente a los problemas o cuestiones extrañas que surgen. Dado que estoy especializado en Forefront Identity Manager de Microsoft, combinado con una vida anterior como ingeniero de Windows Server, dirijo un laboratorio virtual de desarrollo y demostración bastante completo con casi todos los productos principales de Microsoft Server desplegados en una media de 80 servidores virtuales. Si se dan las circunstancias adecuadas, encontrarás productos que no se llevan bien entre sí.
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
[sourcecode language="powershell"]
PARAM(
$Principales = $(throw "`nMissing -Principales ('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 - Actualiza los permisos WMI para el objeto MicrosoftIdentityIntegrationServer"
Write-Host "`tEscrito por Terry Phillips ([email protected])"
Write-Host "`tBlog: https://www.css-security.com/category/blog/"
función get-sid
{
PARAM ($DSIdentidad)
$ID = nuevo-objeto System.Security.Principal.NTAccount($DSIdentidad)
return $ID.Translate( [System.Security.Principal.SecurityIdentifier] ).toString()
}
foreach ($strprincipal in $Principales)
{
$sid = get-sid $strprincipal
Permiso #WMI - Ejecutar métodos, escritura de proveedor, habilitar cuenta, habilitar remoto sólo para este espacio de nombres
$WMISDDL = "A;;CCDCRPWP;;;$sid"
#CoincidenciaParcial
$WMISDDLPartialMatch = "A;;w+;;;$sid"
foreach ($ordenadorstr en $ordenadores)
{
write-host "`nTrabajando en $strordenador añadiendo $strprincipal..."
$security = Get-WmiObject -ComputerName $strcomputer -Namespace root/MicrosoftIdentityIntegrationServer -Class __SystemSecurity
$binarySD = @($null)
$resultado = $security.PsBase.InvokeMethod("GetSD",$binarySD)
# Convertir los permisos actuales a SDDL
write-host "`tConvirtiendo los permisos actuales a formato SDDL..."
$converter = new-object system.management.ManagementClass Win32_SecurityDescriptorHelper
$CurrentWMISDDL = $converter.BinarySDToSDDL($binarySD[0])
# Construir los nuevos permisos
write-host "`tConstruyendo los nuevos permisos..."
if (($CurrentWMISDDL.SDDL -match $WMISDDLPartialMatch) -and ($CurrentWMISDDL.SDDL -notmatch $WMISDDL))
{
write-host "`realizando actualización de SID"
}
else
{
$NewWMISDDL = $CurrentWMISDDL.SDDL + "(" + $WMISDDL + ")"
}
# Convertir SDDL de nuevo a binario
write-host "`tConvirtiendo SDDL de nuevo a binario..."
$WMIbinarySD = $converter.SDDLToBinarySD($NewWMISDDL)
$WMIconvertedPermissions = ,$WMIbinarySD.BinarySD
# Aplicar los cambios
write-host "`tAplicando cambios..."
if ($CurrentWMISDDL.SDDL -match $WMISDDL)
{
write-host "`tLos permisos WMI actuales coinciden con el valor deseado."
}
else
{
$resultado = $security.PsBase.InvokeMethod("SetSD",$WMIconvertedPermissions)
if($result='0′){write-host "`tApplied WMI Security complete."}
}
}
}
[/sourcecode]
Una vez solucionado todo lo relacionado con FIM/WMI, me pregunto a cuántos otros productos instalados se les ha "limpiado" la configuración de WMI con la tormenta. Y como recordatorio: Comprueba siempre todo en tu entorno de demostración el día anterior...
