A entrada do nome principal do Serviço de Integração LDAP do Active Directory 2012 está desaparecendo?

Question

Criando o Serviço Python para Consultar os Atributos do AD

Estou integrando nosso AD com serviços da web executando Python no linux usando Python-LDAP sobre SASL (DIGEST-MD5) para consultar os atributos de usuário do AD 2012 (divisão, departamento, extensão de telefone, email, etc.). Depois de resolver as torções específicas do meu serviço em relação a um AD 2003, comecei a encontrar um erro de SPN em relação ao nosso novo AD 2012, que o digest-uri não correspondia a nenhum SPN no servidor. Eu referenciei a lista do SPN para ambos os servidores e eles contêm análogos idênticos um do outro.

O erro: O digest-uri não corresponde a nenhum SPN LDAP registrado para este servidor

A correção?

Isso foi corrigido pela execução:

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

Apenas adicionar o SPN à lista 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 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 lugar algum, verificadas com a pesquisa -F em toda a floresta na base dn e nada. Eu adicionei e tentei re-adicionar e remover e movi o SPN de objeto para objeto para verificar se ele não está se escondendo em qualquer lugar, mas o segundo eu adiciono o objeto em qualquer lugar e, em seguida, tentar adicionar novamente ele me notifica de uma duplicata. Então, estou muito confiante de que não há uma cópia oculta em algum lugar.

O Hack

Por enquanto, tenho uma tarefa agendada executando novamente 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 eliminado da lista.

Eu não sou o administrador principal deste AD em particular, o administrador pode ter um serviço em execução que sincroniza o SPN de outro serviço no AD e não está ciente disso? Meu título é Web Developer, não como uma desculpa, mas para explicar minha ignorância em relação ao Active Directory. Foi-me dito para tornar o AD o usuário mestre DB e eu tenho lido muito, mas não consigo encontrar em qualquer lugar onde as pessoas estão tendo um problema com o SPN sendo 'sobrescrito' ou 'limpo' periodicamente e nenhum dos Os administradores estão muito familiarizados com o SPN fora das entradas do SQLServer.

Por que preciso do hack?

Até agora, meu hack não parece ter causado problemas para nenhum usuário ou serviço e não gerou nenhum erro, então o administrador diz que ele simplesmente deixará ele rodar 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 ... Então, qualquer ajuda seria apreciada.

Atualizar

Após uma conversa com o administrador de sistemas, ele concordou que construir 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 endpoint que eu possa usar para meus propósitos, o resultado é o mesmo. Vou ficar de olho no que está causando o SPN para limpar. Ligações locais não são um problema usando o Python-LDAP e o serviço local já está ativo e em execução após apenas uma hora ou mais. É lamentável que eu esteja essencialmente envolvendo a funcionalidade incorporada no LDAP, mas nós fazemos o que temos que fazer.

    

Answer 1

Este é um fenômeno verdadeiramente interessante (e chato) e eu insisto que nós descobrimos o que está acontecendo aqui.

Felizmente, o Windows Server tem algumas políticas de auditoria refinadas desde 2008, e podemos usar a auditoria para rastrear quem fez isso. Para fazer isso, precisaremos:

1. Descubra onde a modificação do SPN ocorre
2. Ativar auditoria de alteração de objeto do AD DS
3. Definir uma ACE de auditoria no objeto
4. Reproduzir o erro
5. Inspecione o log de segurança no DC incorreto

Descubra onde a modificação do SPN ocorre:

Abra um prompt de comando elevado em um controlador de domínio e emita este comando:

repadmin /showobjmeta . "CN=computerAccount,DC=domain,DC=local"|findstr servicePricipalName

A saída conterá o nome do controlador de domínio que originalmente escreveu a versão atual do valor dos atributos servicePrincipalName:

AtivarauditoriadealteraçãodeobjetodoADDS:

Seumapolíticadeauditoriaglobalaindanãoestiverdefinida,vocêpoderáfazeressaalteraçãonapolíticadesegurançalocalnoControladordeDomínioidentificadonaetapaanterior

AbraoConsoledeGerenciamentodeDiretivadeGrupo(gpmc.msc),localizeoDefaultDomainControllersPolicyeedite-o.

1. IrparaComputerConfiguration->WindowsSettings->SecuritySettings
2. SelecioneeexpandaLocalPolicies->SecurityOptions
3. VerifiqueseAuditoria:forçarconfiguraçõesdesubcategoriadapolíticadeauditoria...estádefinidocomoAtivado
4. Selecione e expanda Advanced Audit Policy -> Audit Policies -> DS Access
5. Certifique-se de que Auditoria de alterações no serviço de diretório esteja definida para pelo menos sucesso

DefinaumaACEdeauditorianoobjeto:

AbraUsuárioseComputadoresdoActiveDirectory(dsa.msc)everifiqueaconfiguração"Recursos avançados" no menu "Exibir". Navegue até o objeto de conta do computador, clique com o botão direito do mouse e selecione Propriedades. Escolha a guia Segurança e clique no botão "Avançado".

No prompt, selecione a guia Auditoria e verifique se "Gravar todas as propriedades" está sendo auditado para Todos . Caso contrário, ou se você estiver em dúvida, adicione uma nova entrada:

1. Pressione Adicionar .
2. Insira "Everyone" como o principal de destino
3. Selecione "Sucesso" como o tipo
4. Role para baixo nas propriedades e marque "Gravar servicePrincipalName"
5. Pressione OK para adicionar a entrada e sair do ADUC

( Se você é preguiçoso, basta selecionar "Write all properties" )

Reproduzir o erro

Da sua pergunta, parece que o SPN get é deletado a cada minuto, então este é provavelmente o passo mais fácil. Faça uma lição de música de 1 minuto nesse meio tempo.

Inspecione o log de segurança no DC ofensivo

Agora que um minuto passou, vamos inspecionar o log de segurança no controlador de domínio identificado como o originador na etapa 1. Isso pode ser um problema em grandes domínios, mas a filtragem pode ajudar com isso:

1. Abra o Visualizador de Eventos e navegue até Windows Logs -> Security
2. No painel direito, selecione Filtrar log atual
3. No campo de entrada que diz " <All Event IDs> ", insira 5136 (esse é o ID do evento para a modificação do objeto de diretório)

Agora você deve conseguir encontrar uma entrada de evento para cada alteração no atributo servicePrincipalName na conta do computador.

Identifique o "Assunto" responsável pela mudança e veja de onde veio. Mate esse processo / máquina / conta com fogo!

Se o assunto for identificado como SYSTEM , ANONYMOUS LOGON ou uma descrição genérica semelhante, estamos lidando com o processamento interno no próprio controlador de domínio, e precisaremos desmembrar alguns registros de diagnóstico NTDS para descobrir o que está acontecendo. Por favor, atualize a pergunta se este for o caso