Kerberos.NET Documentation

The decoder converts Kerberos ASN.1 data into a JSON structure, which is then rendered as a tree view. The resulting JSON contains several high-level sections:

• Request: Contains the original KrbApReq (Kerberos Application Request) data, including the ticket and authenticator.
• Decrypted: Contains the decrypted contents of the ticket and authenticator (if a key was provided), including SName, CName, SessionKey, and AuthorizationData (such as PAC data).
• Computed: Contains computed values like the full principal name and various restrictions or claims.
• KeyTable: Contains information about the keys used, including encryption types and principal names.

{
  "Request": { ... },
  "Decrypted": { ... },
  "Computed": { ... },
  "KeyTable": { ... }
}

The built-in replay detection uses an in-memory MemoryCache. This is not effective in clustered environments because the cache is not shared across machines.

To implement replay detection for a clustered environment, you have two options:

1. Use Distributed Cache: Register an IDistributedCache implementation via .NET Core dependency injection. The built-in logic will then use this shared cache.
2. Custom Validator: Implement the ITicketReplayValidator interface and pass your implementation into the KerberosValidator constructor.

When implementing an in-process KDC, you must ensure that the same long-term secret is reachable by both the KDC and the service. The sample achieves this by deriving both from a single LocalSecurityStore:

1. The KDC uses the secret via IKerberosPrincipal.RetrieveLongTermCredential to encrypt the service ticket.
2. The service uses the secret via the KeyTable from GetServiceKeyTable to decrypt the final AP-REQ.

If these secrets do not match, the service will be unable to decrypt the credentials sent by the client.

The sample implements an in-process KDC architecture where the KDC runs in the same process as the service, backed by a local account store. This is achieved through several key components:

• LocalSecurityStore.cs: An in-memory account database containing users, services, and the krbtgt account. It handles key derivation and replaces a global KDC or Active Directory.
• LocalRealmService.cs: Adapts the LocalSecurityStore to the KDC's IRealmService, IPrincipalService, and IKerberosPrincipal interfaces.
• InProcessKdcTransport.cs: A KerberosTransport implementation that delivers KDC messages directly to KdcServer.ProcessMessage without using network sockets.
• Program.cs: The entry point that wires the in-proc KDC to the IAKerbInitiator and IAKerbAcceptor handshake and outputs the authenticated identity.

Kerberos.NET uses the KeyTable (keytab) format. On Windows, you can generate these files using the ktpass utility (part of RSAT).

First, ensure RSAT is installed:

Add-WindowsFeature RSAT

Then, run ktpass with your desired parameters. For example, to generate a keytab for an HTTP service:

ktpass /princ HTTP/test.identityintervention.com@IDENTITIYINTERVENTION.COM /mapuser IDENTITYINTER\server01$ /pass P@ssw0rd! /out sample.keytab /crypto all /PTYPE KRB5_NT_SRV_INST /mapop set

To report bugs or request new features for Kerberos.NET, use GitHub Issues. Before creating a new issue, search the existing issue tracker to ensure your topic has not already been addressed. You can file a new issue directly at the following link:

https://github.com/dotnet/Kerberos.NET/issues/new/choose

The Local KDC Sample demonstrates how a server application can host its own in-process Key Distribution Center (KDC) using the IAKERB protocol. This allows a client to tunnel AS/TGS exchanges through the target service as GSS-API tokens, meaning the client never opens a direct socket to a KDC.

To run the sample project, use the following command from the repository root:

dotnet run --project Samples/LocalKdcSample

The recommended way to use the Kerberos.NET library is by installing the NuGet package. This works for .NET Standard 2.0 platforms and .NET Core.

PM> Install-Package Kerberos.NET

The Bruce command line tool is a collection of utilities for interacting with Kerberos.NET components, such as ticket cache and keytab management. It follows MIT and Heimdal command line standards.

To install it globally, use the following command:

dotnet tool install bruce -g

Available tools include:

• kconfig: View and modify krb5 config files.
• kdecode: Decode Kerberos/Negotiate tickets (optionally decrypt if secrets are known).
• kdestroy: Delete ticket cache files.
• kinit: Authenticate a user and request a TGT.
• klist: View tickets in a cache.
• kping: Send an AS-REQ "ping" to a KDC to get user metadata.
• ktpass: View and manipulate keytab files.
• whoami: Request a ticket for the current user and format details.

Use the /verbose parameter with any command to enable detailed logging.

The Kerberos Ticket Decoder is an optional utility provided with the library to decode and potentially decrypt service tickets.

How to use it:

1. Input: Copy a Base64 encoded ticket into the input textbox.
2. Decoding: If no key is provided, the tool will decode the unencrypted message.
3. Decryption: If a key is provided, the tool will attempt to decrypt the message.

Requirements for Decryption:

• RC4 Encryption: You do not need to provide a host value.
• AES Encryption: You must provide a host value to derive the salt.
• Alternative: You can provide a .keytab file instead of a manual key.

Launching the tool:

You can launch the decoder via the bruce command-line tool using the kdecode command.

bruce kdecode

The KerberosClient is a simple, fully-featured client that supports generating SPNego messages. You can use it to authenticate a user with credentials and then request a service ticket.

var client = new KerberosClient();

var kerbCred = new KerberosPasswordCredential("user@domain.com", "userP@ssw0rd!");

await client.Authenticate(kerbCred);

var ticket = await client.GetServiceTicket("host/appservice.corp.identityintervention.com");

var header = "Negotiate " + Convert.ToBase64String(ticket.EncodeGssApi().ToArray());