To express myself better i start by example.
In my client server application there is a users table.
Each user is mapped to a sql server user.
The database is full of tables, anyway each user can query just 1 table.
The table contains the following information:
the version of the database (so the client app can check whether the database version matches with the client version)
the db admin login name (tipically "sa")
the db admin password (this is encrypted with custom algorithm for security - please note i install a dedicated Sql Server Instance for my applciation)
I make sure each user can query just a table by executing for each user:
GRANT SELECT ON ConnectionTable TO LoginName
So the full flow is:
1) the user inserts username/password
2) the client application retrieves all the info from ConnectionTable
3) the client applicaion decrytpts the sa password
4) the client application logs in as sa so all tables are visible and editable
Now this is what i have (legacy) and I cannot change it.
Somehow this "custom login trick" has been done to avoid to write somewhere on the client the sa password, many client server software i know in fact all use sa to connect and user/password are just two fields of a simple USERS table, but the real connection string is somehow (with a certain degree of security) saved on a file in each client; in my case the "connection string" is stored in the database so as a user logs in to the database (even if with a user that has a restricted access) he gets all he needs to succesfully login.
Since i install Sql Server in mixed mode i support also Windows AUthentication.
So at login the user has a switch to choose between SQl Server and Windows Authentication, as it happens when connecting to SS Management Studio.
What i am trying to achieve now is to login as another user.
I would like that the user checks "Windows Authentication" but he/she can still type the username and the password.
My application is written in Delphi using the SDAC components. As far as i understand SDAC does not allow to perform what i need to do, but i could change only the login part using anothe DAC (Firedac for example). My goal is to login as another windows user.
The final goal is to query ConnectionTable so that i can retrieve the encrypted sa password and login.
So my question is:
is it possible (in Delphi Seattle VCL Application) to login to a Sql Server database by setting a windos user different than the current logged in user?
UPDATE:
To better explain my need i describe the real scenario that generates my requirement.
I created a web applciation (using VCL for the web) that uses the same authentication method as my client server application does.
Imagine my user is MyDomain\MyUser, when I am in LAN i will use Windows authentication to login, but when I login let's say from my Android Phone I would like to login as MyDomain\MyUser by providing password. This is the case, in fact i do not need to impersonate other users, i just want to login with my user when i am not logged in on a Windows pc in a LAN.
So somohow at the login screen of my application i would like to choose Auth: Win/SQL and in case Win is chosen, i would like to pass the actual username and password to login.
I hope this clarifies more the scenario.
Moreover i also host my application in the cloud and in this case all users are WIndows authentication users of a domain that i created for administratrive purposes, and each user needs to provide username and password to login.
My request comes from the fact that I always supposd that Winows Authentication = LDAP and therefore in LDAP it is possible to specify user and password, while in sql server it looks somehow user is pre-defined (and = to the logged in user) in case of Windows authentication.
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 need to connect to SQL Server using a Windows Authentication user by specifying username and password in the connection string.
Somehow I need to make a connection like this to work:
driver=com.microsoft.sqlserver.jdbc.SQLServerDriver
url=jdbc:sqlserver://192.168.48.61\\sqlexpress2008r2;
databaseName=MyTestDatabase;integratedSecurity=true;
username=mydomain\eric;password=mypwd
Since the requirement seems odd I try to exlpain my scenario:
in my application the users are mapped to SQL Server users (either using sql authentication or windows authentication)
there is a Windows client to access the database from inside the LAN
i am writing a web application (Tomcat8 servlet) to access the database from internet: in this case i want the user to type domain\username and password in the login screen to log him in
The reason why i do this is because I need to test if the supplied domain\username and password are valid. After this check is done i will connect to the db with the sa user but assign to the logged in user the proper privileges (depending on he username).
Because of an architectural constraint I should test this by trying to conncet to the database using JDBC, so the idea is:
create the connection string for a windows authentication user
try to connect
if connection is esatabilished i assume user and password are correct.
So i need to create a JDBC connection string in which i use integrated security and i explictly define a username (DOMAIN\USER) and password. I did not find any example on how to perform this.
driver=com.microsoft.sqlserver.jdbc.SQLServerDriver
url=jdbc:sqlserver://192.168.48.61\sqlexpress2008r2;
databaseName=MyTestDatabase;integratedSecurity=true;
username=mydomain\eric;password=mypwd
This will NEVER work.
So if there is a user abc\user1 in windows whom you want to allow
access to the database, then create a SQL Server login with exactly
same user name and password.
This will never work too.
You just cannot create SQL Server login (opposed to Windows login in this context) with "\", it will be recognized as Windows login and you'll get an error about invalid characters.
Trusted connection or Integrated security means that it's not a server that authenticates you, but it's Windows that does it.
So in no way can you pass Windows name and a password: your account should be verified by Windows and SQL Server will only trust these credentials.
I'm trying to connect to a local SQL Server database but it gives me this error:
Login failed for user 'DOMAIN\Username'.
When I open SQL server and look in the Security\Logins folder then I do see the user DOMAIN\Username. This is also the user that I use to login into Windows with.
My connection string looks like this:
<add name="ServerConfiguration"
connectionString="server=localhost; database=BN_Configuration;
Integrated Security=false; User ID=DOMAIN\Username; Password=123456;"
providerName="System.Data.SqlClient" />
Anyone any idea why I can't login with these credentials?
--
Note I wish to authenticate with a user that exists in the SQL Server database. So I do NOT want to do Windows authentication with Integrated Security set to false.
It looks like you are using a Windows credential as SQL Server credential. Try integrated security = true, and not to specify user ID and password.
In your connection string Integrated Security=false is saying user ID and password are specified in the connection for an account that exists in SQL Server but is NOT a domain user. When Integrated Security=true, the current Windows account credentials are used for authentication. If it's an application it will use the user who is currently logged in, and for a web application it all depends on how your application pool is set up.
You are mixing up the definitions by saying ``Integrated Security=false` but passing domain credentials which is not possible.
Using a domain account
Set Integrated Security=true
Remove the user id and password sections.
Map the domain account in SQL Server making sure to set Windows authentication
If it's a web application, make sure your application pool is set to run under that domain account.
Using a SQL Server Account
Set Integrated Security=false
Create a SQL login, making sure it uses SQL Server authentication
Set the User ID and Password properties of your connection string to be the same details you created above.
Note: Final point, make sure the user also has access to the database you are connecting to (in your case BN_Configuration).
The conventional wisdom says using your Windows user to login to SQL Server is more secure than using a SQL Server user to login. But isn't the authentication nearly identical?
When you login to SQL server with a database user, a login packet is created with the password encrypted. A certificate is attached to the packet and sent to the database. When the certificate is authenticated, the hashed password is matched to the hashed password stored in the database. If they match, you are logged in.
When you login to SQL server with a Windows user, MSGINA creates a login packet, but I'm not sure if or how it's encrypted. A certificate is attached and the packet is sent to LSA. When the certificate is authenticated, how are the credentials verified?
To make this question fair, assume the certificate service is the same, as well as the method to create the password hash. In this scenario, the two methods seem equally vulnerable to a man-in-the-middle type of attack intercepting the login packet.
Depends how you define "secure". There's more to security than the cryptographic details of the authentication mechanism. For example:
With SQL Server auth, accounts/passwords are under the control of the DBAs. With Windows auth (to a domain) they're under the control of the domain admins.
Security policy (e.g. password strength, password aging, password length, permitted login locations/times, disabling accounts) is readily administered (e.g. via group policy) and audited when using domain authentication.
Domain authentication can use multiple factors (e.g. security tokens), whereas SQL Server authentication (AFAIK) can't.
MITM vulns in AD authentication (and more broadly Kerberos in general) would be big news.
Windows login is very secure - assuming Active Directory, you're sending a hash to AD to authenticate you which returns the ticket that is subsequently used to login to SQLServer.
However, this only applies to AD, local users use NTLM which is pretty old and is easily crackable by today's standards.
Windows logins are used to secure pretty much everything, including the user services like SQLServer runs as, so if its not the most secure then you have more worries than user login to your DB.
The question is how you store the password and login information.
When you use Windows-login you can rely on authentication by your active directory server or simply the windows machine, while when login with SQL Server credentials you will need to have the password somewhere in a form that you'll need to encrypt it in order to add it to the connection string.
This might be fine if the application is on the server, but more complicated when it is a rich client which is accessing the server directly. If you have such a scenario in a company, it is better to let active directory deal with the authentication.
In general it is also easier to administrate when you have the same active directory use everywhere.