Server properties -> Security<\/strong><\/p><\/blockquote>\n Es posible que la mayor\u00eda de nuestros servidores tengan ambos habilitados por lo que tarde o temprano nosotros, como DBAs, tendremos que lidiar con inicios de sesi\u00f3n de SQL, pero adem\u00e1s de proporcionar un nombre y una contrase\u00f1a (una fuerte, por supuesto) hay m\u00e1s cosas.<\/p>\n Si aparte de eso, tenemos diferentes entornos, lo m\u00e1s probable es que queramos crear inicios de sesi\u00f3n diferentes para evitar que las aplicaciones o usuarios de DEV se conecten a LIVE o viceversa.<\/p>\n Pero cuando tenemos inicios de sesi\u00f3n diferentes para cada entorno y, por defecto, usuarios de bases de datos, cuando necesitemos actualizar DEV (TEST, QA …) habr\u00e1 que volver a aplicar todos los permisos otorgados al usuario correcto porque ese inicio de sesi\u00f3n no existe en ese entorno. \u00bfOs suena familiar?<\/p>\n En esta publicaci\u00f3n, os mostrar\u00e9 c\u00f3mo podemos manejar este problema de una manera muy simple.<\/p>\n Podemos crear un inicio de sesi\u00f3n en SQL Server Management Studio navegando a<\/p>\n Server -> Security -> Logins -> New login<\/strong><\/p><\/blockquote>\n Como es habitual, debemos proporcionar la mayor cantidad de informaci\u00f3n posible, incluida la base de datos predeterminada y los usuarios de la base de datos asignados, no olvid\u00e9is anular la opci\u00f3n de db_owner para el nuevo usuario. Para ser sincero, no veo por qu\u00e9 est\u00e1 marcado por defecto.<\/p>\n \u00bfYa sabes de lo que estoy hablando? Efectivamente… el SID.<\/p>\n A diferencia de lo que la gente pueda pensar, SQL Server identifica de manera \u00fanica los inicios de sesi\u00f3n basandose \u200b\u200ben sus SID, no sus nombres.<\/p>\n Los SID (identificadores de seguridad) pueden ser proporcionados por un dominio o una computadora que use Windows o por un servidor SQL Server. Esa es la clave de lo que estamos tratando de lograr. No existe un mecanismo de emparejamiento por nombre<\/em><\/strong>, por lo que todo se basa en el SID del inicio de sesi\u00f3n que intenta conectarse a nuestro servidor SQL.<\/p>\n Los identificadores de seguridad son tambi\u00e9n el mecanismo para emparejar los inicios de sesi\u00f3n del servidor con los usuarios de las bases de datos.<\/p>\n Como dije antes, no hay forma de que en SSMS generemos un script de un inicio de sesi\u00f3n de SQL Server que incluya el SID, pero por suerte hace alg\u00fan tiempo publiqu\u00e9 mi procedimiento almacenado [dbo].[sqlg_securityAuditServerLogins]<\/a> que hace el trabajo por m\u00ed (y por vosotros tambi\u00e9n)<\/p>\n La mejor manera de solucionar un problema es no tener un problema, as\u00ed que veamos c\u00f3mo podemos abordar el hecho de tener diferentes inicios de sesi\u00f3n, uno por entorno que permita el acceso a la base de datos independientemente del entorno en el que nos encontremos.<\/p>\n Necesitaremos:<\/p>\n Fijaos que el usuario de la base de datos no incluye _dev, porque personalmente odio encontrar cosas de _dev en mis servidores de producci\u00f3n, pero eso depende totalmente vosotros.<\/p>\n Una vez que hayamos creado nuestro inicio de sesi\u00f3n, podemos ver el c\u00f3digo comandos, incluido el SID, con mi procedimiento almacenado. Simplemente despl\u00e1cese a la \u00faltima columna para encontrarlo.<\/p>\n![\"\"](\"https:\/\/sqldoubleg.live-website.com\/wp-content\/uploads\/2018\/07\/01_server_authentication.png\")
<\/a><\/p>\n<\/a><\/p>\n
\nAntecedentes<\/strong><\/p>\n
\nCrear un inicio de sesi\u00f3n de SQL<\/strong><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n
\nIndependientemente de si hacemos clic en \u00abAceptar\u00bb o \u00abScript\u00bb, hay algo que falta y es probablemente de lo m\u00e1s importante. Incluso una vez que el inicio de sesi\u00f3n existe y generamos el script de creaci\u00f3n, no se mostrar\u00e1.<\/p>\n
\nEl SID es todo<\/strong><\/p>\n
\nC\u00f3mo ahorrarnos un problema<\/strong><\/p>\n\n
\nEl primer inicio de sesi\u00f3n se puede hacer de cualquiera de las dos formas, usando TSQL o la interfaz de usuario, no importa. <\/p>\n\r\nUSE [master]\r\nGO\r\nCREATE LOGIN [SalesApp_dev] WITH PASSWORD=N'StrongPassword.123!'\r\n\t, DEFAULT_DATABASE=[AdventureWorks2014]\r\n\t, CHECK_EXPIRATION=OFF\r\n\t, CHECK_POLICY=ON\r\nGO\r\nUSE [AdventureWorks2014]\r\nGO\r\nCREATE USER [SalesApp] FOR LOGIN [SalesApp_dev]\r\nGO\r\nGRANT SELECT ON [Person].[Address] TO [SalesApp]\r\n<\/pre>\n
\r\nEXECUTE master.dbo.sqlg_securityAuditServerLogins @loginName = N'SalesApp_dev'\r\n<\/pre>\n