У меня есть служба (AcmeService), работающая в домене (ACME.COM), и пользователь, работающий в другом домене (DISNEY.COM).
mickey@disney.com хочет пройти аутентификацию с помощью AcmeService. Служба знает о домене DISNEY.COM и импортировала всех пользователей в свою локальную базу данных пользователей с помощью LDAP, используя известные учетные данные DISNEY.COM.
Если Микки отправляет свое полное имя пользователя / пароль, 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
Мне нужна волшебная команда вроде "register-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 и Kerberos.
scrooge@disney.com тоже хочет пройти аутентификацию с помощью 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 по какой-либо причине, вы также не сможете создать доверие федерации.
Итак, я предлагаю клиентские сертификаты. (Канал)