Как обновить группу безопасности AD на разрешениях Sql Server

12

Я использую Sql Server 2008 для Small Business Server 2003; клиент использует WinXP.

Я добавил пользователя в свою группу безопасности Active Directory; Почему этот пользователь не может сразу получить доступ к базе данных? Кажется, есть задержка, прежде чем пользователь будет распознан в Sql Server.

Я использую группы безопасности AD для разрешений, поэтому мне не нужно добавлять отдельных пользователей в Sql Server. Поэтому мне не нужно ничего делать, кроме как добавить пользователя в группу безопасности AD для предоставления доступа.

Но по какой-то причине Sql Server не сразу распознает дополнение. Я видел это несколько раз. Я добавляю пользователя в группу, но этот пользователь не может получить доступ к данным до следующего дня. Кажется, что он не запрашивает Active Directory в режиме реального времени. Можете ли вы подтвердить, что это так?

Что мне нужно сделать, чтобы Sql Server «обновил» список пользователей из Active Directory?

sql-server-2008 permissions active-directory

— D_Bester
источник

В SQL Server 2008 Management Studio я добавил имя входа на сервер с помощью группы безопасности и в базе данных создал пользователя, сопоставленного с этим именем входа. Это прекрасно работает!

— D_Bester

Однако после добавления нового пользователя в группу безопасности он не может получить доступ к указанной базе данных. Этот пользователь имеет доступ к серверу, используя другую группу, поэтому просто тестирование соединения с Sql Server работало нормально. Я добавлял соединение с Sql Server для пользователя (на ее компьютере). Когда я указал базу данных, я хотел, чтобы она сказала, что база данных недоступна.

— D_Bester

Выборочная проверка различных контроллеров домена Я вижу, что репликация действительно завершается через 15 минут, но SQL игнорирует нового пользователя в группе AD. Перезапуск сервера SQL решает проблему, так же как и ожидание 24 часа. Должно быть лучше.

— Аарон Аусет

12

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

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

— mrdenny
источник

1

Есть ли команда или сценарий, которые можно запустить на рабочей станции, чтобы «обновить» свой токен AD, чтобы он мог «знать», что пользователь теперь является членом новой доменной группы, и, таким образом, избежать задержки? - Обновление: кажется, что один человек рекомендовал klist purgeна dba.stackexchange.com/a/44922/29371 , но с оговоркой, что он может сломать другие кэшированные средства доступа к ресурсам, которые пользователь должен будет повторно установить / повторно подключиться.

— NateJ

@mrdenny Какие-нибудь рекомендации о том, как обращаться с этим для служебных учетных записей? Мы запускаем все экземпляры SQL под учетными записями служб и используем эти учетные записи служб для соединений между серверами SQL, а также для SSRS и т. Д. В любой момент времени у нас много соединений между компьютерами. Мы не можем действительно отключить все соединения и сделать новый вход в систему, чтобы получить новую информацию о группе AD.

— SomeGuy

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

— Мрденный

5

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

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

Такой же сценарий можно воспроизвести, например, при назначении разрешений для файловой системы; это поведение AD, а не поведение SQL Server.

— Джон Сайгель
источник

1

Таким образом, вы получите немедленный результат: каждый раз вы будете получать новые учетные данные, запустив cmd / скрипт, например:

runas /netonly /user:domain\username "sqlcmd -S serverName -d dbname -q \"insert into testpermissions values (65)\""

используя cmd.exe (не powershell, я не могу правильно указать цитирование).

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

В любом случае, работает для меня, и я надеюсь, что это поможет кому-то еще.

— Карл
источник