Introducción
En un artículo previo acerca de Conectar PowerShell a SQL Server, mostré cómo usar varios métodos en PowerShell para conectarse a SQL Server. En esos ejemplos sólo traté el uso de usuario actual que está corriendo “PowerShell.exe”. En este artículo deseo retomar y mostrar cómo usted usaría los mismos métodos, pero con una cuenta diferente. Cubriré el uso de la Autenticación de Windows (donde se soporte) y la autenticación de SQL.
Hay un objeto en PowerShell utilizado para hacer conexiones como una cuenta separada: PSCredential. Este objeto es usado para capturar las nuevas credenciales. En la mayoría de los casos, le permite pasar de forma segura esas credenciales sin hacer la información de la cuenta visible en su script. En los ejemplos abajo voy a usar el comando “Get-Credential” para construir este objeto. El artículo referenciado al final de este artículo para asegurar sus contraseñas en PowerShell analiza este comando y otros en más detalle.
Opciones
Como en el artículo previo, las siguientes son las opciones que cubriremos:
- SQL Server PowerShell (SQLPS)
- SQL Server Management Objects (SMO)
- .NET (System.Data.SqlClient)
SQL Server PowerShell (SQLPS)
Mientras que SQLPS aún está presente, un mejor módulo que Microsoft lazó con SSMS 2016 fue renombrado a “SqlServer”. Este módulo está siendo expandido a medida que las actualizaciones de SSMS son lanzadas, así que es más robusto que el módulo SQLPS. Los métodos mostrados abajo funcionarían con cualquier módulo.
SqlServer Provider
SQLPS.exe, la utilidad, no va a ser tocada porque no soporta el cambio de cuenta antes de que se conecte. Cuando usted abre esa utilidad, usted es colocado directamente en el proveedor “SQLSERVER:” sin poder cambiar la cuenta. Aunque el proveedor en sí mismo puede ser ajustado para usar una cuenta separada. Si usted ha usado el proveedor de archivos en PowerShell para conectarse a recursos compartidos remotos (equivalente a “uso de red”), funciona de la misma manera.
El comando para crear un nuevo dispositivo en PowerShell es “New-PSDrive”. Este comando requiere los siguientes parámetros para crear el dispositivo:
- Name – Esto es usado para hacer una búsqueda de directorio, así que en lugar de “SQLSERVER:”, usted usaría el nombre provisto.
- PSProvider – Esto le dice al comando qué proveedor usar realmente, en nuestro caso es SqlServer.
- Root – La ruta raíz a la que se desea conectar (por ejemplo, “SQLSERVER:”).
- Credential – La cuenta con la que desea hacer la conexión.
|
1 2 |
New-PsDrive -Name DefaultSql -PSProvider SqlServer -Root 'SQLSERVER:\SQL\SERVERNAME\DEFAULT' -Credential (Get-Credential) |
La limitación que usted tiene con el proveedor SqlServer (el módulo y PSDrive) es que sólo soporta autenticación de SQL Login. Crea el dispositivo con una cuenta de Windows, pero cuando usted trata de hacer una búsqueda de directorio en el dispositivo, usted verá la excepción:
Usted puede ver desde esta captura de pantalla errores de que no existe. No hay una falla de ingreso asociada a SQL Server, así que creo que no fue implementado para manejar apropiadamente el uso de una Cuenta de Windows como soporta SMO. Si usted trata de usar un Inicio de Sesión SQL, usted puede ver un intento exitoso de navegar en el dispositivo:
Módulo SqlServer
El módulo está creciendo lentamente con nuevos comandos cada mes, y ha reemplazado oficialmente al módulo SQLPS. Me he dado cuenta de que no todos los comandos soportan el parámetro “-Credential”, sólo 24 de 82 al tiempo de escribir este artículo. Usted puede fácilmente encontrar aquellos que sí lo hacen usando el siguiente comando:
|
1 |
Get-Command -Module SqlServer -ParameterName Credential |
Usted notará que el comando “Invoke-Sqlcmd” no está listado. El comando “Invoke-Sqlcmd” le permite pasar un nombre de usuario y una contraseña para un Inicio de Sesión SQL, pero sólo en texto plano. Los comandos que soportan el parámetro de credencial tienen la misma limitación que el proveedor, sólo aceptando la autenticación de SQL Login.
Un ejemplo corto que usa “Get-SqlErrorLog”:
|
1 2 |
$cred = Get-Credential Get-SqlErrorLog -ServerInstance MyServer -Credential $cred | select -Last 3 |
SQL Server Management Objects (SMO)
SMO soporta Autenticación de Windows o SQL, pero conectarse con SMO es un poco único, basado en qué tipo de autenticación desea usar. Sólo para refrescar, las líneas para crear nuestro objeto de servidor SMO están anotadas abajo e incluyen sólo crear el objeto PScredential:
|
1 2 3 4 5 |
$cred = Get-Credential Add-Type -AssemblyName "Microsoft.SqlServer.Smo,Version=13.0.0.0,Culture=neutral,PublicKeyToken=8984 5dcd8080cc91" $srv = New-Object Microsoft.SqlServer.Management.Smo.Server MyServer |
Una vez que tiene el objeto de servidor creado, continuamos pasando la cuenta deseada, basados en qué tipo es necesario.
SMO – Autenticación de Windows
Para usar una cuenta de Windows, usted tiene que hacérselo saber a SMO ajustando algunas propiedades a verdadero:
|
1 2 |
$srv.ConnectionContext.LoginSecure = $true $srv.ConnectionContext.ConnectAsUser = $true |
Podemos entonces pasar el nombre de usuario u contraseña desde la variable credencial y conectarnos.
|
1 2 3 |
``powershell $srv.ConnectionContext.ConnectAsUserName = $cred.username $srv.ConnectionContext.ConnectAsUserPassword = $cred.GetNetworkCredential().Password $srv.ConnectionContext.Connect() ``` |
SMO – Inicio de Sesión SQL
En comparación, para usar una cuenta SQL, usted establece LoginSecure a falso, y luego sólo pasa el nombre de usuario y contraseña, pero tenemos que usar un conjunto diferente de propiedades:
|
1 2 3 4 |
$srv.ConnectionContext.LoginSecure = $false $srv.ConnectionContext.set_Login($cred.username) $srv.ConnectionContext.set_SecurePassword($cred.password) $srv.ConnectionContext.Connect() |
dbatools
El módulo dbatools ayuda a hacer las vidas de los DBAs más fáciles donde no tenemos que recordar toda la sintaxis de SMO. En lugar de recordar todas las propiedades anteriores basadas en el tipo de autenticación, ¿no sería más fácil sólo usar una función para crear el objeto de servidor? Déjeme presentarle “Connect-DbaSqlServer”, uno de muchos comandos en el módulo dbatools. Este comando está basado en una función interna que es usada dentro de cada comando para construir el objeto de servidor necesario para SMO. Después de que usted instale dbatools, es tan simple como las siguientes líneas:
|
1 2 3 |
Import-Module dbatools $cred = Get-Credential $srv = Connect-DbaSqlServer -Sqlserver MyServer -Credential $cred |
¿No es eso mucho más fácil de usar?
.NET (System.Data.SqlClient)
SqlClient sólo permite una cuenta de SQL a ser provista. Lo cual es esperado, ya que .NET utiliza el inicio de sesión que inició el proceso para Autenticación de Windows. Para utilizar una cuenta SQL, necesitamos construir un objeto específico de credencial, System.Data.SqlClient.SqlCredential. Usted tiene que pasar el nombre de usuario y la contraseña (como SecureString). Hay una cosa extra requerida para la contraseña. SqlCredential requiere que la contraseña sea de sólo lectura, de modo que no pueda ser alterada una vez que la conexión es hecha. Lo cual significa que una vez que usted la configura, no puede ser revertida, usted tendría que reconstruir el proyecto. Cualquier intento de modificar esa contraseña le dará un error de excepción inválida.
Aún podemos usar PSCredential para recolectar el nombre de usuario y la contraseña. Los siguientes son los pasos a tomar para construir el objeto SqlCredential:
|
1 2 3 4 5 6 7 8 9 |
# First create the PSCredential object $cred = Get-Credential #set the password as read only $cred.Password.MakeReadOnly() # Create the SqlCredential object $sqlCred = New-Object System.Data.SqlClient.SqlCredential($cred.username,$cred.password) |
Después de que tengamos eso, sólo necesitamos configurar la credencial para nuestra conexión:
|
1 2 3 |
$sqlConn = New-Object System.Data.SqlClient.SqlConnection $sqlConn.ConnectionString = “Server=localhost\sql12;Initial Catalog=master” $sqlConn.Credential = $sqlCred |
En resumen
Como probablemente notó, el inicio de sesión de SQL tiene el mayor soporte en las opciones de arriba. Si usted necesita usar Autenticación de Windows, usted tiene unas pocas opciones, pero para la mayor parte necesitará iniciar PowerShell con la cuenta necesaria de Windows. PowerShell ofrece múltiples opciones para conectarse con una Cuenta de Windows diferente que no está directamente relacionada a SQL Server, si el Inicio de Sesión de SQL no es una opción. Usted puede investigar comandos como “Invoke-Command” o “Start-Process”, estos proveen una opción para también pasar una credencial de Windows.
Espero que la información de arriba le provea algo de ayuda en entender el uso alterno de credenciales para conectarse a SQL Server.
Vea más
Considere estas herramientas gratis para SQL Server que mejoran la productividad del desarrollador de bases de datos.
Referencias
- Método SecureString MakeReadOnly
- System.Data.SqlClient.SqlCredential
- Conectando PowerShell a SQL Server
- Cómo asegurar sus contraseñas con PowerShell
Después de pasar 6 años en el mundo de la administración de sistemas y redes, descubrió que disfrutaba aprender y trabajar con SQL Server. Desde 2010, él ha estado involucrado en SQL Server.
Él es un apasionado acerca de PowerShell y la automatización alrededor de SQL Server y Windows. Su experiencia está enfocada en la administración de SQL Server y algo de desarrollo BI (SSIS, SSRS).
Ver todas las publicaciones de Shawn Melton
- Conectando PowerShell a SQL Server usando una cuenta diferente - May 24, 2018
- Conectando PowerShell a un Servidor SQL Server - April 11, 2018
- Introducción de Visual Studio Code para DBAs - February 28, 2017