As credenciais compartilhadas são inseguras e difíceis de gerenciar
Como você descobriu, garantir com segurança o acesso de vários usuários a um recurso usando uma única conta de usuário é problemático. Eu explico no final desta resposta o que torna isso difícil e por que deve ser evitado.
Mas primeiro, a maneira correta de conceder acesso a um recurso é usando contas de usuário individuais para cada usuário que precisa de acesso. A maneira como você faz isso será diferente para as máquinas que fazem parte do domínio do host do recurso de destino e aquelas que não são.
Membros do mesmo domínio
Para usuários que acessam o recurso de computadores que estão no mesmo domínio que o computador que hospeda o recurso, basta conceder acesso às contas de usuário existentes do AD que precisam de acesso. O método das melhores práticas é o seguinte:
- Crie um grupo de segurança de domínio.
- Conceda ao grupo acesso ao recurso de destino.
- Faça com que cada objeto de usuário do AD que precise de acesso ao recurso seja um membro do grupo de segurança.
Não membros do domínio
Para usuários que precisam acessar o recurso, mas de máquinas que não estão no domínio do recurso, o método de melhor prática ainda é conceder acesso a contas de usuários individuais da seguinte forma:
-
Crie contas de usuário do Active Directory usando os mesmos nomes de usuário e senhas usados para fazer logon nos computadores que não são de domínio que exigem acesso ao recurso.
Se, por algum motivo, você não tiver acesso às senhas dos usuários, alternadamente poderá:
a. Crie contas de usuário do AD para cada usuário que não seja de domínio e atribua uma senha de sua escolha. Nesse caso, você deve especificar nomes de usuários diferentes que os usados no computador sem domínio, caso contrário, o nome de usuário corresponderá, mas a senha não será, bloqueando o logon bem-sucedido. (Preferido.)
b. Crie um único objeto de usuário do AD que será compartilhado por todos os usuários que não são do domínio. (Não preferido - veja abaixo.)
-
Crie o (s) novo (s) objeto (s) do (s) usuário (s) AD do grupo que você criou na etapa 1 na seção acima.
Por que evitar um único objeto de usuário ao conceder acesso a vários usuários?
Como você pode ver, a abordagem de melhores práticas evita usar um único nome de usuário e senha para conceder acesso ao recurso. Existem várias razões para isso:
-
As contas compartilhadas são inflexíveis para alterar os requisitos de acesso. Quando chega a hora de revogar o acesso de um usuário, uma conta compartilhada é implacável. Você deve alterar a senha na conta, o que exige a alteração em todos os dispositivos que ainda precisam de acesso, levando a ...
-
As senhas compartilhadas exigem muita mão-de-obra. Presumimos que você esteja usando a senha para manter certos usuários fora, o que torna inevitável a alteração de senha. Mas, em vez de alterar a senha em um dispositivo, você deve alterá-lo em muitos dispositivos, a maioria dos quais geralmente não é gerenciada centralmente. Para piorar as coisas, até que a nova senha seja implantada, os dispositivos que usam a senha antiga não poderão acessar o recurso.
-
As contas compartilhadas não identificam usuários autorizados. Em nenhum lugar do sistema, você terá visibilidade de quem acessa a conta compartilhada. Você (e quem mais gerencia o ambiente) precisará manter uma lista separada. E ao contrário de conceder autorização diretamente aos objetos do usuário, não há garantia que a lista externa seja precisa. Além disso, quando em tempo real monitorar o acesso ao recurso, uma conta compartilhada não revela quem está realmente usando o recurso.
-
As contas compartilhadas estão mais expostas ao comprometimento. Elas são usadas por mais pessoas de mais lugares em mais sistemas, cada uma representando um possível ponto de comprometimento. Consulte novamente a questão 1 para a dificuldade envolvida em remediar isso com uma alteração de senha.
Distribuição em massa de uma única credencial de logon
Talvez você ache que ainda deve empregar um nome de usuário e uma senha compartilhados para conceder acesso ao recurso. Se você se encontrar nesse caso, a má notícia é que não há como distribuí-lo convenientemente de maneira automatizada que mantenha qualquer aparência de segurança.
O principal problema da automação é o fato de que é necessário usar / salvar a credencial compartilhada no contexto de logon do usuário que acessa o recurso . Isso exclui qualquer processo de automação remota (a menos que você saiba a senha de cada usuário, caso em que você não precisa usar uma credencial compartilhada).
Tudo o que resta é acessar os computadores um a um enquanto o usuário está presente para que eles possam estar logados enquanto você armazena a credencial compartilhada ou para fornecer a credencial diretamente aos usuários para que eles possam inseri-la eles mesmos.