I have account set up on SQL Server such that it uses my Windows authentication to connect to SQL Server.
Is there a way I can set up trusted connection to connect to MS SQL in Grails.
I am using :
Grails 2.0.1
SQL Server 2008
Unix
Thanks
If you're using the jTDS JDBC driver (if not, I would suggest it over the MS driver), the README.SSO file included in the jTDS distribution describes how to configure trusted/single-sign-on authentication. There is a native DLL that needs to be made available to the JVM for SSO to work. Note that the DLL is Windows-only, so you wouldn't be able to host your Grails app on Unix.
Another possibility would be to specify your Windows AD domain, username and password in your jTDS connection string. See http://jtds.sourceforge.net/faq.html#urlFormat specifically, the domain property:
domain
Specifies the Windows domain to authenticate in. If present and the user name and password are provided, jTDS uses Windows (NTLM)
authentication instead of the usual SQL Server authentication (i.e.
the user and password provided are the domain user and password). This
allows non-Windows clients to log in to servers which are only
configured to accept Windoes authentication...
Related
We are deploying a java application to RHEL 7.5, this java application need connect to SQL Server 2016. As security request, we must use integrated security to connect SQL Server 2016. Follow Microsoft website's suggestion, we are implementing Kerberos in Windows AD Server and RHEL 7.5.
Unfortunately, we are facing a credentials issue. klist command is working fine on RHEL 7.5, means Kerberos clinet which has installed in RHEL7.5 can talk to Kerberos Server(Windows AD server) as normal. And RHEL7.5 can ping / talnet AD Server and SQL Server.
we have followed Microsoft's spec to set SPN as following:
setspn -A HTTP/SERVER_01.devdc.local#DEVDC.LOCAL devdc.local\admin.
As microsoft's guideline, we should use MSSQLSvc not HTTP, but it has issue when we use MSSQLSvc, we think the reason is OS version of AD server is Windows Server 2012, so cannot support MSSQLSvc protocal. After change to HTTP, kerberos is working fine. Can use kinit generate ticket and use klist to see the ticket information.
Part of our Java code as below:
System.setProperty("java.security.krb5.conf", "~/krb5.conf");
SQLServerDataSource ds = new SQLServerDataSource();
ds.setServerName("192.168.100.150");
ds.setPortNumber(1234);
ds.setIntegratedSecurity(true);
ds.setAuthenticationScheme("JavaKerberos");
ds.setDatabaseName("DB_TEST");
The error details as following:
Error connection to database:(using class com.microsoft.sqlserver.jdbc.SQLServerDriver)
GSSException: No valid credentials provide (mechanism level: Server not found)
KrbException: Server not found in Kerberos database(7)
KrbException: Identifier doesn't match expected value(906)
I would be grateful if you can help.
You don't appear to be setting the SPN. See
A service principal name (SPN) is the name by which a client uniquely
identifies an instance of a service.
You can specify the SPN using the serverSpn connection property, or
simply let the driver build it for you (the default). This property is
in the form of: "MSSQLSvc/fqdn:port#REALM" where fqdn is the
fully-qualified domain name, port is the port number, and REALM is the
Kerberos realm of the SQL Server in upper-case letters. The realm
portion of this property is optional if your Kerberos configuration's
default realm is the same realm as that of the Server and is not
included by default. If you wish to support a cross-realm
authentication scenario where the default realm in the Kerberos
configuration is different than the realm of the Server, then you must
set the SPN with the serverSpn property.
For example, your SPN might look like:
"MSSQLSvc/some-server.zzz.corp.contoso.com:1433#ZZZZ.CORP.CONTOSO.COM"
Using Kerberos integrated authentication to connect to SQL Server - Service principal names.
The driver will attempt to build the SPN for you from the other connection attributes, but you've got an IP address instead of a FQDN, so it cannot build the correct SPN. In the default configuration SQL Server registers its own SPNs and you can see the correct SPN in the SQL Server log, but there are scenarios where additional SPNs must be registered for the service account, and you would need to use the setspn command on Windows to see them.
Assuming your SQL Server is listening on port 1234, and you haven't changed the service account for the SQL Server instance from the default, then the SPNs should be registered for the machine accoune, and the setspn statements should be:
setspn –A MSSQLSvc/SERVER_01.devdc.local devdc\SERVER_01$
setspn –A MSSQLSvc/SERVER_01.devdc.local:1234 devdc\SERVER_01$
if you've set a domain account as the service account, say devdc\sqlsvc then substitute that.
setspn –A MSSQLSvc/SERVER_01.devdc.local devdc\sqlsvc
setspn –A MSSQLSvc/SERVER_01.devdc.local:1234 devdc\sqlsvc
TL/DR use the SQL Server's fully-qualified domain name (FQDN) for setServerName() instead of an IP address. If that doesn't work, you'll have to ask your network security people what SPNs are registered for the SQL Server service account. If you give up on Kerberos, fall back to NTLM.
Also in the newer JDBC driver Microsoft has implemented NTLM, which is the other Windows Authentication protocol.
But be aware of the following security caveat:
The NTLM protocol is an old authentication protocol with various
vulnerabilities, which pose a security risk. It's based on a
relatively weak cryptographic scheme and is vulnerable to various
attacks. It's replaced with Kerberos, which is a lot more secure and
recommended. NTLM authentication should only be used in a secure
trusted environment, or when Kerberos can't be used.
The Microsoft JDBC Driver for SQL Server only supports NTLM v2, which
has some security improvements over the original v1 protocol. It's
also recommended to enable Extended Protection, or use SSL Encryption
for increased security.
Using NTLM Authentication to connect to SQL Server - Security risks
i have active directory, both sql server db01 and db02 are joined in domain and setup default all.
i'm trying to connect another sql server instance db02 from db01 sql server
file->connect
Server Type: Database Engine
Server Name (i tried IP address or FQDN but it's still not working)
Authentication: Windows Authentication
Domain\Administrator
When i click connect button it says
enter image description here
i also tried enabling the sa account and setting password, can't also connect
i tried firewall off on both db01 and 02, still the same issue.
all services for sql is running, and network tcp and pipename are enabled.
remote connection is set to enable/allow
did i miss anything?
I think the error message tells you correctly that the problem is around authentication.
Either you are using a non-Windows application to connect to the the SQL server instances OR you are logged with your normal account BUT you are trying to authenticate as Domain\Administrator. Windows authentication will mostly not let you do that.
A problem with some non-Windows tools is that they let you try to connect using Windows Authentication and typing in a username, but it will never work. Instead, to use windows authentication you have to login to Windows as Domain\Administrator OR run your Application as Domain\Administrator, using e.g. right-click 'Run as other user'
To connect from a non-Windows platform using windows authentication depends entirely on your application and driver having correctly implemented it.
A .Net Core 2.2 application running in a Linux Docker container fails to authenticate to SQL Server on a different machine using SQL Authentication. The error message is:
Cannot authenticate using Kerberos. Ensure Kerberos has been initialized on the client with 'kinit' and a Service Principal Name has been registered for the SQL Server to allow Kerberos authentication.
We have configured the connection string to use SQL Authentication (user name and password). We have tried setting trusted_connection=false, but the connection still attempts to use Kerberos authentication.
The (redacted) connection string is:
"server=ourfullyqualifiedserver.domain,1433;database=our-database;user=sql-user;password=sql-password;"
I would expect to be able to connect to SQL Server from the container using SQL Authentication, but it is still attempting to use Kerberos. Why, and how do we make the connection use SQL Server Authentication?
You may have to add "Trusted_Connection=false;" to your connection string.
And also, use the Server IP with the Port that you exposed to the server.
It turns out that the connection string in the base appsettings.json configuration file was not being overwritten by the environment-specific settings file (appsettings.Development.json). Our DevOps group set the environment variable for the container and it correctly connected using the SQL Server credentials.
We hosted a .Net core 2.2 API in Red Hat Open shift container platform. API is using Entity Framework connecting to a SQL Server db on Windows Server, but both the container platform, SQL Server are on the same domain.
Now the API is unable to establish connection with the SQL server db. We tried with SQL Auth, but still the API hosted on container pod is trying to establish sql connection using kerberos, which has following issue.
System.Data.SqlClient.SqlException: Cannot authenticate using Kerberos. Ensure Kerberos has been initialized on the client with 'kinit' and a Service Principal Name has been registered for the SQL Server to allow Kerberos authentication.
Need some inputs on What are the additional setup, configurations required to connect SQL Server from open shift container platform ?
Right now there are no environment variables, config maps, additional drivers for SQL configured in the open shift container platform.
The problem with mine was the connection string. I had to remove "Trusted_Connection=true"
I want to access a remote Microsoft SQL Server 2012 database from a Java web application (JSP and surrounding classes) using Microsoft JDBC Driver 4.0. I was told the username/password for the database, but would prefer not storing the verbatim password as part of the web application's configuration.
Does Microsoft SQL Server 2012 support another authentication method where I could pass e.g. some kind of service token instead from a remote (not necessarily Windows-based) host, and more generally, what are best practices for storing and configuring database access configuration parameters in such a scenario?
From a Windows box in an Active Directory (AD) environment, you can use integrated security. This will connect to SQL Server using the AD security credentials of the current process (Windows account).
Specify integratedSecurity=true instead of user name and password in the connection string. See Building the Connection URL for more information.
SQL Server also supports Kerberos authentication using the Microsoft JDBC driver for Linux as specified with the authorizationScheme connection string keyword.