none
Usuarios de servicio o cuentas de servicio gestionada RRS feed

  • Pregunta

  • Saludos, estoy buscando la forma de poder crear usuarios de servicio en la que no tenga que indicar una contraseña sino que sea el AD quien se encargue de esto. He visto un procedimiento pero al tratar de replicarlo cuando asigno el usuario creado al servicio y trato de iniciarlo se despliega un mensaje de error 1068 esto ya desde el equipo destino, si lo realizo en el mismo server funciona sin problemas.

    En este video es donde he visto los pasos:   https://www.youtube.com/watch?v=XkCDfmT_MIE

    Luego de analizar el tema, requiero que el usuario pueda ser usado en varios servidores, no en uno específico como sería al seguir estos pasos.

    Les agradezco si me pueden brindar una orientación para poder realizar esta tarea.

    Saludos,

    Jorge


    Jorge

    jueves, 4 de abril de 2019 4:50

Respuestas

  • Hola konacurmi, hay algo importante a tener en cuenta, porque muchas veces por la nomenclatura que se le ha dado no es clara la diferencia

    No es lo mismo "Managed Service Account" que "Group Managed Service Account", para usarla en varios servidores debe ser obligatoriamente la segunda opción

    Si no recuerdo mal, es una de las nuevas características de W2012R2

     


    Guillermo Delprato
    Buenos Aires, Argentina
    El Blog de los paso a paso

    MCSE - MCSA2012
    MCITP: Enterprise Administrator / Server Administrator
    MCTS: Active Directory/Network Configuration/Applications Configuration/Server Virtualization/Windows 7 Configuration/Windows 7 & Office 2010 Deployment/Vista Configuration

    Este mensaje se proporciona "como está" sin garantías de ninguna clase. Usted asume todos los riesgos.

    jueves, 4 de abril de 2019 11:38
    Moderador
  • Buen dia "konacurmi",

    Recomiendo saber como trabaja una cuanta de servicio y en que casos se usa, debajo dejo una notas:

    Using a Domain User Account as a Service Logon Account
    https://docs.microsoft.com/en-us/windows/desktop/ad/domain-user-accounts

    What's New for Managed Service Accounts
    https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/what-s-new-for-managed-service-accounts

    Windows Server 2012: Group Managed Service Accounts
    https://blogs.technet.microsoft.com/askpfeplat/2012/12/16/windows-server-2012-group-managed-service-accounts/

    Espero sea de ayuda
    Saludos.

    jueves, 4 de abril de 2019 11:21
  • CUENTAS DE SERVICIO
    Cuando hablamos de cuentas de servicio, hacemos referencia a cuentas normales de usuario pero las cuales van a ser utilizadas por un "servicio" como por ejemplo Internet Information Services IIS o SQL Server, la única diferencia con una cuenta normal de usuario, es que indicamos que la contraseña nunca caduca, lo cual claramente representa un riesgo de seguridad, y si por alguna razón el dominio no maneja contraseñas complejas el riesgo es aún mayor, se hace de este modo debido a que generalmente se puede utilizar una cuenta de dominio en más de un equipo, por ejemplo, el servicio de una herramienta de copia de seguridad se puede configurar para correr en múltiples equipos al mismo tiempo, sin embargo si cambia la contraseña de dominio, debe cambiarla manualmente en cada uno de los servidores que la usan. 
    CUENTAS DE SERVICIO ADMINISTRADAS

    Para desafiar los riesgos expuestos en el punto anterior, a partir de Windows Server 2008 R2, Microsoft lanzó una característica llamada Managed Service Account (MSA en adelante) o  cuenta de servicio administrada en español.
    Se trata de una cuenta de dominio que se asocia a un servicio en un único computador, y uno o varios servicios pueden usar dicha cuenta en el mismo servidor como cuenta para iniciar el servicio. El computador, de manera automática cambia la contraseña de la cuenta de servicio cada 30 días por defecto.
    Otro tema asociado MSA es la administración de los Service Principal Names (SPN) los cuales son componentes críticos de la autenticación Kerberos. Las cuentas de servicio administradas se aseguran que si el nombre de un computador cambia los SPN asociados con el servicio en ejecución cambian en el dominio, adicionalmente la administración de SPN puede ser delegada a otros administradores.
    Para poder utilizar MSA el nivel funcional del dominio debe ser Windows Server 2008 R2 en adelante, si el nivel funcional es Windows Server 2008, puede usar MSA pero la administración de SPN debe hacerse de forma manual. MSA puede usarse en equipos desde Windows 7 en adelante y en servidores Windows Server 2008 R2 en adelante no es posible utilizar esta característica en versiones anteriores a las mencionadas.
    CREAR Y CONFIGURAR UNA CUENTA DE SERVICIO ADMINISTRADA

    Hasta el momento para crear y utilizar MSA se debe hacer uso de Windows PowerShell, no existe una GUI para hacerlo.
    Para crear una MSA se debe ejecutar lo siguiente:
    Add-KdsRootKey –EffectiveTime ((get-date).addhours(-10))

    Seguidamente, ejecutamos lo siguiente:
    New-ADServiceAccount MiServicio -Enabled $true -Path "CN=Managed Service Accounts, DC=contoso,DC=com"

    Nota sobre versiones: Es importante tener en cuenta que las MSA solamente pueden usarse con servicios Windows, hasta el momento esta característica no es soportada en servicios que no sean Windows, por otra parte, al no poder usarse la cuenta en más de un computador, no es posible usarlas en servicios de balanceo de carga o en cluster, como por ejemplo granjas de Sharepoint, ya que éstas usan varios servidores, pero OJO, esto solo ocurre si usa Windows Server 2008 R2, si está usando Windows Server 2012 R2 puede utilizar una nueva característica llamada Group Managed Service Account gMSA, que permite usar la misma cuenta en más de un servidor, lo cual significa que ahora si la podemos usar en servicios de balanceo de carga y cluster. 
    Para crear grupos de cuentas de servicio administradas solo se hacen unos pequeños cambios, que básicamente consisten en indicar los nombres de los computadores que pueden usar la cuenta agregando el signo $
    Set-ADServiceAccount –Identity MiServicio -PrincipalsAllowedToRetrieveManagedPassword SRV01$, SRV02$


    Si tiene varios equipos para crear el grupo, tal vez prefiera especificar un grupo de seguridad que contenga todos lo equipos que conformarán el grupo, en lugar de especificar uno por uno, para ello puede ejecutar lo siguiente, suponiendo que el grupo que contiene los equipos se llama GMSA-Group
    New-ADServiceAccount –Name MiServicio –PrincipalsAllowedToRetrieveManagedPassword GMSA-Group –DNSHostname dc1.contoso.com
    Por último, ya podemos hacer uso de la cuenta en cualquier servicio Microsoft que ofrezca soporte para MSA o GMSA.
    Si revisamos el contenedor Managed Service Accounts en Active Directory podemos observar que allí se encuentra la MSA.
    Luego, podemos usar la cuenta en cualquier servicio, buscándola desde las propiedades del mismo.
    jueves, 4 de abril de 2019 15:46
  • Gracias Ignacio, la idea es poder cambiar los usuarios que se crean de forma normal y que tienen una contraseña, que son para uso de algunos sistemas, el problema es porque esas claves se les brindó a los desarrolladores en algún momento y ahora las utilizan para acceso remoto lo cuál se requiere eliminar. Al usar este tipo de cuenta nos asegura que el usuario será únicamente para los servicios.

    He realizado los procedimientos que he encontrado, pero siempre tengo el mismo problema, al querer iniciar un servicio por ejemplo el Spooler de impresión, sale el error 1068

    Lo de los grupos es debido a que un usuario se va a requerir pueda ejecutarse en varios servidores.


    Jorge

    viernes, 5 de abril de 2019 5:29
  • Respecto al error 1068, lo único que encuentro es este enlace ¿podrá ser?

    The SQL Server service and the SQL Server Agent Service fail to start on a stand-alone server
    https://support.microsoft.com/en-us/help/307288/the-sql-server-service-and-the-sql-server-agent-service-fail-to-start

    Respecto al tema de los desarrolladores-administradores es un tema difícil, porque si no son administradores, por lo menos dicen, que no pueden aunque a veces puedan :)

    Es un tema a plantear en un foro de desarrollo donde quizás puedan compartirte alguna experiencia, por mi parte no se me ocurre nada a no ser un tipo contrato obligatorio donde se establezcan condiciones muy claras sobre qué es lo que pueden y lo que no pueden. Con esto no puedo ayudarte mucho :(

     


    Guillermo Delprato
    Buenos Aires, Argentina
    El Blog de los paso a paso

    MCSE - MCSA2012
    MCITP: Enterprise Administrator / Server Administrator
    MCTS: Active Directory/Network Configuration/Applications Configuration/Server Virtualization/Windows 7 Configuration/Windows 7 & Office 2010 Deployment/Vista Configuration

    Este mensaje se proporciona "como está" sin garantías de ninguna clase. Usted asume todos los riesgos.

    viernes, 5 de abril de 2019 21:09
    Moderador

Todas las respuestas

  • Buen dia "konacurmi",

    Recomiendo saber como trabaja una cuanta de servicio y en que casos se usa, debajo dejo una notas:

    Using a Domain User Account as a Service Logon Account
    https://docs.microsoft.com/en-us/windows/desktop/ad/domain-user-accounts

    What's New for Managed Service Accounts
    https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/what-s-new-for-managed-service-accounts

    Windows Server 2012: Group Managed Service Accounts
    https://blogs.technet.microsoft.com/askpfeplat/2012/12/16/windows-server-2012-group-managed-service-accounts/

    Espero sea de ayuda
    Saludos.

    jueves, 4 de abril de 2019 11:21
  • Hola konacurmi, hay algo importante a tener en cuenta, porque muchas veces por la nomenclatura que se le ha dado no es clara la diferencia

    No es lo mismo "Managed Service Account" que "Group Managed Service Account", para usarla en varios servidores debe ser obligatoriamente la segunda opción

    Si no recuerdo mal, es una de las nuevas características de W2012R2

     


    Guillermo Delprato
    Buenos Aires, Argentina
    El Blog de los paso a paso

    MCSE - MCSA2012
    MCITP: Enterprise Administrator / Server Administrator
    MCTS: Active Directory/Network Configuration/Applications Configuration/Server Virtualization/Windows 7 Configuration/Windows 7 & Office 2010 Deployment/Vista Configuration

    Este mensaje se proporciona "como está" sin garantías de ninguna clase. Usted asume todos los riesgos.

    jueves, 4 de abril de 2019 11:38
    Moderador
  • CUENTAS DE SERVICIO
    Cuando hablamos de cuentas de servicio, hacemos referencia a cuentas normales de usuario pero las cuales van a ser utilizadas por un "servicio" como por ejemplo Internet Information Services IIS o SQL Server, la única diferencia con una cuenta normal de usuario, es que indicamos que la contraseña nunca caduca, lo cual claramente representa un riesgo de seguridad, y si por alguna razón el dominio no maneja contraseñas complejas el riesgo es aún mayor, se hace de este modo debido a que generalmente se puede utilizar una cuenta de dominio en más de un equipo, por ejemplo, el servicio de una herramienta de copia de seguridad se puede configurar para correr en múltiples equipos al mismo tiempo, sin embargo si cambia la contraseña de dominio, debe cambiarla manualmente en cada uno de los servidores que la usan. 
    CUENTAS DE SERVICIO ADMINISTRADAS

    Para desafiar los riesgos expuestos en el punto anterior, a partir de Windows Server 2008 R2, Microsoft lanzó una característica llamada Managed Service Account (MSA en adelante) o  cuenta de servicio administrada en español.
    Se trata de una cuenta de dominio que se asocia a un servicio en un único computador, y uno o varios servicios pueden usar dicha cuenta en el mismo servidor como cuenta para iniciar el servicio. El computador, de manera automática cambia la contraseña de la cuenta de servicio cada 30 días por defecto.
    Otro tema asociado MSA es la administración de los Service Principal Names (SPN) los cuales son componentes críticos de la autenticación Kerberos. Las cuentas de servicio administradas se aseguran que si el nombre de un computador cambia los SPN asociados con el servicio en ejecución cambian en el dominio, adicionalmente la administración de SPN puede ser delegada a otros administradores.
    Para poder utilizar MSA el nivel funcional del dominio debe ser Windows Server 2008 R2 en adelante, si el nivel funcional es Windows Server 2008, puede usar MSA pero la administración de SPN debe hacerse de forma manual. MSA puede usarse en equipos desde Windows 7 en adelante y en servidores Windows Server 2008 R2 en adelante no es posible utilizar esta característica en versiones anteriores a las mencionadas.
    CREAR Y CONFIGURAR UNA CUENTA DE SERVICIO ADMINISTRADA

    Hasta el momento para crear y utilizar MSA se debe hacer uso de Windows PowerShell, no existe una GUI para hacerlo.
    Para crear una MSA se debe ejecutar lo siguiente:
    Add-KdsRootKey –EffectiveTime ((get-date).addhours(-10))

    Seguidamente, ejecutamos lo siguiente:
    New-ADServiceAccount MiServicio -Enabled $true -Path "CN=Managed Service Accounts, DC=contoso,DC=com"

    Nota sobre versiones: Es importante tener en cuenta que las MSA solamente pueden usarse con servicios Windows, hasta el momento esta característica no es soportada en servicios que no sean Windows, por otra parte, al no poder usarse la cuenta en más de un computador, no es posible usarlas en servicios de balanceo de carga o en cluster, como por ejemplo granjas de Sharepoint, ya que éstas usan varios servidores, pero OJO, esto solo ocurre si usa Windows Server 2008 R2, si está usando Windows Server 2012 R2 puede utilizar una nueva característica llamada Group Managed Service Account gMSA, que permite usar la misma cuenta en más de un servidor, lo cual significa que ahora si la podemos usar en servicios de balanceo de carga y cluster. 
    Para crear grupos de cuentas de servicio administradas solo se hacen unos pequeños cambios, que básicamente consisten en indicar los nombres de los computadores que pueden usar la cuenta agregando el signo $
    Set-ADServiceAccount –Identity MiServicio -PrincipalsAllowedToRetrieveManagedPassword SRV01$, SRV02$


    Si tiene varios equipos para crear el grupo, tal vez prefiera especificar un grupo de seguridad que contenga todos lo equipos que conformarán el grupo, en lugar de especificar uno por uno, para ello puede ejecutar lo siguiente, suponiendo que el grupo que contiene los equipos se llama GMSA-Group
    New-ADServiceAccount –Name MiServicio –PrincipalsAllowedToRetrieveManagedPassword GMSA-Group –DNSHostname dc1.contoso.com
    Por último, ya podemos hacer uso de la cuenta en cualquier servicio Microsoft que ofrezca soporte para MSA o GMSA.
    Si revisamos el contenedor Managed Service Accounts en Active Directory podemos observar que allí se encuentra la MSA.
    Luego, podemos usar la cuenta en cualquier servicio, buscándola desde las propiedades del mismo.
    jueves, 4 de abril de 2019 15:46
  • Gracias Ignacio, la idea es poder cambiar los usuarios que se crean de forma normal y que tienen una contraseña, que son para uso de algunos sistemas, el problema es porque esas claves se les brindó a los desarrolladores en algún momento y ahora las utilizan para acceso remoto lo cuál se requiere eliminar. Al usar este tipo de cuenta nos asegura que el usuario será únicamente para los servicios.

    He realizado los procedimientos que he encontrado, pero siempre tengo el mismo problema, al querer iniciar un servicio por ejemplo el Spooler de impresión, sale el error 1068

    Lo de los grupos es debido a que un usuario se va a requerir pueda ejecutarse en varios servidores.


    Jorge

    viernes, 5 de abril de 2019 5:29
  • Gracias Guillermo, Lo de los grupos es debido a que un usuario se va a requerir pueda ejecutarse en varios servidores.

    El problema que tengo es al querer iniciar el servicio que muestra siempre el error 1068, no sé si tienes alguna idea de que puede ser, he buscado con agregar el usuario dentro de políticas pero siempre sucede lo mismo (Log On as a Service)

    Saludos y gracias


    Jorge

    viernes, 5 de abril de 2019 5:31
  • Gracias Carlos, justo esa información ya la había revisado, justo es parte de lo que requiero para poder tener un usuario de servicio en varios equipos.

    El detalle es que me muestra el error 1068 cuando intento iniciar algún servicio como el Spooler de impresión.

    Saludos,


    Jorge

    viernes, 5 de abril de 2019 5:34
  • Gracias Guillermo, Lo de los grupos es debido a que un usuario se va a requerir pueda ejecutarse en varios servidores.

    El problema que tengo es al querer iniciar el servicio que muestra siempre el error 1068, no sé si tienes alguna idea de que puede ser, he buscado con agregar el usuario dentro de políticas pero siempre sucede lo mismo (Log On as a Service)

    Saludos y gracias


    Jorge

    Hola Jorge, por ahora no tuve tiempo para buscar por el número de error que nombras ¿lo has hecho? porque seguramente no eres el único

    Por otra parte veo que en una de tus respuestas dices que usan esa cuenta para acceder remotamente ¿es desde afuera? porque eso lo puedes cerrar fácilmente por permisos

     


    Guillermo Delprato
    Buenos Aires, Argentina
    El Blog de los paso a paso

    MCSE - MCSA2012
    MCITP: Enterprise Administrator / Server Administrator
    MCTS: Active Directory/Network Configuration/Applications Configuration/Server Virtualization/Windows 7 Configuration/Windows 7 & Office 2010 Deployment/Vista Configuration

    Este mensaje se proporciona "como está" sin garantías de ninguna clase. Usted asume todos los riesgos.

    viernes, 5 de abril de 2019 11:40
    Moderador
  • Saludos Guillermo, lo que he podido observar del error es que para solucionarlo debo de incluir la contraseña del usuario, que en este caso no se tiene porque la administra el AD. Lo relacionan mucho para servicios de SQL o del IIS.

    Con respecto a lo de los accesos remotos, estos lo usan los desarrolladores para poder accesar a los servidores y así poder hacer cambios sin consentimiento por así decirlo, entonces la idea principal es bloquear dicho acceso sin afectar el servicio.

    Una de mis dudas en este punto de bloquear el acceso remoto es debido a que si el usuario tiene permisos de Administrador (Local), al eliminarle los permisos de acceso remoto, si el servicio se ve afectado.

    En un momento hice un cambio a nivel del usuario, donde está la pestaña de Remote Control, le deshabilité la opción pero al probar, este usuario sigue ingresando remotamente.

    Si tienes una idea de como puedo hacerlo, te lo agradecería.

    Saludos,

    Jorge


    Jorge

    viernes, 5 de abril de 2019 17:48
  • [Guillermo] Respondo entre líneas

     

    Saludos Guillermo, lo que he podido observar del error es que para solucionarlo debo de incluir la contraseña del usuario, que en este caso no se tiene porque la administra el AD. Lo relacionan mucho para servicios de SQL o del IIS.

    [Guillermo] No recuerdo todo el procedimiento, lo leí pero nunca tuve que implementarlo, pero si no recuerdo mal la contraseña de la cuenta de servicio había que dejarla en blanco. Y había uno de los comandos (PowerShell) que incluía un cambio de horario de comienzo porque de otra forma había que esperar 10 horas. Y por supuesto todo desde un PowerShell "ejecutado como administrador"

     

    Con respecto a lo de los accesos remotos, estos lo usan los desarrolladores para poder accesar a los servidores y así poder hacer cambios sin consentimiento por así decirlo, entonces la idea principal es bloquear dicho acceso sin afectar el servicio.

    Una de mis dudas en este punto de bloquear el acceso remoto es debido a que si el usuario tiene permisos de Administrador (Local), al eliminarle los permisos de acceso remoto, si el servicio se ve afectado.

    [Guillermo] Los desarrolladores no deben usar la cuenta del servicio, así que bloquearles el acceso remoto no debería tener ninguna consecuencia, a lo sumo pruebas :) Cuando hablo del acceso remoto me refiero a si el acceso es desde afuera de la red, ahí negarles la entrada, que supongo que será por VPN y a través de un cortafuegos ¿o están permitiendo el acceso directo por Escritorio Remoto? Esto último nunca, es un problema muy grave de seguridad

     

    En un momento hice un cambio a nivel del usuario, donde está la pestaña de Remote Control, le deshabilité la opción pero al probar, este usuario sigue ingresando remotamente.

    [Guillermo] Sí, por que es administrador

     

    Si tienes una idea de como puedo hacerlo, te lo agradecería.

    [Guillermo] A mi entender, el problema es la base de la que se ha partido, y es permitirle a un desarrollador control completo sobre un servidor que es parte de un Domino, y menos en forma remota. Que te pasen por escrito todos los instructivos, que es lo que deberían hacer y documentar, y tu te ocupas de los cambios

     

    Saludos,

    Jorge


    Jorge



    Guillermo Delprato
    Buenos Aires, Argentina
    El Blog de los paso a paso

    MCSE - MCSA2012
    MCITP: Enterprise Administrator / Server Administrator
    MCTS: Active Directory/Network Configuration/Applications Configuration/Server Virtualization/Windows 7 Configuration/Windows 7 & Office 2010 Deployment/Vista Configuration

    Este mensaje se proporciona "como está" sin garantías de ninguna clase. Usted asume todos los riesgos.

    viernes, 5 de abril de 2019 18:43
    Moderador
  • Los accesos son por la red interna, a nivel externo no se brinda.

    Tal como indicas, al seguir el procedimiento, los espacios de contraseña se dejan en blanco, pero al asociar el usuario a un servicio es donde indica ese error que solicita una contraseña.

    Con respecto al brindar la contraseña, lastimosamente ese fue un error del antiguo administrador, y que se tornó como política de que con cada usuario, la contraseña se entregaba, todo para evitar que lo estuvieran llamando cada vez que querían hacer algo con el usuario, por ello buscaba una opción donde la contraseña no se brinde y fue donde surgió el tema de los usuarios de servicio administrados por el AD. Lo correcto es que cada cambio, venga con una solicitud y se da una ventana de tiempo para que entre el desarrollador y quien administra el servidor puedan trabajar.

    La idea es ir cerrando todas esas brechas de seguridad.


    Jorge

    viernes, 5 de abril de 2019 20:23
  • Respecto al error 1068, lo único que encuentro es este enlace ¿podrá ser?

    The SQL Server service and the SQL Server Agent Service fail to start on a stand-alone server
    https://support.microsoft.com/en-us/help/307288/the-sql-server-service-and-the-sql-server-agent-service-fail-to-start

    Respecto al tema de los desarrolladores-administradores es un tema difícil, porque si no son administradores, por lo menos dicen, que no pueden aunque a veces puedan :)

    Es un tema a plantear en un foro de desarrollo donde quizás puedan compartirte alguna experiencia, por mi parte no se me ocurre nada a no ser un tipo contrato obligatorio donde se establezcan condiciones muy claras sobre qué es lo que pueden y lo que no pueden. Con esto no puedo ayudarte mucho :(

     


    Guillermo Delprato
    Buenos Aires, Argentina
    El Blog de los paso a paso

    MCSE - MCSA2012
    MCITP: Enterprise Administrator / Server Administrator
    MCTS: Active Directory/Network Configuration/Applications Configuration/Server Virtualization/Windows 7 Configuration/Windows 7 & Office 2010 Deployment/Vista Configuration

    Este mensaje se proporciona "como está" sin garantías de ninguna clase. Usted asume todos los riesgos.

    viernes, 5 de abril de 2019 21:09
    Moderador