Is there a way in SQL Server Management Studio 2005 (or later) to change the Windows Authentication user (as you could in SQL Server 2000 and older)?
This is the general connection properties dialog(note the greyed out UID/PWD when selecting Windows Auth):
FYI - One workaround is to use runas but I'm looking for a solution that will allow me to work with multiple Windows accounts across multiple servers (and across multiple domains).
While there's no way to connect to multiple servers as different users in a single instance of SSMS, what you're looking for is the following RUNAS syntax:
runas /netonly /user:domain\username program.exe
When you use the "/netonly" switch, you can log in using remote credentials on a domain that you're not currently a member of, even if there's no trust set up. It just tells runas that the credentials will be used for accessing remote resources - the application interacts with the local computer as the currently logged-in user, and interacts with remote computers as the user whose credentials you've given.
You'd still have to run multiple instances of SSMS, but at least you could connect as different windows users in each one.
For example: runas /netonly /user:domain\username ssms.exe
Hold shift and right click on SQL Server Mangement studion icon. You can Run as other windows account user.
One other way that I discovered is to go to "Start" > "Control Panel" > "Stored Usernames and passwords" (Administrative Tools > Credential Manager in Windows 7) and add the domain account that you would use with the "runas" command.
Then, in SQL Management Studio 2005, just select the "Windows Authentication" and input the server you wanna connect to (even though the user that you can see greyed out is still the local user)... and it works!
Don't ask me why ! :)
Edit:
Make sure to include ":1433" after the server name in Credential Manager or it may not connect due to not trusting the domain.
None of these answers did what I needed:
Login to a remote server using a different domain account than I was logged into on my local machine, and it's a client's domain across a vpn. I don't want to be on their domain!
Instead, on the connect to server dialog, select "Windows Authentication", click the Options button, and then on the Additional Connection Parameters tab, enter
user id=domain\user;password=password
SSMS won't remember, but it will connect with that account.
The runas /netonly /user:domain\username program.exe command only worked for me on Windows 10
saving it as a batch file
running it as an administrator,
when running the command batch as regular user I got the wrong password issue mentioned by some users on previous comments.
For Windows 10:
Go to the Sql Management Studio Icon, or Short Cut in the menu:
Right Click > Select Open File Location
Hold Shift and right Click the shortcut, or ssms.exe file that is in the folder. Holding shift will give you an extra option "Run as different user":
This will pop up a login box and you can type the credentials you would like your session to run under.
A bit of powershell magic will do the trick:
cmdkey /add:"SERVER:1433" /user:"DOMAIN\USERNAME" /pass:"PASSWORD"
Then just select windows authentication
There are many places where someone might want to deploy this kind of scenario, but due to the way integrated authentication works, it is not possible.
As gbn mentioned, integrated authentication uses a special token that corresponds to your Windows identity. There are coding practices called "impersonation" (probably used by the Run As... command) that allow you to effectively perform an activity as another Windows user, but there is not really a way to arbitrarily act as a different user (à la Linux) in Windows applications aside from that.
If you really need to administer multiple servers across several domains, you might consider one of the following:
Set up Domain Trust between your domains so that your account can access computers in the trusting domain
Configure a SQL user (using mixed authentication) across all the servers you need to administer so that you can log in that way; obviously, this might introduce some security issues and create a maintenance nightmare if you have to change all the passwords at some point.
Hopefully this helps!
Did anybody tried "plain" runas without parameters? Those /netonly /savcecred all of them sound ambiguous and to me utter nonsense.
C:\Windows\System32\runas.exe /user:DOMAINX\OtherUser02 "C:\Program Files (x86)\Microsoft SQL Server Management Studio 18\Common7\IDE\ssms.exe"
This works just fine. No matter what, runas WILL ask you for the user password. Just type it and be security audit compliant.
The only way to achieve what you want is opening several instances of SSMS by right clicking on shortcut and using the 'Run-as' feature.
Related
I have an issue with logging a Support user into an Application that has a SQL Server backend.
When configuring the application itself, the SQL set-up asked me to assign whether the Security to access the Application would be Windows Authentication or SQL: server Authentication, I chose Windows Authentication, and as I was using a login called
'LabUser1' I have been able to login to the application fine.
However, when I logon to the server using a different windows login, this time 'Support', SQL keeps giving me the error:
Error accessing the database DSN
Now I know the reason is because the install of SQL happened using the 'Labuser1' profile, but how can I create a script that will allow me to add the 'Support' user to the 'Allowed Logins' so that I can logon to the app server and at least open the Application? (I have seperate logins for when I see the applicatiojn login window, so please don't confuse the matter by thinking it is a simple case of creating a login for Support....I am talking about logging into the server)
The current batch file I am trying to run is:
sqlcmd -S localhost\OCDBB01 -i createSupportlogin.sql
Then I run this batch file after having created the following SQL script:
CREATE LOGIN OCDMW1\Support FROM WINDOWS
GO
Your description of the situation is a bit confusing to me however it appears that the "SQL setup" that is part of the application configuration created a ODBC DSN that uses the credentials of person logging into the machine as the login for SQL Server.
Simply creating a new (correct) login to the SQL instance may not resolve this issue since that does nothing to modify the DSN. If you are tied to using Window Authentication for SQL access it might be necessary to create multiple DSNs for the application to use and find a way to have the correct DSN associated to the right login for the application to use.
Please find all the files I'm refering to at this link:
http://whyisthisinmyfood.com/sql/
I have installed a new copy of "SQL Server 2008 R2 Management Studio Express (x86)" on two Windows 7 computers. The SAME install file for both computers. Installed the same way. (as far as I know, I chose the same options)
One at home and one at work.
The one at home seems to work perfectly I "Execute" this file (ITD132-Inventory Initial with data.sql) and it works fine. When I "Execute" it at work I get:
Msg 262, Level 14, State 1, Line 1
CREATE DATABASE permission denied in database 'master'.
..and a bunch of stuff after that which is caused because the database was not created in the first place.
I have compared the permissions on both computers.
see these files:
home computer : non-networked.jpg
work computer: work-networked.jpg
I read in one post that to create new Logins one must be logged in as the Administrator. I log into the Server Managment studio with my windows credentials and I am the Local Admin for my work computer and I have not been able to find any other place to log in as an administrator for this SQL Server Management Studio (so clearly I'm not sure whats meant by that)
At this point I think my problem is that I need to create a user who is not just the "BUILTIN\User" (because this login does not have permissions) with permissions.
But I have no idea how to login as an administrator to create this user role.
Please forgive me if these are obvious answers as I am just starting with this MS Management studio and am not very familiar with T-SQL.
Thanks,
Diana
If you install SQL Server, you get asked during installation process which user or user group should have the Admin-Privileges. If your computer is part of a domain and you login locally, things might get complicated.
The easiest (but not safest way) to login as a "superuser" if to enable the "sa" user.
this is one user that logs on with a password (not integrated logon) and has all the juice to run every script possible :-) By default it's disabled - googling I found a easy how-to enable it:
http://sudeeptaganguly.wordpress.com/2010/04/20/how-to-enable-sa-account-in-sql-server/
I think you are correct that you need to create another user with enough permission. Generally logging in with "integrated security" using your Windows credentials should have enough permissions (assuming the same user is the user that installed SQL Server). If not, you have better luck logging in as the SQL Server user "sa" (system administrator) which should have full permission. Do you know the "sa" password?
Note: the security mode for SQL Server can be set to "Only integrated security with Windows users", "SQL Server security" or "both". The "sa" account will only work if the SQL Server security is enabled. You may be able to access these settings using your BuiltIn\User account.
First off, I can connect to both databases with SQL Server Enterprise Manager, so I know the servers are up and available. One of them is SQL1, the other is SQLTEST.
In my program when I use the following connection string, it work connects just fine:
conn = New DBConnect("Data Source=SQL1;Initial Catalog=SignInspection;Integrated Security=SSPI")
However, if I change SQL1 to SQLTEST the connection times out I don't get any errors other than the timeout error.
I can run the profiler on SQLTest and see that it is most definitely NOT even attempting to connect. Nothing happens at all, not a peep, nor hellow.
Any ideas? Thanks
EDIT:
Well, it's a moot point now because I got authentication working properly on our SQL1 server.
I'll post the configuration here so perhaps someone else can benefit.
First off, the web server is running IIS and .NET. Users are logged in to the intranet using Active Directory, and the .NET page needs to retrieve their log-in credentials (username most notably). The database is SQL Server 2005, running on a different machine. But the .NET app needs to impersonate as another user to connect to the database.
To successfully do both of these things go to Windows > Run, enter inetmgr and hit run. Navigate to the site and right click > properties, then click on the tab titled Directory Security, click Edit.., make sure only Integrated Windows Authentication and Digest authentication are enabled. Enter your proper AD realm and click OK. Apply the settings/hit OK.
In web.config you need the following lines
<authentication mode="Windows" />
<identity impersonate="true" username="myDomain\MyUserName" password="123mypasswordgoeshere">
replacing, of course, myDomain\MyUserName and 123mypasswordgoeshere with the username and password that has login rights on both your domain and your sql server. The connection string can probably be modified, but this is mine and it works:
Server=SQL1;Database=SignInspection;Trusted_connection=True;
These are the steps that worked for me and hopefully they'll be of use to someone else.
When you connected with the enterprise manager, was that from the same machine as you're running the VB.Net code on?
Otherwise, it can be quite a few things, ranging from firewall or DNS as mdma mentions to being setup with the wrong network protocol or maybe not accepting remote connections.
This article contains a list of things to look at (it's for SQL 2000 but it's something to get you started at least).
The obvious question - does SQLTEST have a database called "SignInspection"? Also do you log on to SQLTEST via SQL Management Studio using Windows Authentication or SQL Authentication? I would expect if either of these were the problem you would get an exception, but its worth checking.
Whenever I try to access SSRS 2008 R2 through a URL (i.e. after being published on the net), it always shows a login prompt when accessing the report. The problem does not appear in the development environment.
How do I prevent this login prompt from showing whenever I try to access a report? For the time being, we are solving this problem by providing a username and password in <appSettings> in the web.config. Once this change is made, the login prompt does not appear.
Is there a better solution to this? Am I doing this the wrong way?
I am assuming the prompt is for the username / password for the domain. Internally you are likely getting through the AD authentication check in your application as you will have permissions to deliver the report (you can test that premise with Firefox or other browser that doesnt handle AD authentication like IE does/
I think you may have setup for basic authorisation to view the report RSReportServer.config rather than web.config is that what you have done? (see this to see example http://msdn.microsoft.com/en-us/library/cc281309.aspx.)
If you are trying to get full anonymous access then you are in for some fun; luckily one of the RS team blogged a way to achieve it; I wouldn't advocate doing it straight onto a production box though.
http://blogs.msdn.com/b/jameswu/archive/2008/07/15/anonymous-access-in-sql-rs-2008.aspx
I'd start with using Internet Explorer, on a domain.. which will pass your credentials (if that is how you have this configured).
It IS possible to configure firefox to pass Windows Authentication / Token.. I don't remember how I had done this previously.
The BEST platform for using SSRS is Apple / Safari.. because when you hit the checkbox that says 'remember password' it actually remembers the password. It blows my mind that Chrome, Firefox, IE give you a prompt that says 'remember password' - but from my experience, remembering passwords only work as I expect when I am using Safari.
I'm not sure from you're question is the login box a prompt to get you access to the report server or is it a prompt on the reports datasource.
It sounds a bit like permissions to access the report server, I guess you could try giving the app pool user permissions to access the report server and run the report or use an impersonation account to access the report.
I was running into this problem for a different reason than the accepted answer. While SSRS was installed, it wasn't properly configured. Being new to installing SSRS, I had assumed some tabs in the Reporting Services Configuration Manager were set to defaults. They weren't. Once I went back and actually set them, everything worked fine.
Disable loopback
http://thetazblog.taznetworks.com/2006/03/crm-30-sbe-sql-reporting-error.html
............................
Under normal circumstances, a VB.NET application of mine can check the ClientName environmental variable to get the name of the workstation the user is connecting from.
So when WorkstationX RDPs into ServerA:
ComputerName=ServerA
ClientName=WorkstationX
That works fine.
If I right-click on the application and choose Run As Administrator, the ClientName variable is not set.
Does anyone know of a way of easily getting the workstation name of the client connected to the terminal server, even when the application is launched via "Run As Administrator"?
If you don't want to deal with the P/Invoke business yourself, you can use Cassia, which wraps it for you:
New Cassia.TerminalServicesManager().CurrentSession.ClientName
The terminal services API might be your answer. I use it in a VB.NET app to log off user sessions on a given server, and to retrieve the names of the workstations connected to those sessions. The code I have has a lot of p-invoke stuff and is rather unwieldy, but I can post it if you want.