Блог

В настоящее время я использую следующий код для получения доменов из текущего леса.

 Forest currentForest = Forest.GetCurrentForest();
DomainCollection domainCollection = currentForest.Domains;
 

Этот метод использует протокол LDAP для связи с AD, который находится через порт 389.
Я ищу альтернативу для совершения того же вызова через порт 636 (LDAP SSL).

Это кажется невозможным. System.DirectoryServices.ActiveDirectory использует System.DirectoryServices.DirectoryEntry , который, в свою очередь, использует ADSI внизу для получения данных:

Система.Пространство имен DirectoryServices

Обеспечивает легкий доступ к доменным службам Active Directory из управляемого кода. Пространство имен содержит два класса компонентов, DirectoryEntry и DirectorySearcher, которые используют технологию интерфейсов служб Active Directory (ADSI).

Сам ADSI поддерживает два типа шифрования: на основе Kerberos и на основе SSL. Из документации:

Шифрование на основе Kerberos

Чтобы использовать шифрование на основе Kerberos, укажите ADS_USE_SEALING флаг при вызове ADsOpenObject или IADsOpenDSObject::OpenDSObject . ADS_USE_SEALING Флаг также можно использовать для проверки целостности данных, то есть для обеспечения того, чтобы полученные данные совпадали с отправленными. Если ADS_USE_SEALING флаг указан, ADS_USE_SIGNING флаг также будет указан автоматически. Оба флага требуют проверки подлинности Kerberos, которая работает только при следующих условиях:

• Клиентский компьютер должен быть зарегистрирован в домене Windows или в домене, которому доверяет домен Windows.
• ADsOpenObject или IADsOpenDSObject::OpenDSObject должен вызываться с нулевыми учетными данными; то есть альтернативные учетные данные не могут быть указаны.

Шифрование на основе SSL

Чтобы использовать шифрование на основе SSL, укажите ADS_USE_SSL флаг при вызове ADsOpenObject или IADsOpenDSObject::OpenDSObject . Если указан только ADS_USE_SSL флаг, ADSI открывает SSL-порт 636, а затем выполняет простую привязку по этому SSL-каналу. Если ADS_SECURE_AUTHENTICATION указаны оба флага ADS_USE_SSL и, поведение привязки зависит от клиента, с которого выполняется вызов. В неподдерживаемых версиях Windows ADSI сначала открывает канал SSL и выполняет простую привязку с использованием указанного имени пользователя и пароля или текущего контекста пользователя, если имя пользователя и пароль равны нулю. В поддерживаемых версиях Windows ADSI выполняет безопасную проверку подлинности, а не простую привязку.

Это означает, что для выполнения SSL-аутентификации необходимо указать дополнительный флаг для привязки ADSI. Это не настраивается внутри System.DirectoryServices.ActiveDirectory , как указано в соответствующем коде:

 AuthenticationTypes authType = Utils.DefaultAuthType;

if (useServerBind)
{
    authType |= AuthenticationTypes.ServerBind;
}

de = new DirectoryEntry(ldapPath, username, password, authType);
 

Эти флаги аутентификации жестко Utils.DefaultAuthType закодированы , что определяется как:

 internal const AuthenticationTypes DefaultAuthType = AuthenticationTypes.Secure | AuthenticationTypes.Signing | AuthenticationTypes.Sealing;
 

Поэтому вы не можете указать дополнительный флаг AuthenticationTypes.SecureSocketsLayer для получения шифрования SSL, НО стандартный набор флагов совместим с шифрованием Kerberos, которое ADSI включает по умолчанию. Если вы соответствуете требованиям (компьютер, подключенный к домену, без пользовательских учетных данных), связь будет автоматически зашифрована с помощью Kerberos без какой-либо дополнительной настройки. Это можно проверить с помощью Wireshark (обратите внимание на первоначальное чтение RootDSE анонимно в обычном виде, запрос привязки и все последующие сообщения с зашифрованной полезной нагрузкой).: