Kerberos

Kerberos is supported by vScope when inventorying various data sources and in the Active Directory integration.
It allows secure authentication without including passwords in requests.

How Kerberos works in vScope

When using Kerberos, vScope can authenticate to services in two ways:

Library	Method of getting credentials	Best for	Requirements	Limitations
Native GSS (OS-provided)	Uses the vScope service account’s existing OS ticket cache	Domain-joined vScope servers running as a domain service account	- Server is domain-joined - vScope runs as a domain account (e.g., `DOMAIN\svc_vscope`) - Kerberos configured in the OS	- Cannot specify alternate credentials - Cannot use keytabs
Java GSS (default)	Uses Java’s Kerberos implementation with explicit credentials (keytab, username/password, or ticket cache)	Environments needing more control over principal and authentication method	- Kerberos config file (`krb5.conf` / `krb5.ini`) - Jaas configuration - Credentials (keytab, ticket cache, or username/password)	- More setup steps - For non-domain machines, manual Kerberos config is required

Choosing GSS implementations

Use Native GSS if:

The vScope server is domain-joined
vScope runs as a domain account (e.g., DOMAIN\svc_vscope)
You want to use the account’s existing Kerberos tickets
You don’t need to supply keytabs or alternate credentials

Configure with native GSS library

Use Java GSS if:

You want to use a keytab
vScope runs as LOCAL_SYSTEM or a non-domain account
You need control over the principal and authentication method, e.g. access services with a keytab for UPN DOMAIN\svc_vscope or SPNs ldap/dc.domain.com@DOMAIN.COM or MSSQLSvc/sqlserver.domain.com@DOMAIN.COM

Configure with Java GSS library

Configure Generic Security Services (GSS)

Generic Security Services (GSS) is a standard API that vScope uses to handle authentication for Kerberos and other secure protocols. In this section, we explain how to configure GSS in vScope for Kerberos authentication, using either the OS-provided Native GSS library or Java’s built-in GSS implementation.

Common Prerequisites

Before starting, ensure that:

Kerberos is configured on the vScope server.
DNS resolution works correctly for domain controllers and service names.
The vScope server’s time matches the domain controllers.
You can modify the sun.security.jgss.native setting in vScope:
- true = Native GSS
- false = Java GSS
You have the necessary credentials ready (domain account or keytab).

Configure with Native GSS Library

The Native GSS library uses the OS ticket cache to authenticate with existing credentials for the vScope service account.

Requirements:

vScope server is domain-joined.
vScope runs as a domain account.
Kerberos is configured in the OS.
sun.security.jgss.native=true.

Limitations:

Will not work if vScope runs as a non-domain account (e.g., LOCAL_SYSTEM).

Configure with Java GSS Library

The Java GSS library is the default and offers more control over which credentials are used.
It supports keytabs, custom ticket caches, or username/password authentication.

Prerequisites

sun.security.jgss.native=false.
The vScope server has a Kerberos configuration file (Kerberos5 Configuration File).
- On domain-joined machines, this is usually already in place.
- On non-domain machines, you must create a manual configuration.
A Jaas configuration file exists and points to your credentials (keytab, ticket cache, or username/password).

Ticket Cache

The ticket cache contains Ticket-Granting-Tickets (TGTs) and Service Tickets which are basically credentials that allow vScope the same access to services as the service account. Ticket caches can be custom or native. The custom ticket cache is something configurable and the native ticket cache is the OS ticket cache (on Windows LSA) which contains tickets for the logged in user.

To enable the use of ticket cache the Jaas configuration must contain useTicketCache=true.

The ticket cache contains Ticket-Granting-Tickets (TGTs) and Service Tickets.

To enable in Jaas:

useTicketCache=true

Native Ticket Cache The native ticket cache is always used as a fallback with useTicketCache=true. See note about access to the Windows LSA cache. OS ticket cache (Windows LSA).

Custom Ticket Cache Java will look for the custom ticket cache in the following locations:

On Linux: /tmp/krb5cc_uid where the uid is numeric user identifier. If the ticket cache is not available in the above location, or if we are on a Windows platform, it will look for the cache as {user.home}{file.separator}krb5cc_{user.name}. For Windows, if a ticket cannot be retrieved from the file ticket cache, it will use Local Security Authority (LSA) API to get the TGT.

You may override the location by configuring ticketCache=c:\\myticketcache in the Jaas configuration.

Keytab

A keytab contains principals and keys to use for Kerberos authentication.

Generate on a domain controller for svc_vscope@ISL.LOCAL: A keytab contains principals and keys to use for Kerberos authentication. The keytab is generated on a server (e.g. the domain controller) and is practically a container of credentials. It should be treated as such and kept safe.

To generate a keytab for the user svc_vscope@ISL.LOCAL you can run the following on a domain controller.

ktpass /princ svc_vscope@ISL.LOCAL /mapuser ISL\svc_vscope /pass MYPASSWORD /out C:\svc_vscope.keytab /crypto all /ptype KRB5_NT_PRINCIPAL /mapop set

Copy the created C:\svc_vscope.keytab to the vScope server and configure useKeytab to true and the location in jaas.conf by setting keyTab to the location of the file and the principal setting to the principal used when the keytab was generated. The principal must match exactly what is in the keytab, including exact casing. A mismatch in case (e.g., svc_vscope@isl.local instead of svc_vscope@ISL.LOCAL) will cause key lookups to fail silently.

It is also possible to generate a keytab for SPN instead of an UPN but that is beyond the scope of this guide.

Configure in Jaas: The Jaas configuration specifies which principal to use for Kerberos authentication and how to authenticate. Below is a basic example for principal svc_vscope@ISL.LOCAL which attempts to use both a keytab and ticket cache(s) to find credentials.

useKeyTab=true
keyTab="C:\svc_vscope.keytab"
principal="svc_vscope@ISL.LOCAL"

Kerberos5 Configuration File

To configure vScope for Kerberos java.security.krb5.conf needs to be set to the location of that configuration. The file is usually named krb5.conf on Linux and krb5.ini in Windows. Java does not really care about the suffix. Below is a very basic Kerberos configuration for the domain isl.local.

Example (krb5.conf for domain isl.local):

[libdefaults]
  default_realm = ISL.LOCAL
  dns_lookup_kdc = false
  dns_lookup_realm = false
  forwardable = true

[realms]
  ISL.LOCAL = {
      kdc = ad.isl.local
      admin_server = ad.isl.local
  }

[domain_realm]
  .isl.local = ISL.LOCAL
  isl.local = ISL.LOCAL

Jaas Configuration File

Example configuration for principal svc_vscope@ISL.LOCAL using keytab + ticket cache:

ldapnetworkconnection {
  com.sun.security.auth.module.Krb5LoginModule required
    useKeyTab=true
    keyTab="C:\svc_vscope.keytab"
    principal="svc_vscope@ISL.LOCAL"
    useTicketCache=true
    refreshKrb5Config=true
    doNotPrompt=true
    debug=true;
};

Key fields:

useKeyTab – Enables keytab authentication.
keyTab – Path to keytab file.
principal – Principal for authentication (case-sensitive).
useTicketCache – Enables ticket cache use.
doNotPrompt – Prevents interactive prompts (must be true without username/password).

Troubleshooting

Kerberos is complex and there are several components and parties involved in authentication.

Registry Settings Reference

Purpose	Registry Path	Value
Allow Java GSS to access Windows LSA ticket cache	`HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters\AllowTGTSessionKey`	`1` = allow, `0` = deny
Control LDAP channel binding enforcement (AD DS)	`HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters\LdapEnforceChannelBinding`	`0` = none, `1` = relaxed, `2` = strict
Control LDAP channel binding enforcement (AD LDS)	`HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<LDS-instance-name>\Parameters\LdapEnforceChannelBinding`	Same as above

Channel Binding and LDAPS/StartTLS

Due to limitations in the LDAP library used by vScope, binds using LDAPS/StartTLS might fail if channel binding tokens are enforced (LdapEnforceChannelBinding set to 2).
Using plain binds or switching to Java GSS may work around this.