search

jborean93 / LocalKdc

Info on how to use Kerberos KDC on a non-domain joined host
37 stars 2 forks source link

Additions #2

Open grawity opened 1 month ago

grawity commented 1 month ago

All of these apply to every Windows version from XP to current:

Client-side usage without special SSPI calls

If Domain credentials matching the server name are stored in the Windows Credential Manager, then SSPI will automatically use them, without the client program needing to pass anything explicitly. For example:

cmdkey /add:*.example.org /user:foo@EXAMPLE.ORG /pass
cmdkey /add:shortname /user:foo@EXAMPLE.ORG /pass

...makes even Unix-style programs that don't prompt for credentials, such as ssh (bundled Windows OpenSSH) or pyspnego or Firefox/Thunderbird, automatically work with Kerberos. It pretty much functions as a persistent kinit.

In the past I've also used runas /netonly /user:foo@REALM to achieve this without storing credentials persistently.

Client-side usage with non-AD Kerberos

If a realm subkey exists under HKLM\System\CurrentControlSet\Control\Lsa\Kerberos\Domains (such as if the realm was added using ksetup.exe), then the realm is considered a "MIT realm" and the DC Locator process is not used:

  1. The SRV query is made for _kerberos._udp.{realm} instead.
  2. The CLDAP ping is not done.

An empty subkey is enough,

reg add HKLM\System\CurrentControlSet\Control\Lsa\Kerberos\Domains\EXAMPLE.ORG

but I usually do:

ksetup /setrealmflags EXAMPLE.ORG TcpSupported NcSupported

just in case that might do something useful. (I don't know whether it does.) The same ksetup can be used to manually define KDCs for MIT realms, like krb5.conf, if the realm lacks SRV records.

UPN vs Kerberos principal

Non-joined machines cannot translate custom AD UPN suffixes that might have been set up, so it's probably still best to specify the username in Kerberos principal format (samaccount@REALM) or I guess samaccount@primarydomain?

With non-AD realms, it's always user@REALM, there are no UPNs without AD so I think it always expects the case-sensitive realm in this case.

jborean93 commented 1 month ago

Thanks for the info, would love to see a PR if you wanted to add that info to the README somewhere. I mostly shied away from the ksetup/registry configuration where possible as I wanted to see what the default lookup behaviour involved. While I haven’t tested this assumption I believe the ksetup realm configuration required a reboot, I’m unsure if the realm specific flags are the same though.

grawity commented 1 month ago

ksetup realm config seems to be checked on the fly. Possibly subject to the regular DC locator caching, but as long as I did the change before attempting to use Kerberos, it always had an immediate effect.

AFAIK only the "join machine to MIT realm" option might need a reboot, but that's probably not an option anyone would use. (Apparently it used to be deliberately crippled in 'client' Windows versions, anyway.)