Как аутентифицировать пользователя из внешнего Windows Domain (Active Directory)
У меня есть сервис (AcmeService), работающий на домене (ACME.COM) и пользователь, работающий в другом домене (DISNEY.COM).
mickey@disney.com хочет пройти проверку подлинности с AcmeService. Сервис знает о домене DISNEY.COM, и он импортировал всего пользователя в своей базе данных локального пользователя с LDAP при помощи известных учетных данных DISNEY.COM.
Если mickey отправляет его полностью определенное имя пользователя/пароль, AcmeService может аутентифицировать его использующий LDAP путем соединения непосредственно с контроллером домена DISNEY.COM (который он уже знает).
scrooge@disney.com хочет пройти проверку подлинности также с AcmeService, но хочет пройти проверку подлинности с интегрированной защитой, потому что он не доверяет AcmeService достаточно для выдачи его пароля. (В моем сценарии это использует.Net NegotiateStream, который является оберткой вокруг SSPI),
Мое понимание этой проблемы - то, что AcmeService не может аутентифицировать с интегрированной защитой пользователя, который не является частью его домена (ACME.COM).
Я думаю, что общее решение состояло бы в том, чтобы создать исходящие доверительные отношения между ACME.COM и DISNEY.COM, но это не возможно в моем сценарии.
Существует ли решение позволить AcmeService аутентифицировать пользователя с SSPI, если тот пользователь находится во внешнем домене и нет никаких определенных доверительных отношений? Хорошо, если решение работает только над машиной AcmeService.
Я мог бы ошибиться, но у меня создается впечатление, что было бы возможно сделать такую вещь с внешним MIT Kerberos при помощи ksetup/addkdc.
Какая-либо идея?
Спасибо
ОБНОВЛЕНИЕ
Коммуникация между клиентом и AcmeService уже защищается с TLS (без взаимной аутентификации). После того, как соединение завершено, клиент знает, что говорит с реальным AcmeService (благодаря TLS), но он теперь должен аутентифицировать свои идентификационные данные в AcmeService с помощью его учетных данных DISNEY.COM, клиентский сертификат здесь не является опцией, AcmeService только знает об учетных записях ActiveDirectory, что ранее импортировал.
NTLM (v2) был бы достаточно хорош для моего сценария, но я не вижу, почему Kerberos не был бы возможен. AcmeService имеет учетную запись DISNEY.COM (acmeuser@disney.com), он может использовать для взаимной аутентификации с Kerberos.
Я думаю, что проблема состоит в том, что при попытке аутентифицировать пользователя disney.com с SSPI, AcmeService не может определить местоположение контроллера домена автоматически для домена DISNEY.COM. Машина AcmeService должна знать, что контроллер DISNEY.COM может быть расположен по "dc.disney.com".
Вот результаты dcdiag, и nltest работал на машине AcmeService:
dcdiag /s:dc.disney.com /u:disney.com \acmeuser/p:XXXX/test:LocatorCheck
Running enterprise tests on : disney.com
Starting test: LocatorCheck
Warning: DcGetDcName(GC_SERVER_REQUIRED) call failed, error 1722
A Global Catalog Server could not be located - All GC's are down.
Warning: DcGetDcName(PDC_REQUIRED) call failed, error 1722
A Primary Domain Controller could not be located.
The server holding the PDC role is down.
Warning: DcGetDcName(TIME_SERVER) call failed, error 1722
A Time Server could not be located.
The server holding the PDC role is down.
Warning: DcGetDcName(GOOD_TIME_SERVER_PREFERRED) call failed, error 1722
A Good Time Server could not be located.
Warning: DcGetDcName(KDC_REQUIRED) call failed, error 1722
A KDC could not be located - All the KDCs are down.
......................... disney.com failed test LocatorCheck
nltest /dsgetdc:disney.com
Getting DC name failed: Status = 1355 0x54b ERROR_NO_SUCH_DOMAIN
То, в чем я нуждаюсь, является волшебной командой как "доменный регистром /domain:DISNEY.COM /controller:dc.disney.com", как я сказал ранее, хорошо, если только AcmeService может аутентифицировать пользователей DISNEY.COM, решение не должно работать со всеми в домене ACME.COM.
Есть ли решение, позволяющее AcmeService аутентифицировать пользователя с помощью SSPI, если этот пользователь находится во внешнем домене и нет определенных доверительных отношений?
Нет.
Если у вас есть ограничен работой с классом .NET NegotiateStream, тогда вы увидите в документации MSDN для класса NegotiateStream, [MS-NNS] :
Протокол .NET NegotiateStream использует SPNEGO (который выбирает между Kerberos и NTLM), чтобы определить используемый протокол безопасности.
Итак, ваш выбор - NTLM, и (скрытый) тоже хочет пройти аутентификацию с помощью AcmeService, но хочет пройти аутентификацию со встроенной безопасностью, потому что он недостаточно доверяет AcmeService, чтобы выдать [свой] пароль.
Что ж, тогда NTLM отсутствует. NTLM v1, v2 и v2 с Session Security все полагаются на слабые алгоритмы хеширования, и, кроме того, хеши пароля по существу эквивалентны паролю, поэтому я согласен с вами, что использование NTLM для аутентификации в службе означает передачу пароля
Итак, теперь у вас остался только Kerberos. И Kerberos в том виде, в каком он реализован в Active Directory, не будет проверять учетные данные для ненадежного домена.
Итак, теперь у вас не осталось выбора.
Я думаю, что общим решением будет создание исходящих доверительных отношений между ACME.COM и DISNEY.COM, но в моем сценарии это невозможно.
Вы правы в том, что создание доверия позволит одной области Kerberos доверять механизму аутентификации другой области Kerberos, но, поскольку вы не можете создать доверие, вы SOL.
Если вы хотите обеспечить надежную взаимную аутентификацию между клиентом и сервером и не можете использовать Kerberos, тогда вы используете PKI, цифровые сертификаты, TLS.
Обычно я предлагаю вам изучить службы федерации AD, но есть вероятность, что если вы не можете создать традиционные доверительные отношения AD по какой-либо причине, вы также не сможете создать доверие федерации.
Итак, я предлагаю сертификаты клиентов. (Канал)