Выполнение действия от имени пользователя в кастомном сервисе

[ZooY]

Есть сервер с развернутым CRM 2016.
На отдельном сервере размещается сайт с WebAPI (поддерживает работу фронта CRM в части сложной бизнес-логики).

Для этого кастомного сайта включена Windows аутентификация, все сотальные способы аутентификации выключены.
Основная масса логики выполянется на сайте от имени пользователя, указанного в Application Pool (т.е. без каких либо извратов). В Web.config есть строка адреса OrganizationService, а пользователь AppPool имеет права системного администратора... И все это прекрасно работает.

Появилась необходимость выполнять часть кода от имени того пользователя, который стучиться на этот кастомный сайт (естественн, пользователь является пользователем CRM).

Казалось бы - все просто...

using (var impersonationContext = ((WindowsIdentity)User.Identity).Impersonate())
{
    var credentials = new ClientCredentials();
    credentials.Windows.ClientCredential = CredentialCache.DefaultNetworkCredentials;
    var service = new OrganizationServiceProxy(serviceUrl, null, credentials, null);
    ...
}

Делаешь имперсонализацию, потом создаеш экземпляр сервиса (который будет создан уже от имени нужного пользователя).
И когда CRM и кастомный веб-сервис находятся на одном сервере (в одном IIS) оно таки работает.
А вот когда CRM и сервис разнесены по разным серверам - получаю ошибку "The caller was not authenticated by the service".

Вычитал в интернетах, что проблема может быть связана с неким Double-Hop.
Предлагается решение - использовать Kerberos, но там чета SPN настрой, IIS настрой, даже браузер настрой...

Собственно вопрос... Сталкивался ли кто-то с такой проблемой и действительно ли она решается использованием Kerberos или как то можно решить ее по другому?

[a33ik]

С такой проблемой не сталкивался, но подошел бы к решению со стороны CRM CDK.
У CrmServiceClient есть возможность имперсониваться через установку свойства CallerId - https://docs.microsoft.com/en-us/dot...rmtooling-ce-9

Так что алгоритм был бы следующий:
1. Получить из контекста идентификатор пользователя, который стучится.
2. Инстанциировал CrmServiceClient под учетной записью администратора.
3. Из systemuser по AD имени пользователя получил бы его Guid в CRM.
4. Присвоил бы полученный Guid свойству CallerId.
5. Все последующие вызовы будут идти от имени указанного пользователя.

[ZooY]

Вообще говоря, с CallerId я уже пробовал играться...
Делаю вот так

var credentials = new ClientCredentials();
credentials.Windows.ClientCredential = CredentialCache.DefaultNetworkCredentials;
var service = new OrganizationServiceProxy(serviceUrl, null, credentials, null);
service.CallerId = new Guid("DBFD0A87-77DF-E911-A86A-005056010A7B");

Пробовал даже с использовать богомерзкий CrmServiceClient

var service = new CrmServiceClient(CredentialCache.DefaultNetworkCredentials, "domain.ru", "80", "MyOrg", true);
service.CallerId = new Guid("DBFD0A87-77DF-E911-A86A-005056010A7B");

При любом раскладе, результат выполнения WhoAmIRequest - пользователь из AppPool.
Либо этот прием не распространяется на WhoAmIRequest, либо я чета не так делаю, либо это вообще не работает...

[a33ik]

Цитата:

Сообщение от ZooY

Пробовал даже с использовать богомерзкий CrmServiceClient

В вопросы религии/верований не вмешиваюсь, но ваш код с OrganizationServiceProxy не будет работать с онлайном. Код с CrmServiceClient будет работать и онлайн и последний онпрем и даже онпрем 2013. Но опять таки убеждать не буду - ваше дело.

Цитата:

Сообщение от ZooY

Либо этот прием не распространяется на WhoAmIRequest, либо я чета не так делаю, либо это вообще не работает...

WhoAmI сообщение всегда будет возвращать пользователя, под которым выполнено подключение к системе. А вот после доставки сообщения в систему результаты будут несколько другими. У меня под рукой была тестовая консоль, которая создавала в системе имейлы. Вторая строка со скриншота - без установки CallerId, первая - с установкой другого пользователя. Результат, как говорится, на скришоте: