собственно проблема старая, и у многих возникшая...

есть 2 физических сервера (на обоих установлен сервер 1с, один сервер продакт второй для разработки)

serv-1
serv-2

на serv-2 поднята IIS и настроена сквозная доменная авторизация, которая замечательно работает с сервером 1с на serv-2, но вот на сервер 1с который стоит на serv-1 доходит запрос на подключение без указания домена...


на сколько я понимаю проблема в длинном доменном имени, которое 1с (точнее ее длл которая прикручена к IIS) не может скушать. Вроде для 1с нужно нетбиос имя домена.

Может кто подскажет где поправить? То-есть нужна настройка которая для IIS явным образом указывает соответствие длинных имен доменов к коротким...

Там вроде проблема не в длинных/коротких именах, а в имперсонализации.

>а в имперсонализации.

с этим борются через trust computer for delegation

читаем еще раз

serv-1
serv-2

два сервера в одном домене !!!

когда IIS и 1с на одном сервере - все работает, когда на разных (но в одном домене) - нет

(3) Читай ещё раз (2). Дело в этом.

(4) при чем тут делегирование билета?

обьясните на пальцах чего надо сделать/попробовать или теорию

Есть старая темя на партнерке, но там некоторые пишут, что им не помогло. https://partners.v8.1c.ru/forum/message/890925
"Windows Server 2008, в отличии от Win2003, не позволяет использовать многократную передачу «билета» NTLM при использовании многозвенной архитектуры. Для решения проблемы попробуйте выполнить следующие настройки:



На клиентской рабочей станции настройте Internet Explorer таким образом, чтобы он использовал аутентификацию Windows, а также добавьте адрес сайта в зону локальной сети, поскольку для зоны Internet браузер не использует аутентификацию Windows. Для этого:
- Запустите браузер Internet Explorer. В строке меню выберите пункт "Tools" и выберите команду "Internet Options". Перейдите на вкладку "Advanced" установите флажок напротив пункта "Enable Integrated Windows Authentication".
- Перейдите на вкладку "Security" выберите зону для изменения "Local intranet", нажмите кнопку "Sites" укажите имя web-сервера, нажмите "Add".



Настройте Web-сервер таким образом, чтобы он использовал аутентификацию Windows и отключите использование анонимного доступа, так как если он включен то web-сервер сначала пытается воспользоваться этим способом аутентификации. Для этого:
- Запустите оснастку iis.msc находящуюся в каталоге "%SystemRoot%\system32\inetsrv\iis.msc" перейдите в раздел "Web Sites - Default Web Sites - <ИмяОпубликованнойИБ>" из контекстного меню выберите "Properties". Перейдите на вкладку "Directory Security" нажмите кнопку "Edit" в разделе "Authentication and access control". Установите флажок "Integrated Windows authentication". Остальные флажки должны быть обязательно сняты.



Настройте Active Directory для делегирования полномочий Kerberos (необходимы права администратора домена). Для этого:
- Разрешите делегирование web-серверу. На контроллере домена откройте оснастку "Active directory users and computers", в группе "Computers" выберите компьютер являющийся web-сервером, откройте его свойства. Если функциональный уровень домена "Windows Server 2003", то выберите вкладку "Delegation" и установите флажок "Trust this computer for delegation to any services (Kerberos only)", если функциональный уровень домена "Windows 2000", то на вкладке "General" установите флажок "Trust this computer for delegation".
- Разрешите делегирование пользователю. На контроллере домена откройте оснастку "Active directory users and computers", в группе "Users" выберите пользователя, откройте его свойства. На вкладке "Delegation" установите флажок "Trust this user for delegation to any services (Kerberos only)" и убедитесь, что на вкладке "Account" в разделе "Account options" снят флажок для пункта "Account is sensitive and cannot be delegated"."

давайте порассуждаю логически

вариант 1, когда IIS и 1с на одном сервере
---------------------------------------------
IIS создает отдельную сессию и ее авторизует по керберосу, сессия эта работает под службой IIS которая запущена под системной учеткой.

билет кербероса хранится в связке с этой сесией...

далее IIS вызывает DLL 1с, скорее всего в DLL вполне удачно передается билет кербероса...

далее DLL дает запрос на сервер 1с, при этом серверу 1с билет не достается, а достается текстовое поле "домен\пользователь" + его пароль

далее сервер 1с пытается авторизовать этого пользователя, если не выходит переходит в режим "авторизация 1с"
--------------------------------------------------------

вариант 2, когда IIS и 1с на разном сервере

все тоже самое только DLL передает серверу 1с поле "пользователь" + его пароль (это я точно знаю так как парсил трафик), по сколько домена нет сервер не знает где его авторизовать...

--------------------------------------------------
я тут вижу 2 проблемных места

1. возможно в первом варианте сервер 1с как-то умеет авторизовать юзера даже без передачи ей имени домена

2. возможно в первом случае в 1с приходит имя домена а во втором нет

как понять что верно а что нет - пока не понимаю...

(6) завтра посмотрю

еще одну странность заметил

IIS и 1с на разных серверах, запускаю ослика на сервере - где установлен IIS

http://local/baza - работает
http://server/baza - не работает
http://IP/baza - не работает

(9) От какого пользователя запускаешь? Входит ли этот пользователь в группу локальных админов?

(10) какая разница?

вся эта байда в (6) работает как-то через раз...

у нас как-то получилось настроить. работало. потом поменяли настройку в iis не относящуюся напрямую - все развалилось нафих

еще можно повтыкать про "double hop authentication"

(11) Разница в политиках локальной машины для разных групп. А дальше я не полез, надоело.

(13) локальная политика перекрывается доменной

(14) При условии, что в доменной политике задано значение. Проверь, делов то.