I am currently new to managing databases hence the question. From my lecture notes, it states that
A user logs into the network, Windows or otherwise.
The user opens a nontrusted connection to SQL Server using a username and password other than those used to gain network access. It’s called a nontrusted connection because SQL Server doesn’t trust the operating system to verify the user’s password.
SQL Server matches the username and password entered by the user to an entry in the sys.syslogins table.
My question is that how does the user open a nontrusted connection to SQL? I'm confused. What does it mean by SQL Server doesn’t trust the operating system to verify the user’s password.
Trusted connection is a legacy term and really a misnomer mostly because of how developers think of apps connecting to a database rather than how a database actually handles connection requests. SQL Server doesn't actually trusts connections. It trusts a 3rd party that you designated to authenticate a user and present the appropriate token it will then use for authorization. Just so happens Windows is the only 3rd party you can tell it to trust but it doesn't have to be.
Important things to distinguish in the process are authentication and authorization. Both SQL Server and Windows can authenticate a login attempt but only SQL Server can authorize access to objects/data. They are distinct though related parts.
When you connect using integrated authN, your security token is passed to SQL Server which then does basic checks for login mapping to establish connection. If successful, it goes on to do what it needs to for authZ(e.g. database context switch, authorization, etc...). It only cares that you have a valid token from a trusted source. In this case, it's Windows (simplifying the AD, Kerberos, etc... processes behind this). It doesn't further authenticate, it trusts that Windows has done the right checks already. Note that it doesn't have to be a network or domain user. Even local users can be setup for integrated authN but that's generally not a good idea.
If you connect with SQL Server credentials, after the pre-login handshake, your credentials are then passed to SQL Server for authorization where it'll check for login, compare password hash, policies (if any), etc... Essentially, the user authentication checks that Windows would have done when you login to a host but the security scope is SQL Server only. Until this authN is done, you are not logged in. These steps occur because the connection attempt is made with un-validated credentials rather than a secure token issued by a trusted party. Once it successfully completes authN then it goes down the same code path as before for authZ.
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
I have purchased an SSL certificate and installed it using IIS on my remote system. So I can therefore access my remote system using https://myremotesite.co.uk. All is fine, it seems to work; users can register and login to my remote site and download my GUI to run my application which stores and retrieves data from my SQL Server database.
When a user runs my GUI to access my application it prompts them for their login-id and password and, if they are authenticated, my application pops up on their screen. All is well, it all seems to work fine.
However, I have read that access to the SQL Server database itself can be restricted with an SSL certificate and to do this I would need "Encrypt=yes" in the connection string which my GUI uses to check authentication.
Is it necessary for me to do this? Or is safe to just rely on the IIS HTTPS service? So my question is ... do I need to register my SSL certificate with BOTH IIS AND SQL Server or just ONE of them, and if so, which ONE?
Thanks for the answers thus far .. to explain further, the GUI connects to an IIS controlled website which has specific handlers written to perform a restricted set of database queries. So my database DOES reside on my server, but it only allows my server's (local) IIS to 'login' and insert, update and extract data.
Once the IIS website service has extracted data, it then returns the same to the GUI. So the GUI has no DIRECT access to the database. What I am concerned about is if - by some malicious means - the database was copied in its entirety ... could/should I use my SSL certificate to encrypt sensitive data in this event?
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.
If you use SQL Server Authentication (2005), are the login details sent in clear text over the wire?
As secure as you want to make it...
you can configure SSL fairly easily, and if you don't have a trusted cert, if you force encryption, SQL Server can create/issue it's own self signed cert for your use...from this write-up
Credentials (in the login packet) that
are transmitted when a client
application connects to SQL Server are
always encrypted. SQL Server will use
a certificate from a trusted
certification authority if available.
If a trusted certificate is not
installed, SQL Server will generate a
self-signed certificate when the
instance is started, and use the
self-signed certificate to encrypt the
credentials. This self-signed
certificate helps increase security
but it does not provide protection
against identity spoofing by the
server. If the self-signed certificate
is used, and the value of the
ForceEncryption option is set to Yes,
all data transmitted across a network
between SQL Server and the client
application will be encrypted using
the self-signed certificate
Whether or not the login credentials are encrypted depends on the encryption capability/configuration of the client and server.
At the protocol level, completely unencrypted SQL logins are allowed, though my guess is that these are rare because I suspect most modern database drivers do not support them.
Details
Clients communicate with Microsoft SQL Server using the Tabular Data Stream (TDS) protocol.
Shortly after a client opens a TDS connection to the server, it informs the server of its encryption capability. The server compares this announcement with its own configuration/capability to determine the encryption state for the connection.
In a nutshell, the encryption state is determined as follows:
If client or server announces that they do not support encryption and the other side does not require encryption, the entire connection—including login—will be unencrypted.
If both client and server announce that they support encryption but do not require it, just the first TDS packet of the login request will be encrypted. The remainder of the connection, including any additional login request packets, will be unencrypted. A properly-designed database driver will ensure that the SQL authentication password is placed in first login packet, but this isn't required at the protocol level.
If either client or server announces that they require encryption, the entire connection will be encrypted (except for a small amount of preliminary data) unless the other side does not support encryption. In that case, the connection will be terminated.
The only way to ensure that login requests are always encrypted is to set the 'require encryption' option on either client or server. There’s no option to disallow completely unencrypted connections without requiring full encryption.
Regardless of whether or not the login or connection is encrypted, the SQL authentication password is always obfuscated but the scrambling is easily reversible.
Further Reading:
Technical details on connection encryption states - MS-TDS 2.2.6.5 PRELOGIN (under heading Encryption)
Password obfuscation formula - MS-TDS 2.2.6.4 LOGIN7 (see last paragraph)
Slightly more in-depth write-up on the topic - SQL Passwords: Encrypted Between Client and Server? (disclaimer: this is a post on my blog)
The credentials are sent in clear text.
You can probably find a number of sources for this, but here's one:
"Secure the channel between the Web server and database server because credentials are passed in an unencrypted format. For example, use SSL or IPSec."
Here's a link to some security best practices for SQL 2005. That doc states in part:
In Windows Authentication mode,
specific Windows user and group
accounts are trusted to log in to SQL
Server. Windows credentials are used
in the process; that is, either NTLM
or Kerberos credentials. Windows
accounts use a series of encrypted
messages to authenticate to SQL
Server; no passwords are passed across
the network during the authentication
process. When SQL logins are used, SQL login passwords are passed across the network for authentication. This makes SQL logins less secure than Windows logins.
Reading this thread made me even more confuse then I was!
Anyway, I did some tests with Wireshark, with or without encrypted connection I was never able to see my password (and my user name I think). What was very visible without encryption is the actual queries.
Perhaps it is the lack of knowledge with Wireshark to retrieve the login credentials, but since I was able to see everything else I'm pretty sure I was looking at the right spot and the password was ALWAYS hidden.
Apart from the fact that passwords are sent in clear text, it is also possible to replace the hash of the password.
Ever since moving to Vista some time ago on my development machine, connecting to SQL Servers in our DMZ active directory domain from client tools like SSMS has not worked like it used to. In XP, as long as I had authenticated in some way on the server (for example directing Explorer to \server.dmzdomain\c$ and entering valid creds into the login prompt), SSMS would use those cached credentials to connect.
However since switching to Vista, when trying to connect SSMS to a server in the DMZ domain I get the message Login failed for user ''. The user is not associated with a trusted SQL Server connection. If I change the connection options to use Named Pipes instead of the default TCP/IP, my cached credentials are sent and everything works fine. This is the case whether Windows Firewall is off or on, and connections to servers in our internal domain (the same domain my dev PC is in) work fine over TCP/IP or named pipes.
I don't mind too much using named pipes for these connections as a workaround, but it seems like TCP/IP is the recommended connection method and I don't like not understanding why it's not working as I'd expect. Any ideas?
"Login Failed for user ' ', the user is not associated with a trusted SQL Server connection".
In this scenario, client may make tcp connetion, plus, running under local admin or non-admin machine account, no matter SPN is registered or not, the client credential is obviously not recognized by SQL Server.
The workaround here is:
Create the same account as the one on the client machine with same password on the target SQL Server machine, and grant appropriate permission to the account.
Let's explain in more detail:
When you create the same NT account (let's call it usr1) on both
workstations, you essentially connect and impersonate the local account of
the connecting station. I.e when you connect from station1 to station2,
you're being authenticated via the station2's account. So, if you set the
startup account for SQL Server (let's assume it's running on station2) to be
station2's usr1, when you connect to SQL from station1 with station1's usr1
login, SQL will authenticate you as station2's usr1.
Now, within SQL, you can definitely access station1's resources. Though, how
much access will depend on station1's usr1 permission.
So far, SQL only deal with an user who is part of the sysadmin role within
SQL Server. To allow other users (non-sysamdin) access to network resources,
you will have to set the proxy account. Take a look at the article for
additional info.
taken from http://blogs.msdn.com/sql_protocols/archive/2006/12/02/understanding-kerberos-and-ntlm-authentication-in-sql-server-connections.aspx
Have you tried running SSMS in elevated mode, and do you have the latest SP installed on the client?
I would assume that this is because Vista runs most applications in isolation from either other.
I would recommend that you either set the DMZ username and password to match the internal domain username and password, or use named pipes to connect.