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.