Cómo actualizar el grupo de seguridad de AD en los permisos del servidor SQL

12

Estoy usando Sql Server 2008 en Small Business Server 2003; El cliente está utilizando WinXP.

Agregué un usuario a mi grupo de seguridad de Active Directory; ¿Por qué este usuario no puede acceder de inmediato a la base de datos? Parece que hay una demora antes de que el usuario sea reconocido en SQL Server.

Estoy usando Grupos de seguridad de AD para permisos expresamente, de modo que no necesito agregar usuarios individuales en SQL Server. Así que, efectivamente, no necesito hacer nada más que agregar al usuario al Grupo de seguridad de AD para otorgar acceso.

Pero por alguna razón, SQL Server no reconoce de inmediato la adición. Lo he visto varias veces. Agrego el usuario al grupo, pero ese usuario no puede acceder a los datos hasta el día siguiente. Parece que no consulta el Active Directory en tiempo real. ¿Puedes confirmar que es así?

¿Qué debo hacer para que SQL Server "actualice" la lista de usuarios de Active Directory?

D_Bester
fuente
En SQL Server 2008 Management Studio, agregué un inicio de sesión del servidor utilizando el Grupo de seguridad y en la base de datos creé un usuario asignado a ese inicio de sesión. Eso funciona muy bien!
D_Bester
Sin embargo, después de agregar un nuevo usuario al Grupo de seguridad, no pudo acceder a la base de datos especificada. Ese usuario tiene acceso al servidor utilizando otro grupo, por lo que simplemente probar la conexión al servidor SQL funcionó bien. Estaba agregando una conexión al servidor SQL para el usuario (en su computadora). Cuando especifiqué la base de datos que quería, decía que la base de datos no estaba disponible.
D_Bester
Comprobación puntual de varios controladores de dominio. Veo que la replicación ha finalizado después de 15 minutos, pero SQL ignora al nuevo usuario en el grupo AD. Reiniciar el servidor SQL resuelve el problema, al igual que esperar 24 horas. Debe ser una mejor manera.
Aaron Auseth

Respuestas:

12

El usuario debe cerrar sesión en su estación de trabajo e iniciar sesión nuevamente. Es por eso que los cambios parecen surtir efecto al día siguiente. La razón de esto es que cuando el usuario inicia sesión al día siguiente, obtiene un nuevo token del controlador de dominio y este token contiene la lista de grupos de dominio de los que es miembro. Este token con la lista de grupos de dominio solo se actualiza cuando el usuario inicia sesión en su computadora, por lo que si el usuario nunca cierra la sesión, el token nunca se actualiza.

También hay demoras en la replicación de dominios de sitios múltiples que deben tenerse en cuenta si sus controladores de dominio se encuentran en diferentes ubicaciones físicas.

mrdenny
fuente
1
¿Hay un comando o script que se pueda ejecutar en la estación de trabajo para "actualizar" su token AD para que pueda "saber" que el usuario ahora es miembro del nuevo grupo de dominio y así evitar el retraso? --Actualización: parece que una persona lo recomendó klist purgeen dba.stackexchange.com/a/44922/29371 , pero con la advertencia de que podría romper otros accesores de recursos en caché que el usuario tendría que restablecer / volver a conectar.
NateJ
@mrdenny ¿Alguna recomendación sobre cómo manejar esto para las cuentas de servicio? Ejecutamos todas las instancias de SQL bajo cuentas de servicio, y usamos estas cuentas de servicio para conexiones entre servidores SQL, y para SSRS, etc. En cualquier momento, tenemos muchas conexiones entre máquinas. Realmente no podemos desconectar todas las conexiones y hacer un nuevo inicio de sesión en algún lugar para obtener nueva información del grupo AD.
SomeGuy
Para las cuentas de servicio, todo lo que puede hacer es reiniciar el servicio en la máquina que necesita los nuevos derechos.
mrdenny
5

Cuando un usuario inicia sesión, se le asigna un token de seguridad que incluye toda la información sobre la pertenencia a su grupo.

Este token persiste hasta que el usuario cierra la sesión, momento en el que se descarta, incluso si realiza cambios en la pertenencia al grupo en AD mientras tanto. Los cambios que realice solo tendrán efecto la próxima vez que el usuario inicie sesión y reciba un nuevo token de seguridad.

Puede reproducir el mismo escenario al asignar permisos en un sistema de archivos, por ejemplo; es un comportamiento de AD, no un comportamiento de SQL Server.

Jon Seigel
fuente
1

Por lo tanto, obtendrá resultados inmediatos: obtener nuevas credenciales cada vez que ejecute un cmd / script como:

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

usando cmd.exe (no powershell, no pude obtener la cita correcta).

De esa manera, obtendrá un nuevo token cada vez (pero tendrá que ingresar su pwd). Probablemente también podría hacer algo con un texto de contraseña guardado, si las cosas fueran demasiado onerosas.

De todos modos, funciona para mí y espero que ayude a alguien más.

Karl
fuente