Создание нового пользователя и настройка прав в MySQL
Как работать с пользователями в MySQL: создавать и удалять учетные записи, предоставлять и отзывать привилегии, а также просматривать права доступа.
Эта инструкция — часть курса «MySQL для новичков».
Смотреть весь курс
Введение
В статье речь пойдет о работе с пользователями открытой реляционной системы управления базами данных (СУБД) MySQL, появившейся в 1994 году. В 2008 году Sun Microsystems купил MySQL AB, а в 2010 уже Sun была поглощена Oracle. Эти продажи побудили авторов исходной СУБД создать форк — MariaDB, свободный от лицензионных ограничений текущего владельца и совместимый с Oracle MySQL. Помимо «Марии» известен другой форк, Percona, — от Петра Зайцева и Вадима Ткаченко. Оба форка совместимы с MySQL.
БД от Percona обладает дополнительными функциями, направленными на повышение производительности. Многие дистрибутивы (например, Red Hat) перешли на MariaDB из-за предсказуемой лицензионной политики. В своих проектах автор использует MariaDB.
Есть несколько способов работы с БД MySQL: через графические phpMyAdmin, MySQL WorkBench и т.д.
Поскольку работа с пользователями задача больше административная и нерегулярная, рассмотрим наиболее надежный способ — через консоль.
Для этого понадобится минимум — консольный клиент mysql. Запускать его можно на своей рабочей станции (mysql —host= [—user=] [—password=] [database]) или через ssh на самом сервере (в случае ОС Linux).
Зачем нужны пользователи
После установки MySQL технически мы можем подключаться из нашего ПО от имени root’а, но это не безопасно. Работая с информационными системами, мы всегда должны помнить и соблюдать принцип наименьших привилегий. Для более безопасной работы и создаются пользователи БД. Привилегии должны быть предоставлены пользователю строго только те, что действительно необходимы.
Администратору MariaDB в работе требуется создавать учетные записи «обычных» пользователей с ограниченным доступом к данным, определять права доступа, при необходимости — создавать дополнительных (привилегированных) суперпользователей. Также важно проводить аудит — просматривать выданные полномочия и корректировать их по мере необходимости.
Пользователи MySQL
Имя пользователя MySQL
В MySQL имя пользователя состоит из 2-х частей: имени пользователя (обязательно) и хоста (может быть опущена, тогда она означает ‘%’):
‘someuser’@’somehost’, аналогично, почтовому адресу.
Поняв это правило, посмотрим, как по умолчанию выглядит суперпользователь. На самом деле полностью учетка записывается трижды: ‘root’@’localhost’, ‘root’@’127.0.0.1’ и ‘root’@’::1’ с одинаковым парольным хешем.
В хостовой части могут использоваться DNS-имена, IP-адреса и символ подстановки %, обозначающий любой (любые) символы.
Примеры записи хоста:
somehost.example.com localhost 127.0.0.1 ::1 192.168.123.% 192.168.123.0/255.255.255.0 %Примечание: имена и адреса следует указывать в том формате, в каком возвращает системный DNS resolver сервера.
Просмотр всех пользователей
Давайте проверим, какие пользователи есть в нашей БД. Выведем основную информацию о пользователях:
SELECT host, user, password, password_expired FROM mysql.user;Когда список получается большим, мы можем добавить фильтр (в примере — по хостам, начинающимся с msk):
SELECT host, user, password FROM mysql.user WHERE host LIKE 'msk%';Или использовать в конце модификатор \G, оптимизирующий вывод для отображения в консоли:
SELECT host, user, password FROM mysql.user\G;SELECT * FROM mysql.user[\G];Создание нового пользователя MySQL
Новый пользователь в MySQL добавляется командой:
CREATE USER 'some_user'@'somehost.somedomain' IDENTIFIED BY 'some_password';Теперь давайте создадим нашего первого пользователя:
CREATE USER 'test'@'localhost' IDENTIFIED BY 'secret'; FLUSH PRIVILEGES;Полезная возможность — добавление комментария:
CREATE USER 'test'@'localhost' COMMENT 'My 1st user for app';FLUSH PRIVILEGES
Обратите внимание на эту команду: она дает серверу команду перечитать привилегии. Как следует из документации, команда FLUSH PRIVILEGES в MySQL нужна только в случае прямой модификации таблиц привилегий MySQL операторами типа INSERT, UPDATE или DELETE. Но для простоты запоминания будем указывать ее и для «правильных» операторов таких как GRANT, REVOKE, SET PASSWORD и RENAME USER, как в примере выше и остальных, используемых в статье.
Удаление пользователя MySQL
Для удаления пользователя используется команда
DROP USER 'some_user'@'somehost.somedomain';На нашем предыдущем примере:
DROP USER 'test'@'localhost'; FLUSH PRIVILEGES;Создание дополнительного суперпользователя
Это не лучшая практика, но бывают ситуации, когда у СУБД несколько хозяев и всем нужно быть суперпользователями. В MySQL добавить пользователя с root-правами можно так:
GRANT ALL PRIVILEGES ON *.* TO 'admin'@'%' WITH GRANT OPTION; FLUSH PRIVILEGES;Теперь пользователь root безопасно хранится у нас, а для административной работы с БД мы можем передать коллегам или партнерам учетную запись admin.
Отзыв полномочий у пользователя
Команда отзыва привилегий функционально обратна GRANT, “TO” заменяется на “FROM”:
REVOKE SELECT ON `somedb`.* FROM 'someuser'@'somehost'; REVOKE ALL PRIVILEGES ON `somedb`.* FROM 'someuser'@'somehost'; REVOKE ALL PRIVILEGES, GRANT OPTION FROM 'someuser'@'somehost';Смена пароля
Для изменения пароля учетной записи пользователя применяется команда ALTER USER:
ALTER USER 'test_user'@'localhost' IDENTIFIED BY 'new_password';Предоставление доступа пользователю MySQL
Доступ предоставляется командой:
GRANT SELECT ON `some_db`.* TO 'some_user'@'somehost.somedomain'; FLUSH PRIVILEGES;Допустим, наше ПО использует базу данных test_db. Для его работы мы создали пользователя test_user, а FQDN хоста, где работает ПО — наш локальный хост (localhost). Наше приложение только считывает данные из БД — выполняет SELECT.
Создадим пользователя и БД (часто БД называют схемой, в терминах MySQL):
CREATE SCHEMA test_DB; CREATE USER 'test_user'@'localhost' IDENTIFIED BY 'secret';Команда для предоставления доступа будет выглядеть так:
GRANT SELECT ON `test_db`.* TO 'test_user'@'localhost'; FLUSH PRIVILEGES;Наследование привилегий
В предыдущем примере наш пользователь сможет только читать данные из базы test_db, но передать свои права другому пользователю не сможет. Используя GRANT OPTION, мы можем позволить ему сделать это. Тогда пользователь получит возможность передавать другим то, что разрешено ему самому.
GRANT SELECT, INSERT, UPDATE, DELETE ON `some_db`.* TO 'some_user'@'somehost' WITH GRANT OPTION;В этом примере some_user может поделиться правами на SELECT, INSERT, UPDATE, DELETE для базы some_db.
Из соображений безопасности использовать GRANT OPTION небезопасно! В случае компрометации учетной записи злоумышленник сможет не только получить доступ к данным, но и сделать закладку в виде копии учетной записи.
Доступ к таблице
Примеры выше дают доступ ко всей БД. Часто доступ должен быть ограничен строго определенным набором таблиц:
GRANT SELECT ON `test_db`.`table_users` TO 'test_user'@'localhost';Выполнение команды приведет к ошибке, т.к. этой таблицы еще нет.
CREATE TABLE `test_db`.`table_users` (id INT AUTO_INCREMENT PRIMARY KEY, user_name VARCHAR(16) NOT NULL, password VARCHAR(32));и повторим предоставление доступа:
GRANT SELECT ON `test_db`.`table_users` TO 'test_user'@'localhost';Доступ к столбцу
Предоставляется перечислением столбцов:
GRANT SELECT (id, user_name), UPDATE (user_name) ON `test_db`.`table_users` TO 'test_user'@'localhost';В этом примере пользователю дано право читать идентификатор, читать и менять имя пользователя, а парольный хэш доступен не будет.
Просмотр привилегий пользователей MySQL
Часто возникает задача выяснить полномочия учетной записи или определить, кому дан доступ к базе или таблице. Остановимся на этом подробнее.
Проверка текущих полномочий пользователя
Нам пригодится команда:
SHOW GRANTS FOR 'someuser'@'somehost.somedomain';SHOW GRANTS FOR 'appuser'@'srv14.example.com'; +--------------------------------------------------------------------------------------------------------------------------------+ | Grants for appuser@srv14.example.com | +--------------------------------------------------------------------------------------------------------------------------------+ | GRANT USAGE ON *.* TO 'appuser'@'srv14.example.com' IDENTIFIED BY PASSWORD '*F4E0A7F0B10264F70558CF07A4ABD4E041182D6E' | | GRANT SELECT ON `net_database`.* TO 'appuser'@'srv14.example.com' | +--------------------------------------------------------------------------------------------------------------------------------+ 2 rows in set (0.00 sec)Проверка полномочий к данным
Через read-only БД information_schema доступно множество метаданных — системной информации. Информация о доступе на БД (схемы), таблицы и столбцы доступны в таблицах schema_privileges, table_privileges и column_privileges. Работа с ними — обычные SQL-запросы:
SELECT * FROM information_schema.schema_privileges; SELECT * FROM information_schema.table_privileges; SELECT * FROM information_schema.column_privileges; SELECT * FROM information_schema.column_privileges WHERE GRANTEE="'test_user'@'localhost'";MariaDB [information_schema]> select * from information_schema.column_privileges WHERE GRANTEE="'test_user'@'localhost'"; +-------------------------+---------------+--------------+------------+-------------+----------------+--------------+ | GRANTEE | TABLE_CATALOG | TABLE_SCHEMA | TABLE_NAME | COLUMN_NAME | PRIVILEGE_TYPE | IS_GRANTABLE | +-------------------------+---------------+--------------+------------+-------------+----------------+--------------+ | 'test_user'@'localhost' | def | test_db | table_usr | id | INSERT | NO | | 'test_user'@'localhost' | def | test_db | table_usr | user_name | UPDATE | NO | +-------------------------+---------------+--------------+------------+-------------+----------------+--------------+ 2 rows in set (0.001 sec)Просмотр привилегий через системную БД mysql
Аналогичных результатов можно добиться, обратившись к системным таблицам напрямую.
Информация о пользователях:
SELECT * FROM mysql.user;Привилегии на базы данных:
SELECT * FROM mysql.db;Права, назначенные на таблицы:
SELECT * FROM mysql.tables_priv; SELECT * FROM mysql.columns_priv;
Просмотр глобальных привилегий
Глобальные полномочия смотрим здесь:
SELECT * FROM information_schema.user_privileges;Заключение
Полученная информация поможет выполнить базовые операции при работе с пользователями: создание и удаление учетных записей, предоставление и отзыв привилегий, а также просмотр прав доступа.
При выдаче прав избегайте избыточности. Права не нужно выдавать с запасом, часто выполнение GRANT ALL PRIVILEGES ON *.* TO ‘myUser’@’%’ — не лучший выход. Другой важный момент, часто упускаемый из виду новичками, — наличие в имени хостовой части. Игнорирование хоста может привести к ошибкам.
Всем высоких скоростей, безаварийной работы и долгого аптайма!
Как создавать таблицы в MySQL (Create Table)
SQL пользователь с ограниченным доступом
После восстановления базы MS SQL можем получить такую ошибку Для решения этой проблемы мы должны выполнить команду в консоли
USE test ALTER DATABASE test SET SINGLE_USER WITH ROLLBACK IMMEDIATE GO ALTER DATABASE test SET MULTI_USER GO 
Нужна помощь?
Если у Вас возникли трудности и Вы не можете справиться самостоятельно, наши специалисты готовы оказать удаленную помощь. HELP
Эту и другие технические статьи написали наши программисты 1С и получили за них премии. Если вы тоже работаете с 1С и любите делиться опытом, приходите разработчиком в МИТ
Наши сервисы по этой теме:
Линия консультаций 1С
Консультации по телефону и электронной почте дают специалисты службы технической поддержки по «1С:Предприятию» и обслуживающего партнера
Блокировка доступа к данным в SQL Server
Иногда возникает необходимость ограничения доступа ряду сотрудников к определенной информации, хранящейся в базе банных. Я предлагаю познакомиться с одной из функций SQL Server, которая позволяет контролировать доступ к уровню строк в таблице базы данных в зависимости от пользователя, выполняющего запрос.
Безопасность на уровне строк (Row-Level Security, RLS) ограничивает пользователей таким образом, чтобы они могли работать исключительно с теми данными, к которым у них имеется доступ. Кроме того, данная функция не дает возможности пользователям вставлять, обновлять или удалять данные, доступ к которым запрещен.
Давайте рассмотрим, как можно использовать функцию Row-Level Security на примере условной таблицы, назовем ее ObjectCheck, в которой отражена информация об объектах аудита, сроках начала и завершения проверок и т.д.
Перед нами поставлена задача: каждый пользователь базы данных должен получить доступ к данным, относящимся только к нему, без доступа к проверкам, назначенным другим сотрудникам.
Для выполнения примера создадим трех пользователей базы данных:
create user Ivanovii without login; create user PetrovPP without login; create user SidorovSS without login;
предоставим доступ select к таблице ObjectCheck для этих пользователей:
grant select on ObjectCheck to Ivanovii; grant select on ObjectCheck to PetrovPP; grant select on ObjectCheck to SidorovSS;
Кроме того, желательно создать отдельную схему для объектов базы данных Row-Level Security:
create schema rs; GO
Ограничение доступа к данным с использованием Row-Level Security достигается путем определения предиката безопасности (Security predicate) как функции, которая ограничивает строки на основе логики фильтрации, которая вызывается и применяется политикой безопасности (Security Policy), созданной с помощью T-SQL оператора create security policy, и работает как контейнер предикатов.
Давайте выполним настройку функции безопасности на уровне строк для таблицы ObjectCheck.
Создаем функцию, зависящую от пользователей, вошедших в систему, чтобы была возможность фильтровать пользователей и проверять их доступы к данным:
create function rs.fn_secureData(@Username as sysname) returns table with schemabinding as return select 1 as ‘secureObjectCheck’ where @Username = User_Name();
Создадим политику безопасности в таблице ObjectCheck, используя ранее созданную функцию предиката:
create security policy Object_Check add filter predicate rs.fn_secureData(User) on dbo.ObjectCheck with (state = on);
Теперь защита на уровне строк настроена и готова к фильтрации доступа к данным в таблице ObjectCheck.
Так, если выполнить запрос, указав пользователя Ivanovii:
execute as user = ‘Ivanovii’; select * from ObjectCheck; revert;
то запрос вернет только две записи, связанные с пользователем Ivanovii:
Аналогичный результат будет возвращен при запросе данных из таблицы ObjectCheck пользователями PetrovPP и SidorovSS:
execute as user = ‘PetrovPP’; select * from ObjectCheck; revert;
execute as user = ‘SidorovSS’; select * from ObjectCheck; revert;
Из приведенных примеров видно, что функция безопасности на уровне строк может использоваться для фильтрации данных, которые может видеть каждый пользователь, в зависимости от критериев фильтрации, определенных в функции предиката.
Если необходимо прекратить использование функции безопасности rs.fn_SecureData, то можно отключить политику безопасности Object_Check с помощью инструкции ALTER security policy:
alter security policy Object_Check with (state = off)
Затем выполнить запрос DROP для удаления функции и политики безопасности:
drop security policy Object_Check drop function rs.fn_secureData
Теперь безопасность на уровне строк полностью удалена из таблицы Object_Check.
Можно легко добавлять предикаты и критерии фильтрации, подходящие для определенных ситуаций, однако, слишком сложные предикаты ухудшают производительность базы данных, поскольку предикат будет проверяться каждый раз при выполнении доступа к данным. Более подробно ознакомиться с Row-Level Security можно на сайте Microsoft.
MSSQLSERVER_4064
Имя входа SQL Server не удалось подключиться к SQL Server, либо из-за проблем с разрешением пользователя базы данных, связанного с именем входа в базе данных по умолчанию, либо с проблемой со своей базой данных по умолчанию.
Проблемы с разрешениями могут быть одним или несколькими из следующих:
- Имя входа не имеет соответствующего сопоставленного пользователя в базе данных по умолчанию.
- Вы назначили базу данных по умолчанию для входа, но не создали сопоставление пользователей в указанной базе данных.
- Сопоставленный пользователь для имени входа был отказано в доступе. (Например, это может произойти, если пользователь непреднамеренно добавляется в предопределенную роль базы данных db_denydatareader .)
База данных по умолчанию может быть недоступна во время подключения по следующим причинам:
- База данных по умолчанию находится в режиме подозрения.
- База данных по умолчанию больше не существует.
- База данных по умолчанию находится в однопользовательском режиме, и единственное доступное подключение уже используется кем-то или другим.
- База данных по умолчанию отключена.
- База данных по умолчанию имеет состояние RESTRICTED_USER.
- База данных по умолчанию находится в автономном режиме.
- Для базы данных по умолчанию задано состояние ЭКСТРЕННОГО РЕАГИРОВАНИЯ.
- База данных по умолчанию является частью зеркального отображения базы данных.
Кроме того, учетная запись входа может быть членом нескольких групп, а база данных по умолчанию для одной из этих групп недоступна во время подключения.
Дополнительные сведения о пользователях базы данных в SQL Server см. в разделе «Создание пользователя базы данных».
Действие пользователя
Вы можете выполнить одно из следующих действий:
Обход проблемы
Если вам не нужно получить доступ к текущей настроенной базе данных по умолчанию и вам просто нужно подключиться к экземпляру SQL Server для других операций с помощью SQL Server Management Studio (SSMS), выполните следующие действия:
- Откройте SQL Server Management Studio (SSMS).
- В обозревателе объектов выберите «Подключить>ядро СУБД».
- Заполните диалоговое окно «Подключение к серверу «.
- Выберите Параметры.
- В разделе «Свойства подключения» измените значение подключения к базе данных с помощью одного из следующих параметров:
- Если имя входа является членом роли sysadmin, введите master и выберите «Подключиться «, чтобы установить подключение к SQL Server. После успешного подключения к SQL Server можно изменить базу данных по умолчанию на другую, которая в настоящее время доступна на странице «Общие » свойств входа в SSMS. Дополнительные сведения см. в разделе Создание имени входа.
- Если имя входа не является членом роли sysadmin, введите имя базы данных на сервере, к которому у вас есть доступ. Кроме того, можно попробовать ввести имя системной базы данных, например master , а затем нажмите кнопку «Подключить». Этот шаг может не работать, если системный администратор явно отказался от разрешений гостевого master пользователя в базе данных. В этом сценарии необходимо работать с системным администратором, чтобы устранить проблему.
Устранение проблемы
Системный администратор может проверить, является ли текущая база данных по умолчанию пользователя, с помощью следующего запроса:
SELECT name, default_database_name FROM sys.server_principals WHERE type = 'S' AND name = ''; Используйте следующую таблицу, чтобы определить соответствующее действие для устранения проблемы для связанных причин:
| Причина | Решение |
|---|---|
| В базе данных по умолчанию для входа не существует сопоставления пользователей или пользователь был отказано в доступе. | Эти пользователи базы данных также называются потерянными пользователями. Эта проблема обычно возникает при перемещении баз данных между двумя экземплярами сервера и является одной из распространенных причин ошибки 4064. Сведения об обнаружении потерянных пользователей и устранении этой проблемы см. в статье «Устранение неполадок потерянных пользователей (SQL Server)». |
| Для входа не существует пользователя базы данных | Создайте пользователя базы данных и назначьте соответствующие разрешения для доступа к базе данных. |
| Учетные записи пользователя базы данных запрещены разрешения на доступ к базе данных | Перейдите к свойствам пользователя в базе данных (разверните пользователей системы безопасности > узла> базы данных) и проверьте, является ли пользователь частью db_denydatareader роли на странице членства. Вы также можете проверить действующие разрешения пользователя с помощью sys.fn_my_permissions. |
| База данных по умолчанию находится в режиме подозрения. | База данных может перейти в состояние SUSPECT по нескольким причинам. Возможные причины включают отказ в доступе к ресурсу базы данных операционной системой и недоступность или повреждение одного или нескольких файлов базы данных. Вы можете проверить состояние базы данных с помощью этого запроса: SELECT DATABASEPROPERTYEX (N», N’STATUS’) AS N’Database Status’; В SSMS состояние подозрительных баз данных отображается как (ожидание восстановления). Чтобы устранить эту ситуацию, может потребоваться восстановить базу данных из резервной копии. |
| База данных по умолчанию больше не существует. | Если вы намеренно удалили базу данных с сервера, измените базу данных по умолчанию для входа на другую существующую базу данных на сервере с помощью SSMS или инструкции ALTER LOGIN (Transact-SQL). При необходимости может потребоваться проверить наличие других имен входа на сервере, для которой для базы данных по умолчанию задана эта не существующая база данных с помощью этого запроса: SELECT name AS Login_Name FROM sys.server_principals where default_database_name = »; |
| База данных по умолчанию находится в однопользовательском режиме, а единственное подключение используется администратором или другим пользователем. | Если для целей обслуживания для базы данных задан режим с одним пользователем, его следует вернуть в режим с несколькими пользователями после завершения действия обслуживания, используя следующий запрос: ALTER DATABASE SET MULTI_USER; Дополнительные сведения см. в разделе «Настройка базы данных в однопользовательском режиме». Примечание. Чтобы проверить, находится ли база данных в однопользовательском режиме, можно использовать следующий запрос: SELECT name, user_access_desc FROM sys.databases WHERE name = »; Если вам по-прежнему нужно ограничить доступ к базе данных, но хотите включить подключение к затронутым именам входа, измените базу данных по умолчанию на другую базу данных на сервере. |
| База данных по умолчанию отключена. | Отключение базы данных удаляет ее из экземпляра SQL Server и больше не доступно. Чтобы сделать его доступным для входа, подключите базу данных с помощью SSMS или sp_attach_db хранимой процедуры. Дополнительные сведения см. в разделе «Отсоединение базы данных» и «Подключение» (SQL Server). |
| Для базы данных по умолчанию задано состояние RESTRICTED_USER. | Если для базы данных задано состояние RESTRICTED_USER, только члены предопределенных ролей базы данных db_owner, а также предопределенных ролей сервера dbcreator и sysadmin могут подключаться к базе данных. Если вам больше не нужно ограничивать доступ к соответствующей базе данных, задайте для базы данных многопользовательский режим, используя следующий запрос: ALTER DATABASE SET MULTI_USER; Примечание. Чтобы проверить, находится ли база данных в состоянии ограниченного пользователя, можно использовать следующий запрос: SELECT name, user_access_desc FROM sys.databases WHERE name = »; Если вам по-прежнему нужно ограничить доступ к базе данных, но хотите включить подключение к затронутым именам входа, измените базу данных по умолчанию на другую базу данных на сервере. |
| База данных по умолчанию находится в автономном режиме. | Невозможно изменить базу данных, которая находится в автономном состоянии. Вы можете перевести базу данных в режим «в сети», используя следующий запрос: ALTER database SET ONLINE; Можно проверить, является ли база данных автономной либо с помощью SSMS, либо с помощью этого запроса: SELECT DATABASEPROPERTYEX (N», N’STATUS’) AS N’Database Status’; Дополнительные сведения см. в разделе «Состояния базы данных» и параметры ALTER DATABASE SET (Transact-SQL) — SQL Server. Если необходимо сохранить базу данных в автономном состоянии, но хотите включить подключение к затронутым именам входа, измените базу данных по умолчанию на другую базу данных на сервере. |
| Для базы данных по умолчанию задано состояние ЭКСТРЕННОГО РЕАГИРОВАНИЯ. | Возможно, база данных была помещена в состояние аварийного реагирования для устранения неполадок системным администратором. Только пользователи роли sysadmin могут получить доступ к базам данных, заданным для состояния ЧРЕЗВЫЧАЙНОЙ СИТУАЦИи. Вы можете перевести базу данных в режим «в сети», используя следующий запрос: ALTER database SET ONLINE; Можно проверить, находится ли база данных в состоянии аварийного реагирования с помощью SSMS или этого запроса: SELECT DATABASEPROPERTYEX (N», N’STATUS’) AS N’Database Status’; Дополнительные сведения см. в разделе «Состояния базы данных» и параметры ALTER DATABASE SET (Transact-SQL). Если вам по-прежнему нужно сохранить базу данных в состоянии АВАРИЙНОго реагирования, но хотите включить подключение к затронутым именам входа, измените базу данных по умолчанию на другую базу данных на сервере. |
| База данных по умолчанию является частью зеркального отображения базы данных. | Вы не можете подключиться к зеркальной базе данных на зеркальном сервере, и это поведение выполняется путем проектирования. Чтобы проверить, находится ли база данных в зеркальной роли, используйте этот запрос SELECT DB_NAME(database_id) as database_name, mirroring_role_desc FROM sys.database_mirroring WHERE DB_NAME(database_id) = »; . Дополнительные сведения о зеркальных отображениях баз данных см. в разделе «Зеркальное отображение базы данных» (SQL Server). |
| Учетная запись входа может быть членом нескольких групп, а база данных по умолчанию для одной из групп недоступна во время подключения. | Чтобы перечислить группы с указанным пользователем с помощью PowerShell, см. статью Get-ADPrincipalGroupMembership (ActiveDirectory). |
Изменение базы данных по умолчанию для данного пользователя
Чтобы внести изменения в базу данных пользователя по умолчанию, необходимо иметь разрешение ALTER ANY LOGIN. Если измененное имя входа является членом предопределенных ролей сервера sysadmin или участника разрешения CONTROL SERVER, при внесении следующих изменений также требуется разрешение CONTROL SERVER. Члены роли sysadmin имеют эти разрешения по умолчанию. Дополнительные сведения см. в разделе ALTER LOGIN (Transact-SQL).
- Среда SQL Server Management Studio
- Служебная программа sqlcmd
- PowerShell
Изменение базы данных по умолчанию с помощью SSMS
- Подключитесь к экземпляру SQL Server с помощью SQL Server Management Studio (SSMS).
- Выберите «Имена входа безопасности> «, чтобы найти пользователя и изменить базу данных пользователя по умолчанию на другую, которая в настоящее время доступна на странице «Общие» свойств входа в SSMS. Дополнительные сведения см. в разделе Создание имени входа.
- После подключения к экземпляру SQL Server можно выполнить инструкцию ALTER LOGIN , как показано в следующих примерах: ALTER LOGIN WITH DEFAULT_DATABASE = ; — это заполнитель для имени существующей базы данных, к которым можно получить доступ с помощью имени входа SQL Server в экземпляре. — заполнитель для входа SQL Server с необходимыми ALTER LOGIN разрешениями. Например:
ALTER LOGIN [SQLLogin] WITH DEFAULT_DATABASE = master; ALTER LOGIN [Constoso\Windowslogin] WITH DEFAULT_DATABASE = [AdventureWorks]; Изменение базы данных по умолчанию с помощью служебной программы sqlcmd
Чтобы изменить базу данных по умолчанию, можно использовать следующую процедуру, используя служебную программу sqlcmd:
- На компьютере под управлением SQL Server нажмите кнопку «Пуск», а затем нажмите кнопку «Запустить«, введите и нажмите клавишу ВВОД cmd .
- Подключитесь к SQL Server с помощью служебной программы sqlcmd и одного из следующих параметров:
- Если вы хотите использовать проверку подлинности Windows для подключения к экземпляру с помощью учетной записи пользователя Windows, вошедшего в систему, введите следующую команду в окне командной строки и нажмите клавишу ВВОД: sqlcmd -E -S -d master Например:
sqlcmd -S "contoso\sql22" -E -d master sqlcmd -S contososql -U sqladmin -P
ALTER LOGIN [SQLLogin] WITH DEFAULT_DATABASE = master; ALTER LOGIN [Constoso\Windowslogin] WITH DEFAULT_DATABASE = [AdventureWorks]; Изменение базы данных по умолчанию с помощью PowerShell
Для обновления базы данных по умолчанию для указанного имени входа можно использовать следующий скрипт PowerShell.
# Define the variables for the SQL Server instance name and login name $instanceName = "YOUR_SQL_SERVER_INSTANCE_NAME" $loginName = "YOUR_SQL_SERVER_LOGIN_NAME" $newDefaultDB = "YOUR_NEW_DEFAULT_DATABASE" # Connect to the SQL Server instance $connectionString = "Server=$instanceName;Integrated Security=True" $connection = New-Object System.Data.SqlClient.SqlConnection($connectionString) $connection.Open() # Execute a T-SQL command to change the default database for the specified login $tsql = "ALTER LOGIN $loginName WITH DEFAULT_DATABASE = $newDefaultDB" $command = New-Object System.Data.SqlClient.SqlCommand($tsql, $connection) $command.ExecuteNonQuery() # Print a message indicating the update was successful Write-Host "The default database for the login '$loginName' has been successfully updated to '$newDefaultDB'" # Close the SQL Server connection $connection.Close() Ошибка 18456 отображается вместе с ошибкой 4064
При использовании таких приложений, как SSMS, которые получают ошибку 4064, отображаемой пользователю, в журнал ошибок SQL Server регистрируется следующее сообщение. В этом весь замысел. Исправление базы данных по умолчанию для неудачного входа с помощью процедур, описанных в этой статье, автоматически устраняет ошибку 18456.
2023-02-06 18:17:02.56 Logon Error: 18456, Severity: 14, State: 40. 2023-02-06 18:17:02.56 Logon Login failed for user '. Reason: Failed to open the database '' specified in the login properties. [CLIENT: ] Обратная связь
Были ли сведения на этой странице полезными?