Bug 5556 - Option to net ads join to specify servicePrincipalName (SPN) attribute on AD computer account
Option to net ads join to specify servicePrincipalName (SPN) attribute on AD ...
Status: RESOLVED INVALID
Product: Samba 3.0
Classification: Unclassified
Component: net utility
3.0.30
All All
: P3 enhancement
: none
Assigned To: Gerald (Jerry) Carter
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-06-22 05:20 UTC by darkmarc666
Modified: 2008-07-12 22:08 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description darkmarc666 2008-06-22 05:20:01 UTC
When using security = ads and Kerberos to authenticate client connections to the Samba server, the Windows client requests a service ticket from AD to the service principal names cifs/hostname or cifs/hostname.domain.com. This goes for Win XP and newer. Win 2000 clients requests host/hostname or host/hostname.domain.com. In multi-platform, multi-domain environments it may be desireable to have the option to specify which service principal names that are actually written to the AD computer account upon joining the domain.

Existing Samba 3.0.* seems to write "host/hostname" and "host/hostname.domain.com" to the servicePrincipalName (SPN) attribute (multi-valued) of the AD computer account. The hostname and domain that is used probably also depends on your Samba server's /etc/hosts, resolv.conf, NetBIOS hostname and aliases etc configurations.

In environments where for example a NetBIOS alias is used for the Samba service, an SPN on the form cifs/samba-alias and/or cifs/samba-alias.domain.com etc is needed. 

If you, like we do, use some other product (Vintela Authentication Services) to join your Unix system to AD, the SPN "host/hostname" and "host/hostname.domain.com" are already "occupied" by another computer account. We therefore need explicit SPNs using cifs/ on the Samba computer account for AD to be able to tell the two apart when assigning service tickets. In this scenario, it does not matter that cifs/ is "included" in host/, since they need to exist on separate computer accounts.

All in all, different scenarios call for different configurations and in this specific scenario we need specific SPNs on specific computer accounts. This is today solved by manually setting the SPN on the affected computer accounts using some ldap tool like ADSI Edit, ldapmodify, setspn.exe etc.

In the Samba end, I would like to request that "net ads join" by default sets the same SPNs it does today, and that this functionality is also extended with a --setspn option or similar that makes it possible for the administrator to choose which SPNs to use upon joining AD. Finally, the default behaviour, the --setspn option as well as some considerations about choosing which SPNs to use, should be documented in the net command documentation. I'd be happy to provide input if needed.
Comment 1 Gerald (Jerry) Carter 2008-06-25 07:19:33 UTC
(In reply to comment #0)

> All in all, different scenarios call for different configurations and in this
> specific scenario we need specific SPNs on specific computer accounts. This is
> today solved by manually setting the SPN on the affected computer accounts
> using some ldap tool like ADSI Edit, ldapmodify, setspn.exe etc.


According to the MS KB, the AD DC will thunk down requests from cifs/name to host/name when attempting to match the SPN.  If you want additional SPNs, you can alway get them via setting "user kerberos keytab = yes" and smb.conf
and the call"net ads keytab add <principal>".  Does that server you need ?
Comment 2 darkmarc666 2008-07-08 04:57:19 UTC
(In reply to comment #1)

> According to the MS KB, the AD DC will thunk down requests from cifs/name to
> host/name when attempting to match the SPN.  If you want additional SPNs, you
> can alway get them via setting "user kerberos keytab = yes" and smb.conf
> and the call"net ads keytab add <principal>".  Does that server you need ?

I was not aware of the "net ads keytab add <principal>" functionality. It might actually serve what I need. It does, however, require the use of a Kerberos keytab file for storage of the computer credentials. In our case, we will therefore have to be careful not to overwrite the other Kerberos keytab that the host already has from the VAS software that joins it to AD. I am not sure how to configure this since there is only one /etc/krb5.conf file, and in there I am familiar with the "default_keytab_name" config option. Not sure how to configure krb5.conf to use different keytab files for different apps.

I am aware that the AD DC interprets requests for cifs/hostname as host/hostname if no cifs/hostname SPN is available. What I was initially referring to was that if there is a need to register a "cifs/alias-hostname" SPN attribute on a host that previously only had "host/hostname", the AD DC cifs->host substition does not work since there are different hostnames involved. Thus the need to have a flexible configuration of the SPN attribute, and I thought putting that functionality into the "net ads join" command was a good idea.
Comment 3 Simo Sorce 2008-07-12 22:08:55 UTC
Please contact VAS support or consult the VAS documentation (or better the resource central documentation).
I have personally added an option in their samba version, while working there, to address the problem of sharing the same kerberos account. I think they may also have added some support in VAS itself to automatically update the samba secret when VAS perform a password change on the account.

I am closing this as invalid, please re-open if there is something else that is samba specific.