We have a local group the consists of users from a trusted domain.. THis is a one way trust, us trusting them.. When I add that local group as a trusted SQL login the users cannot access the database... We have narrowed it down to the security by verifying the user can log in using a test sql account and hit the database.. Any ideas??? IS it possible to map an account to a Local group on the domain or does it have to be a global group????
-A "master domain" AD, a "sub domain" AD, a trust relationship between the two (sub trust master) -A sql server 2005 on a win server 2003 in "sub domain" AD -A linked server to "sub domain" AD -A linked server login using a "sub domain" admin acccount -A view to this linked server -A grant on masterDomain/Domain Users to the database -A grant on subDomain/Domain Users to the database -We want all connections done through "Windows Authentication" not "Database Authentication".
Queries on the view work fine using "sub domain" user accounts. Queries on the view fail using "master domain" user accounts (including master domain admin accounts)
"Msg 7399, Level 16, State 1, Line 1
The OLE DB provider "ADsDSOObject" for linked server "ADSI" reported an error. The provider indicates that the user did not have the permission to perform the operation."
All connections are done through "Windows Authentication" not "Database Authentication".
Can we establish cross domain connectivity with "Windows Authentication" ?
Below are details of the implementation:
SELECT TOP (100) PERCENT * FROM OPENQUERY(ADSI, 'SELECT displayname, givenName, sn, cn (etc...) FROM ''LDAP://OU=PEOPLE,DC=subDomain,DC=com'' WHERE objectCategory = ''Person'' AND objectClass = ''user'' ')
In SQL Server Mngt Studio in Server Objects/Linked Servers/Providers/ ADSI properties security tab I have:
"connections will: <be made using this security context> Remote login:'subDomainAdminAccnt' With password: 'subDomainAdminAccntPassword'
Error: Msg 7399, Level 16, State 1, Line 1
The OLE DB provider "ADsDSOObject" for linked server "ADSI" reported an error. The provider indicates that the user did not have the permission to perform the operation.
Msg 7320, Level 16, State 2, Line 1
Cannot execute the query "SELECT displayname, givenName, sn, cn
FROM 'LDAP://OU=PEOPLE,DC=subDomain,DC=com'
WHERE
objectCategory = 'Person'
AND objectClass = 'user'
" against OLE DB provider "ADsDSOObject" for linked server "ADSI".
I am trying to perform an upgrade to 7.0. I have a two-way trusted domain in place. When I try to proceed with through the upgrade wizard I received the following error message:
"unable to connect to the export server.."
Basicly what I have is a SQL 6.5 in DOMAIN A and I created a SQL 7 in DOMAIN B. I want to upgrade the database from DOMAIN A to DOMAIN B. Is it possible to do so or does the SQL 7 needs to be in the same domain as the 6.5?
Thanks for any help. I will take any pointer someone can give me at this point.
1. Two trusted domains(Domain 1 and Domain 2) connected through 128kbps intranet in two different buildings. 2. A Computer(Machine 1) running SQL server 2000 connected with Domain 1. 3. An application which connects to sql server and with its related database on Machine 1. 4. I want to replicate data onto a computer (Machine 2) on Domain 2.so that users of domain 1 and domain 2 can have a synchronize database. And whenever they visit each other in different building they have their data availabe to them.
I€™m working on an application that needs to support multiple users without log in and out of Windows. I would like to use trusted/integrated security (domainusername) so I.T. does not have to manage two accounts per operator. Is it possible to use trusted accounts (domainusername) in the SQLClient.Connection object?
I recently changed the name of my pc to MYNEWPC ...but in SQL Server 2005 Security/Logins there are a couple of logins pointing to the old name...would i need to add these, change these or do something to make it point to the new pc name?
Here is what I see that needs to be changed from MYOLDPC to MYNEWPC, how do i go about doing this..is this needed?
One of my users gets the following error when he tries to connect to my SQL Server 2000 database using windows authentication via Query Analyzer:
[Micorsoft][ODBC SQL Server Driver][SQL Server] Login failed for user '(null)'. Reason: Not associated with a trusted SQL Server connection.
Me and the server are located in Colorado and are on the NADomain. User is in London on the EURDomain. The EURDomain has a one way trust to the NADomain to use NADomain resources. I have granted access to the database to the user via Enterpise Manager as EURDomainuserid. All the literature I've read says this should be sufficient to connect but isn't. User can connect with SQL Server authentication. Users on the NADomain in Toronto can connect just fine with Windows Authentication. EURDomain user can access other file server resources in the same building as the SQL Server in Colorado.
SQL Server version is:
Microsoft SQL Server 2000 - 8.00.818 (Intel X86) Standard Edition on Windows NT 5.0 (Build 2195: Service Pack 4)
EURDomain Client ODBC version is 2000.85.1022.00 and MDAC is 2.8.
(Cross post from newsgroup) Attempting to implement Windows authentication between trusted domains. . . I have a domain trust set up between two domains connected via persistent vpn:
Is there a way to change a logins based on domain users, we just changed domains so all the domainlogin logins are not working anymore. Do I have to reapply every security on every database object? There has to be a fix for this, its a common thing.
Any help is greatly appreciated, everything i googled applied to SQL Server 2000 and system tables that dont exist in 2005
This question is regarding a brand new out-of-the-box SQL Server 2005 Workgroup Edition install. The old SQL Server 2000 server is working properly with regard to the issue we're having:
We are using Windows Authentication, and have created SQL logins for about
40 different groups on our domain. We've given those logins the appropriate
permissions on the databases they're supposed to be able to access. The SQL Server is not a domain controller, but is a member of the domain, and domain logins do work for Windows-login purposes on this box.
The problem is that when users try to connect to the SQL server, they are denied access. An error 18456 is thrown, and logged in the Application event log
stating "Login failed for user OURDOMAIN heuser" (example values). The
domain user is properly a member of group added as a login to SQL Server, and we've confirmed that there are not conflicting permissions that would deny those
users access via another route. These same groups are working fine on the SQL Server 2000 box.
This is only a problem for domain-based groups. If we create a local group
on the SQL server machine, through Computer Management -> Local Users and
Groups, then make the same domain users a member of THAT group, and finally then follow the same process to add that local group to SQL Server Logins and set
the database privileges, it works!!
Our group memberships change frequently, and are used for a lot more than
just SQL server permissions. So, using local groups and maintaining
membership in both places is not really feasible. Any ideas why a local
machine group containing domain user accounts would work fine, but a domain
ok, first, I know... I forgot to run a backup of the master database, and I forgot to run a script to caputure logins. Not that that is out of the way... I need to recreate the logins under the Securities tab below the databases. All the company databases have the user names and passwords assigned to them, but they are not able to login, because they are not able to authenticate to the SQL server first.
Is there a script that someone has that will copy the company database security info for the users and recreate them in the SQL security tab?
I know that I can rebuild them manually, but I need to delete them first in the application software, then delete them from the databases, and then recreate them in the application software... and as simple as that sounds... it is a slow moving process.
I would move a Database to another server. I try to use DTS but I have problems with this process because DB have big tables, I think. I try to use DETACH and ATTACH procedures but logins doesn't export. And more, in new server there are already logins from another DBs.
What's the best way to solve this problem? Please, help Thanks
I am a systems analyst and work with an app that runs against 2 SQL Server DBs. Though I have some familiarity with SQL Server and SQL, I am not a DBA.
The app executable is tied to a Windows service. When we install the app, we run a process that builds 2 dbs to include: Tables, indexes, stored procedures, views and user accounts. SQL Server is set up for mixed mode authentication.
Normally, the dbs run off the local db user accounts which are tied to local logins with the same names. We have a client that wants to remove our standard logins so that they can run on only a Windows login. I know I should be able to tie the db users to a Windows login. And I can do the same for the service.
But I am at a loss as to how to get this done. How do you associate db users with a Windows login? When I have tried sp_change_users_login I get an error that the Windows login does not exist. (Though I have added the Windows account to the DB.)
After using ADMT to migrate the domain user or group into the root domain, when I use enterprise manager to try and change the permissions allocated to that domain user/group, i get the 'Error 15401 NT user or Group not found'.
This is a correct error as the user is now in the root domain, however sql (in sysxlogins) still thinks its in the child domain.
Is there a simpler way, other than collecting the users permissions, deleting the user from SQL then adding back in with the correct domainusername format, then adding the permissions back?
I tried renaming the 'name' in sysxlogins (not recommended) and while that worked, whenever I tried to add the migrated user to another database, the login name was missing and would not resolve.
I believe it is something to do with the SID not matching.
we recently migrated from our in-house domain to the Enterprise domain. Everything went smooth except for the fact that I can no longer accept my dBs using my SA or my domain admin account. There is only 1 account I can get into the management studio with but it has no admin privileges, so I can't make any  password changes or add accounts. I don't have a test environment so kind of hesitant to experiment with our production system.
I'm trying to run a test from my test environment which is a non-domain Windows 2000 server to access my domain 2003 with SQL2005. I have install 2005 tools to try to access the SQL server.
- I have try following the KB265808 - no success. - Reading alot of blogs and it seems all are pointing to the same problem. "Remote access" but the settign is enabled.Error Message:
TITLE: Connect to Server ------------------------------
An error has occurred while establishing a connection to the server. When connecting to SQL Server 2005, this failure may be caused by the fact that under the default settings SQL Server does not allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server) (Microsoft SQL Server, Error: 53)
For help, click: http://go.microsoft.com/fwlink?ProdName=Microsoft+SQL+Server&EvtSrc=MSSQLServer&EvtID=53&LinkId=20476
Question: Could Windows 2003 security be blocking access? I'm using sa account to access.
Also, sa account does not seems to work for remote access. It is ok when accessing locally.
Hi all,it happen to me a strange problem:i have a mdb file (in Access 2K) with SQL Server 2K linked tables whoruns on a workstation which is on a different domain that the SQLServer. It works.If i create a mdb file from a workstation which is a the domain of theSQL Server and then i run it a my non-domain workstation i have errormessage:Login failed for user '(null)'. Reason: Not associated with a trustedSQL Server connectionBut if i reattached my tables it works.If someone have an idea....PS: same ODBC on both machines
I'm trying to set up replication from one SQL server to another.
The publishing server is not a member of a domain and is located in a hosting center (but we have full control over the server). I can set up a Snapshot publication just fine.
The subscribing server is located in another remote location and is a member of a domain. Here I can also set up the subscription without errors.
The errors, I think, comes when the snapshot is about to be created, the error is, on the publisher server:
[298] SQLServer Error: 18456, Login failed for user 'NT AUTHORITYANONYMOUS LOGON'. [SQLSTATE 28000]
And the snapshot is not created.
Is it even possible to set up replication like this. I need to transfer the data from one sql server to another so we have a working "backup" so to speek if the other server does not respond.
I have a Web application in asp.net 1.1Iam using windows authentication. The application is on IIS on MachineA. When i try to access this from MachineB as http://MachineA/test/test.aspx, it gives me the error "login failed for user 'null' : not associated with a trusted sql connection"Both MachineA and MachineB are on the same domain & iam not using any sql authentication. Could someone suggest me where i might have gone wrong. Web.config has authentication as 'windows', allow users = "*" and Identity impersonation = trueOn IIS, the vitual directory of 'test' application has Directory secuirty set to 'Integrated Security'Please let me know if someone had dealt with similar scenario. Thanks.
Hey all, not sure if this is even possible but is there a way to connection an SQL server with ASP.NET using my username and password as the trusted connection? As I am a trusted connection but the ASP.NET working process isnt. Anything can be done about this apart from addeing the ASP.NET account as a trusted connection?
I was just wondering about the old error:"user not associated with a trusted connection"I know how to solve it, but I dont really understand what im doing. If my connection string is like:Trusted_Connection=true;Initial Catalog=jobitdev;Data Source=192.168.109.4;Packet Size=4096;then how validation is done on the sql server side of things? If i specify the "Trusted_connection" property what does the server do to validate the user? I'm assuming that the user it checks is the current windows user?
I have just installed MSSQL 2000 on Windows 2000. what I am finding is that I cannot open an isql (or query analyzer) session using the sql login (i am successful when i use NT authentication). The error message I get is as follows
Msg 18452, Level 14, State 1: Login failed for user 'xxx'. Reason: Not associated with a trusted SQL Server connection. DB-Library: Login incorrect.
MSDN talks about setting the registry entries differently, but that seems to be only for SQL 7.
I'm attempting to set up a dts transfer SQL 7 box to SQL 7 box. These two servers are on two separate NT domains with no trust relationship, and I will be sending the info across a VPN.
Anyone out there have a similar situation? Offer any recommendations, pitfalls, ports used, ways to do this??? I'd appreciate any ANY ideas on how to make this work. Thanks in advance. -Tricia
Can anyone please tell me how to create a trusted connection?. I am from Unix world and NT is still kind of new to me. Let say my SQL server is located in this machine residing in domain X and I want a NT user, ABC, who is in domain Y to have acess to my server. What do I need to do?. Many thanks.
Is there any way to connect to SQL Server from a non trusted domain. Passthrough authentication works for other NT Server resources (like exchange folder, printers, shared folders), but SQL Server 7.0 does not seem to accept this passthrough authentication (where the username and password are the same in both domains). There is no internet access required.
Does anyone know how to create trusted connections?. What I want to do is to have connection to a sql server that's in a different domain as I am (a NT workstation). I tried to create a login id on the server with my nt id but got an error:
I operate the above environment and have been advised due to application issues to upgrade my ODBC to 3.6 from 2.x
I upgraded one of my clients and am unable to use the already successfully configured and operational Integrated Security, It will only operate with Standard security.
However the other clients with ODBC 2.x are still able to use Integrated Security.
The configuration of both ODBC's in so far as is possible (different screens and entries) is identical. I confirm the after the 3.6 ODBC is installed the end summary screen confirms a Trusted configuration. However the test connection utility fails with the well and guaranteed to give a hernia "not associated with a trusted SQL connection".
With anticipation and thanks.
Peter Dear
PS Why when I do a spell check on ODBC's, does it return "Oddballs"?
