При работе в локальной сети компании сквозная аутентификация Windows (Single Sign-On, или SSO) в базах данных 1С настраивается относительно просто. Пользователь открывает базу через веб-браузер или тонкий клиент, веб-сервер IIS или Apache распознает его доменную учетную запись, и вход происходит автоматически без ввода паролей. Однако ситуация резко усложняется, когда сотрудникам требуется подключиться к 1С с домашних или удаленных компьютеров, которые физически находятся вне офиса, не включены в корпоративный домен Active Directory и имеют доступ к публикации 1С только через интернет.
В этой статье мы подробно разберем, почему стандартные протоколы аутентификации Windows не могут работать напрямую через интернет, и проанализируем эффективные технические решения, позволяющие организовать безопасный беспарольный или централизованный вход для удаленных сотрудников без необходимости развертывания VPN-клиентов на каждом устройстве.
Прежде чем переходить к настройкам, выясним техническую причину этой проблемы. Прозрачная авторизация Windows в веб-среде базируется на механизме Negotiate, который в первую очередь пытается использовать протокол Kerberos, а при невозможности — откатывается к NTLM.
Чтобы протокол Kerberos успешно отработал:
Если удаленный компьютер находится в домашней сети или подключен к публичному интернету, браузер физически не сможет связаться с контроллером домена. Как следствие, он не получит билет авторизации и не сможет передать его веб-серверу IIS. Попытка аутентификации завершится ошибкой или бесконечным запросом логина и пароля, который не будет приниматься сервером.
Рассмотрим несколько альтернативных способов решения этой задачи, начиная от простых настроек веб-сервера и заканчивая современными федеративными системами идентификации.
---
Если мы не можем обеспечить клиенту доступ к контроллеру домена, мы можем переложить эту задачу на веб-сервер IIS. Сам веб-сервер IIS находится внутри корпоративного периметра и имеет постоянную связь с Active Directory. Мы можем настроить его так, чтобы он запрашивал у внешнего пользователя доменное имя и пароль, самостоятельно проверял их в AD и авторизовал пользователя в 1С.
Разберем по шагам, как настроить этот механизм:
Шаг 1. Настройка аутентификации в IIS
DOMAIN\user они смогут вводить просто user).Важное предупреждение о безопасности: Базовая аутентификация передает учетные данные пользователя в заголовках HTTP в открытом виде (закодированными по алгоритму Base64, который легко декодируется). Поэтому использовать Basic-аутентификацию в интернете допускается исключительно поверх защищенного соединения HTTPS (SSL/TLS). Без SSL-сертификата ваши доменные пароли будут перехвачены злоумышленниками в первой же публичной Wi-Fi сети.
Шаг 2. Настройка сопоставления в 1С:Предприятии
В конфигураторе 1С в справочнике «Пользователи» (или в списке пользователей в администрировании) для нужного сотрудника необходимо установить флаг «Аутентификация операционной системы» и прописать его доменное имя в формате DOMAIN\username. Когда пользователь введет эти учетные данные в окне базовой авторизации браузера, IIS успешно проверит их в домене и передаст имя пользователя в платформу 1С, которая автоматически сопоставит его и впустит в базу.
Шаг 3. Решение проблемы Double Hop (двойного прыжка)
Если веб-сервер IIS и сервер приложений 1С:Предприятия установлены на разных физических или виртуальных серверах, вы столкнетесь с классической проблемой передачи учетных данных между серверами. IIS не сможет просто так передать доменные данные на сервер 1С.
Чтобы решить эту проблему, администратору домена необходимо настроить Ограниченное делегирование Kerberos (Kerberos Constrained Delegation):
---
Как отмечают участники обсуждения, одним из наиболее перспективных решений является использование встроенного OpenID-провайдера 1С. Однако администраторы часто отказываются от него из-за того, что сессия пользователя быстро истекает, требуя постоянного повторного ввода пароля. Выясним, как управлять этим поведением.
При использовании встроенного OpenID-провайдера 1С (начиная со старых версий OpenID v2) вся конфигурация авторизационных токенов хранится в конфигурационном файле публикации default.vrd. Время жизни сессии авторизации по умолчанию составляет ровно одну неделю (604 800 секунд), но мы можем легко переопределить это значение на любой удобный период, например, на один месяц или даже на полгода.
Проанализируем структуру файла default.vrd на стороне базы данных, которая выступает в роли OpenID-провайдера. Нам нужно вручную добавить или отредактировать параметр <lifetime> внутри тега <provider>.
Пример фрагмента файла default.vrd:
<?xml version="1.0" encoding="UTF-8"?>
<point xmlns="http://v8.1c.ru/8.2/virtual-resource-system"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
base="/openid_provider">
<ws>
<provider>
<!-- Время жизни авторизационного токена в секундах. 2592000 секунд = 30 дней -->
<lifetime>2592000</lifetime>
</provider>
</ws>
</point>
Увеличив значение этого параметра, мы избавим удаленных сотрудников от частых запросов на ввод логина и пароля. Пока токен действителен, вход в базу 1С с данного компьютера будет выполняться мгновенно и незаметно для пользователя.
---
Если перед организацией стоит задача построить надежную, безопасную и действительно бесшовную схему авторизации сотрудников без привязки к локальной доменной сети, классический домен Active Directory в чистом виде уступает место современным системам управления идентификацией (IdP). Платформа 1С:Предприятие (начиная с версий 8.3.14 / 8.3.17+) имеет встроенную глубокую поддержку протокола OpenID Connect (OIDC).
В качестве центрального шлюза авторизации мы можем развернуть во внешнем контуре защищенный сервер Keycloak или Authentik. Эти системы умеют синхронизировать пользователей с вашим внутренним каталогом Active Directory (через защищенный протокол LDAPS) и выступать единой точкой входа (Identity Provider) для всех корпоративных приложений, включая 1С.
Схема взаимодействия выглядит следующим образом:
Как настроить постоянную привязку к устройству без ввода пароля в OIDC?
В отличие от устаревшего OpenID v2, протокол OIDC поддерживает механизм Refresh Tokens (токенов обновления) и механизм скользящего времени жизни сессии (Sliding Expiration). В настройках клиента Keycloak администратор может задать параметры:
Благодаря этому пользователь вводит пароль всего один раз при первоначальной настройке своего компьютера, а во все последующие разы авторизация проходит бесшовно в фоновом режиме по сохраненному токену обновления.
---
Если компания предъявляет повышенные требования к информационной безопасности и категорически запрещает публиковать форму ввода доменных паролей в открытый интернет (даже по HTTPS), отличным решением является организация авторизации по клиентским SSL-сертификатам (Client Certificate Authentication).
Этот метод позволяет жестко привязать возможность входа в 1С к конкретному физическому устройству сотрудника без необходимости вводить пароли вручную.
Алгоритм настройки беспарольного входа по сертификатам:
Этот способ гарантирует, что никто посторонний, даже зная логин и сложный пароль сотрудника, не сможет открыть форму авторизации 1С из интернета, так как доступ будет физически заблокирован веб-сервером на этапе SSL-рукопожатия (SSL Handshake) при отсутствии валидного сертификата.
---
Выбор конкретного технического решения зависит от масштаба вашей инфраструктуры и требований безопасности компании: