Results 1 to 5 of 5
  1. #1
    Join Date
    Sep 2004
    Posts
    2

    Unhappy Unanswered: SQL Server 2000 requiring Windows Authetication

    Hi, I'm having a rough weekend and really need some advice. We've been having some problems with our SQL Server ever since an upgrade to SQL 2K and then were moved by the IT security people to a new domain that is not in a trust relationship with the domain the SQL Server is on. After the move, attempts to log into a CMMS application we use, called Maximo, are failing. The error indicated that the user's domain login isn't trusted with the SQL Server. This is odd, because we use SQL Server Authentication and each user has a different username on the SQL Server and shouldn't care about the domain login, so I don't know why it's even being passed. This application has been working fine on SQL Server 7 for the past 3 years.

    Our SQL Server is setup for Mixed Mode (set during installation and verified in Ent Mgr) and the clients are using ODBC to connect with TCP/IP port 1433 (setup with the client configuration in the ODBC properties) using SQL Server Authentication. The problem is that the settings seem to be ignored and it's using Windows Authentication only, which is a major problem. All of the grants are given to the SQL Server user by the Maximo application and all records are tracked by the login, so we can't use Windows Authentication. I am able to add the user's domain login to SQL Server and give it RW rights to the database and the user is able to login, however unable to run reports because the grants are given to the SQL Server login, not the domain login.

    I tried removing the server from the domain it was on and making it a stand alone server, which resulted in the following error:

    Login failed for user '(null)'. Reason: Not associated with a trusted SQL Server connection.

    This is telling me that it's ignoring SQL Server Authentication. I've also tried installing Patch 3a on SQL Server and installing MDAC 2.8 on the client.

    Please help, I need to get it running by Monday.

    Thanks

  2. #2
    Join Date
    Feb 2004
    Location
    In front of the computer
    Posts
    15,579
    Provided Answers: 54
    My first guess would be that whatever is creating the connection string is specifying that it wants an NT (Trusted) connection, overriding whatever you provide as SQL authentication. This appears to be a client side problem, not server side to me.

    -PatP

  3. #3
    Join Date
    Sep 2004
    Posts
    2
    Thanks for the response, the only problem is that it's an off the shelf application and we can't modify the connection string. We are foced to rely on the ODBC settings on the client side. Oddly enough, it was working ok with SQL Server 7 and we were able to get in from other domains across the internet using port 1433. After SQL 2K this didn't work, so we added everyone to the administrators group to get it working until the problem could be resoved, even though it was a security risk. It wasn't a major problem until everyone was moved off the domain that the SQL server was on, which is beyond our control. I tried to reinstall SQL Server and restore the databases, but still have the problem.

    Quote Originally Posted by Pat Phelan
    My first guess would be that whatever is creating the connection string is specifying that it wants an NT (Trusted) connection, overriding whatever you provide as SQL authentication. This appears to be a client side problem, not server side to me.

    -PatP

  4. #4
    Join Date
    Feb 2004
    Location
    In front of the computer
    Posts
    15,579
    Provided Answers: 54
    If you are using ODBC connections created using the Windows ODBC manager, then that is where the problem appears to be... If you remove then recreate the ODBC connection, you ought to be able to correct the problem.

    -PatP

  5. #5
    Join Date
    Jun 2004
    Location
    Far away from heaven
    Posts
    194
    Try using CLIENT NETWORK UTILITY. Create alias exaclty with the same name as specified in ur application(SERVER NAME). In the alias, select TCP/IP.
    Alias shall overide the network protocol specified in the ODBC.
    Since named-pipes couldn't be used by non-trusted connection, only TCP/IP is allowed; the reason why u can't connect.
    To test this;
    I created an odbc connection named TEST and used TCP/IP in the CLIENT-CONFIGURATION. Then i mention the connection string in my application:
    Provider=MSDASQL.1;Persist Security Info=False;Data Source=TEST
    Connected the application.
    In QA, SELECT * FROM MASTER..SYSPROCESSES
    the NET-LIBRARY in use is TCP/IP

    Now i create ALIAS in the CLIENT NETWORK UTILITY and force the NAMED-PIPES protocol for the servername.
    Connected the application, again.
    In QA, SELECT * FROM MASTER..SYSPROCESSES
    the NET-LIBRARY in use is NAMED/PIPES.

    I suspect your client machines are using older net-library not compatible with SQL2k.
    Also u need to upgrade CLIENT-NETWORK UTILITY on each of the client using SQL 2K setup.
    My 2 cents!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •