У нас есть приложение, которое использует Active Directory для своей аутентификации. Это включает в себя многоскачковое делегирование Kerberos, которое требуется приложению. Он состоит из клиента WinForms, подключающегося к набору веб-сервисов через WCF 4.0 и размещенного в IIS 7.5.
Обычно все это устанавливается на собственное оборудование наших клиентов и интегрируется с их AD. Но мы недавно установили, что веб-службы работают в частном облаке (доступном через IPSec VPN) с собственной реализацией AD, и где мы можем установить одностороннее доверие Active Directory между нашей AD и клиентской AD, тогда все будет хорошо, и приложение работает как задумано.
Однако у нас есть несколько клиентов, которые запускают свои AD на сервере Small Business Server, и поэтому установить доверие невозможно.
Учитывая следующие ограничения ...
- Серьезный вариант переписать приложение, чтобы оно не использовало AD / Kerberos, - недопустимый вариант.
- Принудительное переключение клиента с SBS на полноценную Windows Server AD нецелесообразно.
... Я ищу способы решения этой проблемы, которые требуют минимальных изменений в основном приложении.
Я вижу 3 варианта, которые кажутся сразу очевидными:
- Службы сертификации Active Directory - Клиенты используют сертификат, выданный нашей AD, который связан с учетной записью AD в нашем домене. Но не уверен, что это позволит делегации Kerberos.
- Службы федерации Active Directory - Похоже, что это тоже может сработать, но мы никогда не использовали его раньше.
- Active Directory Lightweight DS - Если клиент должен был установить это и каким-то образом связать его со своей AD, а мы настроили доверие к экземпляру LDS, это могло бы сработать? Опять же, мы никогда раньше не использовали AD LDS.
Кто-нибудь имеет опыт подобной ситуации или чего-то подобного?
У кого-нибудь есть какие-либо рекомендации относительно того, какой из 3 маршрутов смотреть в первую очередь?
У кого-нибудь есть другие альтернативы?