Como faço para gerenciar o Windows como Linux / Unix: direitos administrativos por associação ao grupo sem acidentes e sem compartilhar a senha do administrador?


8

Estou fazendo algumas alterações fundamentais em um ambiente Windows Server 2003/2008. No lado do Unix, minhas restrições de segurança são simples:

  1. Os usuários que devem ter direitos de administrador estão em um grupo especial ("roda" ou similar).
  2. Quando esses usuários efetuam logon nessas máquinas, ainda não têm direitos de administrador, até que executem explicitamente um comando com esses direitos de administrador ("comando sudo" ou "su").
  3. Mesmo quando eles executam o comando com "su" (mais ou menos como "runas"), eles ainda precisam digitar uma senha: própria.

Neste sistema, posso controlar quem possui privilégios de administrador (por associação ao grupo), impedir que eles executem acidentalmente algo com privilégios de administrador por acidente (exigindo "su" ou "sudo") e nunca revelar um "administrador" principal (por exemplo, senha "root"), pois são solicitadas por elas próprias.

Como faço o equivalente no Windows Server? As opções que eu vejo são:

  1. Adicionar usuário à conta de administradores locais: mas tudo o que eles fazem é como administrador, correndo o risco de erro.
  2. Exija que eles façam "runas Administrator": Mas eles precisam saber a senha do administrador, da qual não quero compartilhar.

Existe alguma solução em que eu possa simultaneamente: controlar quem tem acesso por membros do grupo; evite que eles causem danos acidentalmente, exigindo uma senha separada; impedi-los de conhecer a senha do administrador?

Respostas:


8

Primeiro, apenas os administradores devem ter acesso de administrador, a menos que haja uma enorme (não consigo pensar em uma boa) razão pela qual eles precisam, então isso deve ser deixado para os administradores; há ocasiões raras em que um usuário comum obtém privilégios de administrador e, mesmo assim, geralmente sou cético sobre o motivo de precisar dele.

Segundo, você pode realizar o que deseja fazer usando a Associação ao Grupo no Windows. Você não disse que estava usando o Active Directory; portanto, não tenho certeza se você tem um domínio, mas pode criar Grupos de Segurança e adicionar contas de usuário individuais a eles. Veja aqui. Eu não adicionaria usuários ao grupo de administradores locais no servidor individualmente, pois isso ficará confuso e difícil de acompanhar no futuro, e isso trará muita dor de cabeça para você e possíveis problemas de segurança. O que eu faria, como mencionado acima, é criar um grupo de segurança e adicionar os membros aos quais você deseja ter acesso de administrador a esse grupo. Você criaria duas contas de usuário para seus usuários; uma para logon regular e, em seguida, uma segunda conta que foi usada apenas para ações elevadas. Você adicionaria a conta "superior / privilegiada" aos usuários ao Grupo de Segurança. Em seguida, pode colocar esse grupo em uma associação elevada de grupo local no servidor real, como Usuários Avançados, por exemplo. Isso permitirá que eles executem muitas funções sem serem administradores.

No que diz respeito a Executar como administrador, você não precisa fazer isso o tempo todo. A melhor maneira de fazer com que as pessoas executem as coisas sem saber a senha do administrador ou de qualquer administrador é usar Shift + clique com o botão direito do mouse e selecione Executar como usuário diferente ou clique com o botão direito do mouse e Executar como administrador. Primeiro, você deseja criar um usuário separado para eles com direitos mais altos ou direitos elevados, como mencionado acima (esse usuário elevado seria adicionado ao Grupo de Segurança novamente como mencionado acima), pois esse usuário poderia ser usado para executar coisas que exigem elevação o tempo todo, com uma conta de usuário normal / padrão. Veja minha captura de tela:

insira a descrição da imagem aqui

Isso deve cuidar do que você deseja fazer, na medida em que executa tarefas como administrador. Uma observação final que devo acrescentar é manter o UAC ativado. Se você fizer isso, os usuários deverão digitar sua senha (elevada) e não uma senha de administrador para as coisas que eles fazem no servidor. É uma dor quando você tem que digitar muito, mas por segurança vale a pena.


isto é exatamente o que os outros 2 sugeriram. Você está certo, estamos executando o AD e os adicionaremos a um grupo de administradores de servidores, que terá privilégios de administrador local.
Deitch

RE:, Run as Administratorqualquer credencial administrativa servirá. Se a conta na qual você efetuou login não tiver credenciais administrativas, você será solicitado a fornecer um nome de usuário e uma senha e poderá inserir uma conta administrativa. Sua postagem realmente não deixa isso claro.
HopelessN00b

E, neste caso, estou falando de administradores de sistemas. Uma boa prática de segurança é que os administradores de sistemas não tenham uma senha de conta de produção / sistema, apenas executem as coisas como sua própria conta. Eu quero estender isso para administradores de sistemas.
Deitch

1
Sim, isso é exatamente o que fazemos em $ [dayjob]. Todos nós, pessoal de TI, temos contas de usuário e contas administrativas normais. Efetue login em tudo como usuários limitados e execute a Run as Administratoropção para qualquer coisa que precise de elevação. usuários de administrador local não são usados a menos que eles têm que ser (de confiança de domínio quebrado, etc.)
HopelessN00b

2
@ HopelessN00bGeniusofnetwork, então RunAsAdministrator não significa "Executar como conta de Administrador", significa "Executar como qualquer conta que tenha privilégios de Administrador, desde que você possa fornecer credenciais para essa conta"?
Deitch

5

Deixe a conta padrão como 'padrão'. Crie para eles uma segunda conta privilegiada e adicione-a aos vários grupos administrativos. Use 'runas' com a conta privilegiada. (Você pode achar útil desativar logons interativos com a conta de administrador, mas, novamente - isso provavelmente será irritante).


1
Entendi. Então você tem 2 contas: Sobrique e SobriqueA. O SobriqueA está impedido de efetuar login em qualquer sistema em um console / controle remoto, só pode executar runas. SobriqueA é membro de um grupo com privilégios de administrador. O usuário efetua logon como Sobrique, depois executa "runas SobriqueA", que requer a senha da SobriqueA, e todos esses comandos são executados com privilégios de administrador completos. É um pouco complicado, mas poderia ser pior.
Deitch

2
Está correto.
Brad Bouchard

1
+1 para endereçar desativar logons interativos. Caso contrário, os usuários apenas acessarão as credenciais de administrador e estarão sujeitos à preocupação do OP sobre todas as ações como administrador.
Byron C.

4

No Server 2003, você precisaria usar a Run As...opção para executar como uma conta com privilégios administrativos.

Com o Server 2008+, você usa o UAC e / ou a Run as Administratoropção sugerida. Isso não requer o conhecimento da senha da conta administrativa [local] - qualquer credencial administrativa será necessária.

Portanto, você adicionaria suas contas aos grupos administrativos locais, ou melhor, do ponto de vista da segurança, criaria contas administrativas separadas e as adicionaria aos grupos administrativos locais. Então, quando eles precisam executar algo com privilégios administrativos, o UAC solicitará credenciais administrativas e / ou eles usariam a opção Run As.../ Run as Administrator.


Isso é muito semelhante à resposta do @ sobrique. Então, Win considera as contas como tendo privilégios de administrador ou não? E ele não tem o conceito de "esta conta tem o direito de executar as coisas como administrador, se pedir e autenticar explicitamente"?
Deitch

1
Basicamente, não. O Windows possui vários direitos de segurança - geralmente esses direitos são concedidos a um grupo (porque por usuário é desagradável). A participação no grupo confere os direitos. A prática comum é apenas fazer login usando uma conta de administrador, porque é fácil - mas isso não significa que esteja certo. Temos contas de usuário local e contas de administrador de domínio que usamos para fazer login em servidores de gerenciamento (que possuem diversas ferramentas de gerenciamento do Windows instaladas).
Sobrique

Você pode mexer com 'secpol.msc' e configurar um perfil de direitos personalizados - conceder acesso a um grupo 'não exatamente Administradores' e adicionar as contas básicas de usuário a ele. Mas você provavelmente ainda tropeçará na necessidade de uma conta de administrador 'adequada' de qualquer maneira.
Sobrique

1
Bem, isso é essencialmente o que o UAC é / permite. Ele permite que você execute como conta administrativa, mas seja solicitado qualquer coisa que exija "elevação". (Autenticação por token dividido.) Não é tecnicamente uma questão de o Windows criar uma dicotomia "Administrador ou não administrador", mas executar algo como administrador é um recurso tão comum que recebe uma opção de menu específica. Na maioria dos casos, essa opção não é estritamente necessária (você sempre pode executar como outro usuário, que por acaso é um administrador), mas é apenas mais conveniente ter essa opção de menu lá.
HopelessN00b

1
Bem, John ainda precisará saber as credenciais de uma conta administrativa para executar algo como administrador - simplesmente não precisa ser a conta de administrador.
HopelessN00b
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.