SQL Server authentication problem
-
We have four systems, which I will designate as follows: MySvr1 - Windows Server 2003 - MSDE 2000 SP3 MySvr2 - Windows Server 2003 - MSDE 2000 SP3 DbSvr1 - Windows Server 2000 - SQL Server 2000 SP3 DbSvr2 - Windows Server 2003 - SQL Server 2000 SP3 All of these systems are members of a domain that I'll call DOMAIN. MySvr2 has a service running under the local system account. This service wants to access a database using its domain computer account. We've created a security group (call it SecGroup) that includes DOMAIN\MySvr2$ among its members. We've created a database login for SecGroup on all four servers. The service running on MySvr2 attempts to connect to the database using the connect string: Provider=sqloledb;Integrated Security=sspi;Initial Catalog=MyDatabase;Data Source=servername If the service attempts to connect to the database on MySvr2 or MySvr1 it succeeds. Furthermore, if I remove the SecGroup login on MySvr1 and try to connect, I get a login error message that indicates login failure for "DOMAIN\MySvr2$". This is exactly what I would expect and hope for. If we attempt to connect to the database on DbSvr1 we get a login failure: IDispatch error #3149 Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'. If we attempt to connect to the database on DbSvr2 we get a login failure: Unspecified error Login failed for user '(null)'. Reason: Not associated with a trusted SQL Server connection. As one more test, we created a share on DbSvr1 with a file in it. We put an ACL on the share, the underlying folder, and the file, that granted access only to members of SecGroup. When I tried to access the file from MySvr2, while logged in as myself, I got access denied (as expected). When the service tried to access the file it was able to do so, and we could verify that it had authenticated to DbSvr1 as DOMAIN\MySvr2$. The TCP/IP transport is enabled on all four servers. Anyone have any ideas as to what could be causing this? Any remedies? -------- There are 10 types of people in this world. Those who know binary and those who don't.
-
We have four systems, which I will designate as follows: MySvr1 - Windows Server 2003 - MSDE 2000 SP3 MySvr2 - Windows Server 2003 - MSDE 2000 SP3 DbSvr1 - Windows Server 2000 - SQL Server 2000 SP3 DbSvr2 - Windows Server 2003 - SQL Server 2000 SP3 All of these systems are members of a domain that I'll call DOMAIN. MySvr2 has a service running under the local system account. This service wants to access a database using its domain computer account. We've created a security group (call it SecGroup) that includes DOMAIN\MySvr2$ among its members. We've created a database login for SecGroup on all four servers. The service running on MySvr2 attempts to connect to the database using the connect string: Provider=sqloledb;Integrated Security=sspi;Initial Catalog=MyDatabase;Data Source=servername If the service attempts to connect to the database on MySvr2 or MySvr1 it succeeds. Furthermore, if I remove the SecGroup login on MySvr1 and try to connect, I get a login error message that indicates login failure for "DOMAIN\MySvr2$". This is exactly what I would expect and hope for. If we attempt to connect to the database on DbSvr1 we get a login failure: IDispatch error #3149 Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'. If we attempt to connect to the database on DbSvr2 we get a login failure: Unspecified error Login failed for user '(null)'. Reason: Not associated with a trusted SQL Server connection. As one more test, we created a share on DbSvr1 with a file in it. We put an ACL on the share, the underlying folder, and the file, that granted access only to members of SecGroup. When I tried to access the file from MySvr2, while logged in as myself, I got access denied (as expected). When the service tried to access the file it was able to do so, and we could verify that it had authenticated to DbSvr1 as DOMAIN\MySvr2$. The TCP/IP transport is enabled on all four servers. Anyone have any ideas as to what could be causing this? Any remedies? -------- There are 10 types of people in this world. Those who know binary and those who don't.
If TCP is enable, why don't you use this connection string: