WCF: взаимосвязь между NetworkCredential и олицетворением

Question

У меня есть служба WCF, размещенная в IIS 7 в пуле приложений по умолчанию в интегрированном режиме с отключенным анонимным доступом и аутентификацией Windows.

Я применил следующий атрибут реализации метода для моего интерфейса.

[OperationBehavior(Impersonation = ImpersonationOption.Required)] 

Если я не поставить сетевые учетные данные в вызове моей службы я получаю ожидаемое поведение в том, что выполняются следующие условия:

ServiceSecurityContext.Current.WindowsIdentity.Name = MYDOMAIN \ MyUser
ServiceSecurityContext .Current.PrimaryIdentity.Name = myDomain \ myUser
Thread.CurrentPrincipal.Identity.Name = myDomain \ myUser
Я могу подключиться к базе данных в удаленной системе с использованием аутентификации SSPI и myDomain \ myUser.
WindowsIdentity.GetCurrent(). Name = myDomain \ myUser
Я могу использовать Thread.CurrentPrincipal.IsInRole(), чтобы проверить, что пользователь находится в роли.
Я могу использовать WindowsIdentity.GetCurrent(). Группы для извлечения списка групп для пользователя.

Но если поставить сетевые учетные данные, используя следующие:

var networkCredential = new NetworkCredential(user, pwd, dom); 
base.ClientCredentials.Windows.ClientCredential = networkCredential; 
base.ClientCredentials.Windows.AllowNtlm = true;  
base.ClientCredentials.Windows.AllowedImpersonationLevel 
      = System.Security.Principal.TokenImpersonationLevel.Delegation; 

Тогда все вышеперечисленное же, за исключением подключения к базе данных и две из перечисленных групп различны. Соединение с базой данных выполняется с помощью пользователя NT Authority \ Anonymous. Использование NetworkCredentials помещает пользователя в группу NT Authority \ Network, а не в NT Authority \ Interactive, и дополнительно удаляется группа LOCAL.

Моя цель - сделать подключение к базе данных с использованием учетных данных, переданных NetworkCredential, любые советы будут оценены.

Шейн Holder

Answer 1

Походит типичные проблемы двойного прыжка.

Я предполагаю, что в вашем рабочем сценарии Kerberos привыкает по умолчанию, что даст вам токен делегирования на удаленном сервере.

Во втором случае он не использует Kerberos из-за предоставленного пользователя/пароля и не поддерживает получение токена делегирования.

Единственный другой способ получить токен делегирования на удаленном сервере, о котором я знаю, это использовать базовую аутентификацию (с SSL), полную боль.

Concerning the credentials double hop issue