Archivos de la categoría: Active Directory

Cuentas con privilegios locales en productos de System Center

Hola Mundo:
Los productos de System Center están orientados, principalmente, a la administración. Por lo tanto,
es necesario que estas herramientas tengan los privilegios adecuados, ni más ni menos, para poder realizar operaciones propias de la administración con ellas.
Es el caso de System Center Operations Manager en el que la plataforma debe tener acceso  a la máquina que será monitoreada para la instalación del agente, ya sea en cualquier plataforma, o bien, para la ejecución de procesos propios del monitoreo. Esta cuentas son las Action Account y RunAs Accounts. También existen otras cuentas de mantenimiento que no serán tocadas en este artículo.
Por su parte, System Center Configuration Manager, tiene que ser capaz de realizar la instalación del agente, Client Push Installation Account, o poder subir a la máquina al dominio, en caso de estar ejecutando un Task Sequence de distribución de sistemas operativos que incluya esa tarea.

En muchos casos, también se debe configurar una cuenta para que la máquina pueda acceder a los recursos en red para la obtención de un paquete. En los dos últimos casos, esta cuenta se llama Network Access Account.
Es una muy buena práctica y altamente recomendado que las cuentas a configurar no tengan privilegios sobre el dominio. Solo deben poder autenticarse. Es un riesgo innecesario que las cuentas tengan privilegios de administrador de dominio. 
La creación de una cuenta que tenga permisos de administración local de las máquinas administradas no es proceso distinto a como cuando se crea una cuenta de usuario en Active Directory.  
Lo que si es necesario es la configuración de una política de dominio para que esta cuenta se miembro del  grupo de administradores de la máquina.
Para crear esta política ir a la herramienta de administración de políticas de grupo (se requiere permisos sobre el dominio para llevar a cabo esta acción). Idealmente, esta cuenta no debe expirar. En el caso de cambio de contraseña, actualizar las configuraciones realizadas en la plataforma.
Crear una nueva política y asignarle un nombre descriptivo.
En el editor de políticas, navegar hacia: Computer Configuration -> Preferences -> Control Panel Settings -> Local Users and Groups
Crear una nueva definición de grupo. Tener muy en cuenta que la acción Update no quitará los otros miembros que ya forman parte del grupo de administradores local de las máquinas. El ámbito de esta configuración solo aplica a nivel local de las máquinas clientes.
En el combo box se debe seleccionar el grupo Administrators (built-in)
En la última porción del cuadro, se debe agregar los miembros. Aquí es donde se agrega la cuenta que se creó para este propósito. La acción debe ser  Add to this group.
Así se verá el cuadro una vez que se hayan realizado las configuraciones necesarias
Dándole OK a todos los cuadros, la política queda lista para ser enlazada a una OU de computadores y las cuentas listas para ser configuradas.
Sobre los detalles de cuentas de SCCM y SCOM visitar los enlaces:
Espero que sea de su utilidad.

Error con SSRS y SCCM

Hola Mundo:

Actualizar un SCCM 2012 a 2012 R2 puede ser una tarea sin mayor complicación, pero si no se toman los resguardos puede provocar un gran dolor de cabeza.
Uno de los elementos que hay que tener en cuenta es el acceso a los servicios de apoyo, como lo que es SQL Server Reporting Services, en el que SCCM se conecta para consumir sus propios reportes.
Para que SCCM pueda acceder a SSRS necesita de una cuenta de usuario. Esta cuenta debe tener ciertos privilegios sobre el servidor de reportes para que pueda crearlos y consumirlos. Esta autenticación es permanente. 
El error que puede aparecer en el servidor de reportes es:
System.Web.Services.Protocols.SoapException: The DefaultValue expression for the report parameter ‘UserTokenSIDs’ contains an error: Logon failure: unknown user name or bad password. 

Según la documentación: https://technet.microsoft.com/en-us/library/gg712698.aspx#BKMK_InstallReportingServicesPoint la cuenta de servicio que accede al servidor de reportes, debe formar parte del grupo Windows Authorization Access Group y debe tener acceso a los Token Groups Global And Universal

Una vez que agreguen la cuenta al grupo, el problema estará solucionado.

Saludos!

Instalación de roles requeridos para SCCM

Hola Mundo:

Hoy les quiero compartir una herramienta que, en lo personal, me apoya bastante en la instalación de SCCM 2012 y 2012 R2.

Es un script construido en Powershell y tiene interfaz gráfica (¡Si! y no bromeo). Requiere de permisos de administador para ejecutar.

Más información sobre las características y descargas pueden encontrarlas en el link de la herramienta:https://gallery.technet.microsoft.com/ConfigMgr-2012-R2-e52919cd

Antes de ejecutar, hay que quitar la protección de ejecución de scripts de Powershell:

Una vez que el sistema está permisivo, se ejecuta la herramienta y muestra su ventana principal:

De inmediato la herramienta acusa que le falta un reinicio al servidor y que no está siendo ejecutada con permisos de administrador.
Ofrece instalar los roles requeridos para cada uno de los tipos de sitio y además permite hacer la descarga de los paquetes requeridos.
También permite hacer otras operaciones como la extensión de esquema de Active Directory, instalación de WSUS, instalación de Windows ADK, creación del contenedor System Management, entre otros.
Si quieres instalar SCCM esta herramienta ayudará a ahorrar mucho trabajo y disminuye el riesgo de la falta de algún rol o configuración.
Espero que les sirva.
¡Chau!

Migración de File Server y configuración de los SPN

Hola Mundo:
No hay migración de servicios que no esté acompañada de dolores de cabeza. Especialmente si son servicios críticos para las organizaciones, como es el caso de los servidores de archivos.

Nunca hay que creer cuando comentan que la migración de un File Server es solo mover los archivos de un lugar a otro usando Robocopy y luego hacer el cambio en el servidor DNS para que siga conservando el mismo nombre que el servidor de origen y el cambio sea transparente a los usuarios.

Antes de explicar el cambio de SPN, me gustaría que se entendiera el concepto de SPN en su definición más fundamental.
SPN viene de la sigla de Service Principal Name.
Éstos deben estar asociados a un objeto de Active Directory (cuenta de usuario, grupo o computador) en el cual el servicio se ejecuta. Su función principal es soportar la autenticación mutua entre un cliente y un servicio.

Entonces, la configuración de un SPN consiste en la asociación de un servicio a un objeto de AD. Un objeto de AD puede tener varios SPN asociados, pero un SPN solo puede estar asociado a un objeto de AD. En el caso de que se duplique un SPN, vendrán los problemas.

Cuando se realiza una migración de File Server y posteriormente se hace el cambio en el DNS para que el antiguo servidor apunte al nuevo y se intenta acceder a la ruta, el visor de eventos mostrará un error así:

The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server SRV-NUEVO$. The target name used was cifs/SRV-VIEJO. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using. Ensure that the target SPN is only registered on the account used by the server. This error can also happen if the target service account password is different than what is configured on the Kerberos Key Distribution Center for that target service. Ensure that the service on the server and the KDC are both configured to use the same password. If the server name is not fully qualified, and the target domain (DOMINIO.CL) is different from the client domain (DOMINIO.CL), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server. 

Como el SPN no estaba configurado de forma correcta, no es posible hacer ni mantener la autenticación, por lo tanto, da error.

Para configurar el SPN, se debe hacer con una cuenta con privilegios sobre el dominio.

Eliminando un SPN
Antes de asignar un SPN a un objeto, hay que eliminarlo  del objeto al cual estaba asignado. Se debe seguir la sintaxis:
setspn -D servicio/host ObjetoAD Por ejemplo:

setspn -D host/srv-viejo.midominio.cl srv-viejo
setspn -D host/srv-viejo srv-viejo
setspn -D cifs/srv-viejo.midominio.cl srv-viejo
setspn -D cifs/srv-viejo srv-viejo

De esta forma se elimina los SPN asociados al file server del objeto srv-viejo.

Asociar un SPN
Una vez desasociados los SPN al antiguo objeto, se debe asociar al nuevo objeto. La sintaxis es:
setspn -S servicio/host ObjetoAD Por ejemplo:

setspn -S host/srv-viejo.midominio.cl srv-nuevo
setspn -S host/srv-viejo srv-nuevo
setspn -S cifs/srv-viejo.midominio.cl srv-nuevo
setspn -S cifs/srv-viejo srv-nuevo

De esta forma, el servicio podrá autenticar y mantener la autenticación. El recurso compartido es accesible desde los clientes. Hay que tener un especial cuidado con los clientes con Windows XP. Por que aparte de configurar los SPN correspondientes, también hay que hacer un cambio en el editor del registro de Windows. Seguir la documentación de este link: https://support.microsoft.com/en-us/kb/281308

Más información sobre la herramienta setspn se puede encontrar aqui: https://technet.microsoft.com/en-us/library/cc961723.aspx

Así que para la próxima vez que alguien diga que las migraciones de File Server son un proceso sencillo y sin muchos pasos, es pura fantasía.

Hasta la próxima.

Chau