If you have Microsoft Advanced Threat Analytics (ATA) within your environment, you may have seen the following warning:

Encryption downgrade activity
The encryption method of the ETYPE_INFO field of KRB_ERR message from x computers has been downgraded based on previously learned behavior. This may be a result of a Skeleton Key on x domain controllers.

I work for quite a large firm, and we were getting these for a handful of computers and accounts.

Initially we looked through Microsoft’s somewhat useful Advanced Threat Analytics suspicious activity guide. However under the heading “Encryption downgrade activity” it somewhat puts the fear of God into you. Indeed, after we did our investigations with the tools provided in that article, we found nothing. So what was going on?

We raised an incident with Microsoft and eventually found that these accounts have passwords that had not been updated for a very long time (before 2010).

Essentially:

1. When a client negotiates with the KDC (a Domain Controller), it will send the client principal name and realm (eg username/domain.local)
2. The KDC will look up the client in Active Directory, specifically the supplementalCredentials field in AD.
3. Should the user be missing the Primary:Kerberos-Newer-Keys property, then the KDC will negotiate a lower encryption with the client, and the warning will be raised in ATA.

If your domain functional level is Windows 2008 or higher (which quite frankly it should be by now!), reset the users password, as 2008 DFL introduces the Primary:Kerberos-Newer-Keys property. By resetting the users password, this *should* set the Primary:Kerberos-Newer-Keys property, and the error should go away in ATA.

If you want to test if you have this issue, just try logging on with one of these impacted user accounts to a domain joined PC, or any other system that authenticates via Kerberos.  Just use a bogus password for the account, don’t worry about it if you don’t know the accounts password because the Kerberos negotiation happens before authentication. If your failed logon raises an alert in ATA, then that account needs to change it’s password.

TL;DR: Just reset the password of the impacted users.

 

I looked everywhere and couldn’t really find an answer to this!

The company I work for had some legacy system that interfaced with the Active Directory, when a users attribute was emptied in the software, the software did not clear the attribute in AD, it just put a space character. 😦

This has been annoying for us as applications such as Exclaimer Mail Signatures have a if attribute has a value, write the attribute into the email signature. When peoples Mobile numbers are just a space in AD, it does technically have a value!

So I needed to find a query to fix this.

Find users with spaces in attributes

(objectCategory=user)(homePhone=20)

You can use ascci characters in an LDAP query. The ascci character for space (in hexadecimal) is 20. The backslash is an LDAP query escape character. The query above should find all the users that just have the space character in the homePhone attribute.

How to clear them all

Now that the offending accounts have been found, it’s time to fix em! Use PowerShell, and run this command:

Get-ADUser -LDAPFilter "(objectCategory=user)(homePhone=20)" | Set-ADUser -Clear homePhone

Done!