If there is a permission missing for this principal, just grant the CONNECT permission at the correct endpoint. grantee_principal_id ) as grantee_principal , To see all the permissions on the endpoints you can run the following query: On the other hand, if the login exists, it may be possible that that particular user doesn’t have permissions to connect in the right endpoint. If you cannot find the proper entry, you can grant permission to connect to SQL Server by adding a login.
You can look first in sys.server_principals for example:Īnd look for your Windows principal name directly, or for a group she belongs to and grants permission to connect.
Bear in mind than any other service from the same machine will have the same privileges.Ĭonnect to SQL server using a sysadmin account and look if the Windows user has access to SQL Server.
Why would SQL care about the computer account hosting the application?įrom your description it seems like the 3 rd party software is attempting to connect to SQL Server using the service account credentials, it is most likely running under “Network Service”, “Local System” or another local account and that’s why when trying to access resources (in this case connect to SQL Server) it uses the machine account ( \$), and as this account doesn’t have privileges to connect to SQL Server it fails.Ĭheck the 3 rd party product documentation, it may be possible that you need to run it using a domain account (I also recommend verifying with your domain administrator regarding your specific environment policies regarding running services under domain accounts).Īnother potential workaround would be to grant permission to connect to this machine account, and granting it the minimum permissions required for the software you are testing. It describes error states 11 and 12 as " Valid login but server access failure" but I'm not sure what that means. I've looked up "error state 11" using the following resource: TESTDA1 is the server name that the 3rd party software is running remotely from. There are two strange parts to this: 1) The application appears to be working fine on the surface, and, 2) The MYDOMAIN\TESTDA1$ account mentioned in the error text is not the user account that we are using to connect the application to SQL 2005. " and "Login failed for user 'MYDOMAIN\TESTDA1$'. The text accompanying the message alternates between "Login failed for user 'MYDOMAIN\TESTDA1$'. The SQL Error Log is saturated with the error message listed in the subject line. We're testing out a 3rd party application that is using Windows Authentication to connect to SQL 2005. I have a SQL 2005 SP1 test server running Developer Edition on top of Windows Server 2003 SP1.