Как предоставить доступ к MS SQL пользователям из AD?

Question

[ITF]

Как сделать что бы к MS SQL можно было настраивать пользователей и доступы к базам через AD?

Answer 1

[zhaar]

MSSQL по умолчанию так умеет - в разделе security нужно добавить пользователя, введя его логин из AD с учетом домена domain\user1 и назначив ему требуемые права.
Пользователь у себя на машине запускает приложение\студию, выбирает авторизацию через AD и сразу подключается, даже не требуя ввода пароля.

Comments

[ITF]

Добавил. Вроде зашло, но например хочу прописать подключение к базе на сервере 1С под этим пользователем - не работает.
Т.е. что бы не через sa подключать.
Что-то вроде MSA учетной записи.

[Довольный Айтишникъ]

ITF, 1с не умеет доменные учетки, только sa и им подобные

[ITF]

Довольный Жизнью, 1C сервер?
Имеется ввиду в кластере когда базы прописываешь нужно указать сервер БД, базу, логин и пароль

[ITF]

И находил статью, старую, там на примере Win2K сервера, делали публикацию сервера MS SQL в AD, что бы через групповые политики можно было назначать доступ пользователям к базам.

[ITF]

зашел на сервер под domain\user1 - ни Аутентификация Windows, ни AD-пароль не пускают.
Выдает ошибку "Ошибка входа пользователя" 18456.
Или, если поставить галочку шифрования: "Цепочка сертификатов выпущена центром сертификации, не имеющим доверия"

[unfilled]

ITF, c 1С, если вы хотите, чтобы сервер 1С подключался к MS SQL Server под доменной учётной записью, есть только один вариант: запустить сам сервер 1С под доменной учёткой, дать этой учётке права на подключение к SQL Server и в свойствах ИБ оставить поля "Пользователь СУБД" и "Пароль пользователя СУБД" (ну или как там они называются) пустыми.

[ITF]

unfilled, вот, тут и возникает проблема, что MS SQL не пускает пользователя заведенного в AD, хотя в пользователях MS SQL он так же присутствуют, у него стоят права на подключение и у него стоят права на базы данных (db_owner, db_creator)

[ITF]

Вообще в идеале хотелось бы иметь возможность заводить в целом в MS SQL пользователей через AD, т.е. под разные сервисы, и там же указывать базы на которые доступ есть.
Но как понял сейчас это решается только на уровне скриптов, без какого-либо готового инструмента?
Ну и для начала хоть одного AD-шного пользователя авторизовать в MS SQL -_-

[unfilled]

ITF, т.е. в Security->Logins в SSMS вы видите пользователя domain\user1, под domain\user1 запускаете ssms, выбираете win-авторизацию и вас не пускает?
Под sa (или любым другим SQL-логином) можете с этой машины под этим доменным пользователем зайти?
Какое полное сообщение об ошибке?

[ITF]

unfilled, все верно, вижу пользователя но зайти не могу.
Тип авторизации смешанный.
Под SA заходит.

зашел на сервер под domain\user1 - ни Аутентификация Windows, ни AD-пароль не пускают.
Выдает ошибку "Ошибка входа пользователя" 18456.
Или, если поставить галочку шифрования: "Цепочка сертификатов выпущена центром сертификации, не имеющим доверия

Центр сертификации не разворачивал, никаких сертификатов никуда не устанавливал.

[unfilled]

ITF, Приведите полный текст ошибки, или скриншот. В качестве проверки подлинности в SSMS должно быть выбрано "Проверка подлинности Windows"

Вообще в идеале хотелось бы иметь возможность заводить в целом в MS SQL пользователей через AD, т.е. под разные сервисы, и там же указывать базы на которые доступ есть.
Но как понял сейчас это решается только на уровне скриптов, без какого-либо готового инструмента?

SSMS, Security->Logins ПКМ, добавить пользователя. Чем не инструмент? Или вы хотите им прямо из AD разрешать логиниться к SQL Server? Тогда можно, теоретически, на группы создавать логины и включать в них нужных пользователей.
Попробуйте, кстати, в SSMS пересоздать своего проблемного domain\user1.

[ITF]

unfilled, не, имеется ввиду, как писал выше, регистрация серверов и БД в AD, но на свежие версии найти подобного не могу.

Проблемный юзер сам по себе не проблемный, т.к. и пересоздавал, и заводил другого. Ошибка одна и та же.
Заходить пытаюсь с самого сервера MS SQL, он в домене. Под пользователями SQL сервера заходит, под пользователями Windows/AD - нет.

По ошибкам гуглил, в одном случае советуют проверить роль для подключению к серверу (она стоит), в другой кому-то добавить сертификат в доверенные, но где кому и как так и не нашел.

[ITF]

Пытаюсь зайти так:

Вот ошибки с разными галками:

[MedicineMan]

ITF, получилось решить?

[ITF]

MedicineMan, нет.
1. Ничего подобного не нашел, только если скриптами добавлять пользователей входа. Но как таковой информации о регистрации именно баз или серверов MsSQL в AD не увидел.
2. Разумеется зайдя под одной учетной записью на сервер, например по RDP, от имени другой учётной записи из AD он у меня не авторизует, т.к. остается либо SQL-авторизация, либо Windows (запись под которой зашёл). Авторизация которая пишется как "Пользователь AD" - это как я понял для работы через облако (Azure)

Но малую часть хотелок реализовать получилось. Например 1С сервер имеет доступ к БД под учёткой из AD (gMSA).
В ручную завел пользователя (gMSA) в MsSQL для входа, раскидал ему нужные права на нужные базы (в последствии скриптами автоматизирую). Под этой же учёткой запускаю 1С сервер.
Логика такая: если при прописывании информационных баз логин и пароль пустой, то запрос в MsSQL сервер стучится под той учёткой под которой запущен 1С-сервер (служба), а вот она уже AD видит.

[MedicineMan]

ITF, жаль конечно. спасибо за ответ!
У меня задача банальная. Есть этот сервер в домене и к нему нужно пустить сторонних разработчиков. Ясное дело, зачем им подключаться к нему по рдп, если просто каждый в своей студии может добавить себе эту базу. Не охота создавать им пользователей в самом mssql...

[zhaar]

MedicineMan, Так разработчики внутри домена или нет? Если снаружи, то и не получится.

[MedicineMan]

zhaar, компьютеры с которых они подключаются не в домене. доменные учетки у них есть. они могут подключиться по рдп к серверу, запустить студию и работать с базой, но это не удобно, а вот добавить базу себе в студию с доменной учеткой они не могут.

[MedicineMan]

zhaar, проверка подлинности - Active Directory - Password

[zhaar]

MedicineMan, мммм, все равно, ни разу в своей практике не сталкивался с тем, что к БД пытались подключиться под доменной учеткой вне домена.
Только что попробовал аналогичным способом подключиться к серверу, тоже получил ошибку про сертификат.

Попробуй еще указывать порт в адресе подключения, а так же в доп. параметрах: TrustServerCertificate=True;

[MedicineMan]

zhaar, пробовал. ошибки. Аутентификацию при помощи Active Directory можно прикрутить ко многим вещам. Скажем так, компьютер не в домене, но учетка пользователя то доменная. Какая ему разница? Он же на компьютер не смотрит. Подключится по рдп можно, а к MSSQL нельзя если не логинишься в систему, притом что пользователь добавлен и все права ему даны.

[zhaar]

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

[ITF]

MedicineMan, как я писал ранее, "Active Directory - пароль" под облачную (Azure) инфраструктуру . По крайне мере у Mircosoft на сайте так написано. Поэтому дальше мучаться не стал.

Answer 2

[CityCat4]

Через оснастку "Пользователи и компьютеры"? Никак. AD ничего не знает о наличии или отстутствии на некотором сервере некоторых БД. Управление правами делается из студии - вот там можно доменный логин добавить.

Comments

[ITF]

Вот кстати статья которая побудила меня задать такой вопрос:
https://www.osp.ru/winitpro/2004/05/177064

А пользователя из АД руками добавил - не заходит.