I have a remote database I need to create a linked server to. The problem is it's been set up with my group's functional account an not my own. The only way I can think of doing this is logging out of my personal work account and then back in with out functional account and then set up the link that way, but that is impractical.
So my question is, is there any possible way to set up a linked server using different active directory credentials on a SQL Server 2005 server?\
EDIT: Bascially I am logged in as AD_MAIN\OhioDude but I need to authenticate to the remote server using AD_MAIM\DeptGroup
You can change the properties of the linked server so it uses an alternate set of credentials. From SSMS if you right-click on the linked server and go to Properties -> Security, you can change how the authentication is done for the remote server. I don't know if you can specify a Windows-based login for the remote security context, but it's worth a try.
Related
I have a Microsoft Access Application which generates a connection string like:
Provider=SQLNCLI11;Server=servername;Database=db_name;Trusted_Connection=yes;
This works without any problem.
What I want to do is to connect to a SQL Server instance where the user must insert his Active Directory name and password.
Like this:
Provider=SQLNCLI11;Server=servername;Database=db_name;Uid=username;Pwd=password;
This only works for users which are created on the SQL Server directly.
I tried Uid=DOMAIN\username, but it isn't working.
Is this possible? Or is there another way how I can get through this?
The environment:
The User is using a local PC with a local account and then he's doing a "NetworkConnect" with his AD-User and password.
After that, "RunAs" as his AD-User is working BUT there is another Application that is started from the Access Application and this App must be started with the local User-Account.
SQL-Server and the AD-User are member of the same domain.
Your choices are
Login to SQL Server using your the Windows Domain account that you are currently logged into. You do this automatically by specifying Trusted_Connection=yes;, or
Login to SQL Server using a SQL Login.
Those are the only two choices possible using a SQL provider connection string. Specifically, you cannot use the SQL access provider to do impersonation, that is, to login to SQL Server using a different Windows domain account than the one that you are currently logged into.
Microsoft designed the AD integration with SQL Server to use the account of the client application, not to be able to handle logging in as a part of the connection string. If the user isn't going to be logged into the machine using the account needed for the database access, the next best option may be something like ShellRunAs in order to let the user run your client app as the correct AD account.
Using the example below, which is in my App.Config file, are the uid and password values for the SQL Server, or the SQL Server instance, or for the database that is on the SQL Server?
value="server=localhost;database=myDb;uid=myUser;password=myPass;"
Thanks,
ADawn
Sql Server separates the concept of a login from a user. A server instance itself has logins. Individual databases hosted on a server instance have users.
When you want to run a query or otherwise interact with a database, you generally first connect to the server. You supply a username (uid) and password that match a server login. This login in turn maps to a user in one (or more!) databases hosted by that server.
You can see the user mappings by opening Sql Server Management Studio and connecting to your server. In the Object Explorer area expand the Security and then Login folders (just under "Databases"). Double-click a login to open it's Properties window, and find the User Mappings section.
The connection string also includes a database. The purpose here is (again) because a login might map to more than one database. Specifying a database as part of the connection provides context, so you don't need a database name with every table reference in your SQL code.
There's also Windows/Active Directory authentication (Integrated Security). This makes things even messier, because you can set up Active Directory groups (in addition to users) as server logins to manage access for a number of people at once. An Active Directory user can belong to more than one of these groups... and thus map to more than one user in a single database. In my experience, when this happens you tend to get the union of the set of permissions from every database user you could claim, but I haven't studied that situation thoroughly.
server=localhost;
This is the location of the server. You can use the IP address or the name of the computer. Localhost means this code is on the same machine as the SQL server
database=myDb;
This is your database. Such as master (which is a system one)
uid=myUser;
This is a login on the SQL server. Make sure that login has permissions to the database you are trying to access (and subsequent tables). See the picture below, that is a login abc_test.
password=myPass;
The password for the above user
It is possible to have those Logins as Windows Authenticated logins but in my experience in code it's usually SQL Server authentication (mixed mode) logins.
As sniperd said You can create a new login with a new username and password by right clicking on Logins. Or you can use an existing Login name and change its password. Hope this gonna work!
I'm trying to run a VBScript which calls a stored procedure (SQL Server 2012) that Inserts records into a Linked Server Table.
The script returns the following error:
The Microsoft Access database engine cannot open or write to the file '\999999999\99999999\9999999\9999999.accdb'. It is already opened exclusively by another user, or you need permission to view and write its data.".
Nobody else is using the table.
However, when I execute the stored procedure from Management Studio it works fine. I believe the problem is related to permissions. How do I grant a user explicit rights to Linked Servers?
I apologize for not providing more detail to my question earlier, I made the mistake in thinking that there was a simple solution, with that said here are some more details:
The key to this problem is: When I login as Windows Authenticated User on SSMS I'm able to run my Stored Procedure (Which connects to the Linked Server) without a problem. Couple of more technical points to add as I do more research (and finding this is not a simple problem):
The SQL Server is on Subnet ...5.X
The Access Database is on Subnet ...2.X
VBScript runs from a Job Processing Server on Subnet ...5.X
The Windows Authenticated Account on SQL Server has the Linked Server setup and can connect using the IP address and shared folder \192.168.2.X\Blah Blah Blah\thedatabase.accdb
If I login to SQL Server using SQL Server Authenticated User they cannot access the Linked Server (See error in original post)
If I attempt to run the VBScript from the Job Processing computer as the SQL Server Authenticated User or with a Trusted Connection I'm unable to access the Linked Server.
I've tried mapping a drive on the SQL Server computer for the SQL User (didnt work)
I've tried various combination of Login configurations on the Linked Server: Made without using security context, made using the login's current security context, made using the security context (admin username and password on other machince, SQL server admin username and password)
I've added the SQL User to the domain user group (But I only made them a standard user, need to research this one before making to many modifications)
I've added the SQL User as an Admin on the Access Database computer.
The key to my problem is: Why can the Windows Authenticated user connect to the MS Database via Linked Server and the SQL User cannot
Again apologies for not supplying this much detail upfront but I made the mistake of thinking this was a simple security problem.
From server1, I've created a connection to a remote server (server2) with the Linked Server facilities. Both servers are on the same domain. When I log to server1 I can successfully execute my stored procedures from SQL Server Management Studio but when I execute my stored procedures from my browser application I get the following error on server 2.
Error: 18456, Severity: 14, State: 58.
Login failed for user 'sa'. An attempt to login using SQL authentication failed.
Server is configured for Windows authentication only.
I've searched the Internet and Stackoverflow for solutions but I'm not sure what's the best way to solve this issue. I'm sure it involves adding/changing database security settings but I'm unsure where to make these changes.
Thanks in advance.
Right-click the server in Enterprise Manager, select properties, goto Security, and change to SQL Server and Windows Authentication mode.
Mixed mode is required if you want to use sa or any other sql-account for authentication. However i believe that the recommended way is to keep the server at Windows authentication mode, and use domain accounts for authentication. The sa-account is the quick and dirty way.
If you have the exact same security setup on both servers, the link between them should work if you select "Be made using the login's current security context" in the linked server properties. That way, the account will be "inherited" in the connection to the linked server.
Check under Security - Logins on each of the server so that the same account is added to both servers. Also check the properties of both entries, under Server Roles you can try to add the sysadmin-role to make sure the accounts will have access to all databases on the server. You should however limit this access in live environments :)
I want to create a linked server in one sql server to another using the sp_addlinkedserver procedure. When i access the remote server I would like it to logon as me (i.e. using my windows account). How do I do this?
You can do this with the sp_addlinkedsrvlogin procedure:
EXEC master.dbo.sp_addlinkedsrvlogin
#rmtsrvname=N'<your linked server name>',
#useself=N'True',
#locallogin=NULL,
#rmtuser=NULL,
#rmtpassword=NULL
This assumes you log in to the server on which the link was created using Windows authentication.
Following on from Ed Harper above:
You need to set "Security Account Delegation" for the SQL service account to enable it to pass through your login token.
Edit:
This is not a SQL problem. Delegation/pass through authentication is a Windows/AD feature.
It's also used to enable an intranet web site to use the end user windows login to authenticate onto the SQL box where (of course) the web server is a separate box.
In this scenario, you configure the web server for delegation.
In the OP's scenario, we are enabling the 1st SQL box to delegate credentials onto the 2nd box.
Edit2:
The other thread explains this too.
Finally, nothing to do with SQL logins.
This can be maddening to set up. Check this related question:
https://stackoverflow.com/questions/33153/sql-server-to-sql-server-linked-server-setup
With Sql Server 2005 on a 2K3 domain, the most secure way to set up a linked server, unfortunately, is probably to use an old fashioned Sql Login. You have to make a lot of what I consider risky changes to your domain security settings to get it to work with a domain account.
Use SQL Management Studio to see the properties for the linked server.
There you will find your logon information