Qu'est-ce qui pousse mon contrôleur de domaine à enregistrer des dizaines de tentatives d'authentification réussies par seconde?

7

Nous avons un domaine avec environ 15 serveurs et environ 30 postes de travail. Les serveurs sont principalement 2008r2 et les postes de travail sont principalement Windows 7. Les deux contrôleurs de domaine sont 2012r2. Toutes les quelques semaines, l'un de nos comptes d'administrateur est verrouillé. J'essaie de réduire la cause et j'ai atteint une impasse.

Voici ce que j'ai.

Le journal des événements sur le PDC affiche l'événement 4776 - réussite de l'audit:

Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
Logon Account:  username
Source Workstation: 
Error Code: 0x0

Tous pour le même nom d'utilisateur et récurrents plusieurs fois par seconde.

Sur la base des ID d'événement, il s'agit de connexions NTLM plutôt que Kerberos. Bien que le type d'authentification utilisé soit moins inquiétant pour moi que la quantité de cisaillement. Cela se produit plusieurs fois par seconde et se répète toutes les deux secondes à l'infini, toute la journée, la nuit ou le week-end.

Le journal des événements affiche également l'ID d'événement de réussite d'audit 4624 (ouverture de session) et 4634 (fermeture de session) pour ce nom d'utilisateur, mais comme dans l'événement ci-dessus, le champ "poste de travail" est vide.

J'ai activé la journalisation détaillée de netlogon et les émissions netlogon.log 

02/28 17:11:03 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation1) Entered
02/28 17:11:03 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation1) Returns 0x0
02/28 17:11:04 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation2) Entered
02/28 17:11:04 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation2) Returns 0x0
02/28 17:11:19 [LOGON] [8468] domain: SamLogon: Transitive Network logon of domain\username from  (via server1) Entered
02/28 17:11:19 [LOGON] [8468] domain: SamLogon: Transitive Network logon of domain\username from  (via server1) Returns 0x0
02/28 17:11:19 [LOGON] [8468] domain: SamLogon: Transitive Network logon of domain\username from  (via server2) Entered
02/28 17:11:19 [LOGON] [8468] domain: SamLogon: Transitive Network logon of domain\username from  (via server2) Returns 0x0
02/28 17:11:19 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation3) Entered
02/28 17:11:19 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation3) Returns 0x0
02/28 17:11:19 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation2) Entered
02/28 17:11:19 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation2) Returns 0x0
02/28 17:11:19 [LOGON] [5476] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation4) Entered
02/28 17:11:19 [LOGON] [8468] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation5) Entered
02/28 17:11:19 [LOGON] [5476] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation4) Returns 0x0
02/28 17:11:19 [LOGON] [8468] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation5) Returns 0x0
02/28 17:11:20 [LOGON] [5476] domain: SamLogon: Transitive Network logon of domain\username from  (via server3) Entered
02/28 17:11:20 [LOGON] [5476] domain: SamLogon: Transitive Network logon of domain\username from  (via server3) Returns 0x0
02/28 17:11:20 [LOGON] [5476] domain: SamLogon: Transitive Network logon of domain\username from  (via server4) Entered
02/28 17:11:20 [LOGON] [5476] domain: SamLogon: Transitive Network logon of domain\username from  (via server4) Returns 0x0

Et ainsi de suite. La source apparente de ces connexions (via XYZ) peut inclure des postes de travail et des serveurs à travers le réseau.

Cela ressemble clairement à une automatisation ou à un script. Étant donné que les connexions sont généralement toutes réussies, je ne pense pas que ce soit une tentative d'intrusion. Certaines connexions, cependant, échouent de temps en temps, mais je n'ai identifié aucun motif de l'échec et elles se produisent si rarement que (la plupart du temps), elles ne verrouillent pas le compte. Le code d'échec lorsqu'il y en a un est généralement 0xc0000022 (accès refusé)

J'ai désactivé et désinstallé notre agent de surveillance à distance (actuellement Kaseya, mais nous passons finalement à LabTech) à partir d'un des serveurs, mais j'ai encore vu de nouveaux événements provenant de ce serveur, donc cela exclut les tâches d'automatisation. J'ai également vérifié le planificateur de tâches sur quelques serveurs et je n'ai rien trouvé d'extraordinaire. J'ai vérifié les services pour vérifier les comptes d'ouverture de session et ce compte n'est utilisé dans aucun service.

J'ai couru Netstat pendant un bon moment et j'ai vu principalement des connexions au PDC à partir de "System" et "System Idle Process". J'ai vu des connexions occasionnelles à partir de spoolsrv et lsass et ismserv (le serveur sur lequel je teste est un serveur Citrix XenApp, mais d'autres serveurs "source" ne sont pas dans la batterie XenApp, et bien sûr les postes de travail "source" ne le sont pas non plus). J'ai arrêté le service de spouleur d'impression juste pour tester et cela n'a eu aucun impact sur les événements de connexion.

Je travaille dans un MSP et il s'agit de notre compte administrateur dom technicien principal, il est donc hautement prioritaire qu'il fonctionne et soit sécurisé. La dernière idée qui me reste est de changer le mot de passe et de voir ce qui se casse, mais sans savoir à quoi le compte est utilisé, cela pourrait avoir des conséquences potentiellement catastrophiques. Cependant, je soupçonne que cela pourrait simplement être une AD mal configurée.

Est-ce que quelqu'un a déjà vécu quelque chose comme ça et a pu identifier la source?

active-directory windows-server-2008-r2 windows-server-2012-r2 Thomas
la source
Pour ceux qui sont curieux du nombre élevé de serveurs, ils ont les serveurs XenApp avec SharePoint face au public pour une main-d'œuvre hautement mobile avec BYOD. Ils avaient également un personnel informatique précédent qui était allé un peu trop loin dans leur infrastructure pour la taille de leur entreprise. Depuis qu'ils nous ont contractés, nous avons essayé de les amincir un peu pour quelque chose de plus approprié à leurs besoins.
Thomas
Vous pouvez essayer d'installer Microsoft Network Monitor sur l'un des serveurs, démarrer une capture, attendre qu'une entrée du serveur soit enregistrée dans le journal de netlogon, puis regarder la capture et voir si vous pouvez trouver la conversation dans Network Monitor . Le Moniteur réseau doit vous montrer le processus responsable de la conversation. Si cela ne le réduit pas suffisamment, vous pouvez utiliser le Moniteur réseau conjointement avec le Moniteur de processus pour identifier le processus responsable.
joeqwerty
Microsoft Network Monitor est obsolète et remplacé par Microsoft Message Analyzer. Même accord que Wireshark. J'ai exécuté une capture de paquets et n'ai trouvé absolument rien d'utile. Les seuls événements qui sont étroitement liés aux événements NetLogon sont les connexions WMI et RPC.
Thomas
À droite, NetMon est obsolète mais c'est toujours un bon outil. Si vous n'avez pas utilisé Message Analyzer auparavant, cela peut être un peu écrasant. NetMon est assez simple et intuitif. Je l'utilise habituellement avant toute autre chose. - Quant à votre capture, le trafic RPC peut contenir des indices.
joeqwerty
Ouais, rien. Il y a une liaison MSRPC envoyée et Ack reçu pour créer une session cryptée suivie d'un paquet NRPC envoyé et reçu contenant une demande et une réponse NetrLogonSamLogonEx, les deux dernières étant cryptées. Le processus d'appel sur l'ordinateur source est LSASS, qui exécute le service Netlogon. Il n'y a aucun détail utile dans les données de paquets du trafic Bind et bien sûr les paquets chiffrés ne me sont d'aucune utilité.
Thomas

Réponses:

1

Je recommande d'activer davantage l'audit NTLM sur vos contrôleurs de domaine. À l'aide de la stratégie de contrôleur de domaine par défaut, activez les paramètres de stratégie suivants:

Sécurité réseau: Baliser NTLM: Audit entrant trafic = Activation de l' audit pour tous les comptes de la sécurité réseau: NTLM Restreindre: l' authentification NTLM d' audit dans ce domaine = Activer tout sécurité réseau: restreindre NTLM: trafic NTLM sortant vers des serveurs distants = Audit Tous

https://support.symantec.com/en_US/article.HOWTO79508.html

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/jj865682(v=ws.10)

Une fois activé, accédez dans votre visualiseur d'événements à: Journaux des applications et des services> Microsoft> Windows> NTLM> Opérationnel

Il y aura des événements avec des horodatages correspondant à vos horodatages d'événement netlogon. Ce journal révélera le nom réel du poste de travail.

Et spécifiquement pour vous aider à identifier davantage la source, le nom de canal sécurisé dans ce journal aiderait à affiner l'origine du processus.

Homebrew Hops
la source
Merci d'avoir répondu. Malheureusement, ce client particulier n'est plus un de nos clients, je ne peux donc pas essayer vos instructions. Je suis allé de l'avant et j'ai accepté votre réponse, car ma propre compréhension de la maladie d'Alzheimer me dit que cela devrait me donner les détails dont j'ai besoin. (Je ne sais pas pourquoi je n'ai pas pensé à ajuster la politique d'audit, mais vous basculez pour l'avoir suggéré.)
Thomas