I have a .Net application that connects to a SQL Server over the network. The user logs in as the Windows user. The SQL Server is set up as Windows Authentication only. From the client machine, the user is not created on the SQL Server as a login yet. On the first startup of the application, the application needs to check if the windows user is a sql server login and if not, the login must be created by the .net application.
My question is with which user do I log in to the SQL Server to check if the login exists. Obviously it cannot be the current windows user, as this user must be created first and on first run does not exist on sql server.
I already know how to proceed once a connection is established, and need help on the correct login to use when the windows user does not exist as a login on SQL server. Keep in mind that the server is set up for Windows Authentication only.
All of this must be done through .net code (vb or c#).
Thanks for the help.
I do not fully understand your question, but answering it upon what I think you are asking:
You need to be logged in as the Administrator in Windows since you are using Windows Authentication Only.
Once you have logged in as Admin, Windows will recognise that and give you all the authentication rights so when you go into your SQL server these rights will automatically be passed on, allowing your to create new user permissions and grant access etc...
Let me know if this answers your question correctly.
Related
The authentication mode is "Mixed" for my SQL Server 2016.
I'm using SSMS to run cross-server queries.
I've checked the user account & have ensured that the account has proper authority. I can use a different account and run cross-server queries as expected. The account has proper authority to the databases in question and it has authority to them. I've tried everything I've seen on the internet searches I've done and no luck. The account can login using SSMS.
My linked server properties are:
The account's login properties are:
Has anyone else seen this & have a resolution?
** EDIT: rebooting the target server fixed the issue
When creating a linked server you choose the authentication mechanism by which the remote connection will be made. If you select the fourth option (pictured), the remote login must be a Sql Server authenticated login. It cannot be a windows login.
The only way to connect through a linked server using windows authentication is to forward the credentials of the login on the local server. There is no option to specify a windows username and password.
Indeed, there is no way, ever, to specify a password when connecting to a Sql Server with windows credentials, since the whole point of windows credentials is that you're already authenticated. That happened when you logged in to windows in the morning*
You can only (and must always) specify a password if you are using Sql Server authentication.
What seems to be going on in your case is that the linked server may have been created with the wrong security options. This is just easier to explain with an image:
* More precisely, a connection will be made using the account that the client is running under. If you start SSMS using a "runas /user ..." command, then the windows credentials used to connect to servers will be the credentials specified in runas
When moving my SQL database from the test location to the production environment I've had to move from SQL server authentication to windows authentication. The server is setup for only "sql" login accounts to be able to access it, rather than the everyday user accounts that exist within the company.
This means that the easiest way to make a database viewing tool like DBeaver work is to "run as" your sql login and use the windows authentication dialogue via right click.
My app is an outlook addin though, and so outlook needs to run as the normal user, otherwise they get the wrong email! Is there any way to set the add-in to always run as a particular windows user, or to get it to "login" as that user when it's loaded?
The connection string to authenticate for the current user is easy enough to find on: https://www.connectionstrings.com/sql-server/
This question is answered under a question about active directory authentication here. Hopefully leaving this under the windows authentication tag here will avoid future confusion.
The answer is that it's only possible to authenticate against the "current" user, and there's no way to use a different username for different portions of software. The only way to do this is via other authentication methods.
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.
I have a simple EF Code First project that has to create a database in my local SQL server if it doesn't exist. However, when I try to debug my application I get the error:
Cannot open database "<Database>" requested by the login. The login failed.
Login failed for user 'MicrosoftAccount\someone#me.com'.'
I somewhat understand that because I login to Windows with my Microsoft account.
So I changed my connection string from using integrated security to username and password.
I made sure the user is created on the SQL server (Login & sysadmin rights) but it still fails when I debug in Visual Studio.
So..... I build the project and ran the application directly via the exe file and everything works. But I want to understand why it doesn't work with the debugger.
Have I missed something obvious here?
So I found the problem.
My local Windows account was paired with my Microsoft account. For some reason Visual Studio sends my Microsoft account to the SQL server to authenticate even when run under specific local credentials.
My solution was to create anew local user on my workstation with NO assosiated MS account.
I made the account member of Administrators and gave it permission to the SQL server then everything was fine...
Please ensure the server and database name are specified correctly in connection string. I had a typo, and got the error.
I guess that the debugger runs with different credentials (or could be set to do so). Especially if your account is not admin.
Maybe this helps: https://blogs.msdn.microsoft.com/greggm/2008/05/15/visual-studio-remote-debugger-service-user-account-requirements/
I've been working to try and connect an ASP.NET application to an IIS Site running in an App Pool using Integrated Security. I was eventually unsuccessful in that attempt until I made the Login I'd created to represent the App Pool a Sysadmin, which I understand is not a good thing to leave in there. It's on localhost, but it still makes me uneasy.
So I decided to try to use a Login/Password combo instead of Integrated Security. To that end, I created a new Login in my SQL Server Management Studio:
And told it to use a password, making sure that I know what the password and username are.
My Default database is master
Server Roles is only 'public'
In User Mapping I added db_owner to one of my databases, and all the others are only 'public'
In Securables, 'Connect SQL' is Granted to the SQLEXPRESS server
I then disconnected from SSMS and tried to reconnect using my newly-created Login.
It didn't allow me to log in:
According to:
https://learn.microsoft.com/en-us/sql/relational-databases/security/authentication-access/create-a-login
After creating a login, the login can connect to SQL Server, but does not necessarily have sufficient permission to perform any useful work.
However, that appears to not be the case in this instance. What am I doing wrong?
I did make sure that my Server Authentication was set correctly, per SQL Server 2008 can't login with newly created user
Another data point: when I try (and fail) to log in 10 times in rapid succession and then go back in with Windows authentication, the 'Login is locked out' notification in the Status tab is not checked.
The thing I was missing was going to Windows Services, and restarting SQLEXPRESS to get the change to 'SQL Server and Windows Authentication Mode' to take effect.
After I did that, I was able to log in with my testuser.