При попытке публикации базы 1С:Предприятие на веб-сервере IIS для доступа через интернет администраторы часто сталкиваются с вопросом: можно ли сделать так, чтобы пользователи, находящиеся вне офиса и не имеющие прямого подключения к домену, могли автоматически проходить Windows-аутентификацию? Давайте разберем эту задачу подробно, проанализируем ограничения и определим пути решения.
Первым делом важно прояснить, почему стандартная Windows-авторизация в IIS работает в локальной сети, но вызывает сложности при доступе извне. Когда ваш компьютер находится внутри корпоративной сети, он входит в состав домена и при обращении к серверу IIS автоматически обменивается с ним криптографическими билетами по протоколу Kerberos или NTLM. В этот момент браузер «знает» ваши учетные данные текущей сессии Windows и прозрачно передает их серверу.
Когда же пользователь выходит в интернет с домашнего или личного компьютера, ситуация кардинально меняется:
Если вы столкнулись с тем, что после ввода логина и пароля в окне IIS система 1С всё равно запрашивает авторизацию, это означает, что 1С не распознала передаваемые IIS учетные данные как доверенные для текущего пользователя 1С.
Прежде чем приступать к изменениям, давайте выполним ряд проверочных действий, чтобы локализовать причину сбоя:
DOMAIN\User или User@domain.local. Иногда система требует явного указания доменного имени.В вашем случае сервер IIS и сервер 1С разнесены на разные физические или виртуальные машины. В системном администрировании это называется проблемой Double Hop (двойного прыжка). Когда IIS принимает запрос от пользователя, он должен «передать» эти данные на сервер 1С. Протокол NTLM по своей архитектуре не поддерживает такую передачу (он не может делегировать права на второй сервер). Для корректной работы здесь необходимо использовать Kerberos с настроенным constrained delegation (ограниченным делегированием) и правильно прописанными SPN (Service Principal Names).
Учитывая, что полноценная «бесшовная» авторизация извне на недоменных компьютерах практически недостижима из-за отсутствия связи с контроллером домена, рассмотрим альтернативные методы обеспечения доступа:
Это самый безопасный и правильный путь. Развернув VPN-шлюз (например, на базе WireGuard, OpenVPN или штатных средств Windows Server), вы создаете виртуальный «туннель». Пользователь, подключившись к VPN, становится частью локальной сети, и его компьютер получает возможность полноценно общаться с доменным контроллером. В этом сценарии доменная авторизация будет работать точно так же, как если бы сотрудник сидел в офисе.
Разверните на границе сети решение типа Nginx или специализированный Web Application Firewall. Прокси-сервер может брать на себя задачу по приему внешних соединений и проверке подлинности, после чего он будет передавать «авторизованный» запрос на внутренний сервер 1С. Это защитит ваш IIS от прямого контакта с интернетом и позволит реализовать более гибкие сценарии входа.
Рассмотрите возможность использования OIDC (OpenID Connect) или SAML. Если ваша инфраструктура включает ADFS или Keycloak, вы можете настроить 1С таким образом, чтобы она перенаправляла пользователя на страницу входа вашего провайдера аутентификации. Это избавит от необходимости передачи NTLM-хэшей через интернет и обеспечит современный уровень безопасности, включая двухфакторную аутентификацию.
Для компьютеров, которые не входят в домен и находятся вне сети, автоматическая (бесшовная) доменная аутентификация невозможна в силу архитектуры протоколов Windows. Браузер всегда будет запрашивать логин и пароль. Чтобы упростить жизнь пользователям, рекомендуем либо использовать VPN, либо внедрить современные системы единого входа (SSO) через SAML/OIDC, которые работают через браузер без жесткой привязки к доменной сети.