Limite al usuario de AD para que solo inicie sesión en la computadora en una unidad organizativa específica

Limite al usuario de AD para que solo inicie sesión en la computadora en una unidad organizativa específica

Tenemos un dominio AD (aún local) que admite una biblioteca, entre otras cosas. Esta biblioteca tiene varias computadoras públicas y estas computadoras públicas están en su propia unidad organizativa en Active Directory. También tenemos un publicinicio de sesión de invitado genérico que nuestros bibliotecarios pueden usar para dar acceso a las máquinas a invitados externos.

Quiero limitar esta cuenta, y solo esta cuenta, para que solo pueda acceder a las computadoras en la PublicComputersunidad organizativa.

Tenemos muchos otros usuarios que también deberían poder iniciar sesión en estas computadoras y otras.

Conozco el Log On To...botón en un objeto Usuario en AD, pero no encaja bien ya que estas computadoras van y vienen. La membresía de OU se mantiene por otras razones, pero si necesitamos usar ese botón cada vez que una computadora se mueve, rápidamente terminará desactualizado.

Las partes relevantes de nuestra jerarquía AD se ven así:

Domain Root > InstitutionComputers > Library > PublicComputers
            > ServiceAccounts > public
            > Users (group) > {ManyOtherUsers}
            > OtherOU > {ManyOtherUsers}

¿Cómo puedo hacer esto?


Intenté configurar una política de denegación de inicio de sesión a nivel de dominio para incluir la cuenta pública, y luego otra política de denegación de inicio de sesión en el nivel de unidad organizativa más específica que no incluye la cuenta.

En las pruebas, esto funciona en algunas máquinas, pero otras bloquearán el inicio de sesión del usuario público. Si miro en la Política de seguridad local desde una máquina que no funciona, veo que tiene la política completa desde el nivel de dominio, en lugar del nivel de OU. , pero he confirmado que la máquina es miembro de la unidad organizativa correcta. Además, gpresultmuestra ambas políticas. (También estoy agregando esta información a la pregunta), para saber que la política más específica coincide con estas computadoras. Esto continúa sucediendo incluso después de ejecutar gpupdate /forcey reiniciar la computadora.


Resulta que tenía una idea errónea de cómo funciona "aplicado" en la Política de grupo, donde se parece más a CSS! Importante frente a habilitado/deshabilitado. Desmarcar "aplicado" permitió que funcionaran las reglas de precedencia documentadas, sin dejar de aplicar todas las políticas.

Respuesta1

Cree 2 GPO:

  1. GPO a nivel de dominio. Agregar publicusuario a la política de seguridad Denegar inicio de sesión local
  2. GPO de nivel de unidad organizativa (la unidad organizativa que tiene objetos de computadora). Configure Denegar inicio de sesión local como vacío (o lo que necesite, en caso de que tenga otros usuarios que deba bloquear)

Para obtener más información, consulte los documentos de Microsoft:https://learn.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/deny-log-on-locally

La precedencia de aplicación funciona en sentido inverso en comparación con el orden de aplicación habitual:

Si hay configuraciones conflictivas en los GPO que se aplican en dos niveles de la jerarquía, prevalece la configuración aplicada más alejada del cliente. Esto es una inversión de la regla habitual, en la que prevalecería la configuración del GPO vinculado más cercano.

https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc758377(v=ws.10)?redirectedfrom=MSDN

información relacionada