Criptografia reversível do Active Directory para conexão única?

4

Problema: criar e manter centenas de contas de alunos

A escola onde eu trabalho executa o Active Directory no Server 2008. Todos os anos, nossos alunos precisam se inscrever para contas com um sistema de gerenciamento escolar SaaS de terceiros. Isso criou muito trabalho no passado, pois os códigos precisam ser gerados para os alunos, e os alunos geralmente perdem os códigos ou não conseguem descobrir como inseri-los. Mais tarde, os alunos que conseguiram se inscrever podem esquecer seus nomes de usuário ou senhas e vir até mim (o administrador de sistema) para redefinir a senha e assim por diante.

Solução 1: peça aos usuários suas senhas

Neste outono, nos mudamos para um novo SMS, que aparentemente não suporta nenhum tipo de inscrição de aluno em lote. A administração planejava reunir-se com cada aluno, pedir-lhe um nome de usuário e senha e criar uma conta para ele manualmente. Eu pensei, não seria legal se pudéssemos integrar os dois sistemas e evitar isso? Quando entrei em contato com a empresa de terceiros, eles disseram que não se integraram ao Active Directory.

Eu decidi criar meu próprio sistema: um banco de dados acoplado a um programa que é executado como um script de logon para contas de alunos. Funciona assim:

  1. Quando os alunos fazem login no Windows pela primeira vez, eles solicitam suas senhas
  2. As senhas são verificadas em relação às senhas armazenadas no Active Directory
  3. Se corresponderem, as senhas serão armazenadas no banco de dados (as senhas não podem simplesmente ser descartadas do Active Directory para o banco de dados, pois as senhas do Active Directory são somente para gravação)
  4. Um componente do lado do servidor do programa cria contas para os alunos com a empresa de terceiros, usando as senhas do Active Directory armazenadas no banco de dados do programa

Novo problema

Agora, o problema é que, se as senhas dos usuários forem redefinidas no Active Directory, elas não serão atualizadas no banco de dados. Se os usuários alterarem suas senhas de estações de trabalho, as senhas não serão atualizadas no banco de dados. Há também a questão da segurança do próprio banco de dados.

Solução 2: criptografia reversível

Noto que o Active Directory pode armazenar senhas com criptografia reversível. Eu sei que não é oficialmente bem documentado, e estou bem ciente de que mesmo escrevendo a frase "recuperação de senha" traz consigo a possibilidade de trazer O Fim do Mundo. Mas, olhando para o risco, não acredito que nossos servidores corram um grande risco de serem comprometidos e, mesmo que fossem, não há muito que um invasor possa fazer com as contas dos alunos.

Conselhos?

Como você recomendaria que eu resolva este problema? Existe uma maneira eu posso soltar meu banco de dados intermediário e simplesmente usar informações do Active Directory diretamente? Devo abandonar a tentativa de integrar os sistemas?

Todos os pensamentos são bem-vindos, incluindo observações sobre como a minha ideia de single sign-on foi posta em causa.

    
por Eric Eskildsen 27.11.2012 / 16:50

1 resposta

2

O AD não foi projetado como uma ferramenta de sincronização de senha; é um diretório. Capturar senhas e descriptografá-las (elas são criptografadas da mesma forma que a seção SAM é criptografada se a memória for veiculada) não é uma solução de produção viável ou um cenário suportado.

Existem muitas soluções de gerenciamento de identidade por aí que podem enganchar as alterações de senha feitas no AD usando uma API semelhante à do seu script de login e propagando-as. Coletar esses dados por si mesmo não é uma coisa que pode ser roteirizada; você precisaria escrever uma DLL de diretiva de senha.

A maneira correta e sem truques de fazer isso é usar a federação do AD e fazer com que o outro aplicativo autentique os usuários no AD em vez de em seu próprio banco de dados interno. Não parece que isso apóia isso, mas pode ser algo para se investigar.

    
por 28.07.2013 / 23:40