Короткий ответ
Учётка, которой кластер SRV-1C ходит в SQL01 к Accounting, не должна быть sysadmin. Для клиент-серверной 1С обычно достаточно login + user в базе с правами, которые требует платформа (на практике часто db_owner на этой базе, не на всём экземпляре). sa в строке инфобазы, персональные админы и «BUILTIN\Administrators` в sysadmin — уберите из повседневности. Backup, Agent, диски — другие роли, не 1С.
Симптомы и как отличить
Типичная картина:
- в строке соединения 1С:
sa; - любой локальный админ Windows = sysadmin SQL;
- после переноса базы 18456 или user без login;
- 1С «случайно» видит чужие базы на экземпляре.
Отличия:
| Симптом | Не «мало прав 1С» |
|---|---|
| 40/1433 | сеть |
| 18456 state 8 | пароль |
| 18456 state 5 | нет login |
Возможные причины
- Когда-то поставили 1С «под sa, потом разберёмся».
- Restore на новый SQL01 без
ALTER USER ... WITH LOGIN. - Windows-аутентификация: компьютер
SRV-1C$не в нужной роли, зато админы да. - Job backup под той же учёткой 1С.
- Ревизии не было годы.
Диагностика
SELECT name, type_desc, is_disabled, is_policy_checked
FROM sys.server_principals
WHERE name IN (N'sa', N'1c_accounting', N'CONTOSO\svc-1c');
SELECT r.name AS role, m.name AS member
FROM sys.server_role_members rm
JOIN sys.server_principals r ON rm.role_principal_id = r.principal_id
JOIN sys.server_principals m ON rm.member_principal_id = m.principal_id
WHERE r.name = N'sysadmin';
USE [Accounting];
SELECT dp.name AS db_user, dp.type_desc, sl.name AS login
FROM sys.database_principals dp
LEFT JOIN sys.server_principals sl ON dp.sid = sl.sid
WHERE dp.principal_id > 4;Orphan: db_user есть, login NULL.
Проверка, чем реально коннектится 1С: свойства инфобазы в кластере (пользователь СУБД) + sys.dm_exec_sessions login_name во время сеанса.
Решение
Сценарий A. Выделенная учётка
Создайте SQL login 1c_accounting (или gMSA CONTOSO\svc-1c) с длинным паролем в сейфе:
CREATE LOGIN [1c_accounting] WITH PASSWORD = N'<из сейфа>', CHECK_POLICY = ON;
USE [Accounting];
CREATE USER [1c_accounting] FOR LOGIN [1c_accounting];
ALTER ROLE [db_owner] ADD MEMBER [1c_accounting];db_owner на одной базе — компромисс, который 1С часто требует для реструктуризации. Не sysadmin. Не db_owner на master.
В кластере 1С пропишите эту учётку, уберите sa. Проверьте вход предприятия и конфигуратора (реструктуризация).
Сценарий B. Снять sysadmin с приложения
ALTER SERVER ROLE [sysadmin] DROP MEMBER [1c_accounting];Сначала убедитесь, что user в Accounting достаточно. Тест на копии.
Сценарий C. Orphan после restore
USE [Accounting];
ALTER USER [1c_accounting] WITH LOGIN = [1c_accounting];SID должен совпасть. Если user другое имя — сопоставьте явно.
Сценарий D. Windows auth с SRV-1C
Login для машины/службы кластера, user в Accounting. Не добавляйте Domain Admins. SPN и делегирование — отдельно, не через sysadmin.
Сценарий E. Кто должен быть sysadmin
Персональные DBA, возможно gMSA Agent. Не учётка 1С, не бухгалтерия.
Контур 1С: что проверить после смены учётки СУБД
В консоли кластера свойства инфобазы Accounting: пользователь сервера СУБД, не «Windows текущего пользователя» админа, который когда-то жал кнопки. После смены пароля login SQL 1С не подхватит его из AD сама, если это SQL auth — обновите пароль в кластере. Сеансы могут жить со старым паролем до пересоздания соединений; новые упадут 18456. Короткое окно: сменить пароль в SQL и в кластере, перезапуск рабочих процессов по необходимости.
Не храните пароль 1С-login в открытом RTF рядом с ibases.v8i. Секрет — в сейфе/secret storage, в заявке — «пароль обновлён», не сам пароль.
Аудит: раз в квартал sysadmin members. Если появился CONTOSO\1C_Users — уберите. Клиентам 1433 не нужен. Если появился разработчик с sysadmin «на неделю отладки» — снимите, отладка не на проде.
Для мониторинга (Zabbix/Prometheus exporter) — отдельный login с VIEW SERVER STATE / VIEW ANY DEFINITION по необходимости, не учётка 1С и не sa.
После restore на тестовый SQL01 не копируйте прод-login с тем же паролем в общий чат. Тест — свой пароль, иначе тестовый стенд становится ключом к прод-SQL, если сеть не изолирована.
Как проверить, что проблема устранена
SELECT r.name, m.name
FROM sys.server_role_members rm
JOIN sys.server_principals r ON rm.role_principal_id = r.principal_id
JOIN sys.server_principals m ON rm.member_principal_id = m.principal_id
WHERE r.name = N'sysadmin';В списке нет 1c_accounting/sa-сессии приложения. 1С открывает Accounting, регламент и проведение работают. Попытка USE otherdb этой учёткой — отказ.
Если не помогло
- Реструктуризация падает 229 — не хватает права в базе, добавьте точечно (часто всё же db_owner на время обновления на копии), не sysadmin.
- 18456 — пароль/lockout, не роль.
- Нужны VIEW SERVER STATE для мониторинга — отдельная учётка монитора, не 1С.
Профилактика
- Запрет sa в инфобазах (ревью квартал).
- Секрет пароля 1С в сейфе, ротация.
- После переноса — чеклист SID.
- Аудит: кто в sysadmin.
Минимум для 1С — login, user в Accounting, права на объекты этой базы (практически часто db_owner только там). Всё, что шире, должно иметь срок и владельца. sa отключите (CHECK_EXPIRATION, rename, disable) если политика позволяет, либо длинный пароль в сейфе, не в строке инфобазы. Windows-группа локальных администраторов в sysadmin удобна до первого ransomware. После переноса базы прогоните скрипт orphaned users сразу, не дожидаясь утреннего 18456. Конфигуратор на проде под той же учёткой, что предприятие, — нормально; sysadmin для этого не нужен. Если реструктуризация на копии проходит с db_owner, не добавляйте серверные роли «про запас».
FAQ
1С «официально просит sysadmin».
Проверьте актуальную документацию вашей 8.3. Часто достаточно прав на базу. Sysadmin — лень установки. Если вендор написал sysadmin для конкретной операции — временное окно на копии, не навсегда на проде.
db_owner vs ddladmin+datawriter.
Реструктуризация 1С трогает схему. На копии проверьте минимальный набор; многие оставляют db_owner на одной БД как практический минимум выше «только write».
Windows-группа «1C Users» в SQL.
Клиенты 1С не должны ходить на 1433. Только сервис кластера. Не путайте AD-группу бухгалтеров с login SQL.
Можно ли один login на все базы 1С?
Технически да, риск шире. Лучше login на базу/контур (прод/тест).
Agent job под 1c_accounting.
Нет. Backup — Agent с правами на файлы backup, не приложение.