Criando serviço Python para consultar atributos do AD
Estou integrando nosso AD a serviços da Web executando Python no linux usando Python-LDAP sobre SASL (DIGEST-MD5) para consultar atributos de usuário do AD 2012 (divisão, departamento, extensão de telefone, email, etc.). Depois de resolver os problemas específicos do meu serviço em relação a um AD 2003, comecei a encontrar um erro de SPN em nosso novo AD 2012, que o digest-uri não correspondia a nenhum SPN no servidor. Eu fiz uma referência cruzada à lista SPN dos dois servidores e eles contêm análogos idênticos um ao outro.
O erro: O digest-uri não corresponde a nenhum SPN LDAP registrado para este servidor
O conserto?
Isso foi corrigido executando:
setspn -A ldap/<Domain_Name> <Computer_Name>
Observe que a criação de uma conta de serviço não corrigiu meu erro de SPN, mesmo quando o seguinte comando foi executado:
setspn -A ldap/<Domain_Name> <Domain_Name>/<Service_Account_Name>
simple_bind_s () não precisa de SPN, sasl_interactive_bind_s () precisa de SPN
Somente a adição do SPN à lista de SPN da máquina local funcionou para o meu serviço Python-LDAP usando sasl_interactive_bind_s (). Também devo observar que a etapa SPN pode ser ignorada se eu usar simple_bind_s (), mas esse método envia credenciais em texto não criptografado, o que é inaceitável.
No entanto, notei que o registro só permanece na lista do SPN por cerca de um minuto antes de desaparecer? Não há erros quando executo o comando setspn, os logs de eventos estão completamente vazios, não há duplicatas em nenhum lugar, verificados com a pesquisa -F em toda a floresta na base dn e nada. Eu adicionei e tentei adicionar novamente e remover e movi o SPN de um objeto para outro para verificar se ele não está oculto em nenhum lugar, mas no segundo que adiciono o objeto em qualquer lugar e depois tento adicioná-lo, notifico uma duplicata. Portanto, estou muito confiante de que não há uma duplicata oculta em algum lugar.
The Hack
Por enquanto, tenho uma tarefa agendada reexecutando o comando para manter o registro na lista, para que meu serviço funcione apropriadamente chamado "SPN Hack"
cmd.exe /C "setspn -A ldap/<Domain_Name> <Computer_Name>"
até que eu descubra por que o SPN está sendo limpo da lista.
Não sou o administrador principal desse AD em particular. O administrador poderia ter um serviço em execução que sincroniza o SPN de outro serviço no AD e não o conhece? Meu título é desenvolvedor da Web, não como desculpa, mas para explicar minha ignorância em relação ao Active Directory. Disseram-me para fazer do AD o usuário mestre do banco de dados e tenho lido muito, mas não consigo encontrar em nenhum lugar onde as pessoas estejam tendo problemas com o SPN sendo 'substituído' ou 'limpo' periodicamente e nenhum dos Os administradores estão muito familiarizados com o SPN fora das entradas do SQLServer.
Por que eu preciso do hack?
Até agora, meu hack não parece ter causado problemas a nenhum usuário ou serviço e não gerou nenhum erro. Portanto, o administrador diz que ele apenas o deixa executar e eu continuarei procurando. Mas então eu me encontro na situação precária de escrever um serviço cuja implementação é construída, essencialmente um cron hack / shiver ... Portanto, qualquer ajuda seria apreciada.
Atualizar
Após uma conversa com o administrador de sistemas, ele concordou que criar um serviço em cima de um hack não é uma solução; portanto, ele me deu permissão para criar um serviço local com criptografia de terminal que eu possa usar para meus propósitos, o resultado é o mesmo . Vou ficar de olho no que está causando o SPN. Ligações locais não são um problema ao usar o Python-LDAP e o serviço local já está em funcionamento após apenas uma hora. É lamentável que eu esteja essencialmente incorporando a funcionalidade incorporada no LDAP, mas fazemos o que temos que fazer.
