Именно это я и хочу узнать - опыт сообщества или хотя бы общие мысли и аргументы.
Можно поинтересоваться, чем вы руководствуетесь, говоря, что надо создавать дополнительные учетные записи?
Вы считаете, чтоесли у администратора уже есть:
1) учетка обычного доменного пользователя
2) учетка доменого пользователя с правами локального админа
3) учетка доменного админа
, ему для работы с системами, которые используют LDAP аутентификацию надо делать для кажой такой системы новую учетную запись? Например:
4) администратор антивируса
5) администратор телефонии
6) администратор 1с
7) администртатор сервера аутентификации
8)...
Итого может быть 5-10 доменных учетоку одного пользователя. Я думаю, что проблема тут возникнет с тем, что он просто не сможет запомнить столько логинов-паролей и в итоге система станет еще хуже, чем, если бы он использовал учетную запись простого доменного пользователя для доступа к таким системам.
Ну крайний случай, который я рассматриваю - 4я учетная запись - одна для всех систем администрирования.
Я часто работаю с сервером Nexus Hybrid Access Gateway. Он позволяет организовать доступ к ресурсам (не только веб) по сертификатам и другим методам аутентификации. Права на ресурсы можно распределять по группам, в том числе доменным. В вашем случае сервер Nexus HAG будет стоять "перед" веб-ресурсом в режиме reverse-proxy и пускать на ресурс только аутентифицированных пользователей с соответстующими правами. Причем права не только по группе в домене, но и можно по IP, времени входа и пр.
Сертификат от LE и от любого другого доверенного УЦ с технической точки зрения одинаковые. Скорее всего проблема в содержимом сертификата, а не в УЦ.
1. Почему вы считаете, что виноват сертификат? Та причина, про которую вы написали не может быть правильной, потому что сертификат не содержит инофрмации об SNI.
2. Что значит "перезапустил сертификат"?
Покажите сертификаты и сайт, чтобы вам помогли разобраться. Если хотите, можете написать мне в личку на хабре или в linkedin.
1. Насколько я помню, современные браузеры не проверяют CRL напрямую, а обращаются к собственным спискам отзыва. К тому же OCSP Stapling позволяет не зависеть от УЦ, а быстро предоставить подписанный ответ о валидности сертификата.
2. Хорошим тоном является, когда все сертификаты в цепочке (кроме корневого) передаются от веб-сервера. Так что дополнительные запросы не пойдут.
А без HTTPS у вас корректно работала аутентификация по паролям?
То есть при доступе к директории у вас появлялось дополнительное окно браузера, которое предлагало ввести логин и пароль, после чего браузер отображал контент, а в случае неверного ввода пароля была та же ошибка 401. Все так?
Статья, приведенная вами как интсрукция, по которой вы все настраивали указывает, что вам надо создавать сертификаты для пользователей, в которых указывать UPN. В вашем случае пользователь user@domain2 предоставляет контроллеру домена domain2 сертификат пользователя user@domain1. По идее контроллер домена должен отказать во входе.
Попробуйте добавить сертификат пользователя user@domain1 сюда:
Да, проверил. У меня именно эти сертификаты comodorsaaddtrustca.crt (1.91 KB)
addtrustexternalcaroot.crt (1.49 KB)
Они должны быть в цепочке вместе с сертификатом УЦ, который выпустил мой сертификат. У меня это был COMODO RSA Domain Validation Secure Server CA.
Если что - посмотрите, какой у вас выпускающий УЦ, возможно, для него цепочка будет другая. Пришлите название и serialnumber вашего выпускающего сертификата - попробую помочь тогда с поиском цепочки.
Я не знаю куда вы импортировали сертификат открытого ключа. Судя по всему сертификат должен импортироваться в хранилище компьютера в Личные сертификаты - Certificates(Local Computer)/Personal.
Все можно сделать через Remote Desktop Gateway Manager.
Вот подробная инструкция от MS: https://technet.microsoft.com/en-us/library/cc7328...
На старом шлюзе должен быть.
Вообще процесс получения сертификата примерно такой:
1. генерируете ключевую пару
2. отправляете открытый ключ в удостоверяющий центр. Закрытый ключ при этом остается только у вас.
3. Получаете сертификат открытого ключа от удостоверяющего центра.
Дальше вы загружаете закрытый ключ и полученный сертификат на ваш gateway.