Introducing Agent Safe Governance for the AI Era

Read the Blog

MSSQL Server with Integrated Security and Kerberos Authentication for Windows

Last updated: June 11, 2026

If your application runs on a Windows machine joined to an Active Directory domain, you can use integrated security to access your Microsoft SQL Server database. Integrated security uses your Windows domain identity, rather than a username and password stored in Liquibase, to authenticate to MSSQL Server.

Kerberos is an authentication protocol that works based on tickets to provide strong authentication for client/server applications by using secret-key cryptography. The Kerberos authentication protocol does not store passwords locally or send them over the Internet.

On a domain-joined Windows machine, Windows negotiates Kerberos for you: the Microsoft JDBC driver picks up the logged-in user's credentials automatically, no kinit, no ticket management, and no JAAS configuration. This is the NativeAuthentication scheme and is the recommended way to use integrated security on Windows.

Authentication scheme

When to use

NativeAuthentication (default)

The machine is joined to the domain and Liquibase runs as the domain user that should connect. Recommended.

JavaKerberos

The process must authenticate as a different principal than the logged-in user, or in cross-realm setups. Manages tickets in Java, like on Linux and macOS. See the Alternative: JavaKerberos scheme section below.

Note: If you want to connect with a username and password instead, you do not need Kerberos — see Using Liquibase with MSSQL Server.

Before you begin

  • Install Liquibase.

  • Ensure you have Java installed. Liquibase requires Java to run. If you used the Liquibase Installer, Java is included automatically. Otherwise, you must install Java manually.

  • The Windows machine must be joined to the Active Directory domain, and Liquibase must run as a domain user that has a login on the SQL Server instance.

  • SQL Server must run under an account with a registered Service Principal Name (SPN). Without a valid SPN, Windows silently falls back to NTLM, the connection works, but it is not Kerberos. The procedure below verifies this.

Procedure

1

Verify the SPN

SQL Server normally registers its SPN automatically when its service account has permission to do so. This step is typically performed once by a DBA or domain administrator.

1. Open a command prompt as an administrator and verify that an SPN exists for your SQL Server host:

setspn -T * -F -Q MSSQLSvc/<dbserver>*

Sample output

Checking forest DC=mydomain,DC=com
CN=DBSERVER,OU=Servers,DC=mydomain,DC=com
        MSSQLSvc/dbserver.mydomain.com:1433
Existing SPN found!

2. If no SPN is found, register one (requires Domain Admin or delegated rights):

loading

Note: Amazon RDS: for SQL Server on Amazon RDS joined to AWS Managed Microsoft AD, the SPN is registered automatically under the instance's AD machine name (for example EC2AMAZ-XXXXXXX.mydomain.com, visible in the OU=RDS container), not under the *.rds.amazonaws.com endpoint. Connect using the AD machine name, or keep the endpoint in your URL and add ;serverSpn=MSSQLSvc/EC2AMAZ-XXXXXXX.mydomain.com:1433.

Open SQL Server Management Studio as the Active Directory user, log in with Authentication: Windows Authentication, and run the following query to confirm that authentication uses Kerberos:

loading

3. Open SQL Server Management Studio as the Active Directory user, log in with Authentication: Windows Authentication, and run the following query to confirm that authentication uses Kerberos:

2

Configure the Liquibase connection

1. Ensure the driver's native authentication library (mssql-jdbc_auth-<version>-x64.dll) is available. Liquibase installations include the Microsoft JDBC driver; if the DLL is missing, download the Microsoft JDBC driver package and place the DLL in a directory on the Java library path. For example:

loading

2. Specify the database URL in the liquibase.properties file (defaults file), along with other properties you want to set a default value for. Liquibase does not parse the URL. Do not set username or password. See Using Liquibase with MSSQL Server if you want to use username/password authentication instead:

changelogFile: changelog.sql
url: jdbc:sqlserver://dbserver.mydomain.com:1433;databaseName=MYDATABASE;integratedSecurity=true;encrypt=true;trustServerCertificate=true

Note: Adjust encrypt/trustServerCertificate to your environment's certificate policy.

3

Verify the connection

1. Run the liquibase status command to ensure the connection works:

liquibase status --verbose

2. For positive proof that the session authenticated with Kerberos, and not NTLM, run:

loading

Expected output

LOGGED_IN_AS    | AUTH_SCHEME |
MYDOMAIN\lbuser | KERBEROS    |

Alternative: JavaKerberos scheme

Use JavaKerberos when you cannot or do not want to use the logged-in Windows identity — for example, when running as a service account different from the interactive user, or when authenticating to a foreign realm. This scheme manages Kerberos tickets in Java instead of through Windows SSPI, so it works like the Linux/macOS procedure.

Create a krb5.ini file (the Windows equivalent of krb5.conf), for example C:\\kerberos\\krb5.ini:

loading

Note: The realm name must be your Active Directory domain name in UPPERCASE and identical in all three sections.

Obtain a ticket with the JDK's kinit utility (located in %JAVA_HOME%\bin) into a file-based ticket cache:

loading

Note: With JavaKerberos, the JVM reads tickets only from a file cache — it does not use the Windows in-memory (LSA) ticket cache by default.

Use the JavaKerberos URL in liquibase.properties:

loading

useDefaultJaasConfig=true (Microsoft JDBC driver 12.2 and later, included with current Liquibase releases) makes the driver supply its own JAAS configuration — no separate JDBCDriverLogin.conf file and no -Djava.security.auth.login.config property are needed.

Point the JVM at your krb5.ini and verify, in the same terminal where KRB5CCNAME is set:

loading

Troubleshooting

Symptom

Likely cause and fix

auth_scheme shows NTLM instead of KERBEROS

Missing or wrong SPN, or connecting by IP address. Fix the SPN (step 1) and connect by fully qualified domain name

This driver is not configured for integrated authentication

mssql-jdbc_auth-*.dll not found (NativeAuthentication). Set -Djava.library.path to the DLL's directory

No valid credentials provided (Mechanism level: Server not found in Kerberos database (7)), typically only via a CNAME, availability group listener, or RDS endpoint

SPN registered under a different host name. Connect via the AD name or add serverSpn=MSSQLSvc/<ad-host>:1433 to the URL

Kerberos Login failed: Integrated authentication failed ... LoginException (Cannot get any of properties: [user, USER] ...) (JavaKerberos)

No ticket in the file cache. Re-run the JDK kinit with KRB5CCNAME set, in the same terminal

Clock skew too great

Kerberos requires client and domain controller clocks within 5 minutes. Check the Windows Time service

To see detailed Kerberos negotiation logs while diagnosing a problem, add -Dsun.security.krb5.debug=true to JAVA_OPTS. Remove it for normal operation.