Diretiva de Grupo: Direitos de Administrador para Usuários Específicos em Computadores Específicos

11

Sou um programador preso tentando administrar uma instalação do Active Directory para uma pequena empresa. O controlador de domínio está executando o Windows Small Business Server 2008.

Temos uma equipe de trabalhadores de campo usando tablet PC; problemas de configuração com o bloatware ThinkVantage do tablet exigirão que esses usuários tenham o Administrador certo ao usar os tablets. Tudo bem - é útil que eles tenham amplos privilégios quando os oriento através de uma correção por telefone, por isso não estou procurando uma solução alternativa por lá.

Eu gostaria de usar a Diretiva de Grupo para configurar o seguinte cenário: Os usuários de um grupo de segurança (ou unidade organizacional) específico devem estar no grupo BUILTIN / Administrators ao fazer login em computadores em um determinado grupo de segurança (ou unidade organizacional). Tudo bem se os computadores tiverem que estar em uma UO, mas eu prefiro atribuir usuários por grupo.

Obviamente, os trabalhadores de campo não devem ser Administradores em outras estações de trabalho, e a equipe do escritório de baunilha não deve ser Administradora nos tablets.

Atualmente, isso está sendo gerenciado localmente em cada tablet, mas, à medida que adicionamos novas contratações, está se tornando um incômodo.

Eu sinto que Grupos Restritos é a resposta aqui, mas sem uma sólida base nos conceitos e métodos do AD, estou tendo dificuldades para fazer isso acontecer.

Qual é a técnica adequada para esta tarefa e como eu a implementaria?

WCWedin
fonte

Respostas:

13

Crie um grupo para encapsular os usuários (Local-Admins-Tablets) e adicione-os a este grupo

Crie uma sub-OU da OU atual das estações de trabalho e coloque os tablets aqui (Estações de Trabalho \ Tablets)

Crie um GPO (Local-Admins-Tablets-Policy) e vincule-o à UO Workstations \ Tablets

No GPO, defina o seguinte:

  • Config. Comp. - Políticas - Configurações do Windows - Configurações de segurança - Grupos restritos
  • Clique com o botão direito do mouse em Adicionar grupo
  • "Administradores", OK
  • Membros deste grupo: myDomain \ Local-Admins-Tablets

Reinicie os PCs e pronto.

Lembre-se de que a configuração de grupos restritos substituirá a lista existente de máquinas de administradores locais. Se você já possui outros usuários / grupos, precisará adicioná-los a essa política também. Outros exemplos seriam myDomain \ Domain Admins etc.

EDIT: Ah, e altere a filtragem no GPO e adicione computadores de domínio . A maneira mais fácil de fazer isso é usar o snap-in MMC de Gerenciamento de Diretiva de Grupo (você pode obtê-lo nas Ferramentas de Administração de Servidor Remoto da Microsoft)

Izzy
fonte
5
+1. Grupos restritos é a solução aqui. Um gpupdate / force nas estações de trabalho é suficiente para que a alteração entre em vigor, negando a necessidade de uma reinicialização.
31289 joeqwerty
Se os comprimidos são no campo é geralmente mais fácil de obter o usuário a reinicialização que é para explicar o "cmd abertos, tipo gpupdate / force / boot" etc :)
Izzy
1
Usando as Preferências de Diretiva de Grupo ( technet.microsoft.com/en-us/library/cc731892%28WS.10%29.aspx ), você pode atualizar um grupo local sem substituir nada.
Zoredache
1
Bem, isso fez o truque! Apenas duas perguntas: pelo que entendi, ele explodirá completamente todos os membros atuais do grupo Admin, incluindo usuários locais, correto? Isso pode ser uma surpresa desagradável. Presumo que a conta de administrador padrão não será afetada por isso; isso é presunçoso da minha parte?
WCWedin
1
Nunca testei isso, sempre adicionei Builtin \ Administrators a esse grupo restrito. Cinto e suspensórios :)
Izzy
12

A resposta de Izzy é boa se você não se importa que o grupo Administradores seja efetivamente bloqueado de alterações futuras da máquina local. Isso também apagará todos os grupos que já eram membros do grupo Administradores antes da aplicação da configuração de diretiva.

No entanto, você pode usar a mesma configuração de política de uma maneira ligeiramente diferente para ignorar esses aborrecimentos (supondo que você os considere mesmo aborrecimentos).

  • Crie a estrutura da UO / Grupo da mesma maneira que antes
  • Quando você estiver na seção Grupos Restritos do objeto de diretiva de grupo, Adicionar Grupo, mas em vez de especificar Administradores , especifique YOURDOMAIN \ Local-Admins-Tablets .
  • Na seção "Este grupo é membro de" , clique em Adicionar e insira Administradores

É uma diferença sutil, mas importante, na maneira como as duas seções funcionam. Os membros desse grupo efetivamente são "O grupo A sempre conterá os grupos X, Y e Z". Este grupo é membro de efetivamente trabalha para ser "Verifique se o Grupo A é membro dos Grupos X, Y e Z".

Depois de definir a diretiva com os membros deste grupo , a única coisa que pode modificar a associação do grupo é um objeto de diretiva de substituição que também usa os membros desse grupo ou qualquer outra diretiva que use este grupo .

Ryan Bolger
fonte
2

Parece que tudo o que você realmente precisa fazer é criar uma diretiva de grupo que adicione um grupo de domínio ao grupo de administradores locais. Isso é muito fácil de realizar com um script de inicialização simples ou com as Preferências de Diretiva de Grupo .

Script de inicialização simples para adicionar membros do grupo.

DomainName="example"
Set oShell = WScript.CreateObject("WScript.Shell")
Set oProcsEnv = oShell.Environment("Process")
ComputerName = oProcsEnv("COMPUTERNAME")
Set oGroup = GetObject("WinNT://" & ComputerName & "/" & "Administrators")
If Not oGroup.IsMember("WinNT://"&DomainName&"/_Group_Tablet_Admins") Then _
    oGroup.Add ("WinNT://"&DomainName&"/_Group_Tablet_Admins")
Zoredache
fonte
Supondo que ele esteja usando o W2K8, o que não posso dizer com base em sua pergunta.
31289 joeqwerty
As preferências do lado do cliente são suportadas em um domínio 2003r2. Eu simplesmente não tinha um link para o artigo 2003r2 à mão.
Zoredache
Editou a pergunta para adicionar o sistema operacional. O GPP parece ser um bom ajuste para esse cenário, pois é improvável que os usuários modifiquem seus grupos posteriormente, tornando sua natureza temporária um ponto discutível. Dito isto, implantar os pré-requisitos em todas as máquinas clientes parece uma enorme dor de cabeça.
WCWedin 29/10/09
1
É por isso que fazer isso com um script de inicialização simples também é uma opção simples. Também acho preferências úteis para muitas outras coisas. Pode valer a pena instalá-los para outras coisas que você poderá realizar no futuro.
Zoredache
1

O único problema com a solução listada é que ela concede direitos de administrador local a todas as máquinas nas quais essa política se aplica. Normalmente, você deseja conceder direitos de administrador apenas a uma máquina específica. O que observei é que, quando um usuário percebe que possui direitos de administrador local, instala software para todos os seus parceiros.

Existem várias maneiras diferentes de fazer isso, mas posso sugerir uma. Conclua as etapas acima, mas também crie um grupo para cada computador em que os usuários precisem de direitos adicionais. Cada um desses "Grupos de computadores" é adicionado ao grupo myDomain \ Local-Admins.

Os usuários são então adicionados ao grupo que corresponde à máquina à qual precisam acessar.

Portanto, eles são um administrador, mas apenas dessa máquina.

Jacob
fonte
0

Você diz que adicionar novos contratados é um problema, mas não deveria adicionar novos tablets que seriam um aborrecimento?

Eu estaria fazendo algo nesse sentido:

Tenha um grupo de segurança de domínio que contenha todos os usuários que devem ser administradores nos tablet PCs (ou seja, TabletAdministrators).

Em cada tablet, adicione esse grupo ao grupo Administradores.

Se essa é a técnica adequada ou não, eu não sei. É apenas a primeira idéia que me vem sobre como implementar.

Barrett Jacobsen
fonte
2
Não deve ser adicionado manualmente a cada máquina. Isto é o que a diretiva de grupo é para
Izzy
1
Ao configurar um novo tablet, tenho que adicionar 15 usuários a um tablet. Ao adicionar um novo funcionário, tenho que adicionar um usuário a 20 tablets. Ambos são um aborrecimento, mas a mecânica de andar de máquina em máquina torna o último processo tedioso e lento. Sua abordagem aliviaria isso substancialmente, mesmo que não seja especialmente elegante.
WCWedin 29/10/09
1
+1 nesta votação para recuperá-la um pouco. Esta pode não ser a melhor solução, mas é uma solução válida. As pessoas não devem ser votadas negativamente por propor uma solução válida apenas porque não é a solução preferida. A única coisa que falta nessa solução é o uso de Grupos Restritos para automatizar o processo de adição do grupo ao grupo Administradores Locais. Eu digo +1 pelo esforço e por contribuir para a resposta.
31289 joeqwerty
0

Eu escrevi um script que é executado como uma política de computador com direitos administrativos na estação de trabalho local. Ele verifica a última Descrição do usuário conectado no AD que um Administrador de Domínio pode definir em "Usuários e Computadores do Active Directory"; se ele contiver o nome da estação de trabalho, o script adicionará o usuário ao grupo de administradores local, se o nome da estação de trabalho não estiver no diretório Descrição do usuário, ele remove o usuário do grupo de administradores locais. Uma Descrição pode incluir mais de um nome de computador, como este:

Descrição do usuário: "Local Admin on WKST-E445R and WKST-VM398"

Portanto, para tornar alguém um administrador local em apenas uma máquina, basta adicionar o nome deste computador à Descrição do usuário no AD e solicitar que o usuário reinicie , e remover o nome do computador remove os direitos de administrador local.

Essa não é a melhor solução de todos os tempos? :-)

Aqui está o script:

    @if "%debug%" neq "%username%" echo off
set ver=MakeLocalAdmin.cmd henrik@c o m m o r e.se 20150423
:: Adds last logged on domain user to local Administrators group if run by computer GPO with Administrative rights and the user's Comment contains Computername

set log=nul
:: or set log=c:\logs\MakeLocalAdmins.txt

:: Check who was last logged on user
FOR /F "tokens=3 delims= " %%G in ('reg query "hklm\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI" /v LastLoggedOnUser') DO (
set DomainAndUserName=%%G)

:: Remove the spaces
set DomainAndUserName=%DomainAndUserName: =%

:: Get only username part
set LastLoggedOnUserName=%DomainAndUserName:*\=%


:: Check OS language, so we can adapt to localized name of Admin group and Comment
FOR /F "tokens=3 delims= " %%G in ('reg query "hklm\system\controlset001\control\nls\language" /v Installlanguage') DO (
set Language=%%G)

echo %date% %Time% ; %0 ; %computername%; %LastLoggedOnUserName%; %DomainAndUserName%, %Language% >> %log%
goto %Language%

:: Add any langauage specific part below, but if an unknown install language is found,
:: an error 'label not found' should mean script terminates, but anyway make sure it terminates. 
goto end

:0409
:: English
net user /domain %LastLoggedOnUserName% | find "Comment " | find "%computername%" >> %log%
set NoLocalAdmin=%errorlevel%
if %NoLocalAdmin% equ 0 net localgroup Administrators /add "%DomainAndUserName%" >> %log%
if %NoLocalAdmin% equ 1 net localgroup Administrators /del "%DomainAndUserName%" >> %log%
goto end

:041D
:: Swedish 
:: †„” åäö (Swedish char's)
net user /domain %LastLoggedOnUserName% | find "Kommentar " | find "%computername%" >> %log%
set NoLocalAdmin=%errorlevel%
if %NoLocalAdmin% equ 0 net localgroup Administrat”rer /add "%DomainAndUserName%" >> %log%
if %NoLocalAdmin% equ 1 net localgroup Administrat”rer /del "%DomainAndUserName%" >> %log%
goto end



:end
Ele Ele
fonte