Cambiar la contraseña SA de SQL Server desde la línea de comandos

Qué significa realmente cambiar la contraseña de SA

La cuenta SA (System Administrator) es un inicio de sesión integrado de SQL Server que existe desde la instalación y que pertenece al rol fijo de servidor sysadmin. No es un usuario de base de datos normal: se mapea a dbo en cada base de datos y puede hacer prácticamente cualquier cosa en la instancia, desde leer datos hasta borrar bases completas o desactivar la auditoría. Por eso su contraseña es una de las piezas de información más sensibles de todo el entorno.

Cuando alguien pide «cambiar la contraseña de SA», en la práctica se está pidiendo una de estas tres cosas: rotar la clave por política de seguridad, recuperar el acceso después de que un administrador se fue de la empresa, o desbloquear una instalación cuyo único acceso conocido era precisamente sa. Los tres escenarios se resuelven con la misma instrucción básica, ALTER LOGIN, pero cambian mucho los requisitos previos y el margen de error.

Conviene aclarar dos matices que suelen generar confusión:

• En una instancia configurada solo con autenticación de Windows, la cuenta sa existe pero no puede iniciar sesión. Aun así, se le puede asignar una contraseña para dejarla preparada o para cumplir una auditoría. La consulta SELECT SERVERPROPERTY('IsIntegratedSecurityOnly') devuelve 1 en ese caso.
• El cambio surte efecto inmediato. No hace falta reiniciar el servicio ni reconectar las sesiones abiertas; simplemente, cualquier conexión nueva deberá usar la clave nueva. Las conexiones ya establecidas con la clave antigua siguen funcionando hasta que se cierran.

El error más común no es escribir mal la sintaxis, sino olvidar a todos los sistemas que usan esa cuenta: cadenas de conexión de aplicaciones, trabajos del Agente SQL Server, paquetes de ETL, servidores vinculados, herramientas de monitoreo y respaldos. Un cambio de contraseña bien ejecutado es un proyecto pequeño de coordinación, no solo un comando en una consola.

Antes de tocar nada: comprobaciones que evitan un incidente

Verifica la instancia, la edición y el modo de autenticación

Antes de escribir cualquier instrucción, confirma contra qué servidor estás trabajando. Es muy habitual tener abiertas varias consolas y confundir producción con un entorno de pruebas.

SELECT SERVERPROPERTY('ServerName') AS instancia,
       SERVERPROPERTY('Edition') AS edicion,
       SERVERPROPERTY('IsIntegratedSecurityOnly') AS solo_windows;

Un valor de solo_windows = 1 significa que la autenticación mixta está desactivada. Si necesitas que sa pueda iniciar sesión, tendrás que habilitar el modo mixto y reiniciar el servicio, algo que implica una ventana de mantenimiento.

Revisa el estado actual de la cuenta

SELECT name, is_disabled, is_policy_checked, is_expiration_checked
FROM sys.sql_logins
WHERE name = 'sa';

Aquí aparecen tres datos clave: si la cuenta está deshabilitada, si se le aplican las políticas de complejidad y si la contraseña caduca. Si is_policy_checked = 1, la contraseña nueva tendrá que cumplir los requisitos de longitud y complejidad de Windows, además de no repetir las últimas contraseñas registradas para esa cuenta.

Asegura una vía de acceso alternativa

Este es el punto que más problemas ahorra. Antes de cambiar nada, comprueba que tienes otro camino para administrar la instancia: un inicio de sesión de Windows con rol sysadmin, acceso por consola remota o RDP, y permisos para detener e iniciar el servicio de SQL Server. Si dependes exclusivamente de sa, un error tipográfico puede dejarte fuera hasta que hagas una recuperación en modo mono-usuario.

Documenta también la contraseña anterior en un gestor de secretos, aunque la intención sea rotarla de inmediato: durante la ventana de cambio necesitas poder volver atrás sin improvisar.

Método 1: cambiar la contraseña con autenticación de Windows

Cuando tienes acceso con una cuenta de Windows que es sysadmin, este es el método recomendado. Evita exponer la contraseña antigua y funciona incluso si sa está deshabilitada.

Abre una consola como administrador y comprueba primero de qué cuenta se trata:

sqlcmd -S localhost -E -Q "SELECT SUSER_SNAME(), IS_SRVROLEMEMBER('sysadmin');"

El parámetro -E indica autenticación de Windows. Si el resultado devuelve 1 en la segunda columna, tienes permisos suficientes. Ahora ejecuta el cambio:

sqlcmd -S localhost -E -Q "ALTER LOGIN sa WITH PASSWORD = 'ClaveNuevaMuyLarga#7';"

Algunas consideraciones prácticas:

• En instancias nombradas, usa -S localhost\SQLEXPRESS o el nombre del servidor tal como aparece en la red.
• Con versiones recientes de las herramientas de línea de comandos puede aparecer un aviso sobre el certificado del servidor. Si estás en una red controlada y entiendes el riesgo, puedes añadir -C para confiar en el certificado; en producción lo correcto es instalar un certificado válido y cifrar la conexión.
• Si quieres que la contraseña cumpla las políticas y además verificar el resultado, encadena instrucciones separadas por punto y coma dentro del mismo -Q.

Después del cambio, verifica iniciando una conexión nueva con las credenciales nuevas, en un servidor distinto o al menos en otra ventana:

sqlcmd -S localhost -U sa -P "ClaveNuevaMuyLarga#7" -Q "SELECT @@VERSION;"

Si esa conexión funciona, el cambio quedó aplicado.

Método 2: cambiar la contraseña usando la propia cuenta sa

Si no dispones de un inicio de sesión de Windows con privilegios, puedes usar la contraseña actual de sa para cambiarla por una nueva. Es un escenario típico en instancias heredadas o en servidores a los que solo se accede por red.

sqlcmd -S tcp:192.168.10.20,1433 -U sa -P "ClaveActual" -d master -Q "ALTER LOGIN sa WITH PASSWORD = 'ClaveNuevaMuyLarga#7';"

Detalles que importan:

• La base de datos de contexto debe ser master, porque los inicios de sesión son objetos de nivel de servidor.
• Las contraseñas con caracteres especiales deben ir entre comillas y, en entornos tipo Bash, conviene usar comillas simples para que el shell no interprete $ o !.
• Si el puerto no es el predeterminado, indícalo con tcp:host,puerto.
• Esta operación queda registrada en el proceso del sistema mientras se ejecuta. En equipos compartidos, evita dejar la contraseña en el historial del shell.

Un punto sutil: al cambiar la contraseña del mismo inicio de sesión que estás usando, la sesión actual no se corta, pero cualquier reconexión —incluido el reciclado del pool de conexiones de una aplicación— necesitará la clave nueva. Por eso, si puedes elegir, usa el método con autenticación de Windows.

Recuperación: qué hacer si nadie recuerda la contraseña de sa

Cuando sa está deshabilitada, bloqueada o simplemente nadie conoce la clave, el camino es arrancar la instancia en modo mono-usuario. En ese modo, cualquier administrador local de Windows entra como sysadmin.

El procedimiento general es:

1. Detén el servicio de SQL Server desde el Administrador de configuración de SQL Server o con net stop MSSQLSERVER.
2. Añade el parámetro de arranque -m (opcionalmente -m"SQLCMD" para limitar las conexiones a esa herramienta) en la pestaña de parámetros de arranque.
3. Inicia el servicio: net start MSSQLSERVER.
4. Conéctate con sqlcmd -S localhost -E y ejecuta:

ALTER LOGIN sa WITH PASSWORD = 'ClaveNuevaMuyLarga#7';
ALTER LOGIN sa ENABLE;

5. Detén el servicio, elimina el parámetro -m y vuelve a iniciarlo normalmente.
6. Comprueba el acceso con la contraseña nueva y revisa que ninguna otra conexión quedó a medias.

Dos advertencias: el modo mono-usuario solo permite una conexión a la vez, así que cierra otras consolas, y en clústeres o grupos de disponibilidad el arranque con -m requiere cuidado adicional para no interferir con la réplica.

Alternativas: SSMS, PowerShell y scripts reutilizables

SQL Server Management Studio. Puedes ejecutar ALTER LOGIN sa WITH PASSWORD = '...' en una ventana de consulta nueva contra la instancia. La interfaz gráfica no siempre expone un campo de contraseña en las propiedades del inicio de sesión, así que la vía T-SQL es la más fiable y la que deja un registro claro de lo que se hizo.

PowerShell. Con el módulo SqlServer:

$q = "ALTER LOGIN sa WITH PASSWORD = 'ClaveNuevaMuyLarga#7';"
Invoke-Sqlcmd -ServerInstance "localhost" -Query $q

Con dbatools, la operación es aún más declarativa:

$segura = ConvertTo-SecureString 'ClaveNuevaMuyLarga#7' -AsPlainText -Force
Set-DbaLogin -SqlInstance localhost -Login sa -Password $segura

Scripts con archivo de entrada. Para cambios repetibles, guarda el T-SQL en un .sql y ejecútalo con -i, redirigiendo la salida a un archivo de registro:

sqlcmd -S localhost -E -i C:\scripts\cambiar_sa.sql -o C:\scripts\cambiar_sa.log

Si el script necesita la contraseña como parámetro, usa variables de sqlcmd ($(ClaveNueva)) y pásalas con -v. Aun así, ten presente que cualquier parámetro escrito en la línea de comandos puede quedar visible en la lista de procesos; para automatizaciones serias, obtén la contraseña desde un gestor de secretos en tiempo de ejecución y no la escribas en el script ni en el repositorio.

Rotación programada: cómo hacerlo sin cortar el servicio

Una rotación ordenada sigue siempre la misma secuencia:

1. Inventario. Localiza todos los consumidores de la cuenta: aplicaciones, cadenas de conexión, trabajos del Agente, servidores vinculados, paquetes de integración, informes, monitoreo, respaldos y scripts de operación.
2. Ventana. Elige un momento de baja actividad, aunque el cambio sea instantáneo, porque la actualización de los consumidores sí puede requerir reinicios de servicios de aplicaciones.
3. Cambio. Ejecuta ALTER LOGIN con la contraseña nueva desde una cuenta administrativa de Windows.
4. Actualización. Modifica cada consumidor. Si usas un gestor de secretos, actualiza el valor y fuerza la recarga.
5. Verificación. Inicia sesión con la clave nueva, revisa el registro de errores de SQL Server y busca intentos de inicio de sesión fallidos.
6. Cierre. Documenta la fecha, el responsable y los sistemas actualizados. Elimina la contraseña antigua de cualquier archivo temporal.

Un patrón que reduce el riesgo es mantener dos cuentas administrativas con nombre propio y privilegios equivalentes, y usar sa solo como último recurso. Rotar una cuenta dedicada es más sencillo y deja una trazabilidad mucho mejor que rotar la cuenta integrada.

Errores frecuentes y cómo diagnosticarlos

Mensaje o síntoma	Causa probable	Solución
Login failed for user 'sa'	Contraseña incorrecta, cuenta deshabilitada o instancia en modo solo Windows	Revisa sys.sql_logins, el modo de autenticación y vuelve a probar
Cannot alter the login 'sa'	La cuenta conectada no es sysadmin	Conéctate con un inicio de sesión de Windows con rol sysadmin
Password validation failed	La clave no cumple longitud, complejidad o historial	Usa una frase larga con mayúsculas, minúsculas, números y símbolos
Error 18456, estado 58	Autenticación SQL activa pero contraseña equivocada	Verifica mayúsculas, comillas y caracteres escapados
Error 18470	La cuenta está deshabilitada	Ejecuta ALTER LOGIN sa ENABLE;
Aviso de certificado en la herramienta de línea de comandos	Cifrado obligatorio con certificado no confiable	Instala un certificado válido o, en entornos controlados, usa -C
No se puede abrir la conexión	Nombre de instancia o puerto incorrecto	Prueba -S tcp:host,puerto

Buenas prácticas después del cambio

Cambiar la contraseña es el principio, no el final. Estas medidas reducen de forma real la superficie de ataque:

• Deshabilita sa si no la necesitas. En la mayoría de instalaciones modernas, las aplicaciones deberían usar cuentas propias con privilegios mínimos.
• No la renombres esperando ocultarla. El SID sigue siendo reconocible y muchas herramientas la localizan igual.
• Aplica políticas de complejidad y caducidad a las cuentas administrativas, y revisa el historial de contraseñas.
• Cifra las conexiones con TLS y exige certificados válidos, especialmente si administras por red.
• Audita los inicios de sesión y alerta ante picos de intentos fallidos: son la señal más temprana de un ataque de fuerza bruta.
• Revisa las cuentas de servicio que pudieran estar usando sa; sustitúyelas por cuentas dedicadas de Windows o por inicios de sesión con permisos acotados.
• Guarda las claves en un gestor de secretos, nunca en scripts versionados ni en hojas de cálculo compartidas.

Preguntas frecuentes

¿Hay que reiniciar SQL Server tras cambiar la contraseña? No. ALTER LOGIN se aplica de inmediato. Solo necesitas reiniciar si cambias el modo de autenticación de la instancia.

¿Afecta a las sesiones abiertas? No se cierran, pero cualquier conexión nueva exige la clave nueva. Los pools de conexiones de las aplicaciones se reciclan y pueden empezar a fallar minutos después del cambio.

¿Necesito la contraseña anterior? Solo si tu única vía de acceso es la propia cuenta sa. Con un inicio de sesión de Windows que sea sysadmin no la necesitas.

¿Funciona en Azure SQL Database? No: ese servicio no tiene cuentas de servidor como sa. Sí existe en Azure SQL Managed Instance, donde el procedimiento es equivalente.

¿Puedo usar sp_password? Está obsoleto y puede desaparecer en versiones futuras. Usa siempre ALTER LOGIN ... WITH PASSWORD.

¿Qué pasa si olvido la contraseña nueva justo después de cambiarla? Si tienes otro acceso sysadmin, repite el cambio. Si no, recupera el acceso en modo mono-usuario.

¿Puedo comprobar la contraseña sin abrir una conexión nueva? No de forma fiable. La única verificación real es iniciar sesión con esas credenciales.

¿Es recomendable usar sa para aplicaciones? No. Crea una cuenta por aplicación con los permisos mínimos que necesite y deja sa para tareas de emergencia.

Lista de verificación final

Antes de dar por cerrado el cambio, confirma cada punto:

• Identificaste la instancia correcta y su modo de autenticación.
• Tenías un acceso alternativo con rol sysadmin.
• La contraseña nueva cumple las políticas aplicadas a la cuenta.
• Ejecutaste el cambio y verificaste con una conexión nueva.
• Actualizaste aplicaciones, trabajos, ETL, servidores vinculados y monitoreo.
• Revisaste el registro de errores buscando fallos de inicio de sesión.
• Guardaste la nueva clave en el gestor de secretos y eliminaste las copias temporales.
• Documentaste la fecha, el motivo y los sistemas afectados.

Con esta rutina, cambiar la contraseña de SA deja de ser una operación arriesgada y se convierte en una tarea de mantenimiento predecible, auditable y reversible.