Я устанавливаю службы Active Directory облегченного доступа к каталогам (AD LDS, также известные как ADAM) на виртуальную машину Windows 2012. После того, как я наконец получил конфигурацию каталога и синхронизацию, я столкнулся с интересной проблемой. Я уже несколько часов занимаюсь поиском в Интернете и могу воспользоваться советами экспертов.
Когда я использую учетную запись «Сетевая служба» в качестве учетной записи службы для моего экземпляра LDS, я вообще не могу инициировать соединение через порт SSL (который я оставил по умолчанию 636). Мы можем подключаться к порту 389. То же самое происходит и с учетной записью службы домена «ADLDSSRVC».
Когда я использую свои личные учетные данные домена в качестве учетной записи службы, мы можем использовать соединения без SSL на порту без SSL и соединения SSL на порте SSL. Затем по SSL-соединению мы можем выполнить привязку к LDS с использованием учетных записей AD DS через перенаправление привязки прокси. У моей учетной записи домена есть права локального администратора на хосте.
Нужно ли мне сделать учетную запись службы домена "ADLDSSRVC" локальным администратором? Мой босс хочет сделать это только в крайнем случае, если я не могу предоставить ему только необходимые разрешения. В частности, я хотел бы знать, если это возможно, какие разрешения необходимы учетной записи службы, чтобы я мог устанавливать SSL ldap-подключения к моему экземпляру AD LDS. А Статья Technet указывает, что учетной записи службы ADLDS требуется доступ для создания, чтения и изменения к% ProgramFiles% \ Microsoft ADAM \ instancename \ data, но это, похоже, не повлияло на открытие порта 636.
Blog.uvm.edu сообщает, что нужно сделать следующее: Откройте инструмент «Пользователи и компьютеры AD», найдите компьютерный объект, на котором вы установили экземпляр. Дайте учетной записи службы LDS «создавать все дочерние объекты» для компьютерного объекта. Я не администратор домена, поэтому не могу этого сделать. Это в основном то же самое, что сделать учетную запись службы локальным администратором?
Для меня это звучит как случай, когда служба AD LDS не может получить доступ к сертификату, необходимому для настройки LDAPS, когда вы устанавливаете AD LDS для использования учетной записи службы, у которой нет разрешений на использование хранилища сертификатов Local Machine \ Personal .
Из Microsoft KB:
Для AD LDS поместите сертификаты в личное хранилище сертификатов для службы, которая соответствует экземпляру AD LDS, а не для службы NTDS.
Так что используйте MMC и добавьте оснастку сертификатов. Выберите «Учетная запись службы» в качестве хранилища сертификатов для просмотра и выберите службу AD LDS, установленную на этом компьютере. Там должен быть установлен ваш SSL-сертификат.
Основываясь на ответе Райана Райса, вот как я решил проблему, не создавая "domain \ adldssrvc" учетной записью администратора:
Откройте хранилище сертификатов, запустив mmc
и добавление оснастки «Сертификат» для локального компьютера.
Щелкните сертификат правой кнопкой мыши в Certificates (Local Computer)\Personal\Certificates\
и выберите All Tasks\Manage Private Keys
.
Это вызывает нормальный экран разрешений. Просто добавьте соответствующего пользователя и предоставьте ему полный контроль над этими закрытыми ключами.
Не забудьте перезагрузить службу LDS после внесения этого изменения! (services.msc)
Пожалуйста, обратитесь к этому сообщению
Я сначала настроил Enterprise CA, а затем воспользовался инструкциями на этой странице
в следующем порядке
Публикация сертификата, поддерживающего аутентификацию сервера
В пункте 5 этого шага это
«5. В диалоговом окне« Дублирование шаблона »оставьте выбранной по умолчанию Windows Server 2003 Enterprise и нажмите кнопку« ОК ».
Тщательно выберите соответствующую ОС, в учебнике говорится, что оставьте ее по умолчанию, но я использовал Windows Server 2012 r2, поэтому я выбрал ту, которую использовал. Выберите подходящую ОС.
Экспорт сертификата LDAPS и импорт для использования с AD DS
Зачем мне нужно соединение ADLDS через SSL?
Поскольку я хочу, чтобы пользователь изменил свой пароль ADLDS, соединение без SSL с использованием PrincipalContext не позволяло мне это сделать. Итак, теперь я использую следующий код, с помощью и Милостью Аллаха Всемогущего Алхумдуллила он работает как шарм.
PrincipalContext pc = new PrincipalContext(
ContextType.ApplicationDirectory,
"YourServerUrl:YourSSLPort",
"CN=YourPartitionName,DC=partition,DC=com",
ContextOptions.SimpleBind | ContextOptions.SecureSocketLayer,
"FullDistinguisedNameOfUser",
"PasswordOfUser");
bool IsUserValidated = pc.ValidateCredentials(
"FullDistinguisedNameOfUser",
"PasswordOfUser",
ContextOptions.SimpleBind | ContextOptions.SecureSocketLayer);
if (IsUserValidated)
{
UserPrincipal up = UserPrincipal.FindByIdentity(
"FullDistinguisedNameOfUser",
"PasswordOfUser");
up.ChangePassword("UserOldPassword", "UserNewPassword");
}