Linux and Windows: a Tale of Kerberos, Sssd, Dfs, and Black Magic (2018)

Posted2 months agoActive2 months ago

indigodaddy

32 points

8 comments

draeath.netTechstory

calmmixed

Debate

20/100

KerberosSssdDfsLinux-Windows Integration

Key topics

Kerberos

Sssd

Dfs

Linux-Windows Integration

The post details the author's journey in setting up Kerberos, SSSD, and DFS on Linux and Windows systems, while the discussion revolves around the challenges and workarounds for similar integrations.

Snapshot generated from the HN discussion

Discussion Activity

Light discussion

First comment

Peak period

18-21h

Avg / period

1.3

Key moments

01Story posted
Nov 1, 2025 at 8:54 PM EDT
2 months ago
Step 01
02First comment
Nov 2, 2025 at 1:03 AM EST
5h after posting
Step 02
03Peak activity
3 comments in 18-21h
Hottest window of the conversation
Step 03
04Latest activity
Nov 3, 2025 at 11:07 AM EST
2 months ago
Step 04

Generating AI Summary...

Analyzing up to 500 comments to identify key contributors and discussion patterns

Discussion (8 comments)

Showing 8 comments

bblb

2 months ago

1 reply

"You should set your hostname to be your FQDN, uppercased."

Never had an issue with this.

"name: initialize Kerberos ticket"

What's the use case for this Ansible task. Never had a need to manually generate tickets.

edit: didn't read it through; this is part of their automation pipeline

We manage 1000+ Windows Servers with Ansible and it's been as simple as Linux SSH. Multiple SOCKS5 proxies to different AD forests, WinRM double hop works great when become:true, GPO works just fine on Linux, initial setup is very simple with realmd. Biggest manual task is setting up the service accounts for Ansible.

mmh0000

2 months ago

1 reply

It’s not required, but it is a long standing convention with the justification that it makes for easier troubleshooting.

https://web.mit.edu/kerberos/www/krb5-latest/doc/admin/realm...

jborean93

2 months ago

1 reply

That's the realm side which should be upper case. The comment reference was for hostname themselves which I've always just done as lower case and have never seen a reason to make it upper case. The krb5.conf has a [domain_realm] section which can map a DNS name/suffix to the actual realm

    [domain_realm]
    .domain.com = DOMAIN.COM
    domain.com = DOMAIN.COM

woleium

2 months ago

iirc, on the windows side, workgroups had to be upper case, so initially the krb realm was set to the workgroup name. dns came later

metmac

2 months ago

1 reply

Now do this in containers with gMSAs. It eliminates the need of passing around Admin creds. Which I cannot stress enough. You shouldn’t be throwing your DA credentials into your random Linux machine’s Kerberos cache.

Amazon open sourced a project trying to solve similar problems.

https://github.com/aws/credentials-fetcher

Nifty, but was clearly made with AWS assumptions and we had to roll our own with the various hooks we needed for our cloud infra.

jborean93

2 months ago

The problem I have with using a gMSA outside of Windows is you need a Kerberos principal and credential for that principal in the first place to allow retrieving the gMSA details. Why not just use that principal and avoid adding this next step.

It would be great if Linux had a mechanism where the host itself could act as the principal to retrieve the gMSA like on Windows but the GSSAPI worker model just works differently there and runs in process. A similar problem exists for using Kerberos FAST/armouring where Windows uses the hosts' ticket to wrap the client request but on Linux there is no privileged worker process that protects this ticket so the client needs to have full access to it.

The closest thing I've seen is gssproxy [1] which tries to solve the problem where you want to protect host secrets from a client actually seeing the secrets but can still use them but I've not seen anything from there to support gMSAs for armouring for client TGT requests.

[1] https://github.com/gssapi/gssproxy

throwaway2037

2 months ago

    > /usr/local/bin/GetDomainAdminPassword

This is goofy. Why not use a keytab?

majoe

2 months ago

I went through a similar journey recently for the local development environment of my team.

I couldn't figure out yet, whether there is a reasonable and safe way to authenticate at an AD inside a GitHub Action. Anyone done that?

View full discussion on Hacker News

ID: 45786962Type: storyLast synced: 11/20/2025, 1:30:03 PM

Want the full context?

Jump to the original sources

Read the primary article or dive into the live Hacker News thread when you're ready.

Open link View on HN