Active Directory 2012 LDAP Integration Service Principal Name Entry is Disappearing?

Solution 1:

This is a truly interesting (and annoying) phenomenon and I insist that we find out what's going on here.

Fortunately, Windows Server has some fine grained auditing policies since 2008, and we can use auditing to track down who did this. To do so, we'll need to:

1. Find out where the SPN modification occurs
2. Enable AD DS object change auditing
3. Set an audit ACE on the object
4. Reproduce the error
5. Inspect the security log on the offending DC

Find out where the SPN modification occurs:

Open an elevated command prompt on a domain controller and issue this command:

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

The output will contain the name of the Domain Controller who originally wrote the current version of the servicePrincipalName attributes value:

Enable AD DS object change auditing:

If a global audit policy is not already defined, you can make this change to the local security policy on the Domain Controller identified in the previous step

Open the Group Policy Management Console (gpmc.msc) and locate the Default Domain Controllers Policy and edit it.

1. Go to Computer Configuration -> Windows Settings -> Security Settings
2. Select and Expand Local Policies -> Security Options
3. Make sure that Audit: Force audit policy subcategory settings... is set to Enabled
4. Select and Expand Advanced Audit Policy -> Audit Policies -> DS Access
5. Make sure that Audit Directory Service Changes is set to at least Success

Set an audit ACE on the object:

Open Active Directory Users and Computers (dsa.msc) and Check the "Advanced Features" setting in the "View" menu.
Navigate to the computer account object, right-click it and select Properties. Choose the Security tab, and hit the "Advanced" button.

In the prompt, select the Auditing tab and ensure that "Write all properties" is being audited for Everyone. If not, or if you're in doubt, Add a new entry:

1. Press Add.
2. Input "Everyone" as the target principal
3. Select "Success" as the type
4. Scroll down under properties and check "Write servicePrincipalName"
5. Press OK to add the entry and exit ADUC

(If you're lazy you can just select "Write all properties")

Reproduce the error

From your question it seems that the SPN get's deleted every minute or so, so this is probably the easiest step. Take a 1 minute music lesson in the mean time.

Inspect the security log on the offending DC

Now that a minute has passed, let's inspect the security log on the Domain Controller identified as the originator in step 1. This can be a pain in large domains, but filtering can help with this:

1. Open Event Viewer and navigate to Windows Logs -> Security
2. In the right pane, select Filter Current Log
3. In the input field that says "<All Event IDs>", input 5136 (this is the event id for directory object modification)

You should now be able to find an event entry for each change to the servicePrincipalName attribute on the computer account.

Identify the "Subject" responsible for the change and see where it came from. Kill that process/machine/account with fire!

If the subject is identified as SYSTEM, ANONYMOUS LOGON or a similarly generic description, we're dealing with internal processing on the domain controller itself, and we'll need to break out some NTDS Diagnostic Logging to find out what's going on. Please update the question if this is the case