Wreszcie!
Wygląda na to, że aplikacja ASP.NET nie ma uprawnień (lub nie wie jak) do sprawdzenia zaufanego magazynu certyfikatów na poziomie komputera. Ponieważ certyfikat był samopodpisany, aplikacja ASP.NET odmówiła nawiązania połączenia.
Naprawiłem problem za pomocą niestandardowego sprawdzania poprawności certyfikatu. Poniższy kod wystarczyły:
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();
Ponieważ jestem pewien, że certyfikat jest ważny, metoda ServerCallBack wygląda tak:
public static bool ServerCallBack(LdapConnection connection, X509Certificate certificate)
{
return true;
}
Ale zawsze można oczywiście pobrać certyfikat z lokalnego maszynę i zatwierdź ją.
Przestrzeń nazw stosowany w tym przykładzie:
System.DirectoryServices.Protocols;
To dlatego przestrzeni nazw:
System.DirectoryServices.DirectoryEntry
nie zawiera metodę uwierzytelniania certyfikatu zwyczaj.
Dziękuję wszystkim za pomoc i czas, i mam nadzieję, że to pomoże komuś w przyszłości!
"Typ uwierzytelnienia jest anonimowy". Nie jest, ustawiasz go na AuthenticationTypes.SecureSocketsLayer. Który identyfikuje nadawcę, aby lepiej ustawić również nazwę użytkownika i hasło. –
Witaj Hans, Próbowałem połączyć się z AD za pomocą narzędzia o nazwie ** JXplorer **. Po ustawieniu na SSL nie działała żadna nazwa użytkownika ani hasło. –
Cóż, miej oczy na piłce. Czy nadal otrzymujesz E_FAIL po określeniu prawidłowego użytkownika? Czy to działa, gdy określasz AuthenticationTypes.Anonymous? Jeśli tak, to możesz założyć, że JXplorer robi coś podobnego po prostu przechodząc z powrotem do anonimowego lub używając zalogowanych poświadczeń użytkownika, gdy żaden użytkownik nie jest określony. –