Error 0X80005000 and Directoryservices

Error 0x80005000 and DirectoryServices

It's a permission problem.

When you run the console app, that app runs with your credentials, e.g. as "you".

The WCF service runs where? In IIS? Most likely, it runs under a separate account, which is not permissioned to query Active Directory.

You can either try to get the WCF impersonation thingie working, so that your own credentials get passed on, or you can specify a username/password on creating your DirectoryEntry:

DirectoryEntry directoryEntry = 
    new DirectoryEntry("LDAP://someserver.contoso.com/DC=contoso,DC=com", 
                       userName, password);

---

OK, so it might not be the credentials after all (that's usually the case in over 80% of the cases I see).

What about changing your code a little bit?

DirectorySearcher directorySearcher = new DirectorySearcher(directoryEntry);
directorySearcher.Filter = string.Format("(&(objectClass=user)(objectCategory=user) (sAMAccountName={0}))", username);

directorySearcher.PropertiesToLoad.Add("msRTCSIP-PrimaryUserAddress");

var result = directorySearcher.FindOne();

if(result != null)
{
   if(result.Properties["msRTCSIP-PrimaryUserAddress"] != null)
   {
      var resultValue = result.Properties["msRTCSIP-PrimaryUserAddress"][0];
   }
}

My idea is: why not tell the DirectorySearcher right off the bat what attribute you're interested in? Then you don't need to do another extra step to get the full DirectoryEntry from the search result (should be faster), and since you told the directory searcher to find that property, it's certainly going to be loaded in the search result - so unless it's null (no value set), then you should be able to retrieve it easily.

Marc

Unknown Error (0x80005000) with LDAPS Connection

Finally!

It seems that an ASP.NET application does not have the rights (or doesn't know how) to examine the trusted certificate store at machine level. Since the certificate was self-signed the ASP.NET application refused to establish a connection.

I fixed the problem using custom certificate validation.
The following code did the trick:

LdapConnection con = new LdapConnection(new LdapDirectoryIdentifier("server", port));
con.SessionOptions.SecureSocketLayer = true;
con.SessionOptions.VerifyServerCertificate = new VerifyServerCertificateCallback(ServerCallback);
con.Credential = new NetworkCredential(String.Empty, String.Empty);
con.AuthType = AuthType.Basic;
con.Bind();

Since I am sure the certificate is valid, the ServerCallBack method looks like this:

public static bool ServerCallBack(LdapConnection connection, X509Certificate certificate)
{
    return true;
}

But you can always of course retrieve the certificate from the local machine and validate it.

The namespace used in this example is:

System.DirectoryServices.Protocols;

This is because the namespace:

System.DirectoryServices.DirectoryEntry

does not contain a method for custom certificate validation.

Thank you all for your help and time, and hopefully this will help someone in the future!

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

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

Error 0x80005000 with LdapConnection and LDAPS

Would something like this work for you..?

const string Domain = "ServerAddress:389";
const string constrParts = @"OU=Users,DC=domain,DC=com";
const string Username = @"karell";
PrincipalContext principalContext = new PrincipalContext(ContextType.Domain, Domain, constrParts);
UserPrincipal userPrincipal = UserPrincipal.FindByIdentity(principalContext,  username);

Here is a really good site for great references and examples
DirectoryServices DirectoryEntry

for Connection over SSL you could do something like the following

const int ldapInvalidCredentialsError = 0x31;
const string server = "your_domain.com:636";
const string domain = "your_domain.com";

try
{
    using (var ldapSSLConn = new LdapConnection(server))
    {
        var networkCredential = new NetworkCredential(username, password, domain);
        ldapSSLConn.SessionOptions.SecureSocketLayer = true;
        ldapSSLConn.AuthType = AuthType.Negotiate;
        ldapSSLConn.Bind(networkCredential);
    }

    // If the bind succeeds, the credentials are valid
    return true;
}
catch (LdapException ldapEx)
{
    // Invalid credentials a specific error code
    if (ldapEx.ErrorCode.Equals(ldapInvalidCredentialsError))
    {
        return false;
    }

    throw;
}

MSDN list of Invalid LDAP Error Codes

0x80005000 Unknown Error on UserPrincipal.GetGroups with Special Characters in OU

I believe this is a bug.

The source code of the .NET Core implementation of the AccountManagement namespace is available online now. I would imagine the .NET Framework version is much the same.

I believe the problem is on line 1218 of ADStoreCtx.cs:

roots.Add(new DirectoryEntry("GC://" + gc.Name + "/" + p.DistinguishedName, this.credentials != null ? this.credentials.UserName : null, this.credentials != null ? this.credentials.Password : null, this.AuthTypes));

That is dropping the user's distinguished name into an LDAP path, which uses slashes as separators, without escaping any slashes in the DN.

I know bugs for .NET Core can be reported in GitHub, but I'm not sure where to report a bug with .NET Framework.

---

Related Topics