Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
odbc connect to sql SErver
- Thread starter orch10
- Start date
- Thread starter
- #3
Olaf Doschke
Programmer
There is no technical problem, you just have no permission to connect. Exactly what the message says or should say (I don't speak Spanish or Portuguese)
When you go with Windows authentication that has the comfort of letting Windows handle the authentication the same way it handles it for your login or access to mapped drives and folders and files etc without you needing to repeatedly login with your password, just once when starting your Windows session. So as a side note: You don't realize how often Windows file system and network check who you are and whether you have access just because you're not bothered to repeatedly enter your password once you have logged in.
When you set up SQL Server that way that doesn't mean all Windows accounts are getting all privileges by default, you have to administrate logins in MSSQL Server:
Just to bust a myth about the [tt]Trusted_Connection=True[/tt] option doesn't tell SQL Server to simply trust the connection, it gets clearer in the nomenclature of OleDB providers, where the same option is specified with [tt]Integrated Security = SSPI[/tt] means using Windows authentication mechanisms, SSPI is short for Security Support Provider Interface.
So the part, which makes this secure is that this Windows interface is very secure and also you don't store the user/password credentials within a connection string or in the DSN. The ODBC Data Source Administrator will ask you for credentials only for testing the connection, it will not store this in a System DSN.
The part that makes using Windows authentication for SQL Server comfortable is not, that everyone has automatic access, that would be a very unsafe policy. You just can recycle assignments you did for users in user groups accessing the file system and application-specific shared and now also assign the same Windows groups to application databases. Administering users then just remains adding them to the corresponding Windows user groups. But SQL Server still needs to know which Windows accounts or groups should have which permissions. So this choice for connecting is also only getting you connected when you have permissions defined by the sysadmin of the SQL server.
Bye, Olaf.
Olaf Doschke Software Engineering
When you go with Windows authentication that has the comfort of letting Windows handle the authentication the same way it handles it for your login or access to mapped drives and folders and files etc without you needing to repeatedly login with your password, just once when starting your Windows session. So as a side note: You don't realize how often Windows file system and network check who you are and whether you have access just because you're not bothered to repeatedly enter your password once you have logged in.
When you set up SQL Server that way that doesn't mean all Windows accounts are getting all privileges by default, you have to administrate logins in MSSQL Server:
Just to bust a myth about the [tt]Trusted_Connection=True[/tt] option doesn't tell SQL Server to simply trust the connection, it gets clearer in the nomenclature of OleDB providers, where the same option is specified with [tt]Integrated Security = SSPI[/tt] means using Windows authentication mechanisms, SSPI is short for Security Support Provider Interface.
So the part, which makes this secure is that this Windows interface is very secure and also you don't store the user/password credentials within a connection string or in the DSN. The ODBC Data Source Administrator will ask you for credentials only for testing the connection, it will not store this in a System DSN.
The part that makes using Windows authentication for SQL Server comfortable is not, that everyone has automatic access, that would be a very unsafe policy. You just can recycle assignments you did for users in user groups accessing the file system and application-specific shared and now also assign the same Windows groups to application databases. Administering users then just remains adding them to the corresponding Windows user groups. But SQL Server still needs to know which Windows accounts or groups should have which permissions. So this choice for connecting is also only getting you connected when you have permissions defined by the sysadmin of the SQL server.
Bye, Olaf.
Olaf Doschke Software Engineering
- Status
Similar threads
- Locked
- Question
