none
Error: The underlying provider failed on open RRS feed

  • Pregunta

  • Buenas,

    Estoy iniciándome con este ORM. He creado un nuevo usuario de BD Sql Server 2014 el cual utilizo para conectar desde una aplicación de consola pero lanza una Excepción al momento de obtener los datos. ¿Alguna idea de lo que puede estar sucendiendo?. Por otro lado, quiero cambiar las credenciales de conexión, esto es, usuario y password, pero sólo encuentro el usuario que utiliza más no el password ¿cómo puedo cambiar las credencias que utiliza Entity Framework?

    Muchas gracias, saludos cordiales.

    sábado, 23 de mayo de 2015 20:42

Respuestas

  • Si vas a usar la cadena de conexión salvada en el .config, entonces al asistente le tienes que seleccionar la opción de "Yes, include sensitive data in the connection string", con el fin de que incluya la password dentro de la cadena.

    Por el contrario, si las credenciales las vas a dar desde código, entonces la cadena de conexión la construirás dinámicamente concatenando sus varias partes, credenciales incluidas. De ser así, da igual lo que le digas al Asistente, porque no usarás la cadena salvada por éste sino la que tú hayas construido. Esa cadena se la pasarás como argumento al constructor del ObjectContext cuando lo instancies en tu código, y de esa manera usará las credenciales que le hayas pasado en lugar de lo que haya en el .config.

    La autenticación de Windows tiene la ventaja de ser más segura porque no se manejan contraseñas en ningún momento (ni en el .config ni en el programa) con lo que no tienes la vulnerabilidad de que un atacante pueda sacarlas de esos archivos. Cuando usas autenticación integrada, el usuario con el que se ejecutan las consultas es el mismo que está ejecutando el proceso que hace la llamada. Si el proceso es un .exe lanzado desde Windows, el usuario es el mismo que hizo login en Windows. Si es un Servicio, la cuenta se establece en el administrador de servicios. Si es una aplicación web, se pone en el Pool de IIS, a no ser que uses un <identity impersonate> en el web.config.

    • Marcado como respuesta eduar2083 domingo, 24 de mayo de 2015 23:12
    domingo, 24 de mayo de 2015 16:32

Todas las respuestas

  • Si en el momento de obtener los datos dice "The underlying provider failed on open", esto típicamente implica que la cadena de conexión tiene algún error, y en consecuencia no se puede establecer la conexión con la base de datos.

    Para cambiar las credenciales de conexión, simplemente edita la cadena de conexión, que debería estar en el fichero .config de tu aplicación. Ahí encontrarás una cadena con un aspecto similar a este:

    <add name="MiCadena" connectionString="metadata=res://*/ModeloMiAplicacion.csdl|res://*/ModeloMiAplicacion.ssdl|res://*/ModeloMiAplicacion.msl;provider=System.Data.SqlClient;provider connection string=&quot;data source=.;initial catalog=MiAplicacion;integrated security=True;multipleactiveresultsets=True;App=EntityFramework&quot;" providerName="System.Data.EntityClient" />

    La parte que hay que cambiar para modificar las credenciales es la que dice "integrated security=True;". Eso significa "utilizar autenticación integrada", es decir, "pasarle a la base de datos el usuario de Windows". Si en su lugar necesitas pasar un usuario y password de SQL Server (teniendo tu servidor en Modo Mixto), entonces cámbialo por "User ID=usuario;Password=contraseña;".
    • Propuesto como respuesta Sergio Parra domingo, 24 de mayo de 2015 12:56
    domingo, 24 de mayo de 2015 8:03
  • Estoy utilizando Autenticación Sql Server y el error ocurre cuando en el Wizard donde se crea la conexión, selecciono la primera opción, es decir, cuando se oculta el Password, pero no ocurre si selecciono la segunda opción. En ambos casos aparentemente las credenciales son correctas ya que el Test connection responde correctamente.

    1) No, exclude sensitive data from the connection string

    2) Yes, exclude the sensitive data in the connection string


    Si quisiera inyectar las credenciales de conexión desde código, es decir, no tomarlas del .config, ¿sería posible?

    Por otro lado, nunca he utilizado autenticación Windows, no sé que beneficios o contras proporciona, además me crea confusión ya que no tengo idea con qué usuario se ejecutan los procedimientos/consultas.

    Muchas gracias, saludos cordiales.

    domingo, 24 de mayo de 2015 14:50
  • Si vas a usar la cadena de conexión salvada en el .config, entonces al asistente le tienes que seleccionar la opción de "Yes, include sensitive data in the connection string", con el fin de que incluya la password dentro de la cadena.

    Por el contrario, si las credenciales las vas a dar desde código, entonces la cadena de conexión la construirás dinámicamente concatenando sus varias partes, credenciales incluidas. De ser así, da igual lo que le digas al Asistente, porque no usarás la cadena salvada por éste sino la que tú hayas construido. Esa cadena se la pasarás como argumento al constructor del ObjectContext cuando lo instancies en tu código, y de esa manera usará las credenciales que le hayas pasado en lugar de lo que haya en el .config.

    La autenticación de Windows tiene la ventaja de ser más segura porque no se manejan contraseñas en ningún momento (ni en el .config ni en el programa) con lo que no tienes la vulnerabilidad de que un atacante pueda sacarlas de esos archivos. Cuando usas autenticación integrada, el usuario con el que se ejecutan las consultas es el mismo que está ejecutando el proceso que hace la llamada. Si el proceso es un .exe lanzado desde Windows, el usuario es el mismo que hizo login en Windows. Si es un Servicio, la cuenta se establece en el administrador de servicios. Si es una aplicación web, se pone en el Pool de IIS, a no ser que uses un <identity impersonate> en el web.config.

    • Marcado como respuesta eduar2083 domingo, 24 de mayo de 2015 23:12
    domingo, 24 de mayo de 2015 16:32
  • Entonces, ¿cuando  se elige la opción "No, exclude sensitive data from the connection string" no se estaría enviando el password y por eso el error?

    Mi primer intento para asignar las credenciales desde código C# fue sobrecargar el constructor REXDbContext de mi capa Modelo con un parámetro que reciba la cadena de conexión, pero arrojaba un error al enviarle la cadena sin más, esto es:

    var connectionString = "Data Source=SERVER01; Initial Catalog=REXDB; User ID=usrrex; Password=*******;"; // hard code
    var context = new REXDbContext(connectionString);

    Pero arrojaba un error debido a que la cadena de EF contiene otras propiedades como la Metadata, me guié de aquí y con esto pude solucionarlo.

    Yo pienso que los sistemas que están en producción JAMÁS tendrán o debería tener las credenciales expuestas en el .config ya que estarían a la vista para cualquier persona que tenga acceso al servidor.

    Respecto a la seguridad integrada, entonces quiere decir que los usuarios Windows son también usuarios de Sql Server y por tanto también se les puede asignar/revocar privilegios como a un usuario Sql Server?

    Muchas gracias, saludos cordiales.



    • Editado eduar2083 domingo, 24 de mayo de 2015 18:44
    domingo, 24 de mayo de 2015 18:43
  • Respecto a la seguridad integrada, entonces quiere decir que los usuarios Windows son también usuarios de Sql Server y por tanto también se les puede asignar/revocar privilegios como a un usuario Sql Server?

    Exacto. Es más, de forma predeterminada, y salvo que expresamente lo habilites, únicamente se pueden usar en SQL Server los usuarios de Windows. Los de SQL Server tienen que habilitarse pasando el servidor a "modo mixto". Cuando asignes un usuario desde la ventana de "nuevo login" usando SSMS, verás que te da la opción de asignar un usuario de Windows o uno de SQL Server. Cuando eliges "usuario de Windows", también puede ser un Grupo en lugar de un usuario, lo que te permite mapear de golpe múltiples usuarios de Windows a SQL Server. Las asignaciones o revocaciones de privilegios funcionan exactamente igual con independencia de que el login al que se asignan los privilegios sea de SQL Server o de Windows.
    domingo, 24 de mayo de 2015 20:40