Bug 12248 - Handle arbitrary principals in keytab
Handle arbitrary principals in keytab
Status: NEW
Product: Samba 4.1 and newer
Classification: Unclassified
All All
: P5 normal
: ---
Assigned To: Andrew Bartlett
Samba QA Contact
Depends on:
  Show dependency treegraph
Reported: 2016-09-08 14:00 UTC by Daniel Kobras
Modified: 2016-09-08 17:40 UTC (History)
1 user (show)

See Also:

s3:utils/net: add SPN entries from net ads (3.18 KB, patch)
2016-09-08 14:00 UTC, Daniel Kobras
no flags Details
s3-libads: update arbitrary principals in keytab (4.05 KB, patch)
2016-09-08 14:01 UTC, Daniel Kobras
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Kobras 2016-09-08 14:00:54 UTC
Created attachment 12452 [details]
s3:utils/net: add SPN entries from net ads

Currently, if Samba is configured to handle keytab updates, it will only consider one of the following types of principals:

* <sAMAccountName>@<DOMAIN>
* <userPrincipalName>
* <service>/<machine_name>@<DOMAIN>
* <service>/<dNSHostName>@<DOMAIN>

All other principals are discarded upon keytab rotation or creation, even if they've been present in the keytab before, or explicitly configured as servicePrincipalNames in the machine account. Furthermore, any principal <service>/<othername>@<DOMAIN> will lead to two keytab entries <service>/<machine_name>@<DOMAIN> and <service>/<dNSHostName>@<DOMAIN> (but no <service>/<othername>@<DOMAIN>), regardless if they actually exist in AD or not.

This seems to be due to logic in source3/libads/kerberos_keytab.c::ads_keytab_add_entry() that tries to add SPN entries to the machine account if required, but is restricted by ads_add_service_principal_name() that can only handle service principals with machine_name and dNSHostName suffix.

There are multiple callers to ads_keytab_add_entry(). However, all but source3/utils/net_ads.c::net_ads_keytab_add() should only ever have to deal with principals that are already existing in AD. Hence, I'm attaching two draft patches that move addition of SPNs up the call chain to net_ads_keytab_add(), and let ads_keytab_add_entry() just add to the keytab whichever principals it's given.

With there patches in place, I've verified that a keytab update now contains entries for all principals previously included in the keytab, as well as all servicePrincipalNames included in the machine account.

As for 'net ads keytab add', I've tried to replicate the existing logic, even though it's not entirely clear to me, ie.

net ads keytab add foo
-> adds foo/machine_name and foo/dNSHostName as SPNs to the machine account in AD, and to the local keytab;

net ads keytab add foo$
-> just adds an entry for foo$ to the local keytab (probably assuming its our machine account that already exists in AD);

net ads keytab add foo@bar
-> just adds an entry for foo@bar to the local keytab.

This code could be further streamlined and extended to consider SPN mappings (based on the sPNMappings attribute in AD), but I'm unsure what's really intended here, and how versatile an interface net ads keytab add is meant to be.
Comment 1 Daniel Kobras 2016-09-08 14:01:41 UTC
Created attachment 12453 [details]
s3-libads: update arbitrary principals in keytab