Проанализируем частую ситуацию, с которой сталкиваются системные администраторы при публикации баз 1С на веб-сервере IIS. База (например, 1С:Зарплата и Управление Персоналом) успешно опубликована, в профилях пользователей настроена аутентификация операционной системы (доменная), и через тонкий клиент вход происходит абсолютно прозрачно (хотя может понадобиться лаунчер для 1C с доменной авторизацией). Однако при попытке входа через веб-интерфейс браузер внезапно выдает системное окно с запросом логина и пароля от домена. После ручного ввода этих данных 1С успешно запускается, не запрашивая пароль от самой информационной базы. Выясним причину такого поведения и рассмотрим подробнее, как заставить браузеры передавать учетные данные автоматически.
Эта проблема чаще всего носит плавающий характер: у одних пользователей работает без запроса пароля, у других системное окно появляется во всех браузерах (аналогичные проблемы решает скрипт установки Apache). Получается, что проблема кроется не столько в 1С, сколько в цепочке доверия между клиентским ПК, браузером, веб-сервером IIS и контроллером домена. Разберем по шагам все возможные причины и пути решения.
Частая причина появления системного окна кроется в том, как браузеры определяют безопасность узла. Если вы обращаетесь к серверу 1С по короткому имени (например, http://server1c/), большинство браузеров автоматически относят его к зоне «Местная интрасеть» и прозрачно передают текущие учетные данные ОС. Если же вы используете полное доменное имя (FQDN, например, http://server1c.domain.local/), браузер может отнести адрес к зоне «Интернет», для которой автоматическая передача токенов безопасности запрещена политиками.
Рассмотрим, как правильно настроить свойства браузера (на примере Internet Explorer / свойств обозревателя Windows, которые влияют и на другие браузеры):
Если в Internet Explorer авторизация работает, а в Google Chrome, Microsoft Edge или Mozilla Firefox всё равно выскакивает окно, посмотрим на специфические настройки этих браузеров.
Для Google Chrome и Microsoft Edge:
Браузеры на движке Chromium могут блокировать сквозную передачу доменного имени. В корпоративной среде это решается через централизованные групповые политики (GPO). Вам необходимо добавить адрес сервера 1С в белые списки для политик:
AuthServerWhitelist = *domain.local
AuthNegotiateDelegateWhitelist = *domain.local
После применения этих политик браузер поймет, что серверу с данным адресом можно доверять и безопасно передавать ему NTLM/Kerberos тикеты.
Для Mozilla Firefox:
В этом обозревателе прозрачная доменная авторизация отключена по умолчанию. Разберем по шагам, как её включить:
about:config и примите риск изменения скрытых настроек.network.automatic-ntlm-auth.trusted-uris и добавьте в его значение адрес вашего сервера (например, server1c.domain.local).network.negotiate-auth.trusted-uris и также впишите туда адрес сервера IIS.Проанализируем ситуацию на стороне сервера. IIS должен быть настроен так, чтобы он запрашивал у клиента Windows-аутентификацию и не пытался пустить его анонимно.
iis.msc).Теперь обратим внимание на важный скрытый нюанс. Выделите строку «Проверка подлинности Windows» и справа в панели действий нажмите Поставщики... (Providers). По умолчанию там стоят провайдеры Negotiate (он же Kerberos) и NTLM. Если в домене есть проблемы с SPN-записями или рассинхронизация времени на клиентах, Kerberos сломается. В этом случае смена приоритета — перемещение NTLM на первое место — может моментально решить проблему с внезапными окнами паролей. Также рекомендуется зайти в Дополнительные параметры проверки подлинности Windows и отключить функцию Расширенная защита (Extended Protection), которая часто конфликтует со старыми клиентами.
Усложним задачу и посмотрим на пример, когда веб-сервер IIS и сервер 1С:Предприятия установлены на РАЗНЫХ физических или виртуальных машинах. Это классическая проблема "Двойного прыжка". Протокол NTLM по соображениям безопасности не позволяет передавать учетные данные пользователя от одного сервера к другому (от браузера к IIS, а затем от IIS к Серверу 1С). В такой архитектуре NTLM работать не будет в принципе, и браузер всегда будет просить пароль, что мешает использовать WEB приложение для управления сеансами.
Решение — строгая настройка делегирования полномочий Kerberos в Active Directory. Разберем по шагам:
Для корректной работы Kerberos системному администратору также потребуется зарегистрировать SPN-записи (Service Principal Name) для учетной записи, под которой работает служба веб-сервера, используя утилиту setspn.
Напоследок выясним причину, связанную с самой базой 1С. Пользователи могут успешно проходить аутентификацию IIS, но 1С их "не узнает". Посмотрим на логи технологического журнала (события CONN) или логи IIS. Проблема в том, что разные рабочие станции могут отправлять доменное имя в разных форматах: DOMAIN\Ivanov или Ivanov@domain.local.
Если в Конфигураторе 1С в карточке пользователя на вкладке аутентификации ОС прописан формат пользователя через слэш (DOMAIN\Ivanov), а браузер передает UPN-суффикс (через @), сопоставление не сработает. Обязательно проверяйте формат, который приходит от проблемных клиентов, и при необходимости корректируйте привязки пользователей в 1С:Предприятии.
Используя данный алгоритм, вы сможете локализовать сбой на уровне браузера, веб-сервера или домена и добиться того, чтобы 1С через веб-интерфейс открывалась без лишних вопросов, как и при использовании тонкого клиента.