Share via

Disparition d’enregistrements DNS: Comment l’évènement 5136 peut vous aider à en identifier la cause.

  • Article

  •  

  • S'applique à Windows 2008 R2 Server, Windows 2012 Server, Windows 2012 R2 Server hébergeant une ou plusieurs zones intégrées Active Directory.  

  • Parmi les incidents DNS/AD sur lesquels j'ai pu intervenir, la suppression inexpliquée d'enregistrements DNS est parmi l’un des plus redondants, entre autres parce que les équipes se sentent parfois désarmées devant le nombre de causes possibles à ce comportement :

    • Intervention d'un serveur DHCP supprimant un enregistrement lors de l'expiration d'un bail.
    • Mise à jour dynamique du client qui, pour une raison ou une autre, considère que son enregistrement est périmé.
    • Intervention d'un administrateur résultant d'une mauvaise intention ou d'une erreur de manipulation.
    • Processus de scavenging local au serveur supprimant un enregistrement dont le timestamp est antérieur à la date du jour minus la période de rétention.
    • Plus généralement, toute opération modifiant une zone au niveau DNS ou directement au niveau AD.

  • Si les causes peuvent parfois être évidentes, il faudra dans les autres cas investiguer pour identifier la source du problème en utilisant par exemple des captures réseau ou - dans le cas où les suppressions concernent une zone intégrée à l'Active Directory n'autorisant que les mises à jour sécurisées - l'audit de sécurité.

  • En effet, les zones intégrées à l'Active Directory forçant la mise à jour sécurisée présentent trois avantages par rapport à ce cas:

    • La suppression d'un enregistrement DNS est en fait une opération de modification d'un objet dnsNode dans l'annuaire.
    • Cette opération nécessite un compte possédant les droits de modification de l'objet et donc un processus d'authentification.
    • Le compte utilisé sera donc identifiable grâce à l'audit.

  •  

  • Grâce à cette méthode, il sera possible de trouver facilement le compte responsable de l’opération sur l’enregistrement, permettant ainsi soit d’identifier immédiatement la cause soit d’affiner considérablement la recherche.

  • Pour mettre en place et exploiter l’audit des créations, modifications ou enregistrements DNS dans une zone intégrée AD, il est nécessaire de procéder à trois opérations :

 

    1. Activez l’audit de changement des objets de l’annuaire :

  • Note: Avant d'activer l'audit, assurez-vous que l'enregistrement circulaire est activé ou que vous disposez de suffisamment d'espace disque. Pour plus d'informations sur l'activation de l'audit voir l'article technet https://technet.microsoft.com/en-us/library/cc731607(v=ws.10).aspx

  • Dans la stratégie des contrôleurs de domaine, naviguez jusqu’à Computer Configuration > Windows Settings > Security Settings > Advanced Audit Policy Configuration > DS Access puis activez l’audit en paramétrant la sous-catégorie Audit Directory Service Changes :

  •  

  • Mettez ensuite en place l’audit sur la zone concernée.

  • Dans la console dnsmgmt.msc, naviguez jusqu’à la zone à auditer puis faites un clic droit sur la zone Properties > Security > Advanced > Auditing et cliquez sur Add.

  • Renseignez alors les champs comme indiqué sur la capture ci-dessous :

  • Security Principal : Everyone

  • Type : All

  • Permissions : Write All properties, Delete, Delete subtree, Create all child objects, Delete All child objects

  • Note: Les permissions Create dnsNode et Delete dnsNode sont implicites des permissions Created all child Objects et Delete all Child objects, il n’est donc pas nécessaire de les selectionner par la console ADSIedit.

  • Une fois l’audit activé et la stratégie de groupe rafraîchie (vous pouvez accélérer le processus en lançant la commande gpupdate /force sur le contrôleur de domaine à auditer), les enregistrements des actions sur la zone DNS sont actifs. 

  • Lors de la prochaine occurrence de l’évènement il faudra alors, avant de recréer l’enregistrement (car sinon vous risquez de le réanimer), déterminer depuis quel serveur il a été supprimé comme détaillé dans l’étape suivante. 

  •  

  • 2.  Identifiez le contrôleur de domaine originaire de la modification de l’objet dnsNode :

  •  

  • Pour cela : 

  •  

    1. Identifiez un enregistrement victime d'une suppression non désirée.

Pour ce premier exemple, il s'agit de l'enregistrement xvcwcv. Cet enregistrement est présent dans la zone contoso.com, elle-même stockée dans la partition DomainDnsZones. Si votre ou vos enregistrements manquants se situent dans une autre partition applicatibe (par exemple ForesDnsZones), vous devrez adapter le DN donné en exemple dans les commandes qui suivent afin de le faire correspondre à la réalité.

      2.    Puis validez que l’enregistrement a bien été tombstoned. Il existe plusieurs méthodes :

 

      • La commande Powershell

  • Get-ADobject -searchbase "dc=contoso.com,cn=microsoftDNS,dc=domaindnszones,dc=contoso,dc=com" -filter {name -eq 'xvcwcv'} -properties * | findstr dNSTombstoned

  • vous permettra par exemple de savoir si l’enregistrement xvcwcv (remplacer le DN donné en exemple par celui de l’enregistrement  manquant) présent dans la zone contoso.com (à remplacer) hébergée dans la partition applicative DomainDnsZones (à remplacer si nécessaire) a bien été supprimé ; dNSTombstoned : True

  • il faut donc adapter les variables à votre environnement et à l’enregistrement que vous recherchez.

  • De la même façon, la commande

  • Get-ADobject -searchbase "dc=contoso.com,cn=microsoftDNS,dc=domaindnszones,dc=contoso,dc=com" -filter * -properties * | Where-Object {$_.dnstombstoned -eq 'true'} | Select-Object dnstombstoned,name

  • permettra de connaître tous les enregistrements supprimés récemment.

  • Note: Cette méthode nécessite cependant que le module Powershell Active-Directory soit installé sur votre contrôleur de domaine ou station d'administration et que les service Active Directory Web Services soit opérationnel. Plus d'informations sur l'interaction entre Powershell et Active Directory ici https://technet.microsoft.com/fr-fr/library/dd378937(v=ws.10).aspx

 

      • ADSIedit

Il est également possible de vérifier cela avec ADSIedit.msc en naviguant dans la partition hébergeant la zone et en vérifiant graphiquement l’attribut dnsTombstoned de l’objet dnsNode contenant l’enregistrement :

clip_image003

 

A présent que nous avons identifié un enregistrement manquant, la commande

repadmin /showobjmeta contosodc1 "dc=xvcwcv,dc=contoso.com,cn=microsoftdns,dc=domaindnszones,dc=contoso,dc=com"

nous permettra de connaître le contrôleur de domaine à l’origine de la modification de l’enregistrement dans la zone, où contosodc1 est le nom d’un contrôleur de domaine à interroger et dc=xvcwcv,dc=contoso.com,cn=microsoftdns,dc=domaindnszones,dc=contoso,dc=com le dN de l’objet dnsNode hébergeant l’enregistrement DNS supprimé.

clip_image004

Sur la capture d’écran, nous pouvons donc constater que l’attribut dNSTombstoned a été modifié depuis CONTOSODC1 à 20 :49 le 19/01/2014.

 

 

 

3. Consultez le journal des évènements du contrôleur de domaine identifié

 

Une fois l’enregistrement et le contrôleur de domaine identifiés, consultez les entrées du journal des évènements d’audit sur le contrôleur de domaine à l’origine de la modification et recherchez les évènements 5136 correspondant à l’heure de modification :

 

Pour reprendre notre exemple de disparition de l'enregistrement xvcwcv.contoso.com voici ce que nous apprend le journal des évènements de CONTOSODC1 à ce sujet:

  •  

  • A directory service object was modified.

    Subject:

    Security ID: CONTOSO\XVCWCV$

    Account Name: XVCWCV$

    Account Domain: CONTOSO

    Logon ID: 0x1E969B

    Directory Service:

    Name: contoso.com

    Type: Active Directory Domain Services

    Object:

    DN: DC=xvcwcv,DC=contoso.com,cn=MicrosoftDNS,DC=DomainDnsZones,DC=contoso,DC=com

    GUID: DC=xvcwcv,DC=contoso.com,CN=MicrosoftDNS,DC=DomainDnsZones,DC=contoso,DC=com

    Class: dnsNode

    Attribute:

    LDAP Display Name: dNSTombstoned

    Syntax (OID): 2.5.5.8

    Value: TRUE

    Operation:

    Type: Value Added

    Correlation ID: {d9022d09-9c03-4ead-af58-c50e810aeaab}

    Application Correlation ID: -

  •  

  •  

  • Cet évènement 5136 nous informe donc que le compte machine XCVXWCV$ a modifié la valeur de l'attribut dNSTombstoned en la passant à TRUE. A partir de là le diagnostic s'oriente clairement vers une mise à jour dynamique avec un TTL à zero car nous savons que c'est le compte machine lui-même qui a supprimé son propre enregistrement.

  • Prenons également l'exemple de la création et de la suppression manuelle d'un enregistrement, nommé NewRR par l'administrateur :

  • Cet évènement correspond à la création du contenu de l’enregistrement.

  • A directory service object was modified.

    Subject:

                    Security ID: CONTOSO\administrator

                    Account Name: Administrator

                    Account Domain: CONTOSO

                    Logon ID: 0x33404

    Directory Service:

                    Name: contoso.com

                    Type: Active Directory Domain Services

    Object:

                    DN: DC=newRR,DC=contoso.com,cn=MicrosoftDNS,DC=DomainDnsZones,DC=contoso,DC=com

                    GUID: DC=newRR,DC=contoso.com,CN=MicrosoftDNS,DC=DomainDnsZones,DC=contoso,DC=com

                    Class: dnsNode

    Attribute:

                    LDAP Display Name: dnsRecord

                    Syntax (OID): 2.5.5.10

                    Value: <Binary>

    Operation:

                    Type: Value Added

                    Correlation ID: {863e3db1-03f7-4fa0-a588-24b1a95c15eb}

    Application Correlation ID: -

  • Lorsque l’on supprime ce même record, voici l’un des 3 évènements 5136 générés qui correspond à la suppression du contenu de l’enregistrement (attribut dnsRecord) :

  • A directory service object was modified.

    Subject:

                    Security ID: CONTOSO\administrator

                    Account Name: Administrator

                    Account Domain: CONTOSO

                    Logon ID: 0x33404

    Directory Service:

                    Name: contoso.com

                    Type: Active Directory Domain Services

    Object:

                    DN: DC=newRR,DC=contoso.com,cn=MicrosoftDNS,DC=DomainDnsZones,DC=contoso,DC=com

                    GUID: DC=newRR,DC=contoso.com,CN=MicrosoftDNS,DC=DomainDnsZones,DC=contoso,DC=com

                    Class: dnsNode

    Attribute:

                    LDAP Display Name: dnsRecord

                    Syntax (OID): 2.5.5.10

                    Value: <Binary>

    Operation:

                    Type: Value Deleted

                    Correlation ID: {7b955f29-b21c-4d33-a7a2-19e3d6f06172}

    Application Correlation ID: -

  • Ici donc, le compte administrator a supprimé l’enregistrement NewRR et l’évènement correspond à la suppression du contenu de l’enregistrement. Il existe également un évènement 5136 pour la modification de l’attribut dNSTOmbsoned, l’un comme l’autre nous renseigneront sur le compte ayant fait la modification.

  • Note : Si lors d'une investigation sur une suppression vous constatez que le serveur à l’origine de la modification est le serveur sur lequel le scavenging est activé et que le compte utilisé pour modifier l’enregistrement est le compte machine du serveur, tentez de relier l’heure de modification de l’attribut dnsTombstoned ou dnsRecord à un event 2501 dans le journal des évènements DNS.

  • Je vous conseille par ailleurs ce post sur le scavenging DNS https://blogs.technet.com/b/networking/archive/2008/03/19/don-t-be-afraid-of-dns-scavenging-just-be-patient.aspx . Vous noterez que l’auteur recommande un seul serveur opérant le scavenging notamment pour une plus grande simplicité en cas de troubleshooting.

  • La recommandation actuelle est cependant d’utiliser deux serveurs car cela permet d’obtenir une redondance de service en cas de panne de l’un des serveurs. Toutefois un seul serveur est acceptable et cela simplifiera dans votre cas la résolution du problème si celui-ci est lié au scavenging.

  •  

  • Et pour les zones autorisant les enregistrement non sécurisés ça marche aussi ?

  • Malheureusement pour les zones non sécurisées la méthode se révèle beaucoup moins utile. En effet le comportement par défaut d'un client DNS, même s'il supporte les mises à jour sécurisées par Kerberos, est de tenter en premier lieu une mise à jour non sécurisée.

  • Autrement dit, si vous autorisez les mises à jour non sécurisées dans une zone intégrée à l'annuaire, aucun enregistrement créé ne sera sécurisé, n'importe quel client DNS pourra requêter une modification sans authentification préalable et les objets dnsNode seront donc directement modifiés par le contrôleur de domaine qui reçoit la demande de mise à jour.

  • Ainsi l’audit ne vous serait d’aucune utilité dans le cas où les suppressions seraient issues d’une demande de mise à jour dynamique.

  • Plus que jamais donc, la mise en place de mises à jour DNS sécurisées n'est pas une bonne pratique pour rien car non seulement elle réduit l'exposition de la zone à certains types d'attaques ou de dysfonctionnements mais en plus, dans le cas où vous seriez malgré tout victime de disparitions spontanées d'enregistrements, elle vous permettra également d'en identifier plus rapidement la cause comme nous venons de le voir ensemble.

  • Pour finir, sachez qu'à Microsoft France nous proposons un workshop 100% en Français sur DNS pour nos clients Premier. Au programme les fondametaux DNS revus et entièrement expliqués en profondeur, l'administration, la sécurité, la sauvegarde/restauration et bien d'autres sujets encore…

  • Si vous êtes intéressé et que vous êtes client Premier, n'hésitez pas à demander à votre TAM de vous inscrire à cet excellent workshop.

  •  

  • François Petit

  • PFE