MSSQL по умолчанию так умеет - в разделе security нужно добавить пользователя, введя его логин из AD с учетом домена domain\user1 и назначив ему требуемые права.
Пользователь у себя на машине запускает приложение\студию, выбирает авторизацию через AD и сразу подключается, даже не требуя ввода пароля.
Добавил. Вроде зашло, но например хочу прописать подключение к базе на сервере 1С под этим пользователем - не работает.
Т.е. что бы не через sa подключать.
Что-то вроде MSA учетной записи.
И находил статью, старую, там на примере Win2K сервера, делали публикацию сервера MS SQL в AD, что бы через групповые политики можно было назначать доступ пользователям к базам.
зашел на сервер под domain\user1 - ни Аутентификация Windows, ни AD-пароль не пускают.
Выдает ошибку "Ошибка входа пользователя" 18456.
Или, если поставить галочку шифрования: "Цепочка сертификатов выпущена центром сертификации, не имеющим доверия"
ITF, c 1С, если вы хотите, чтобы сервер 1С подключался к MS SQL Server под доменной учётной записью, есть только один вариант: запустить сам сервер 1С под доменной учёткой, дать этой учётке права на подключение к SQL Server и в свойствах ИБ оставить поля "Пользователь СУБД" и "Пароль пользователя СУБД" (ну или как там они называются) пустыми.
unfilled, вот, тут и возникает проблема, что MS SQL не пускает пользователя заведенного в AD, хотя в пользователях MS SQL он так же присутствуют, у него стоят права на подключение и у него стоят права на базы данных (db_owner, db_creator)
Вообще в идеале хотелось бы иметь возможность заводить в целом в MS SQL пользователей через AD, т.е. под разные сервисы, и там же указывать базы на которые доступ есть.
Но как понял сейчас это решается только на уровне скриптов, без какого-либо готового инструмента?
Ну и для начала хоть одного AD-шного пользователя авторизовать в MS SQL -_-
ITF, т.е. в Security->Logins в SSMS вы видите пользователя domain\user1, под domain\user1 запускаете ssms, выбираете win-авторизацию и вас не пускает?
Под sa (или любым другим SQL-логином) можете с этой машины под этим доменным пользователем зайти?
Какое полное сообщение об ошибке?
unfilled, все верно, вижу пользователя но зайти не могу.
Тип авторизации смешанный.
Под SA заходит.
зашел на сервер под domain\user1 - ни Аутентификация Windows, ни AD-пароль не пускают.
Выдает ошибку "Ошибка входа пользователя" 18456.
Или, если поставить галочку шифрования: "Цепочка сертификатов выпущена центром сертификации, не имеющим доверия
Центр сертификации не разворачивал, никаких сертификатов никуда не устанавливал.
ITF, Приведите полный текст ошибки, или скриншот. В качестве проверки подлинности в SSMS должно быть выбрано "Проверка подлинности Windows"
Вообще в идеале хотелось бы иметь возможность заводить в целом в MS SQL пользователей через AD, т.е. под разные сервисы, и там же указывать базы на которые доступ есть.
Но как понял сейчас это решается только на уровне скриптов, без какого-либо готового инструмента?
SSMS, Security->Logins ПКМ, добавить пользователя. Чем не инструмент? Или вы хотите им прямо из AD разрешать логиниться к SQL Server? Тогда можно, теоретически, на группы создавать логины и включать в них нужных пользователей.
Попробуйте, кстати, в SSMS пересоздать своего проблемного domain\user1.
unfilled, не, имеется ввиду, как писал выше, регистрация серверов и БД в AD, но на свежие версии найти подобного не могу.
Проблемный юзер сам по себе не проблемный, т.к. и пересоздавал, и заводил другого. Ошибка одна и та же.
Заходить пытаюсь с самого сервера MS SQL, он в домене. Под пользователями SQL сервера заходит, под пользователями Windows/AD - нет.
По ошибкам гуглил, в одном случае советуют проверить роль для подключению к серверу (она стоит), в другой кому-то добавить сертификат в доверенные, но где кому и как так и не нашел.
MedicineMan, нет.
1. Ничего подобного не нашел, только если скриптами добавлять пользователей входа. Но как таковой информации о регистрации именно баз или серверов MsSQL в AD не увидел.
2. Разумеется зайдя под одной учетной записью на сервер, например по RDP, от имени другой учётной записи из AD он у меня не авторизует, т.к. остается либо SQL-авторизация, либо Windows (запись под которой зашёл). Авторизация которая пишется как "Пользователь AD" - это как я понял для работы через облако (Azure)
Но малую часть хотелок реализовать получилось. Например 1С сервер имеет доступ к БД под учёткой из AD (gMSA).
В ручную завел пользователя (gMSA) в MsSQL для входа, раскидал ему нужные права на нужные базы (в последствии скриптами автоматизирую). Под этой же учёткой запускаю 1С сервер.
Логика такая: если при прописывании информационных баз логин и пароль пустой, то запрос в MsSQL сервер стучится под той учёткой под которой запущен 1С-сервер (служба), а вот она уже AD видит.
ITF, жаль конечно. спасибо за ответ!
У меня задача банальная. Есть этот сервер в домене и к нему нужно пустить сторонних разработчиков. Ясное дело, зачем им подключаться к нему по рдп, если просто каждый в своей студии может добавить себе эту базу. Не охота создавать им пользователей в самом mssql...
zhaar, компьютеры с которых они подключаются не в домене. доменные учетки у них есть. они могут подключиться по рдп к серверу, запустить студию и работать с базой, но это не удобно, а вот добавить базу себе в студию с доменной учеткой они не могут.
MedicineMan, мммм, все равно, ни разу в своей практике не сталкивался с тем, что к БД пытались подключиться под доменной учеткой вне домена.
Только что попробовал аналогичным способом подключиться к серверу, тоже получил ошибку про сертификат.
Попробуй еще указывать порт в адресе подключения, а так же в доп. параметрах: TrustServerCertificate=True;
zhaar, пробовал. ошибки. Аутентификацию при помощи Active Directory можно прикрутить ко многим вещам. Скажем так, компьютер не в домене, но учетка пользователя то доменная. Какая ему разница? Он же на компьютер не смотрит. Подключится по рдп можно, а к MSSQL нельзя если не логинишься в систему, притом что пользователь добавлен и все права ему даны.
MedicineMan, как я писал ранее, "Active Directory - пароль" под облачную (Azure) инфраструктуру . По крайне мере у Mircosoft на сайте так написано. Поэтому дальше мучаться не стал.
Через оснастку "Пользователи и компьютеры"? Никак. AD ничего не знает о наличии или отстутствии на некотором сервере некоторых БД. Управление правами делается из студии - вот там можно доменный логин добавить.
Простой
Средний
