Kerberos with PAC and claims

Configure Kerberos sign-in and inspect MS-PAC identity, group and claims data in the Access session.

The KerberosPacAuthentication authenticator signs users in with Kerberos and makes Microsoft Privilege Attribute Certificate (MS-PAC) data from the service ticket available in the Access session. Use it to check that identity information, group memberships and client claims reach Access during sign-in.

Configuration

This authenticator uses the same configuration, login view and sign-in flow as Kerberos/SPNEGO. Keep the existing HTTP service principal, keytab, JAAS entry, realm settings, username mapping and Chain or Selector configuration. Change type from KerberosAuthentication to KerberosPacAuthentication.

PAC collection is enabled by the authenticator type. Supported PAC fields and all decoded client claims are published automatically under the global key kerberos_pac; no additional collection or claim-selection settings are needed.

Properties
Example

The Kerberos/SPNEGO properties and common authenticator properties also apply. The additional property is:

Name	Description	Default	Mandatory
`result_key`	Global key for the PAC result. Use distinct keys for separate PAC authenticator instances. The key must start with a letter and contain only letters, digits and underscores, up to 128 characters. Control-field names and keys already owned by another instance or unrelated global are rejected.	`kerberos_pac`	false

{
  "id": "kerberos",
  "type": "KerberosPacAuthentication",
  "config": {
    "base_path": "/authn",
    "service_principal": "HTTP/[email protected]",
    "jaas_context": "AccessKerberos",
    "on_probe_unavailable": "cancel",
    "username_mapping": "principal"
  }
}

Retaining the existing authenticator ID also retains the targets used by Chain and Selector. To offer both Kerberos types as separate choices, give them different IDs and add each ID as a Selector target. Both use the bundled view at web/authenticator/kerberos.

Check that PAC data reaches Access

Apply the configuration and sign in through the existing Kerberos entry point, using a domain user whose ticket contains the fields or claims you want to inspect.
Find the PAC completion message in the application log. At DEBUG level it contains the result status, diagnostic code and trace ID:
```
Kerberos PAC observation status=PARTIAL code=none trace=<trace-id>
```
At TRACE level, inspect the authentication scopes for the same trace ID. Locate exports.kerberos_pac, or the key configured by result_key. For example, add these logger entries to the Loggers section of the existing log4j2.xml:
```
<AsyncLogger name="fortifiedid.authenticator.kerberos" level="TRACE" />
<AsyncLogger name="fortified.authn.core.auth.chain" level="TRACE" />
```
Check principal, the relevant data section and the corresponding buffer status. For a claim, compare its complete id, numeric source, type and each entry in values with the values configured in Active Directory.

The following excerpt shows a client claim under the default result key:

{
  "kerberos_pac": {
    "principal": "[email protected]",
    "status": "PARTIAL",
    "claims": [
      {
        "id": "ad://ext/PAC-Probe-Depar:88df3a4f2fdca639",
        "source": 1,
        "type": "STRING",
        "value_count": 1,
        "values": ["PAC-Test"]
      }
    ],
    "buffers": [
      {
        "type": 13,
        "status": "READ"
      }
    ],
    "errors": []
  }
}

In this example, buffer type 13 contains client claims. Its READ status and the claim's ID and value show which data was decoded. The overall PARTIAL status can coexist with a successfully read claims buffer; inspect the individual buffer statuses to see how each part was handled.

TRACE logs can contain personal information, group memberships and claim values. Use the existing log access and retention controls, and return the logger levels to their usual settings after the inspection. See System logging for the logging configuration.

Result data

The result belongs to the current session and authenticator instance. A new attempt clears that instance's earlier result, and a cancelled or timed-out attempt cannot publish a late result.

Field	Contents
`principal`	The accepted Kerberos client principal.
`authenticator_id`	The authenticator instance that produced the result.
`status`	Overall PAC processing status.
`logon`	User and domain names, user and primary-group SIDs, group memberships, extra SIDs, resource groups and logon fields. Membership entries retain the SID and its attributes.
`client`	Client name and client FILETIME.
`upn_dns`	UPN, DNS domain, flags and the SAM name and SID when present in that buffer variant.
`claims`	Client claims with complete IDs, sources, types, value counts and value lists.
`attributes`	PAC request flags.
`requestor`	Requestor SID.
`authentication_observations`	Known SID names and their membership locations.
`buffers`	Buffer inventory with type, size, offset, processing status and details.
`errors`	Diagnostic codes and structural details for processing problems.

A data section is included when its corresponding buffer is present and decoded. User session keys, credential payloads and raw ticket bytes are excluded from the result.

Claim values

Every claim keeps its full identifier and a values array, including claims with one value. Source 1 identifies AD claims and source 2 identifies certificate claims; other sources retain their numeric value.

Claim type	Representation in `values`
`STRING`	JSON strings, preserving Unicode and empty values.
`INT64`	Signed decimal strings.
`UINT64`	Unsigned decimal strings.
`BOOLEAN`	JSON `true` or `false`.

Decimal strings preserve the precision of 64-bit integers. FILETIME fields also use unsigned decimal strings, retaining zero and special values. The additional fields in logon.fields retain their field names; counters use decimal strings and flag/status fields use raw hexadecimal strings.

Processing status

Overall status	Meaning
`READ`	The supported fields in the present buffers were decoded.
`PARTIAL`	The result includes decoded data alongside omitted, unsupported or failed buffer content.
`ABSENT`	No PAC was found in the authorization data.
`UNAVAILABLE`	The GSS provider could not supply authorization data.
`ERROR`	The authorization data or PAC layout could not be processed.

Individual buffers use READ, PARTIAL, OMITTED, UNSUPPORTED or FAILED. Compressed claims are recorded with their compression format and lengths and the buffer status UNSUPPORTED. Diagnostic codes such as pac_missing, authz_data_unavailable, claims_compression_unsupported and claims_decode_failed identify the condition to investigate.

Kerberos validation determines whether sign-in succeeds. After Kerberos succeeds, a PAC processing problem is reported in the result while sign-in continues. Inspect the overall status and the status of the specific buffer or claim you need.

Use the result in Pipes and attribute mappings

The global result is available to an application's existing Pipes flow as request.kerberos_pac. With a custom result_key, use that key instead. In expressions that read authentication globals, the corresponding path is exports.kerberos_pac.

When forwarding a claim to an application, select it by its complete ID, source and type, and preserve its value list. A ScriptEval valve can produce a named property such as pac_department for explicit OIDC or SAML attribute mapping. Collection itself does not require a pipe.

PAC collection does not change username, the authenticated subject, amr, acr or AuthnContextClassRef based on PAC content. To return to the existing Kerberos authenticator, change type back to KerberosAuthentication and keep the original configuration.