EDIT: Alguém pode realmente responder a pergunta? Obrigado, eu não preciso de nenhuma trilha de auditoria, eu irei saber todas as senhas e os usuários não poderão alterá-las e eu continuarei a fazê-lo.
Isto não é para hackear!
Recentemente, migramos de um antigo e enferrujado domínio Linux / Samba para um diretório ativo. Nós tínhamos uma pequena interface personalizada para gerenciar contas lá. Ele sempre armazena as senhas de todos os usuários e todas as contas de serviço em texto não criptografado em um local seguro (claro, muitos de vocês não pensarão nisso sendo seguro, mas sem explorações reais ninguém poderia ler isso) e desativaram a mudança de senha no controlador de domínio samba. Além disso, nenhum usuário pode selecionar suas próprias senhas, nós as criamos usando o pwgen. Nós não os trocamos a cada 40 dias ou mais, mas apenas a cada 2 anos para recompensar os funcionários por realmente aprendê-los e não escrevê-los.
Precisamos das senhas para, por exemplo, entre em contas de usuários e modifique configurações que são muito complicadas para políticas de grupo ou para ajudar usuários.
Estas podem certamente ser políticas controversas, mas quero continuar no AD. Agora eu salvo novas contas e suas geradas pelo PWGEN (o pwgen cria palavras aleatórias com boa quantidade de vogais, consoantes e números) manualmente no velho arquivo de texto que os scripts antigos usavam para manter automaticamente.
Como posso recuperar essa funcionalidade no AD?
Vejo que há "criptografia reversível" nas contas do AD, provavelmente para sistemas de autenticação de resposta a desafio que precisam da senha de texto não criptografado armazenada no servidor.
Existe um script que exibe todas essas senhas? Isso seria bom. (Mais uma vez: confio em que meu CD não seja comprometido.)
Ou posso ter um plug-in nos usuários e nos computadores do AD que recebe uma notificação de cada nova senha e a armazena em um arquivo?
Em clientes que são possíveis com GINA-dlls, eles podem ser notificados sobre senhas e obter o texto não criptografado.
Para responder a pergunta, leia isto: link
Na parte inferior do artigo está descrito como obter a senha reversível armazenada. Havent tentou, então não sabe exatamente como fazer como descrito, mas deve funcionar.
Além disso, eu concordo com o resto das pessoas que chora lobo com a sugestão de usar criptografia reversível. Apenas não é seguro.
Parece-me que você está dando suporte ao usuário fazendo logon com suas contas - sabendo suas senhas? Como você disse, essa é uma ideia muito ruim por muitas razões.
Eu sei que alguns usuários da velha escola tendem a gostar disso, eles apenas dão de ombros e pedem para você consertá-lo remotamente e dar a senha deles. Mas apenas diga não. Ninguém deve saber sua senha, mas a si mesmo - princípio básico.
A maioria das coisas pode ser corrigida de outro contexto de usuário, o seu próprio. Aqueles que realmente não podem, e precisam ser feitos com o usuário interativamente logado, exigem que o usuário faça isso e fique e observe como a equipe conserta coisas através da conta do usuário.
Remotamente, há o RDP Shadow, Remote Help e soluções interativas semelhantes nas quais o usuário está no controle e ninguém precisa saber sua senha para ajudar com algum problema relacionado à área de trabalho. Com as diretivas de grupo, basicamente não há necessidade desse comportamento, pois a maioria das coisas é facilmente configurada por um administrador.
Se você der a outras pessoas acesso a contas de usuário de outras pessoas, você também perderá a trilha de auditoria e a responsabilidade por ações realizadas por usuários no sistema, o que poderia facilmente sair do grupo de administradores autorizados.
Eu não estaria tão certo de que meu CD está seguro. Se eu era um atacante ou um testador de caneta, não vou atrás do seu CD primeiro, de qualquer forma. Eu vou atrás de suas estações de trabalho e servidores. Vetor de ataque básico:
A menos que você seja o Vista / Windows Server 2008 / Windows 7, esse é o padrão de ataque básico usado pela maioria dos pentesters. A razão pela qual esses 3 SOs quebram o padrão é porque o ataque de injeção de DLL contra Segredos LSA não foi feito para trabalhar contra esses SOs.
Com tudo isso dito, você não deve usar criptografia reversível e deve desativar os hashes LM. Você quer hashes NTLM. E você não quer armazenar essas senhas em texto simples.
O que você está fazendo é realmente uma péssima ideia. Se você não quer que os usuários tenham que gerenciar senhas, você pode investir em um sistema de token de desafio / resposta para o AD que custará dinheiro mínimo.
Para ser sincero, não acho que seu raciocínio por querer fazer isso seja válido. Como administrador, recebo uma grande dose de heebeejeebees do pensamento de saber a senha de um usuário. É o seu território pessoal, e você está pedindo a eles para colocar um nível enorme de confiança em você. Mesmo afora isso, se houver um vazamento de dados confidenciais, você ficará instantaneamente sob suspeita, pois saberia as senhas do usuário. A falta de uma pista de auditoria verificável é uma bandeira vermelha de segurança colossal. A regra 1 é "proteja-se", e se isso significa ter que aceitar algum inconveniente, então que seja.
Eu acho que existem soluções alternativas que irão realizar o que você quer, sem ter que ir tão longe como o conhecimento de senhas. Você já olhou para as preferências da política de grupo? Quais são as suas habilidades de script? O uso de métodos de força bruta é normalmente uma indicação clara de que a abordagem padrão não está sendo usada de maneira ideal, então acho que seria muito melhor retroceder e repensar o que você está fazendo.
Responsabilidade, registro e acompanhamento.
Temos lutado com a administração por alguns anos. O CEO e o Presidente se recusaram a mudar de senha por anos, e todos os caras de TI que vieram e foram há mais de 7 anos conheciam suas senhas. Mesmo que você "confie" em todos, é muito perigoso que várias pessoas que não são mais funcionários tenham acesso a contas poderosas. Deixe sozinho que todos eles saibam que os outros conhecem as senhas, e seria seguro usá-las.
Nós pregamos aos usuários repetidamente para nunca compartilharem suas senhas, nem mesmo conosco, nunca. Este é o começo para evitar "Social Hacking" Quantos dos seus usuários dariam sua senha para alguém ligando e dizendo que eles são um dos novos caras de TI?
Se realmente precisarmos estar em uma conta de usuário para fazer algo, faremos login e usaremos a espingarda ou alteraremos a senha. Assim que alteramos a senha, somos responsáveis por sua conta e eles não são mais responsáveis até recebermos uma nova senha, com a conta marcada de que o usuário deve alterar a senha no próximo login. Isso preserva o registro e o rastreamento. Com tudo de ruim, ilegal e antiético que os usuários podem fazer na internet. Se eles podem culpar muitos outros que conhecem suas senhas, isso pode gerar muitos problemas.
Agora, estamos trabalhando para eliminar todos os logins de conta compartilhada, como computadores compartilhados. Se precisarmos de um, essa conta tem direitos muito limitados e nenhum acesso à Internet.
Existe uma razão pela qual as senhas são tão importantes. Eles não são apenas para proteger seus dados, eles estão lá para proteger você e seus usuários, etc. Não é difícil encontrar ou discutir exemplos. Jogue as conversas na sua cabeça. "Todos sabiam da minha senha, e um deles entrou no meu computador, leu o e-mail da minha amante e disse à minha esposa" Há muitas possíveis considerações de privacidade além da segurança.
Brian
p.s. tentando muito não ser argumentativo. Embora eu não tenha respondido a pergunta, fiz editoriais contra fazer o que é sugerido. Eu também recomendo não dizer coisas como esta, citação da pergunta - "EDIT: Alguém pode realmente responder a pergunta? Obrigado, eu não preciso de nenhuma pista de auditoria, eu vou saber todas as senhas e os usuários não podem mudá-los e eu continuará a fazê-lo. Isto não é para hackear! "
Acho que as questões de auditoria, responsabilidade e segurança em geral foram tratadas adequadamente, então tentarei uma resposta diferente:)
Há um Serviço de notificação de alteração de senha que pode ser instalado em todos os controladores de domínio que encaminharão todas as alterações de senha com segurança para um serviço de recebimento.
Isso foi projetado para o Identity Integration Server (agora Identity Lifecycle Manager) como um destino, mas deve ser possível gravar seu próprio destino ou até mesmo usar o MIIS / MILM para receber a senha e encaminhá-la para outro conector. sistema.
Você teria que obter os hashes (LM ou NTLM) e fazer um ataque de dicionário sobre eles. Qualquer pessoa com uma senha moderadamente complexa seria quase impossível de descobrir. Não habilite "criptografia reversível" - você precisa mudar a maneira de gerenciar senhas.
Desbloquear Administrador pode resolver parte do seu problema sem exigir o conhecimento da senha.
Existem várias maneiras de fazer isso, que eu já vi usadas por pessoas que penetraram em nossos servidores. O método mais popular é descarregar os hashes de senha em um arquivo usando algo como pwdump4 e, em seguida, executar os hashes resultantes por meio de uma tabela do arco-íris. Existem alguns limites de tamanho de senha que tornam essa abordagem muito mais difícil, e é por isso que nossas senhas administrativas possuem todos os 16 caracteres ou mais.
Uma vez que você investiu em um bom conjunto de mesas de arco-íris (pode ser obtido por um bom dinheiro em muitos lugares na internet, e se isso for realmente uma linha de negócios para você, o custo não deve ser um problema) processo de despejo e descriptografia pode ser feito em menos de 30 minutos para a maioria dos usuários.
Fizemos isso uma vez para ter uma ideia de quão facilmente adivinharam as senhas de nossos usuários. Algo como 30% das senhas foram quebradas dentro de 5 minutos após o início de um simples ataque de dicionário, e perto de 80% foram quebradas através da Rainbow Table em menos de um dia. Isso foi .... 3 anos atrás, então as coisas ficaram mais rápidas. Os resultados foram apresentados à alta gerência, que rapidamente concordou em reforçar as políticas de senhas (na verdade, criar).
Como outros já abordaram, sua política e práticas são pouco ortodoxas na melhor das hipóteses. Anteriormente mencionado Unlock Administrator parece ser um compromisso decente (sem trocadilhos). Seu objetivo declarado para saber suas senhas de usuário para fornecer suporte dentro do perfil de usuário do Windows. Bem. Quando seus usuários precisarem de suporte e precisarem estar em outro local, peça que eles bloqueiem sua estação de trabalho. Depois, com o Unlock Administrator, você pode desbloquear a estação e permanecer no perfil do usuário.
Você perde a capacidade de acessar qualquer estação de trabalho, mas não precisa mais saber sua senha. Isso parece um compromisso decente entre segurança e facilidade de suporte.
A Microsoft tem seu produto ILM que pode replicar senhas, talvez para um armazenamento LDAP externo.
Pegue o L0phtcrack e execute-o contra o DC. Pode demorar HOURS, mas deve ser capaz de obter a maioria das senhas.
Na verdade eu tropecei nisso porque eu estava procurando a mesma coisa, mas meus motivos para conhecer senhas de usuários são bem diferentes.
Estou migrando uma antiga solução de administradores de rede para usar o IIS para hospedagem de FTP do cliente. Recentemente, descobrimos que nosso IIS ftp tinha sido forçado a brutear e estava hospedando spyware. As senhas do usuário não foram documentadas apenas redefinir se alguém esqueceu, Então eu estou mudando para outra solução (FileZilla) que não usa o AD. Eu preciso recriar todas essas contas do AD com as mesmas senhas (contas comprometidas excluídas) para tornar a migração transparente para os usuários finais. Como não há um utilitário de migração do IIS para o FileZilla, minha única esperança é quebrar as senhas dos usuários.
Estou aberto a sugestões sobre como realizar isso sem quebrar as senhas dos usuários.