Quería probar la función de usuarios de la base de datos contenida en Azure SQL Database V12, pero tengo un problema de autenticación que me parece extraño.
Creé una base de datos llamada Classifier
. Agregué mi IP a las reglas del firewall para poder conectarme al servidor Azure db desde SSMS en mi estación de trabajo. Una vez que pude conectarme a través de SSMS para la administración, intenté agregar un usuario con una contraseña a la base de datos, de esta manera:
CREATE USER classifier WITH PASSWORD='thepassword'
También agregué este usuario a los roles de escritor y lector de datos:
exec sp_addrolemember 'db_datawriter', 'classifier'
exec sp_addrolemember 'db_datareader', 'classifier'
Después de esto, puedo conectarme a la base de datos con estas credenciales de SSMS:
Pero aquí es donde las cosas salen mal: he probado varios conjuros de cadenas de conexión diferentes y parece que no puedo conectarme a una aplicación web en la que estoy trabajando. No funcionó en el entorno de Azure, por lo que estoy ejecutando en localhost con una cadena de conexión a la base de datos de Azure, y simplemente no se conecta. Aquí está la cadena de conexión que estoy usando en este momento:
<add name="Classifier" connectionString="Data Source=xxxxxxx.database.secure.windows.net;Initial Catalog=Classifier;User ID=classifier;Password=xxxxxxxxxxxxx;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;" providerName="System.Data.SqlClient"/>
He intentado restablecer la contraseña (a través de SSMS) para el usuario y luego actualizar la cadena de conexión; También verifiqué dos veces la contraseña copiándola directamente de esta cadena de conexión y en el cuadro de diálogo de conexión en SSMS para asegurarme de que no tenía un error tipográfico allí.
Permití la auditoría en el servidor db de Azure con la esperanza de obtener algunos detalles de por qué está fallando, pero todo lo que obtengo es esto:
Y aquí es donde estoy atrapado. La mayor parte de lo que he podido encontrar a través de documentación o blogs indica que lo que hay que hacer es mirar los registros de SQL Server para ver cuál es el estado de error real que indicaría más estrechamente la naturaleza de la falla, pero desde entonces Estoy tratando con Azure, no hay forma de hacerlo (que yo sepa).
¿Qué podría hacer que la aplicación falle donde SSMS (y LinqPad y Visual Studio Server Explorer, por cierto) tiene éxito?