Kerberos

Kerberos is supported in vScope when inventorying various data sources and connecting to Active Directory. It allows secure authentication without sending passwords in requests. Learn more at Kerberos authentication overview in Windows Server (Microsoft).

Note

By default, Kerberos is not configured in vScope.

• If Kerberos is not required, no action is needed — vScope will continue using username-and-password authentication.
• If Kerberos is required, you must configure it. The Java runtime’s default settings on the vScope server are not guaranteed to work.

Why Kerberos is relevant

Kerberos is a widely used authentication protocol in Windows-based networks. In vScope, it matters if:

• You want stronger security by avoiding passwords in connections
• Your organization enforces Kerberos-only authentication (common in larger enterprises or the public sector)
• You want vScope to access Active Directory, SQL servers, or other services that require Kerberos tickets

How Kerberos works in vScope

vScope supports two ways of handling Kerberos via Generic Security Services (GSS):

Library	Method of getting credentials	Best for	Requirements	Limitations
OS native GSS	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	Uses Java’s Kerberos implementation with explicit credentials (keytab, username and 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 and password)	- More setup steps - For non-domain machines, manual Kerberos config is required

Choosing the right implementation

Use OS native GSS if:

• Your vScope server is domain-joined
• vScope runs as a domain service 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
• You want vScope to access the native ticket cache, and you don’t want to modify the AllowTGTSessionKey registry key

Configure with OS 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 svc_vscope@DOMAIN.COM or SPNs ldap/dc.domain.com@DOMAIN.COM or MSSQLSvc/sqlserver.domain.com@DOMAIN.COM
• You need different login contexts in vScope, e.g. different principals for LDAP integration and MS SQL inventory

Configure with Java GSS library

Configuring Kerberos in vScope

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.

Before configuring Kerberos in vScope, check 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 = OS native GSS
  • false = Java GSS
• You have the necessary credentials ready (domain account or keytab).

Case sensitivity

Kerberos is strict about names. Realm names must be UPPERCASE, and principals must match exactly what’s in the keytab.

Configuring with OS Native GSS library

• Ensure the server is domain-joined.
• Run vScope as a domain account (e.g., DOMAIN\svc_vscope).
• Kerberos must already be configured in the OS.
• Set sun.security.jgss.native=true.

Limitations Not available for non-domain accounts or LOCAL_SYSTEM.

Configuring with Java GSS library

• Default mode in vScope (sun.security.jgss.native=false).
• Requires krb5.conf/krb5.ini and a JAAS config file.
• Supports ticket cache, username and password, or keytab authentication.

Ticket Cache

The ticket cache contains Ticket-Granting-Tickets (TGTs) and service tickets—credentials that allow vScope the same access to services as the service account. Ticket caches can be either custom or native. A custom ticket cache is explicitly configured, while the native ticket cache is the OS cache (on Windows LSA) containing tickets for the logged-in user.

To enable use of the ticket cache, the JAAS configuration must include 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).

Note

Java GSS cannot access native ticket cache unless HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters\AllowTGTSessionKey is set to 1 in the registry.

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

• On Windows: {user.home}{file.separator}krb5cc_{user.name}.
  If no ticket is found in the file-based cache, Java will attempt to retrieve the TGT from the Local Security Authority (LSA) API.

• On Linux: /tmp/krb5cc_uid (where uid is the numeric user identifier).
  If no ticket cache is available here, Java will also check {user.home}{file.separator}krb5cc_{user.name}.

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 essentially 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

Heads up!

ktpass updates the mapped account’s password — only use with accounts dedicated to vScope.

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.

Tip

It is also possible to generate a keytab for SPN instead of an UPN, but that is outside 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 caches for authentication.

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

Kerberos 5 Configuration File

To configure vScope for Kerberos, set the Java system property java.security.krb5.conf to the path of the Kerberos configuration file. The file is usually named krb5.conf on Linux and krb5.ini on Windows. Java does not depend on the file 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 and password).

Troubleshooting

Kerberos authentication involves multiple moving parts — the operating system, vScope, Java, and Active Directory.
If authentication fails, check the following areas:

Registry settings

Some Kerberos-related behaviors in Windows are controlled by registry keys:

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, LDAPS/StartTLS binds might fail if channel binding tokens are enforced (LdapEnforceChannelBinding=2).
In this case, use plain binds or switch to Java GSS.

Other common causes

• Principal name or realm case mismatch.
• Time skew between vScope server and domain controllers.
• Java not allowed to access the Windows ticket cache (AllowTGTSessionKey not set).