Tag Archives: sql server

Permisos a NetworkService en remoto

Hoy me he encontrado con una situación que, no siendo habitual, tampoco es tan extraña. Tenía una máquina con un servidor de aplicaciones IIS que hospedaba una aplicación web (unos servicios WCF, por concretar). El Application Pool sobre el que corría dicha aplicación web estaba utilizando la cuenta de Network Service de la máquina, y era preciso que accediera a una base de datos en otra máquina.

Parece fácil, ¿no? Pero, ¿cómo darle permisos a una cuenta que no está en nuestra máquina y que tampoco es una cuenta del dominio en el que se encuentran ambas máquinas? La primera pista la podemos encontrar en IIS.NET, en este post (en inglés). En él nos explican, entre otras muchas cosas, que cada cuenta Network Service de una máquina se convierte en una cuenta distinta cuando trata de acceder a recursos en máquinas distintas. Esta cuenta en la que se “transmuta” Network Service cumple el siguiente patrón:

<nombre_de_dominio><nombre_de_maquina>$

Con lo cual, si nuestra máquina XXX se encuentra en el dominio YYY, su cuenta “transmutada” sería: YYYXXX$. Fácil, ¿verdad? Ahora sólo haría falta dar permisos a dicha cuenta utilizando Management Studio, en el servidor de bases de datos al que queremos atacar. Sin embargo, aquí nos encontramos con otro pequeño problema: Management Studio no es capaz de reconocer dicha cuenta.

Por eso, en su lugar, tendremos que tirar de consola (o de una ventana de query del Management Studio) y ejecutar el siguiente procedimiento almacenado:

exec sp_grantlogin 'nombre_de_dominionombre_de_maquina$'

 

Y, ahora sí, refrescando la carpeta de Logins del servidor SQL Server, podremos a este nuevo login y configurarlo para que tenga los permisos necesarios para acceder a la base de datos que toca.

Usuarios, permisos y SQL Server

Recientemente me encontré ante la situación de tener que configurar, en un proyecto de Database de Visual Studio 2008, una serie de usuarios, permisos y roles.

En concreto, necesitaba crear un rol que pudiera ejecutar procedimientos almacenados y hacer SELECTs sobre un determinado esquema. A este rol, a su vez, pertenecería un usuario que también debía crearse dinámicamente en el script. Tras una mañana de investigación, estas son mis conclusiones.

Logins y Users

En SQL Server hay que distinguir entre Logins y Users. Los Logins se crean a nivel de servidor de base de datos. Pueden crearse como Logins de SQL Server, o pueden crearse a partir de una cuenta Windows, lo que en general es más seguro por utilizarse la autenticación integrada. En mi caso era precisamente eso lo que pretendía hacer, crearlos a partir de una determinada cuenta Windows. Esto es muy sencillo de hacer, basta un comando como el que se puede ver a continuación:

USE [yourdb]
GO
CREATE LOGIN [YourDomainYourUser] FROM WINDOWS
GO

Sin embargo, esto tiene una pega: no se puede hacer en los proyectos de base de datos de Visual Studio 2008, o al menos yo no he encontrado el modo. Tiene su sentido, de todas formas, puesto que estos proyectos no dejan de ser la creación de una base de datos concreta, y no debería afectar a la configuración del servidor en sí.

Una vez creado el Login, ya podemos crear un usuario y asociarlo a él. Esta parte sí se puede añadir al proyecto de BD de VS2008, en concreto en la carpeta Users dentro de Security. El TSQL necesario sería algo así:

CREATE USER [YourDomainYourDbUser] FROM LOGIN [YourDomainYourUser]
GO

Bien, con esto ya tendríamos nuestro usuario concreto de la base de datos creado, asociado a un Login a nivel del servidor.

Roles y permisos

El siguiente paso es crear el rol al que vamos a asociar el usuario que recién hemos creado. Este rol va a pertenecerle a dbo. No podemos darle sus permisos directamente en el script que se crea en la carpeta Database Roles de Security, esa parte tendremos que añadirla en un script de Post-deployment. Así que en el script de creación del rol simplemente tendríamos la siguiente sentencia TSQL:

CREATE ROLE [YourNewRole] AUTHORIZATION [dbo]
GO

Quedarían dos pasos por ejecutar: darle los permisos al rol que necesite y asociarle el usuario que creamos al principio.

La primera parte se completa con una sentencia parecida a ésta. Sería necesario indicar qué esquema de los existentes en la base de datos, va a poder el rol ejecutar sus SPs.

GRANT EXECUTE ON SCHEMA ::[YourSchema] TO [YourNewRole]
GO

En cuanto a la segunda, bastaría algo como lo que sigue, apoyándonos en uno de los procedimientos almacenados del sistema:

EXEC sp_addrolemember N'YourNewRole', N'YourDomainYourUser'
GO

Bibliografía: