Strange COM interop exception 0x80005000 using System.DirectoryServices.AccountManagement libraries

I'm trying to write something that (amongst other things) adds a user to an AD group - using VS2010, .Net4 and the library facilities in System.DirectoryServices.AccountManagement.

I've gotten a user and group by code like the sample below, and this works for other operations like enabling or disabling accounts.

group = System.DirectoryServices.AccountManagement.GroupPrincipal.FindByIdentity(_UserContext, Name);

user = System.DirectoryServices.AccountManagement.UserPrincipal.FindByIdentity(_UserContext, Name);

Now, trying to add the user to the group like:

group.Members.Add(user);

I get an error with a stack trace beginning like the one listed below with a COM interop error 0x80005000 (unknown). This also happens with other users and on 32 and 64 bit builds. Searching this on the web comes up with a few forum questions, but I can't find any answers. In theory, this should work - this codeproject sample is doing much the same thing.

Has anyone seen this error or have any idea what might have caused it?

Stack trace top:

Unhandled Exception: System.DirectoryServices.AccountManagement.PrincipalOperati
onException: Unknown error (0x80005000) ---> System.Runtime.InteropServices.COME
xception: Unknown error (0x80005000)
   at System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail)
   at System.DirectoryServices.DirectoryEntry.Bind()
   at System.DirectoryServices.DirectoryEntry.get_AdsObject()
   at System.DirectoryServices.DirectorySearcher.FindAll(Boolean findMoreThanOne
)
   at System.DirectoryServices.DirectorySearcher.FindOne()
   at System.DirectoryServices.AccountManagement.ADStoreCtx.IsMemberOfInStore(Gr
oupPrincipal g, Principal p)
   --- End of inner exception stack trace ---
   at System.DirectoryServices.AccountManagement.ADStoreCtx.IsMemberOfInStore(Gr
oupPrincipal g, Principal p)
   at System.DirectoryServices.AccountManagement.PrincipalCollection.ContainsNat
iveTest(Principal principal)
   at System.DirectoryServices.AccountManagement.PrincipalCollection.Contains(Pr
incipal principal)
   at System.DirectoryServices.AccountManagement.Princip开发者_开发技巧alCollection.Add(Princip
al principal)
   at System.DirectoryServices.AccountManagement.PrincipalCollection.Add(UserPri
ncipal user)

---

I also ran into the same issue with a (GroupPrincipal instance).Members.Add(UserPrincipal instance).

The workaround (in IronPython) is rather simple thanks to the GetUnderlyingObject method.

de = group.GetUnderlyingObject
# Group member DNs are kept in 'member' attribute in LDAP
de.Properties['member'].Add(user.DistinguishedName)
de.CommitChanges() # Save your work

---

Just ran into this and noticed that the code project sample was explicitly using the domain's name when creating the context (instead of using null). I changed my code to explicitly specify the domain name, and now it's working fine - I can group.Members.Add(user) without issue.