В практике администрирования 1С часто возникает дилемма: служба агента сервера запущена от имени локального пользователя (например, localadmin), а для работы с файлами по сети (выгрузки, хранилище документов, обмен данными) требуются права доменного пользователя. Традиционно это решается либо запуском всей службы от имени доменной учетки, либо дублированием локальных пользователей на всех серверах. Однако существует «третий путь», который позволяет использовать техническую доменную учетную запись для сетевых ресурсов, не меняя владельца основного процесса 1С. Разберем подробно, как это реализовано и какие подводные камни могут возникнуть.
Проанализируем ситуацию, когда система «магическим образом» подставляет нужные учетные данные при обращении к сетевой шаре. В Windows существует специальное хранилище — Диспетчер учетных данных (Credential Manager). Это наиболее вероятный способ скрыть авторизацию от глаз программиста и не прописывать пароли в коде.
Когда процесс rphost.exe, работающий под localadmin, пытается достучаться до пути \\fileserver\share, операционная система сначала проверяет наличие сохраненных паролей для этого конкретного адреса в профиле текущего пользователя.
Рассмотрим по шагам, как настроить такой доступ:
localadmin).fileserver).abc\1cadmin).После этого любое обращение из 1С к этому серверу по протоколу SMB будет автоматически использовать сохраненный токен abc\1cadmin. В коде 1С при этом используется обычный метод КопироватьФайл или НайтиФайлы, и никаких дополнительных параметров передавать не нужно.
Посмотрим на ситуацию, упомянутую в обсуждении, где фигурирует v82.comcntr. В Windows серверные приложения могут быть обернуты в службу компонентов COM+. Это позволяет запускать конкретную библиотеку в отдельном процессе dllhost.exe с собственным контекстом безопасности.
Проанализируем алгоритм настройки через COM+:
dcomcnfg).abc\1cadmin.В этом случае, когда в коде 1С выполняется инициализация объекта:
Connector = Новый COMОбъект("V83.COMConnector");
// Или для старых версий:
// Connector = Новый COMОбъект("V82.COMConnector");
Система порождает процесс dllhost.exe, который физически работает от имени abc\1cadmin. Если дальнейшая работа с файлами идет через методы этого объекта, то и доступ к сети будет осуществляться от имени технической учетки, независимо от того, кто запустил основной rphost.exe.
Выясним причину, почему команда net use может быть полезна, даже если в проводнике не видно сетевых дисков. Команда позволяет установить сессию с сервером, которая будет кэширована в рамках текущего сеанса пользователя.
Рассмотрим пример команды, которую можно выполнить в скрипте перед запуском службы или через КомандаСистемы (хотя последний вариант менее надежен):
net use \\fileserver\share /user:abc\1cadmin mypassword /persistent:yes
Важный момент: Если выполнить эту команду без указания буквы диска (как в примере выше), соединение установится, и Windows «запомнит», что для доступа к \\fileserver\share нужно использовать данные abc\1cadmin. При этом в списке дисков ничего не появится, что часто сбивает с толку администраторов.
Посмотрим на странное поведение: учетка отключена, а 1С продолжает писать файлы до самого утра. Это объясняется спецификой работы протоколов Kerberos и SMB.
Разберем причины устойчивости доступа:
rphost.exe) активен и поддерживает активность в этой сессии, файловый сервер может не перепроверять статус пользователя в Active Directory.Если вам необходимо заменить старую техническую учетку abc\1cadmin на новую abc\newadmin, выполните следующие действия, чтобы изменения вступили в силу гарантированно:
dcomcnfg, чтобы старый dllhost.exe закрылся.net use * /delete /yes.Использование таких методов позволяет гибко настраивать права доступа, не раздувая привилегии локальных учетных записей и не переводя всю службу 1С на доменную авторизацию, что часто бывает избыточным для безопасности сервера приложений.