Microsoft SQL Server auth_scheme do not show Kerberos [closed] - sql-server

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 2 years ago.
Improve this question
I installed a small test environment in AWS to test Kerberos authentication using the SQL Server Cli found on GitHub. I followed some simple steps to get this set up.
Installed an Active Directory node with Windows Server 2019 Base.
Installed a second node with Windows Server 2012-R2 and SQL Server 2016 SP2 Enterprise.
I joined the SQL Server node to the AD and changed the auth part to use my AD.
I ran this query to test Kerberos
select auth_scheme from sys.dm_exec_connections where session_id=##spid
This query is only returning NTLM. Is there a way to fix this or did I miss something obvious in my setup?
EDIT: Added Raghavendra query to the question.
SQL\Administrator TSQL NTLM SQL Microsoft SQL Server Management Studio - Query
NT SERVICE\SQLSERVERAGENT TSQL NTLM SQL SQLAgent - Generic Refresher
NT SERVICE\SQLSERVERAGENT TSQL NTLM SQL SQLAgent - Email Logger
SQL\Administrator TSQL NTLM SQL Microsoft SQL Server Management Studio
NT SERVICE\SQLTELEMETRY TSQL NTLM SQL SQLServerCEIP
SQL\Administrator TSQL NTLM SQL Microsoft SQL Server Management Studio - Query
Output of setspn -L
PS C:\Users\Administrator> setspn -L sql
Registered ServicePrincipalNames for CN=SQL,CN=Computers,DC=mydomain,DC=com:
TERMSRV/SQL
TERMSRV/sql.mydomain.com
MSSQLSvc/sql.mydomain.com:1433
MSSQLSvc/sql.mydomain.com
WSMAN/sql
WSMAN/sql.mydomain.com
RestrictedKrbHost/SQL
HOST/SQL
RestrictedKrbHost/sql.mydomain.com
HOST/sql.mydomain.com

Can you try to use below query?
SELECT
a.session_id,
b.connect_time,
a.login_time,
a.login_name,
b.protocol_type,
b.auth_scheme,
a.HOST_NAME,
a.program_name
FROM sys.dm_exec_sessions a
JOIN sys.dm_exec_connections b
ON a.session_id = b.session_id
Refer this link for more info

In order to have "Kerberos" as auth_scheme, at the very least you need to log in as an AD user, not a local one. From what I see in your sys.dm_exec_sessions output, all connections are established under either NT Service, which is a local service account, or a local user ("local" meaning it is created on your SQL box, not in AD).
You need to create a domain user, say MyDomain\TestUser, and log onto your SQL box (or run your query tool, at least) using its credentials.
In case that's not enough, you should consult with this help article regarding additional configuration steps. In particular, check out the Kerberos Configuration Manager for SQL Server (its download link is available on the aforementioned page).
If my memory serves, apart from the SPN you need to set some flags for the SQL Server service account, but I can't recall their exact names - "Account is trusted for delegation", or something like that.

Related

How to know I have SQL installed? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 3 years ago.
Improve this question
This is what I have if I search for SQL in my installed programs:
and if I try localhost then I get the connection error.
I CAN successfully connect to online database we have at work but for practicing I want to use my own local DB and I can't connect to it?
Check if you have an entry "Microsoft SQL Server xxxx" in your Start Menu > Programs. If so, you have some bits of SQL Server installed.
If you have this folder - try to find the "Configuration Tools > SQL Server xxxx Configuration Manager", and launch it.
If it open, it should show you a screen something like this:
In the "SQL Server Services" tab, find the entries labelled "SQL Server (xxxx)" - if you don't find any --> you do not have SQL Server installed.
If you find some - is their "State = running" ? If not - SQL Server is installed, but not running, so you cannot connect to it.
The value in brackets after "SQL Server" is the instance name - MSSQLSERVER stands for the default (unnamed) instance which you should be able to connect to using ., (local) (including the parenthesis!), or localhost.
If you see any other string, that's the instance name that needs to be used for connecting to it - in my case e.g. SQL2014, so I can connect to that instance using .\SQL2014, (local)\SQL2014, or localhost\SQL2014.

SSMS - Unable to connect to SQL Server 2017 Express on Azure VM using SSMS on local computer [closed]

Closed. This question is not about programming or software development. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed last month.
Improve this question
We have an Azure Virtual Machine with SQL Server 2017 Express.
However, I can't connect to the SQL Server from my local computer using SSMS.
When trying to connect SSMS throws the error message:
"Cannot connect to (VM name):(port number)
-> A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections."
SQL Server 2017 Express has been natively installed on the VM using the download from https://www.microsoft.com/en-us/sql-server/sql-server-editions-express.
SQL Server 2017 Express has NOT been set up using the setup using the Azure portal like in the example in the following link: https://learn.microsoft.com/en-us/azure/virtual-machines/windows/sql/quickstart-sql-vm-create-portal
I have tried the following guides among others, without luck
- https://logicalread.com/connect-windows-azure-vm-using-ssms-tl01/#.XF1dIjNKiUl
- https://www.youtube.com/watch?v=5UkHYNwUtCo
- https://blogs.msdn.microsoft.com/sqlexpress/2005/05/05/how-to-configure-express-to-accept-remote-connections/
- https://learn.microsoft.com/en-us/azure/virtual-machines/windows/sql/virtual-machines-windows-sql-connect
- https://social.technet.microsoft.com/wiki/contents/articles/36674.access-azure-vm-sql-server-outside-of-network.aspx
I have done the following
- Windows Firewall with Advanced Security
--> Adding firewall inbound rule opening the port 1433 & 49170
- SQL Server Configuration Manager
-> SQL Server Network Configuration
--> Protocols for SQLEXPRESS
---> TCP/IP, set to "Enabled"
----> TCP/IP Properties, IP Addresses, IPAll, "TCP Port" set to 49170
----> TCP/IP Properties, IP Addresses, IPAll, "TCP Dynamic Ports" made blank
-> SQL Server Services
--> SQL Server (SQLEXPRESS), restart service
However, In SSMS my local computer can't connect to the SQL Server on the Azure Virtual Machine.
I have tried starting the SQL Browser Service in SQL Server Configuration Manager, as suggested in
Cannot connect to Azure VM with SSMS
I am using Microsoft SQL Server Management Studio 2016 on my local computer.
Why can't I login to the Azure VM's SQL Server from my local computer using SSMS?
Is there something blocking the connection from SSMS?
I have also tried to ping the VM from my local computer using command prompt but without success.
I can't ping my VM even if I temporarily disabled the Windows firewall on it.
On the following article it says that the Azure load balancer could be blocking the signal https://www.petri.com/how-to-remotely-ping-microsoft-azure-vms
Could this be the same issue which blocks Access to the Virtual Machine's SQL Server from my local computer's SSMS?
I have been having the same problem and here is what worked for me. Check to make sure the Port value in configuration is not empty. When I added it, I was able to connect. See attached screen shot.
enter image description here
You mention that you have opened things up in Windows Firewall, but have you opened any ports in the Azure Network Security Group? By default when you create a VM Azure will create an NSG, you will need to go to the portal and add an NSG rule to allow port 1433.
Also, note that you will be unable to ping an Azure VM from the outside, ICMP is disabled.

Authenticating to a SQL Server instance as a Windows User via JDBC

I'm having to support multiple database types for my tenant-enabled web application. Among others, I have successfully supported Microsoft's SQL Server, by using the net.sourceforge.jtds.jdbc.Driver class with a connection String like "jdbc:jtds:sqlserver://192.168.1.189:1433/ApplicationName". This works, but it requires that the user explicitly defines a user in the SQL Server instance and enables SQL Server authentication.
Now, inevitably, requirements changed, and we're supposed to support connecting to SQL Server via Windows Authentication. Evidently this requires some sort of change to the connection string, since the data base server must somehow be able to distinguish whether the credentials passed into the data base connection are for a user defined in the SQL Server installation or in the Windows OS. But what is it?
Acting on advice from the internet, if progressed as far as extending the connection string with ;useNTLMv2=true;domain=WORKGROUP. That seems to make the data base server aware that I want to authenticate as a Windows user, but the actual log-in fails with
The login is from an untrusted domain and cannot be used with Windows authentication. (code 18452, state 28000)
Now im my testing set-up, both the J2EE app and the SQL server instance are in fact on the same machine (although in production they may not be), and still this computer isn't trusted enough to log on to itself? Evidently I'm missing a big part of the puzzle here. What does one have to do to convince an SQL Server instance that the user who started it can in fact log on to it via JDBC?
Edit
Since we have already sunk too much unsuccessful effort trying to integrate our web application with a full Microsoft infrastructure stack (SQL Server, Active Directory, Domain Name Service...), I have to restrict this question:
Does anyone know a way to access an SQL Server installation with a user account defined as a "Windows User" via JDBC form a J2EE application, without having to use Active Directory, a Windows machine running the web application and a proprietary DLL? The bounty is for any solution of that sub-problem. The entire problem is clearly too broad to be answered in one forum post.
I ran into the error
The login is from an untrusted domain and cannot be used with Windows
authentication
when a 2012 SQL Server DB instance was recently upgraded to 2016. In order to use AD based authentication with the JTDS driver and SQL Server 2016, it seems necessary to specify both the useNTLMv2=true and the domain=example.com suffix in order to establish a connection. The name of the domain is absolutely necessary and I confirmed that through testing. This is with JTDS driver version 1.3.1.
Example of a working connection string using AD based authentication to SQL Server 2016 DB with JTDS 1.3.1:
jdbc:jtds:sqlserver://sqlserver2016db.example.com/MY_DB_NAME;domain=example.com;prepareSQL=2;useNTLMv2=true
UPDATE
Recently (due to the pandemic lockdown), I found myself also having to connect to SQL Server using Windows authentication from a non-domain computer (over VPN). This can be accomplished by starting the Windows process initiating the SQL Server connection, e.g. Eclipse / Spring Tool Suite, with the following command:
C:\Windows\System32\runas.exe /netonly /user:domain\user "path_to_executable.exe"
Source: https://www.mssqltips.com/sqlservertip/3250/connect-to-sql-servers-in-another-domain-using-windows-authentication/
In discovering that gem, I also discovered that encryption needed to be used. Here are the settings I'm using (in addition to now running the executable with /netonly and a domain account):
spring.datasource.url=jdbc:jtds:sqlserver://fqdn_of_server_including_domain/DBNAME;domain=mydomain;useNTLMv2=true;ssl=require;prepareSQL=2;
spring.datasource.username=domainaccountname_without_domain_prefix
spring.datasource.password=password
spring.datasource.testOnBorrow=true
spring.datasource.hikari.connection-test-query=SELECT 1
spring.jpa.database-platform=org.hibernate.dialect.SQLServerDialect
What you describe certainly appears to be feasible. I have SQL Server 2008 R2 Express running on a stand-alone server and I was able to connect using a Windows username/password on that server via jTDS 1.3.1 from a separate Windows machine and from an Xubuntu 14.04 box.
On the machine running SQL Server I created a Windows user named 'kilian'. In SQL Server itself I created a SQL Login for NT AUTHORITY\Authenticated Users. Then in the database (named 'myDb') I created a User named 'AuthenticatedUsers' for that SQL Login. Just to keep things simple I gave that user db_owner rights on the database.
There is no SQL Login for 'kilian' and no database User with that name.
Then, from the other two machines (the Windows workstation and the Xubuntu box) I just ran this:
package com.example.jtdstest;
import java.sql.*;
public class JtdsTestMain {
public static void main(String[] args) {
try (Connection con = DriverManager.getConnection(
"jdbc:jtds:sqlserver://192.168.1.137:52865/myDb" +
";domain=whatever",
"kilian",
"4theBounty")) {
try (Statement s = con.createStatement()) {
String sql = "SELECT LastName FROM Clients WHERE ID=1";
try (ResultSet rs = s.executeQuery(sql)) {
rs.next();
System.out.println(rs.getString("LastName"));
}
}
} catch (Exception e) {
e.printStackTrace(System.out);
}
}
}
Additional notes:
I did not have to include useNTLMv2=true. I was able to connect with or without that parameter.
I did have to include domain= to tell the SQL Server not to use SQL authentication, but the actual value I supplied made no difference. (I literally used 'whatever', which was not the name of the server or the name of the workgroup to which it belongs.)
Alternative Method
The alternative solution is to utilize integrated security. This enables your application to connect to the database as the user in which the application is currently running as. This is enabled by adding integratedSecurity=true; into the connection string properties. If you run into any trouble, make sure the sqljdbc_auth.dll is accessible via classpath or within your app library.
Security Note
You're probably already aware, but just have to say make sure not to grant access to "Authenticated Users" to your database as previously suggested as part of the demonstration. Identify which user account your application runs as and grant access to only that specific user in your database server.
Sources / Additional Info
MSDN Doc on JDBC Connection String Configuration (http://technet.microsoft.com/en-us/library/ms378428(v=sql.110).aspx)
The main problem is the windows authentication with a full java solution (no DLL). So you could use one of the libs below:
NTLM authentication: http://ioplex.com/jespa.html
spring based Kerberos authentication: http://projects.spring.io/spring-security-kerberos/
another integrated windows auth lib is SPNEGO (don't know much about this one)
So once your app is authenticated with one of the lib above, your JDBC should run fine using "integratedSecurity=true;" and if needed "authenticationScheme=JavaKerberos".
Firstly you should write the jdbc connection like this:
String url ="jdbc:sqlserver://PC01\inst01;databaseName=DB01;integratedSecurity=true";
then
you need to enable the SQL Server TCP/IP Protocol in Sql Server Configuration Manager app. You can see the protocol in SQL Server Network Configuration.
I can see two possibilities,
1. You are using a local system account which the server won't understand
In this case, switch to a domain account.
Windows authentication has different credential requirements and you might not be meeting those.
In this case try changing the password to match the requirements.
It is very well possible that both are happening.
see this other SO post that describes how to connect to a SQL Server with Windows Authentication from a Linux machine through JDBC
This is my NiFi setup for jTDS driver:
Database Connection URL: jdbc:jtds:sqlserver://192.168.1.189:1433;DOMAIN=domain_name
I didn't need to add useNTLMv2=true, but most people need to, so if it doesn't work you can try also:
jdbc:jtds:sqlserver://192.168.1.189:1433;DOMAIN=domain_name;useNTLMv2=true
Database Driver Class Name: net.sourceforge.jtds.jdbc.Driver
Database User: domain_user_name (**without** #domain)
Password: domain_password
Validation query: select 1
One of the possible reasons for this error to appear is when you configure you data source to use windows authentication and SQL Server is using Extended Protection mode together with SSL (i'm not sure if SSL is required though). This mode requires the client to send additional information - signed service principal name (SPN) and channel binding token (CBT). See more information about Extended Protection Mode here. Currently both JTDS JDBC and Microsoft JDBC drivers do not support this mode. I couldn't find an official statement from JTDS, but there is an open ticket for Microsoft drivers.
In order to configure Extended Protection mode, go to SQL Server Configuration Manager, select properties on SQL Server Network Configuration -> Protocols for %your instance% and change Extended Protection option.

Error connecting to SQL Server using SQL Server Management Studio

I've been trying to connect to SQL Server using SQL Server Management Studio to no avail.
This is what the error says:
Cannot connect to .\HAMED.
ADDITIONAL INFORMATION:
Login failed for user 'HAMED'. (Microsoft SQL Server, Error: 18456)
I have an instance of SQL Server by the name of Hamed which is run in Network Sevice mode. I'm using Windows 7.
I'm guessing you didn't grant yourself SQL admin during the install, but are you sure the DB instance is "HAMED"? That sounds like the machine name. Try connecting to .\sqlexpress
Do you remember the SA password? If so, you can add yourself by logging in with that account. Otherwise, you'll have to jump through some hoops and loops to get yourself added.
If you forgot to add yourself to the SQL admin group, read this article:
http://blogs.ameriteach.com/chris-randall/2009/12/11/sql-server-2008-forgot-to-add-an-administrator-account.html
It looks like you're trying to use "SQL Server Authentication" in the login dialog in SSMS, but the user that you're trying to use is a Windows user/administrator? If so, the fix should be as simple as choosing "Windows Authentication" in the drop-down.
UPDATE: looks like I jumped the gun - this sql server forum thread lists lots of possible issues, including permissions issues, orphan users, etc.
sa... the answer was sa.
I had set the administrative password but didn't know the username to go with it. Very nube, I know, you can hit me with it later.
When I installed SQL it asked me to set administrative password - right now SSMS can login.
Under users I see 1\cory (1 is my machine name - I'm trying a numbering scheme). But if I type that in it fails with the error. SQL says "no, that's an NT login, I can't use those".
Under the users list SQL does in fact show the user as Windows authentication but as I said - for some reason I can't connect using Windows authentication. The connection times out.
I'll just add a direct user name here.
All this is to do the MSVA courses for SQL certification. First exam: get sql SSMS to work.

Minimum permissions for a SQL server "heartbeat" check?

We are developing an application to do a "hearbeat" test of all our SQL servers (2000, 2005 and 2008), and we're trying to figure out the minimum permissions necessary on the SQL server to do that. (Platform involved is TBD, but should use a standard connection string).
We are considering using a "SELECT ##VERSION" query, which should be all that is necessary to determine that the sql server is up and running and responding to requests.
What are the minimum SQL permissions necessary to simply connect to the server with a connection string? (We don't even want to give DataReader, if at all possible) Will those minimum permissions allow me to do the above query? Is there a better/more standard technique for doing this? Will SQL 2000, 2005 and 2008 behave differently?
Just create the login used by the monitor code. On SQL Server 2005 and 2008, you'll also need GRANT CONNECT SQL TO (login), otherwise it's the same.
No other rights are needed for SELECT ##VERSION. The db_datareader you mention is within a database, not the server level.
SQLPing will detect an installation but not always tell you if it's running.
When do do run SELECT ##VERSION, make sure that you open and drop a connection. A connecion left open may still work even if the SQL Servr is not accepting new connections.
Consider SQLPing.
Quote: "SQLPing can be used to discover detailed information about the connectivity of SQL Server 2000 installations without authentication of any kind."
Or google for SQLPing yourself. I've seen several other utilities of the same name.
All that is required is a permission on the tempdb database. This database is guaranteed to be present across all servers and all versions.
This will also make sure that the audit requirements are met as you do not have to give access to any other database for the heartbeat check.

Resources