1C, SQL Server, режимы аутентификации

Проверялось на: Win 2000 Server, SQL Server 2000, 1C 18 релиз

Данная статья является дополнением к статье "Первые шаги", в которой было рассказано как по шагам произвести установку 1С, SQL Server, а также как произвести конвертацию вашей DBF базы. В этой статье будут подробно рассмотрены варианты подключения к SQL Server, вопросы безопасности, а также способ, позволяющий подключаться 1С в режиме авторизации Windows.

При установке SQL Server (либо после его установке) необходимо выбрать режим подключения (аутентификации, авторизация) пользователей к SQL Server. Для этого как в SQL Server 7.0 так и SQL Server 2000 существует два режима: смешанный и авторизация Windows. Вообще-то 1С поддерживает только смешанный способ подключения*. Причиной этого является довольно частое появление следующей ошибки: Login failed for user '%ls'. Reason: Not associated with a trusted SQL Server connection. Для 1С это сообщение означает, что вы выбрали способ авторизации Windows - в своих методических материалах в этом случае 1С рекомендует указывать смешанный режим подключения. Рассмотрим подробно оба режима. Данная информация взята мной из книгиљ издательства "БХВ-Петербург" 'MS SQL Server 2000. Наиболее полное руководство" автор Е. Мамаев, которую я вам рекомендую в качестве настольной по SQL Server 2000.

* - на самом деле режим авторизации "Windows only" также возможен (см. ниже по тексту раздел "1С и режимы авторизации")

Смешанный режим подключения (Mixed Mode, SQL Server and Windows NT / 2000).

В этом режиме возможна авторизация как средствами SQL Server, так и средствами Windows NT / 2000. Рассмотрим вариант авторизации SQL Server (режим авторизации Windows будет рассмотрен далее).

В этом режиме авторизация пользователей производится самим SQL Server. Вся информация о пользователях хранится в системной базе Master. Для каждого пользователя указывается имя учетной записи, уникальный идентификатор SQL Server, пароль и другая информация.

Авторизация SQL Server применяется в основном клиентами, для которых недоступна регистрация в домене Windows NT. Например, пользователям Novell NetWare, Unix и т.д. При подключении к SQL Server через Internet регистрация в домене не выполняется, поэтому в данном случае также необходимо использовать авторизацию SQL Server.

Дополнительно к материалу книги хотел бы отметить еще один важный момент. 1С при подключении к SQL Server может использовать только один логин. Права данного логина (или пользователя) должны позволять 1С производить любые действия с базой данной. Такими правами по умолчанию владеют системные администраторы, а также владельцы базы данных. Чтобы уменьшить риск разрушения данных в других базах, стоит выбирать в качестве такого логина именно владельца базы данных. Если, по причине нарушения безопасности, с базой данных 1С что-то и случится, то это не коснется остальных баз данных, которые управляются данным сервером. Как назначить базе владельца базе данных рассказано в этой статье.

Режим подключения Windows (Windows Authentication Mode, Windows NT / 2000 only)

При авторизации Windows подлинность пользователя проверяется операционной системой. Пользователь автоматически получает права доступа к данным SQL Server сразу же после регистрации в домене. Такой метод предоставления доступа называется установлением доверительного соединения.

Важно! Доверительное соединение в SQL Server 2000 поддерживается только при наличии сетевых библиотек Multiprotocol и Named Pipes.

Операционная система работает с учетными записями (logins), которые содержат все данные о пользователе. Каждая такая запись имеет уникальный идентификатор (login ID) или, как его называют по-другому, идентификатор безопасности (SID, Security Identification), с помощью которого пользователь регистрируется в сети.

Аутентификация Windows NT предусматривает сохранение в системной базе данных Master в SQL Server 2000, только идентификационного номера учетной записи. Остальная информация хранится в базе данных домена. Изменение имени пользователя или его пароля никак не отразится на правах доступа к SQL Server.

Информация об учетной записи считывается SQL Server только при регистрации. Поэтому изменения, которые администратор произвел с ней, отразятся только во время очередной регистрации.

Авторизация Windows NT дает определенные преимущества. На пользователях автоматически отражаются все правила политики безопасности, установленные в домене. Также этот режим упрощает управление правами доступа при наличии нескольких серверов SQL Server. При выполнении запросов на несколько серверов не нужно производить отображение логинов SQL Server.

При авторизации Windows NT следует следить за доверительными отношениями. Если пользователь одного домена подключается к SQL Server в другом домене, то между этими доменами должны быть настроены доверительные отношения.

Если в вашей сети большое количество пользователей, то удобнее будет предоставлять доступ к SQL Server не каждому пользователю, а группе пользователей выбранного домена.

На этом завершим рассмотрение режимов авторизации.

Ссылки по теме.

Enterprise Manager

Server - Properties - Security (выбор режима авторизации)

Server - Security - Loginsљ (управление учетными записями сервера)

Server - Databases - Database - Users (управление пользователями базы данных)

Books Online

Installing SQL Server - Authentication Mode (выбор режима авторизации: коротко)

Administering SQL Server - Managing Security (управление безопасностью)

Administering SQL Server - Managing Security - Authentication Modes (режимы авторизации: подробно)

Как я уже говорил, 1С может подключаться к SQL Server только в случае смешанного режима авторизации. Вернее только этот режим поддерживается при подключении к SQL Server по протоколу TCP/IP. Рассмотрим чем это обусловлено. Прежде всего, подключение возможно только через одну учетную запись, которая указываетсяљ в режиме "Конфигуратор" через меню "Администрирование - Параметры базы данных SQL:". Причем данные поля должны быть обязательно заполнены - иначе выдается сообщение об ошибке (по крайней мере, в 18 релизе это так). В то же время 1С, используя ODBC, создает подключение с помощью функции SQLDriverConnect и для этого передает строку подключения следующего вида:

DRIVER=SQL Server;SERVER=%s;UID=%s;PWD=%s;DATABASE=master;APP=1CV7;UseProcForPrepare=0

Вместо символов %s подставляются имя сервера, пользователь и пароль. Но для подключения в режиме авторизации Windows необходима строка подключения:

DRIVER=SQL Server;SERVER=%s;Trusted_connection=yes;DATABASE=master;APP=1CV7;UseProcForPrepare=0

Поэтому любое имя пользователя, указанное в конфигураторе приведет к ошибке с кодом 18452, которая была приведена выше. Может быть и можно сделать так, чтобы введенное имя пользователя было связано с доверительным соединением. Например, я пробовал записать имя пользователя вместе с доменом - не получилось - выдавалась та же ошибка. Но все равно эти действия не имеют смысла - основная цель авторизации Windows подключение РАЗНЫХ пользователей, но никак не всех под одним логином. Это ограничение можно было бы обойти, если бы в параметрах базы можно было бы указывать пустые параметры. Но как я уже писал выше это не возможно. Здесь мы подходим вплотную к решению проблемы. Мы знаем какую функцию 1С используется для подключения к SQL Server, какая при этом формируется строка и какая строка нам нужна. Эврика! - мы просто меняем эту строку, а находится она в файле bkend.dll. Заменяем ее на строку:

DRIVER=SQL Server;SERVER=%s;UID=;PWD=; DATABASE=master;APP=1CV7;UseProcForPrepare=0

Важно чтобы длина строки оставалась прежней и чтобы она начиналась в файле с того же смещения. Для этого перед словом DATABASE добавляем 4 пробела. Вуаля!

Теперь вы можете поставить авторизацию Windows и наслаждаться. Можно делать такие вещи!љ - аж дух захватывает! Самый простой пример, ограничение определенным пользователям доступа к некоторым таблицам. Дальше дело за вашей фантазией!

Но это еще не все. Данную строку можно переписать по-другому:

DSN=DNS1C; DATABASE=master;APP=1CV7;UseProcForPrepare=0

Опять же нужно соблюсти смещения начала и конца строки. Данная строка позволяет подключаться к SQL Server через источник данных, настроенный на клиенте. Этот способ немного сложнее (нужно настраивать источника на каждом клиенте), но с помощью него можно решить другую проблему - хранение пароля подключения не в файле DBA (который как известно довольно легко расшифровывается), а хранение его средствами операционной системы. Для этого в конфигураторе нужно просто задать имя пользователя, а пароль оставить пустым - теперь-то он хранится в другом месте! Вуаля очередной раз. Плюс небольшой P.S. - в документации для SQL Server 2000 написано, что указание Trusted_connection обязательно, но я проверил это на своей системе - предыдущий метод сработал. Если у вас он работать не будет, то придется использовать данный метод.

Когда будете создавать новых пользователей, то у них не будет никаких прав на данные в базе 1С. Кроме того, что нужно будет выставить эти права, нужно будет также указать роли (для SQL Server 2000, для 7.0 не знаю как): db_datareader, db_datawriter , db_creator. Роль db_creator нужна, так как при старте 1С изменяет некоторые параметры БД (для этого используется ХП sp_dboption, которая в свою очередь использует команду ALTER DATABASE). При установке разрешений на доступ к таблицам и прочая можно запариться ;) - для этого лучше сразу написать скрипт с применением команды GRANT для каждой таблицы, ХП и т.п. Вроде бы все. Не пробовал подключать более двух пользователей (разных). Два одинаковых на моем домашнем компе - работают :).

Обычным образом (то есть без использования хакерских методов) 1С может подключаться в режиме аворизации Windwos только (а может и не только) по протоколу Named Pipes. В этом случае система просто игнорирует имя пользователя и пароль, передаваемые при соединении. Почему это не делается в случае протокола TCP/IP для меня является загадкой. Чтобы такое подключение было возможно желательно, чтобы на сервере был установлен только протокол Named Pipes, либо чтобы он стоял первым в списке в утилитах SQL Server по настройке сетевых протоколов на клиенете и сервере. Если вам это не поможет (так, например, случилось со мной), то нужно просто создать алиас (в SQL Server 2000) с помощью утилиты Client Network Utility, указав что соединение будет производится по протоколу Named Pipes. После этого имя алиаса можно использовать в качестве имени SQL Server и без проблем работать по протоколу Named Pipes. Но. Есть большое "Но" в этом варианте. Использование протокола Named Pipes не рекомендуется по причине его низкой производительности. За мой срок работы с SQL Server я слышал разные комментарии по этому поводу большая часть из них подтверждала это, хотя были и противоположные замечания, в которых указывалось, что использование Named Pipes не снижает производительность работы с SQL Server. Хорошо бы найти четкие экспериментальные подтверждения этому и желательно авторитетные, для меня пока это лишь теоретические предположения.

Под конец хочу дать вам ссылку на еще одну интересную методику. Здесь вы найдете более красивое решение проблемы безопасности, которое не использует хак 1С (в прямом его смысле). Кроме того, этот метод позволяет более гибко настроить ограничения доступа к данным, причем так, что 1С при этом не будет "падать" (если вы будет пользоваться обычной методикой ограничения прав доступа, то 1С при попытке доступа будет "вываливаться" с сообщением об ошибке доступа к данным).

За сим прощаюсь. Безопасных Вам связей!

Шемякин Павел, июль 2002 оригинал на http://1csql.virtualave.net/1csql/