Digamos que você tenha uma unidade de rede compartilhada, ela requer autenticação de usuário e senha para acessar seu conteúdo.
Usuário e senha podem ser adicionados a um único PC, via comando net use ou Gerenciador de credenciais do Windows e é concedido acesso à unidade.
Todos os computadores e a unidade estão na mesma rede e todos podem acessar desde que tenham as credenciais.
Também tentei criar cópias das minhas próprias credenciais do Windows, pois uma cópia pode ser restaurada em outro PC, mas ainda precisa ser feita manualmente, preciso encontrar uma maneira de fazer isso automaticamente.
Como você podeespalhartais credenciais para dizer 100 PCs, sem precisar adicioná-los um por um?
É possível usaruso líquidoem dispositivos específicos, já que conhecemos seus IPs?
A maioria dos computadores está em um domínio. Um único usuário foi criado com permissões específicas concedidas e espera-se que todos os computadores utilizem suas credenciais para trabalhar com o recurso.
Responder1
Credenciais compartilhadas são inseguras e difíceis de gerenciar
Como você descobriu, conceder acesso seguro a vários usuários a um recurso usando uma única conta de usuário é problemático. 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 é usar 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 de recursos de destino e para aquelas que não fazem.
Membros do mesmo domínio
Para usuários que acessam o recurso de máquinas que estão no mesmo domínio do computador que hospeda o recurso, basta conceder acesso às contas de usuário do AD existentes que precisam de acesso. O método de melhores práticas é o seguinte:
- Crie um grupo de segurança de domínio.
- Conceda ao grupo acesso ao recurso de destino.
- Torne cada objeto de usuário do AD que precisa de acesso ao recurso um membro do grupo de segurança.
Membros que não são de domínio
Para usuários que precisam de acesso ao recurso, mas de máquinas que não estão no domínio do recurso, o método de prática recomendada ainda é conceder acesso a contas de usuário individuais da seguinte maneira:
Crie contas de usuário do Active Directory usando omesmonomes de usuário e senhas usados para fazer logon em computadores que não são de domínio e que exigem acesso ao recurso.
Se por algum motivo você não tiver acesso às senhas dos usuários, você poderá:
a. Crie contas de usuário AD para cada usuário que não seja de domínio e atribua uma senha de sua escolha. Neste caso você deve especificar nomes de usuário que sejamdiferentedo que o usado no computador sem domínio, caso contrário, o nome de usuário corresponderá, mas a senha não, 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.)
Torne os novos objetos de usuários do AD membros do grupo que você criou na etapa 1 da 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 prática recomendada evita o uso de um único nome de usuário e senha para conceder acesso ao recurso. Há 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 da conta, o que exige alterá-la em todos os dispositivos que ainda necessitam de acesso, levando a...
As senhas compartilhadas exigem muito trabalho para serem alteradas.Presumimos que você esteja usando a senha para manter determinados usuários afastados, tornando inevitável a alteração da senha. Mas em vez de alterar a senha em um dispositivo, você deve alterá-la em vários dispositivos, muitos dos quais geralmente são gerenciados de forma não centralizada. Para piorar a situação, 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 sobre quem tem acesso por meio da conta compartilhada. Você (e quem gerencia o ambiente) precisará manter uma lista separada. E diferentemente de conceder autorização diretamente a objetos de usuário, não hágarantiaa lista externa é precisa. Além disso, ao monitorizar em tempo real o acesso ao recurso, uma conta partilhada não revela quem está realmente a utilizar o recurso.
As contas compartilhadas estão mais expostas a comprometimentos. Eles são usados por mais pessoas de mais lugares e em mais sistemas, cada um representando um possível ponto de comprometimento. Consulte o problema nº 1 para saber a dificuldade envolvida em remediar isso com uma alteração de senha.
Distribuição em massa de uma única credencial de logon
Talvez você descubra que ainda deve usar 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 de maneira conveniente e automatizada que mantenha qualquer aparência de segurança.
O principal problema da automação é o fato de ser necessário usar/salvar a credencial compartilhadano 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; nesse caso, não é necessário usar uma credencial compartilhada).
Tudo o que resta é acessar os computadores um por um enquanto o usuário estiver presente para que eles possam estar logados enquanto você armazena a credencial compartilhada ou fornecer a credencial diretamente aos usuários para que eles próprios possam inseri-la.