Temos um domínio AD (ainda local) que suporta uma biblioteca, entre outras coisas. Essa biblioteca possui vários computadores públicos, e esses computadores públicos estão em sua própria UO no Active Directory. Também temos um publiclogin genérico de convidado que nossos bibliotecários podem usar para conceder acesso às máquinas a visitantes externos.
Quero limitar esta conta — e apenas esta conta — para que ela possa acessar apenas computadores na PublicComputersUO.
Temos muitos outros usuários que ainda devem conseguir fazer login nesses computadores e em outros.
Estou ciente do Log On To...botão em um objeto Usuário no AD, mas isso não é adequado, pois esses computadores vêm e vão. A associação à OU é mantida por outros motivos, mas se precisarmos usar esse botão toda vez que um computador se movimentar, ele ficará rapidamente desatualizado.
As partes relevantes da nossa hierarquia AD são assim:
Domain Root > InstitutionComputers > Library > PublicComputers
> ServiceAccounts > public
> Users (group) > {ManyOtherUsers}
> OtherOU > {ManyOtherUsers}
Como posso fazer isso?
Tentei definir uma política Negar logon no nível do domínio para incluir a conta pública e, em seguida, outra política Negar logon no nível da UO mais específico que não inclui a conta.
Nos testes, isso funciona em algumas máquinas, mas outras bloquearão o login do usuário público. Se eu olhar na Política de Segurança Local de uma máquina que não está funcionando, vejo que ela tem a política completa no nível do domínio, em vez do nível da UO , mas confirmei que a máquina é membro da UO correta. Além disso, gpresultmostra ambas as políticas. (Também estou adicionando essas informações à pergunta), então sei que a política mais específica corresponde a esses computadores. Isso continua acontecendo mesmo depois de executar gpupdate /forcee reiniciar o computador.
Acontece que eu tinha uma ideia errada de como "aplicado" funciona na Política de Grupo, onde é mais parecido com css! Importante versus ativado/desativado. A desmarcação de "aplicada" permitiu que as regras de precedência documentadas funcionassem, ao mesmo tempo que aplicava todas as políticas.
Responder1
Crie 2 GPOs:
- GPO em nível de domínio. Adicionar
publicusuário à política de segurança Negar logon localmente - GPO de nível de UO (a UO que possui objetos de computador). Configure Negar logon localmente como vazio (ou o que você precisar, caso você tenha outros usuários que precise bloquear)
Para obter mais informações, verifique os documentos da Microsoft:https://learn.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/deny-log-on-locally
A precedência de execução funciona em reversão em comparação com a ordem de aplicação normal:
Se houver configurações conflitantes em GPOs impostas em dois níveis da hierarquia, prevalecerá a configuração imposta mais distante do cliente. Isto é uma inversão da regra usual, na qual prevaleceria a configuração do GPO vinculado mais próximo.