COMException (0x8007200A): The specified directory service attribute or value does not exist.

0 Flares 0 Flares ×

Last few days I spent on investigation, why an “application” we use does not work properly trying to access Active Directory. Long story short, we’re using application which … . The application can use internal users (similar to SQL “sa” account) or Active Directory users and we wanted to use AD users. Our AD is hardened and some default rights are removed. So … application didn’t work and it’s returning error window with message

The specified directory service attribute or value does not exist.

Not too much information, so we contacted application vendor asking what rights are necessary on the Active Directory containers, however vendor didn’t know and doesn’t know till now :).

Investigation started. Application was running on the standard AD user. So first step was to check if this user is able to access AD containers. This can be checked very easily with ldp.exe or AdsiEdit tool. In fact user was able to access the containers. Then I started to listen network traffic. What I was able to find is that application was able to do a “bind” operation to domain and then it was running some queries, but traffic was encrypted, we even tried to decrypt it to check what is inside the frame, but with no luck. It was one of the leads, the second was application log. The message in the log was

System.Runtime.InteropServices.COMException (0x8007200A): The specified directory service attribute or value does not exist.
at System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail)
at System.DirectoryServices.DirectoryEntry.Bind()
at System.DirectoryServices.DirectoryEntry.get_SchemaEntry()
at System.DirectoryServices.AccountManagement.ADStoreCtx.IsContainer(DirectoryEntry de)
at System.DirectoryServices.AccountManagement.ADStoreCtx..ctor(DirectoryEntry ctxBase, Boolean ownCtxBase, String username, String password, ContextOptions options)
at System.DirectoryServices.AccountManagement.PrincipalContext.CreateContextFromDirectoryEntry(DirectoryEntry entry)
at System.DirectoryServices.AccountManagement.PrincipalContext.DoLDAPDirectoryInitNoContainer()
at System.DirectoryServices.AccountManagement.PrincipalContext.DoDomainInit()
at System.DirectoryServices.AccountManagement.PrincipalContext.Initialize()
at System.DirectoryServices.AccountManagement.PrincipalContext.get_QueryCtx()
at System.DirectoryServices.AccountManagement.Principal.FindByIdentityWithTypeHelper(PrincipalContext context, Type principalType, Nullable`1 identityType, String identityValue, DateTime refDate
at System.DirectoryServices.AccountManagement.Principal.FindByIdentityWithType(PrincipalContext context, Type principalType, IdentityType identityType, String identityValue)
at System.DirectoryServices.AccountManagement.UserPrincipal.FindByIdentity(PrincipalContext context, IdentityType identityType, String identityValue)

This error System.Runtime.InteropServices.COMException (0x8007200A): leads to following blog post. According to this post, account used should have at least “read” right on AD Users container. In fact, in my case account had almost “Full Control” on the users container and it was not working. So a colleague compiled the code from the website and we started to test. And of course the nice error appeared 🙂

Then we read once more the most, more carefully. There is one line

“This is also true when searching computer objects using ComputerPrincipal::FindByIdentity and you don’t have read permission on CN=Computer container and have not specified a container”

Out application was not searching computers, so this line should be safely ignored.

IT’S NOT TRUE – we have added read rights on the “Computers” container for the application user account and of course issue was solved.

So the truth is the if there is no container specified while using “System.DirectoryServices.AccountManagement.UserPrincipal.FindByIdentity(…)” you need to assign “read” rights for both “CN=Users” and “CN=Computers” default AD containers for the application account.

Sad the application vendor was not able to provide such information.

Still it was very interesting case …

0 Flares LinkedIn 0 Google+ 0 Facebook 0 Twitter 0 0 Flares ×

Leave a Reply

Your email address will not be published. Required fields are marked *