No estoy 100% seguro de lo que quieres decir:
Trusted_Connection=True;
ES usando credenciales de Windows y es 100% equivalente a:
Integrated Security=SSPI;
o
Integrated Security=true;
Si no desea utilizar seguridad integrada/conexión de confianza, debe especificar el ID de usuario y la contraseña explícitamente en la cadena de conexión (y omitir cualquier referencia a Trusted_Connection o Integrated Security )
server=yourservername;database=yourdatabase;user id=YourUser;pwd=TopSecret
Solo en este caso se utiliza el modo de autenticación de SQL Server.
Si alguna de estas dos configuraciones está presente (Trusted_Connection=true o Integrated Security=true/SSPI ), luego las credenciales de Windows del usuario actual se utilizan para autenticarse en SQL Server y cualquier user iD= la configuración se ignorará y no usado.
Como referencia, consulte el sitio de cadenas de conexión para SQL Server 2005 con muchos ejemplos y explicaciones.
El uso de la autenticación de Windows es la forma preferida y recomendada de hacer las cosas, pero podría generar un ligero retraso ya que SQL Server tendría que autenticar sus credenciales en Active Directory (normalmente). No tengo idea de cuánto podría ser ese ligero retraso, y no he encontrado ninguna referencia para eso.
Resumiendo:
Si especifica Trusted_Connection=True; o Integrated Security=SSPI; o Integrated Security=true; en su cadena de conexión
==> ENTONCES (y solo entonces) tiene autenticación de Windows sucediendo. Cualquier user id= la configuración en la cadena de conexión se ignorará .
Si NO especificar cualquiera de esos ajustes,
==> entonces NO tiene lugar la autenticación de Windows (se utilizará el modo de autenticación de SQL)
