Security.Is It a Bug, or it's normal? | SQL Server Performance Forums

SQL Server Performance Forum – Threads Archive

Security.Is It a Bug, or it’s normal?

Hi folks!
For better security, it’s strongly recommended to use Windows only Authentication and not allowing SQL Server Authentication.
Well, if i configure my SQL eg, SERVER1 for Windows Only Authentication; SQL Server authentication is not allowed for local and remote logon!
If i try connecting SERVER1 using SA logon, SQL doesn’t allow me to logon and i get the following error:
Not a Trusted Connection.
NOW, I create an ALIAS named SERVER1 on a network or local DB machine with NAMED-PIPES protocol using client-network-utility.
If i try connecting SERVER1 using SA logon now, i can fairly connect to the Database Server even configured with WINDOWS ONLY AUTHENTICATION! Why does the server accepts SQL Authentication on NAMED-PIPES. Is it a flaw, or is documented process!
A DBA seems to work only when the users can’t, so i scarcely work!
No its not a flaw, as you’ve configured the ALIAS in client network utility the server is contactable and using SA account with windows authentication it will allow the connection. When the application is on the same computer as an instance of SQL Server 2000, Windows Interprocess Communication (IPC) components, such as Local Named Pipes or Shared Memory, are used. When the application is on a separate client, a network IPC, such as TCP/IP or Named Pipes, is used to communicate with SQL Server. After installing SQL Server 2000, you need to define the behaviors of the client Net Libraries by using the Client Network Utility and server Net Libraries by using the Server Network Utility. If your connection fails with an error for a SQL Login, for example, "Login failed for user ‘sa’. Not associated with a trusted connection," then verify that SQL Server is set up for Windows and SQL Authentication. Try connecting using different Windows or SQL logins. Also try connecting using alternate protocols. Satya SKJ
This posting is provided “AS IS” with no rights for the sake of knowledge sharing.
Hi Grand Ma, nice to c ya! thanX for clearing.
I was thinking that when we set SQL for WINDOWS AUTHENTICATION; it means that SQL won’t accept SQL credentials at all; coz Windows Authentication is much more secure and there’s no need to pass SQL passwords. Even on the local machine, if we try connecting using SQL authentication, it doesn’t allow to do so; But through named-pipes a user can easily go through SQL Authentication!
Son, I think you’re confused.
For named pipes, network communications are typically more interactive. A peer does not send data until another peer asks for it using a read command. A network read typically involves a series of peek named pipes messages before it begins to read the data. These can be very costly in a slow network and cause excessive network traffic, which in turn affects other network clients. Network protocol has no affect on Authenticate mode to connect SQL SErver, if you use WIndows authentication and while connecting even though if you specify username and password it will allow your connection (as windows authenticated) as your login is already has permission as per the setting. Satya SKJ
This posting is provided “AS IS” with no rights for the sake of knowledge sharing.
Just to confirm/clarify Satya’s last post: Your windows account has access to SQL, specifying SQL connection details is ignored.
To check this is really true, either: Run a trace – you’ll see you are authenticated with your windows account Try this whilst logged into your PC with a local account. The connection will fail.