Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'

[alesander]

MS CRM развернут в следующей конфигурации:
На одном Windows Server 2003 Standard x64 sp2 установлен CRM 4.0, а на другом (таком же) сервере установлен MS SQL 2005 SP 3 и SSRS data connector. На сервер CRM и на дата коннектор установлен 12 rollup.

Проблема следующая:
Для CRM дописано приложение которое работает если его запускать с сервера CRM, но почему-то не работает ни на каких других машинах в локальной сети.

Страница приложения подключается ajax-ом к веб сервисам, которые в свою очередь напрямую использут SQL сервер.

Видимо проблема в аутентификации, так как на сервере SQL регистрируется ошибка "Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'. [CLIENT: сервер CRM]". Источник ошибки - sqlserver. Ошибка возникает каждый раз как пытаешься запустить приложение.

В тоже время, если CRM и SQL Server расположены на одной машине - проблем нет.

Подскажите пожалуйста, в чем может быть дело, что можно поковырять?

[Bondonello]

Цитата:

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

MS CRM развернут в следующей конфигурации:
На одном Windows Server 2003 Standard x64 sp2 установлен CRM 4.0, а на другом (таком же) сервере установлен MS SQL 2005 SP 3 и SSRS data connector. На сервер CRM и на дата коннектор установлен 12 rollup.

Проблема следующая:
Для CRM дописано приложение которое работает если его запускать с сервера CRM, но почему-то не работает ни на каких других машинах в локальной сети.

Страница приложения подключается ajax-ом к веб сервисам, которые в свою очередь напрямую использут SQL сервер.

Видимо проблема в аутентификации, так как на сервере SQL регистрируется ошибка "Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'. [CLIENT: сервер CRM]". Источник ошибки - sqlserver. Ошибка возникает каждый раз как пытаешься запустить приложение.

В тоже время, если CRM и SQL Server расположены на одной машине - проблем нет.

Подскажите пожалуйста, в чем может быть дело, что можно поковырять?

Как ваше приложение авторизируется в CRM? возможно вы используете локальный путь, что-то вроде http://localhost/название_организации поэтому на сервере все работает, а на других - нет

[alesander]

Локальный путь не используется. Указывается имя сервера, порт на котором работает приложение и путь до страницы приложения.

[Bondonello]

Цитата:

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

Локальный путь не используется. Указывается имя сервера, порт на котором работает приложение и путь до страницы приложения.

Лучше покажите этот кусок кода

[alesander]

Проблему пока не решил, но нашел решения похожих проблем.

Например здесь: http://social.microsoft.com/Forums/e...7-05f53fd3bcd9 приводится ссылка на тех. поддержку Microsoft http://support.microsoft.com/kb/810572 Там говориться о том как настроить IIS, что прописать в web.config'е приложения и что надо настроить AD для делегации.

IIS и web.config настроены, а делегация нет. Мог бы кто-нибудь подробнее рассказать про делегацию? Для каких компьютеров в AD надо ее включить? Только для сервера на котором работает IIS или для всех компьютеров с которых будет запускаться приложение?

[Артем Enot Грунин]

Механизм делегирования используется в среде без согласования керберос, чтобы серверы могли передавать между собой кредентелы авторизованного пользователя. Подробно можно почитать на примере настройки службы отчетов и CRM вот тут: http://www.microsoft.com/downloads/e...8-b38eefda7b99

[alesander]

Прошу прощения за небольшой оффтопик.
Приложение для CRM о котором идет речь внедряется в организацию со сложной доменной структурой. В организации настроены доверительные отношения между несколькими доменами дружественных предприятий. Админы организации не хотят ставить галку "trust computer to delegate" в AD в свойствах сервера CRM, т.к. боятся, что таким образом они "опубликуют сервер crm" и его ресурсы станут доступны в доменах с доверительными отношениями.
Так вот. Есть ли у них реальный повод бояться? На что может повлиять настройка делегирования для компьтера?

Заранее спасибо!

[Артем Enot Грунин]

Это приводит к тому, что сервер которому разрешена эта делегация может обращаться к другим компьютерам от имени пользователя прошедшего на нем авторизацию. Классический пример из мира CRM 3.0: Система развернута на двух компьютерах 1 - CRM, 2- SQL + Reporting Services. Пользователь заходит на сайт CRM и система с радостью его авторизует. Данные из базы SQL вычитываются под служебной учетной записью, так что проблем на этом участке не возникает. Теперь пользователь решает выполнить отчет. Здесь часть логики реализует CRM сервер - параметры предварительной фильтрации и другие интерфейсные вещи, а часть сайт Reporting Services. Вот в этот момент возникает вторая авторизация: клиент не обращается к Reporting Services напрмую через браузер. За него это делает CRM система, но есть одно важное НО: в данном случае она не может работать под выделенной учетной записью которой можно все: данные в отчете должны быть персонифицированы. Иными словами, запрос к приложению Reporting Services должен быть выполнен от имени пользователя, а не CRM системы. Это и есть право на делигирование: это разрешение доверять промежуточному серверу имперсонировать пользователя: говорить "Я = Вася" не предоставляя его пароль.
Доверительные отношения между доменами при это затронуты быть не должны. Какие "ресурсы" бояться опубликовать ваши админы я вообще не понимаю!

[alesander]

В общем настройка делегирования решает проблему. Воспроизвел все в тестовой среде - с галкой "trust computer to delegate" все работает, а без нее - нет.
Осталось доказать клиентским админам, что галка не страшная.

Спасибо Артему Грунину

[Артем Enot Грунин]

Пожалуйста. Админоборчество - это то с чем сталкивается каждый интегратор. Варианта два - подружиться (предпочтительно) и "сам дурак". В этом случае нужно вести админов на ковер и публично доказывать их проф. непригодность. Отличным подспорьем может оказаться история вашей почтовой переписки, где администратор демонстрирует отсутствие должных знаний, недружелюбие и саботирование процесса внедрения. Обычно после этого они начинают хотеть дружить. Как вариант вам с обидой вручат пароль доменного админа со словами "снимаю с себя всяческую ответственность за действия этого шарлатана!".