The LDIFDE export tool that has shipped with all flavors of Windows since Windows 2000 is one of the more useful tools that can be used for troubleshooting.

A fraction of the things you can do with it include:

  • conditional exporting of data from Active Directory
  • bulk modifying specific attributes
  • testing ACL’s through running LDIFDE in the security context of the user being tested

LDIFDE is however a picky beast – you need to format both the requests and any import data in a very specific fashion or else LDIFDE will reject it (usually with an unhelpful error message).

Another peculiarity is that copying an LDIFDE syntax from a webpage or email and pasting directly into a command prompt for example is likely to cause an error – as the non-alphanumeric characters that are pasted into the command prompt will most likely be in a slightly different format that LDIFDE isn’t able to interpret.


In a recent case I worked on, we identified that some users in the forest did not have the userPrincipalname attribute populated on some user accounts – this in turn caused a problem for smartcards issued by a Windows 2000 CA where the Subject Alternate Name on the certificate got a NULL character inserted where none should have been present. 

 

Symptoms of this include 675 events in the Security Audit log on DC’s:

Event Type:        Failure Audit
Event Source:    Security
Event Category:                Account Logon
Event ID:              675
Date:                     30-11-2009
Time:                     7:10:46
User:                     NT AUTHORITY\SYSTEM
Computer:          WORKSTATION1
Description:
Pre-authentication failed:
                User Name:        USER1
                User ID:                                CONTOSO\USER1
                Service Name:   krbtgt/CONTOSO.COM
                Pre-Authentication Type:             0xF
                Failure Code:     0x3C
                Client Address: 192.168.10.2

 

The NULL character made the SAN in the smartcard certificates effectively invalid but this wasn’t noticed until the customer installed the security hotfix from MS09-056 which implements a check in the CryptoAPI code that rejects any strings that have an embedded NULL (apart from the terminating one).

In short; once the DC’s start checking for embedded extra NULL characters after MS09-056 is installed on them they will not accept smartcard logons from cards with the invalid SAN that contains an embedded extra NULL anymore. 
The affected smartcards are therefore unusable as long as the check is being made.

The attack vector that MS09-056 is primarily targeting is spoofing of certificates when an end-user on a workstation or server is browsing an external website through a web browser.

The ultimate net result is that the smartcards had to be re-issued but as long as the UPN of the user was still empty and the smartcard was still being issued by a Windows 2000 CA you would simply reproduce the problem again in any new smartcards.

This means we had to locate the users with the empty UPN’s to determine how many were affected and to potentially bulk-populate them.

ldifde -F emptyupn.ldf -R ("(&(objectClass=user)(objectCategory=person)(!userprincipalName=*))") –L whencreated,whenchanged,samaccountname,lastlogon,logoncount

This will produce an LDF export of all user accounts (objectClass=user and objectCategory=person) in the forest that have an empty UPN name (!userprincipalname=*).
Note that this will include several system accounts (such as krbtgt, IUSR_machine, etc.) which need to be filtered out.


You can then use that output as a base to either bulk-populate the userPrincipalname from the samAccountName attribute of the user or else manually populate it if the amount of users missing a UPN is manageable.

Further reading:

MS09-056: Vulnerabilities in CryptoAPI could allow spoofing
http://support.microsoft.com/kb/974571

User Logon Name Field Is Empty After Windows NT 4.0 to Windows 2000 Upgrade
http://support.microsoft.com/default.aspx?scid=kb;EN-US;240393