Kerberos Workflows with nimux

Kerberos as an operator workflow

Kerberos is not one command. It is a set of related workflows: requesting tickets, describing caches, converting ticket formats, asking for service tickets, validating delegation behavior, and using those tickets with protocols such as SMB, LDAP, MSSQL, and WinRM. nimux keeps those paths close to the rest of the assessment surface.

The goal is to make ticket handling predictable. Operators should know which cache is being used, which SPN is being requested, which realm is involved, and what file is produced at the end.

Requesting a TGT

The basic starting point is a TGT request. In nimux, this can be written as a Kerberos request operation.

nimux kerberos dc.corp.local -u operator -p '<password>' -d corp.local \
  --request kinit \
  --out operator.ccache

Once the cache exists, later commands can use it with -k and --ccache. Keeping the cache path explicit reduces accidental use of an old ticket.

Describing and converting tickets

During a real workflow, you often need to inspect ticket contents or convert formats.

nimux kerberos dc.corp.local --request describe --ccache operator.ccache

nimux kerberos dc.corp.local --request ccache-to-kirbi \
  --ccache operator.ccache \
  --out operator.kirbi

nimux kerberos dc.corp.local --request kirbi-to-ccache \
  --kirbi operator.kirbi \
  --out imported.ccache

These steps are useful when moving between native Linux workflows, Windows tooling, and documentation artifacts.

Requesting a service ticket

Service tickets are where Kerberos becomes directly useful for protocol access. A CIFS ticket can support SMB workflows. A WSMAN ticket can support WinRM. An MSSQL SPN can support database authentication.

nimux kerberos dc.corp.local -d corp.local \
  --request getst \
  --ccache operator.ccache \
  --spn cifs/server.corp.local \
  --out cifs-server.ccache

The SPN should match the service and hostname that will be used by the next command. If the host is accessed by FQDN, request the FQDN SPN. If the environment has DNS issues, fix name resolution before assuming Kerberos is broken.

S4U and delegation checks

S4U workflows are sensitive and should be handled with clear authorization. They are useful for validating delegation configuration and understanding how service accounts can request tickets on behalf of users.

nimux kerberos dc.corp.local -d corp.local \
  --request s4u \
  --ccache service.ccache \
  --user Administrator \
  --service cifs/server.corp.local \
  --out delegated.ccache

When testing delegation, document the service account, target SPN, impersonated user, output cache, and the reason the test was in scope.

Roasting and hash output

Kerberoasting and ASREPRoasting are common assessment checks when authorized. nimux keeps them in the Kerberos and LDAP command surface so output can be collected with the rest of the workflow.

nimux ldap dc.corp.local -d corp.local -u operator -p '<password>' --kerberoast

nimux ldap dc.corp.local -d corp.local -u operator -p '<password>' --asreproast

The important part is scope control. Do not spray, roast, or validate credentials outside the engagement rules. For reporting, preserve only what is required and handle hashes as sensitive material.

krb5 configuration

Many Kerberos issues are configuration issues. A correct realm, KDC, DNS behavior, and SPN form can save hours of confusion.

nimux krb5conf dc.corp.local -d corp.local --out corp.krb5.conf

Then use that configuration with commands that accept a Kerberos config path. This helps make the workflow repeatable across terminals and shells.

Practical guidance

Good Kerberos work is precise:

• Use explicit cache paths.
• Match SPNs to the hostname and protocol.
• Keep realm and domain names consistent.
• Validate time synchronization.
• Record generated ticket files and delete them when no longer needed.
• Treat tickets like credentials.

nimux does not make Kerberos simple by hiding it. It makes Kerberos manageable by keeping the operations visible and consistent.

Cache discipline

Kerberos workflows can fail in confusing ways when the wrong cache is used. Operators often have several tickets on disk during a test: one for a low-privileged user, one for a service account, one for a delegated service ticket, and one produced by a conversion step. If those files are not named clearly, mistakes are easy.

Use descriptive cache names:

• operator-tgt.ccache
• svc-http-tgt.ccache
• admin-cifs-server.ccache
• wsman-backup01.ccache

Avoid generic names like ticket.ccache when the workflow has more than one step. The filename should tell the next operator what the ticket is for.

Matching service tickets to protocols

The service ticket must fit the protocol being used. A CIFS ticket is not the same as a WSMAN ticket. An HTTP service ticket may be useful for one application but not for SMB. In constrained delegation workflows, the requested SPN and any alternate service choice should be documented carefully.

Examples:

nimux kerberos dc.corp.local --request getst \
  --ccache operator.ccache \
  --spn cifs/fileserver.corp.local \
  --out fileserver-cifs.ccache

nimux kerberos dc.corp.local --request getst \
  --ccache operator.ccache \
  --spn WSMAN/backup01.corp.local \
  --out backup01-wsman.ccache

Then the follow-up command should use the matching hostname and service context.

Kerberos and WinRM

WinRM with Kerberos is sensitive to hostname, SPN, realm configuration, and ticket cache path. If NTLM works but Kerberos fails, do not assume the credential is wrong. Check the full chain:

• Is the KDC reachable?
• Is the client clock in sync?
• Does the cache contain the expected principal?
• Does the SPN match the target hostname?
• Is the realm in krb5.conf correct?
• Is DNS returning the expected host?

A typical WinRM command with a cache looks like this:

nimux winrm host.corp.local -k \
  --ccache operator.ccache \
  -d corp.local \
  --cmd whoami

When the command succeeds, record the cache used and the target hostname. Those details are important for repeatability.

Kerberos through a pivot

Kerberos through a SOCKS pivot adds another layer. The KDC, service host, and DNS path may all be behind the route. Start with connectivity before requesting or using tickets through the pivot.

nimux scan dc.corp.local --port 88,389,445 \
  --proxy socks5://127.0.0.1:1088 \
  --open

Then test a read-only Kerberos-aware operation.

nimux ldap dc.corp.local -d corp.local -k \
  --ccache operator.ccache \
  --query dcs \
  --proxy socks5://127.0.0.1:1088

If this fails, separate route problems from Kerberos problems. A port failure is a route issue. A principal or SPN failure is a Kerberos issue. A DNS failure is a name resolution issue.

Delegation documentation

Delegation tests are high-value because they explain how identity can move between services. They also require careful documentation because the same commands can be misread without context.

For each delegation test, record:

• Source principal.
• Target service.
• Impersonated principal.
• KDC used.
• Ticket cache input.
• Ticket cache output.
• Whether protocol transition was involved.
• Whether alternate service substitution was used.

This turns a technical result into a reportable finding. The report can explain not only that a ticket was requested, but why the configuration allowed it.

Ticket conversion use cases

Ticket conversion is not just a convenience. It helps bridge tool ecosystems and operating systems. A Windows-origin ticket may need to become a ccache. A Linux-origin cache may need to become a kirbi for a controlled lab workflow.

The safe approach is to keep converted tickets scoped and short-lived:

nimux kerberos dc.corp.local --request ccache-to-kirbi \
  --ccache operator.ccache \
  --out operator.kirbi

nimux kerberos dc.corp.local --request kirbi-to-ccache \
  --kirbi operator.kirbi \
  --out operator-imported.ccache

Delete converted artifacts when they are no longer needed. Treat both formats as credential material.

Troubleshooting checklist

When Kerberos breaks, move through a checklist instead of changing random flags:

• Confirm system time.
• Confirm realm name.
• Confirm KDC IP or hostname.
• Confirm DNS search behavior.
• Confirm cache file exists.
• Describe the cache before using it.
• Confirm SPN and hostname match.
• Confirm the requested service is actually Kerberos-enabled.
• Try a smaller read-only operation before remote execution.

This checklist saves time because most failures are configuration mismatches.

Reporting Kerberos findings

Kerberos findings should avoid vague language. Instead of saying “Kerberos delegation works,” explain the path:

> The service account was able to request a service ticket for CIFS on the target host on behalf of a privileged user. This demonstrates that the delegation configuration can be used to access file services under the delegated identity.

Include evidence, but handle tickets and hashes carefully. Reports should not expose reusable credential material unless the engagement explicitly requires it and the report storage is protected.

Final thoughts

Kerberos rewards precision. The same workflow can be clean and repeatable or confusing and fragile depending on naming, cache discipline, SPN selection, and documentation. nimux aims to keep the steps visible: request, describe, convert, use, and clean up.

That visibility is what makes Kerberos manageable during real authorized assessments.