L'entrée du nom principal du service d'intégration LDAP Active Directory 2012 disparaît?

Création d'un service Python pour interroger des attributs AD

J'intègre notre AD avec des services Web exécutant Python sur linux en utilisant Python-LDAP sur SASL (DIGEST-MD5) pour interroger les attributs utilisateur AD 2012 (division, département, extension téléphonique, e-mail, etc.). Après avoir déterminé les anomalies spécifiques à mon service par rapport à un AD 2003, j'ai commencé à rencontrer une erreur SPN par rapport à notre nouvel AD 2012, que le digest-uri ne correspondait à aucun SPN sur le serveur. J'ai croisé la liste SPN pour les deux serveurs et ils contiennent des analogues identiques l'un de l'autre.

L'erreur: le résumé-uri ne correspond à aucun SPN LDAP enregistré pour ce serveur

Le correctif?

Cela a été corrigé en exécutant:

setspn -A ldap/<Domain_Name> <Computer_Name>

Notez que la création d'un compte de service n'a pas résolu mon erreur SPN même lorsque la commande suivante a été exécutée:

setspn -A ldap/<Domain_Name> <Domain_Name>/<Service_Account_Name>

simple_bind_s () n'a pas besoin de SPN, sasl_interactive_bind_s () a besoin de SPN

Seul l'ajout du SPN à la liste SPN de l'ordinateur local a fonctionné pour mon service Python-LDAP à l'aide de sasl_interactive_bind_s (). Je dois également noter que l'étape SPN peut être ignorée si j'utilise simple_bind_s () mais cette méthode envoie des informations d'identification en texte clair, ce qui est inacceptable.

Cependant, j'ai remarqué que l'enregistrement ne reste sur la liste SPN que pendant environ une minute avant de disparaître? Il n'y a aucune erreur lorsque j'exécute la commande setspn, les journaux d'événements sont complètement vides, il n'y a aucun doublon nulle part, vérifié avec la recherche à l'échelle de la forêt -F sur le dn de base et rien. J'ai ajouté et essayé de rajouter et de supprimer et de déplacer le SPN d'un objet à un autre pour vérifier qu'il ne se cache nulle part, mais la seconde j'ajoute l'objet n'importe où, puis j'essaye de le rajouter, il m'informe d'un doublon. Je suis donc très confiant qu'il n'y a pas de doublon caché quelque part.

The Hack

Pour l'instant, j'ai une tâche planifiée réexécutant la commande pour conserver l'enregistrement sur la liste afin que mon service fonctionne correctement nommé "SPN Hack"

cmd.exe /C "setspn -A ldap/<Domain_Name> <Computer_Name>"

jusqu'à ce que je puisse découvrir pourquoi le SPN est nettoyé de la liste.

Je ne suis pas l'administrateur principal de cette AD particulière, l'administrateur peut-il avoir un service en cours d'exécution qui synchronise le SPN à partir d'un autre service sur l'AD et ne pas en être conscient? Mon titre est Développeur Web, non pas comme excuse mais pour expliquer mon ignorance en matière d'Active Directory. On m'a dit de faire de l'AD la base de données utilisateur maître et j'ai beaucoup lu, mais je ne trouve nulle part où les gens ont un problème avec le SPN étant «écrasé» ou «nettoyé» périodiquement et aucun des les administrateurs connaissent très bien le SPN en dehors des entrées SQLServer.

Pourquoi ai-je besoin du hack?

Jusqu'à présent, mon piratage ne semble pas avoir causé de problèmes pour les utilisateurs ou les services et n'a généré aucune erreur, donc l'administrateur dit qu'il va simplement le laisser fonctionner et je continuerai à chercher. Mais alors je me retrouve dans la situation précaire d'écrire un service dont l'implémentation est construite, essentiellement un cron hack / shiver ... Donc, toute aide serait appréciée.

Mise à jour

Après une conversation avec l'administrateur système, il a convenu que la création d'un service au-dessus d'un hack n'est pas une solution, il m'a donc donné la permission de créer un service local avec un cryptage de point de terminaison que je peux utiliser à mes fins, le résultat est le même . Je garderai un œil sur ce qui cause le nettoyage du SPN. Les liaisons locales ne sont pas un problème en utilisant Python-LDAP et le service local est déjà opérationnel après seulement une heure environ. Il est regrettable que j'encapsule essentiellement les fonctionnalités intégrées à LDAP, mais nous faisons ce que nous devons faire.

C'est un phénomène vraiment intéressant (et ennuyeux) et j'insiste pour que nous découvrions ce qui se passe ici.

Heureusement, Windows Server a des stratégies d'audit à granularité fine depuis 2008, et nous pouvons utiliser l'audit pour retrouver qui a fait cela. Pour ce faire, nous devons:

1. Découvrez où la modification SPN se produit
2. Activer l'audit de modification d'objet AD DS
3. Définir un ACE d'audit sur l'objet
4. Reproduisez l'erreur
5. Inspectez le journal de sécurité sur le contrôleur de domaine incriminé

Découvrez où la modification SPN se produit:

Ouvrez une invite de commande élevée sur un contrôleur de domaine et exécutez cette commande:

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

La sortie contiendra le nom du contrôleur de domaine qui a initialement écrit la version actuelle de la valeur des attributs servicePrincipalName:

Activer l'audit de modification d'objet AD DS:

Si une stratégie d'audit globale n'est pas déjà définie, vous pouvez apporter cette modification à la stratégie de sécurité locale sur le contrôleur de domaine identifié à l'étape précédente

Ouvrez la console de gestion des stratégies de groupe ( gpmc.msc), recherchez Default Domain Controllers Policyet modifiez-la.

1. Aller à Computer Configuration -> Windows Settings -> Security Settings
2. Sélectionnez et développez Local Policies -> Security Options
3. Assurez-vous que Audit: Forcer les paramètres de sous-catégorie de stratégie d'audit ... est défini sur Activé
4. Sélectionnez et développez Advanced Audit Policy -> Audit Policies -> DS Access
5. Assurez-vous que les modifications du service d'annuaire d'audit sont définies sur au moins Succès

Définissez un ACE d'audit sur l'objet:

Ouvrez Utilisateurs et ordinateurs Active Directory ( dsa.msc) et vérifiez le paramètre "Fonctionnalités avancées" dans le menu "Affichage".
Accédez à l'objet de compte d'ordinateur, cliquez dessus avec le bouton droit et sélectionnez Propriétés. Choisissez l' onglet Sécurité et cliquez sur le bouton "Avancé".

À l'invite, sélectionnez l' onglet Audit et assurez-vous que "Écrire toutes les propriétés" est audité pour tout le monde . Si non, ou en cas de doute, ajoutez une nouvelle entrée:

1. Appuyez sur Ajouter .
2. Entrez "Tout le monde" comme principal cible
3. Sélectionnez "Succès" comme type
4. Faites défiler vers le bas sous les propriétés et cochez "Write servicePrincipalName"
5. Appuyez sur OK pour ajouter l'entrée et quitter ADUC

( Si vous êtes paresseux, vous pouvez simplement sélectionner "Écrire toutes les propriétés" )

Reproduisez l'erreur

D'après votre question, il semble que le SPN soit supprimé toutes les minutes environ, c'est donc probablement l'étape la plus simple. Prenez une leçon de musique d' une minute en attendant.

Inspectez le journal de sécurité sur le contrôleur de domaine incriminé

Maintenant qu'une minute s'est écoulée, examinons le journal de sécurité sur le contrôleur de domaine identifié comme l'expéditeur à l'étape 1. Cela peut être pénible dans les grands domaines, mais le filtrage peut aider à cela:

1. Ouvrez l'Observateur d'événements et accédez à Windows Logs -> Security
2. Dans le volet droit, sélectionnez Filtrer le journal actuel
3. Dans le champ de saisie " <All Event IDs>", saisissez 5136 (il s'agit de l'ID d'événement pour la modification de l'objet d'annuaire)

Vous devriez maintenant pouvoir trouver une entrée d'événement pour chaque modification de l' servicePrincipalNameattribut sur le compte d'ordinateur.

Identifiez le «sujet» responsable du changement et voyez d'où il vient. Tuez ce processus / machine / compte avec le feu!

Si le sujet est identifié en tant que SYSTEM, ANONYMOUS LOGONou une description générique similaire, nous avons affaire à un traitement interne sur le contrôleur de domaine lui-même, et nous devrons décomposer une journalisation de diagnostic NTDS pour savoir ce qui se passe. Veuillez mettre à jour la question si tel est le cas