У меня есть клиент, который использует интерфейс Okta LDAP. У нас есть инструмент LDAP v3, который подключается к AD, Open LDAP и другим серверам, поддерживающим LDAP v3.
Мы хотим интегрировать интерфейс Okta LDAP в наш инструмент, поскольку он совместим с LDAPv3. Наш код основан на .NET framework + C Sharp.
Мы столкнулись с некоторыми проблемами/проблемами при подключении к интерфейсу Okta LDAP.
В настоящее время мы используем библиотеку System.DirectoryServices от Microsoft, предоставляемую Microsoft. Но столкнулся с проблемами с интерфейсом LDAP.
Для СтартTLS/389
Я получаю сообщение об ошибке:
Нежелание выступать. Код ошибки LDAP 53
Подробнее: Безопасное соединение не может быть установлено. Администратору: для этой службы требуется TLS. LDAP
Для SSL/636
Ошибка: Сервер не работает.
Ссылки:
https://docs.microsoft.com/en-us/dotnet/api/system.directoryservices?view=netframework-4.8
https://ldapwiki.com/wiki/LDAP_НЕЖЕЛАНИЕ_TO_PERFORM
var oktaLDAPPath = "LDAP://dev-506668.ldap.oktapreview.com:636/ou=users,dc=dev-506668,dc=oktapreview,dc=com";
var un = "uid=*******,dc=dev-506668,dc=oktapreview,dc=com";
var pass = "*******";
var filter = "((objectClass=*))";
try
{
using (var userDirectoryEntry = new DirectoryEntry(oktaLDAPPath, un, pass,AuthenticationTypes.SecureSocketsLayer))
{
using (var directorySearcher = new DirectorySearcher(userDirectoryEntry, filter) { PageSize = 100 })
{
directorySearcher.FindOne();
}
}
}
catch (DirectoryServicesCOMException dex)
{
}
catch (Exception ex)
{
}
Спасибо
🤔 А знаете ли вы, что...
C# поддерживает множество парадигм программирования, включая процедурное, объектно-ориентированное и функциональное программирование.
Обновлять: Итак, я провел некоторые тесты для себя. Я вижу, что происходит.
Если вы делаете Поиск DNS на dev-506668.ldap.oktapreview.com
, это дает вам результат CNAME для op1-ldapi-fb96b0a1937080bd.elb.us-east-1.amazonaws.com
.
Браузер будет использовать IP-адрес CNAME, но по-прежнему будет делать запрос с именем хоста, которое вы ему изначально дали. Однако по какой-то причине при запуске соединения LDAP Windows использует CNAME для инициации соединения.
Другими словами, Windows — это изменение запрос к LDAP://op1-ldapi-fb96b0a1937080bd.elb.us-east-1.amazonaws.com:636
. Но затем он получает SSL-сертификат с именем *.ldap.oktapreview.com
и паникует, потому что это не соответствует имени, которое использовалось для запроса (op1-ldapi-fb96b0a1937080bd.elb.us-east-1.amazonaws.com
).
Я проверил все это с помощью Wireshark, отслеживая трафик на порту 636. SSL Client Hello использует op1-ldapi-fb96b0a1937080bd.elb.us-east-1.amazonaws.com
вместо dev-506668.ldap.oktapreview.com
.
Я не знаю, как сделать так, чтобы этого не было. DirectoryEntry
также не может переопределить способ проверки SSL-сертификата. LdapConnection
делает то же самое, что и здесь, но с ним может быть немного сложнее работать. Я никогда не использовал его. (вам, вероятно, следует выполнить проверку немного самостоятельно, а не просто возвращать true
, как в этом примере).
В любом случае, вы можете поделиться этим со службой поддержки Okta.
Оригинальный ответ:
Похоже, ваш компьютер не доверяет SSL-сертификату, используемому на сервере. Чтобы убедиться в этом, я использую Chrome. Вы должны запустить Chrome следующим образом:
chrome.exe --explicitly-allowed-ports=636
Затем вы можете поместить это в адресную строку:
https://dev-506668.ldap.oktapreview.com:636
Если сертификат не является доверенным, вы получите большую ошибку, говорящую об этом. Вы можете нажать кнопку «Дополнительно», чтобы увидеть причину, по которой Chrome не доверяет ему. Но Chrome также позволит вам проверить сертификат, нажав «Небезопасно» в адресной строке слева от адреса, а затем нажмите «Сертификат».
Есть несколько причин, по которым ему нельзя доверять:
dev-506668.ldap.oktapreview.com
) не соответствует тому, что указано в сертификате. Если это так, вы можете просто изменить используемое доменное имя, чтобы оно соответствовало сертификату.