This was changed in bug #1802182 to use netbios+realm, see also bug #1835681.
As an alternative, a new smb.conf option was added "additional dns hostnames", allowing to add SPNs at join time.

Thanks, I already looked at the "additional dns hostnames" option in the smb.conf man page, but did not see this as applicable, because 1) the currently used netbios+realm "name" is clearly related to the realm and not the DNS, and 2) the consistent use of "additional" made me believe that this was not needed for the default FQDN (which would be the logical thing).

Unfortunately I do not have access to bug #1802182, but I managed to find https://bugzilla.samba.org/show_bug.cgi?id=14116. There is not enough information in there for me to understand the problem that it tries to fix, nor the impact of this change for current common use. Were things like GSSAPI authentication supposed to keep working as before with the new netbios+realm solution in common AD environments? If so, what makes our situation uncommon?

Also, the need to explicitly define an (default!) FQDN in the smb.conf seems to be disproportionate to the previous requirement for a correct /etc/hostname (which usually makes live easier in other ways as well). We were using the same standard smb.conf for all our hosts, the need for host-specific options in there makes rollout and updates more complex.

Is it not possible to automatically add an extra SPN with the default FQDN during (or after) the join in a way that any errors for that extra SPN are silently ignored?
(And if so, would this not also be a solution for the original problem, so that this change can be reverted?)

Alternatively, was adding a more visible extra option to net ads join for specifying the additional DNS names directly during the join considered?

Using the "additional dns hostnames" option does create the extra SPN, but does not add it to the keytab? To make ssh GSSAPI logins work I had to manually add the SPN to the keytab.

(In reply to Robbert Eggermont from comment #4)
> Using the "additional dns hostnames" option does create the extra SPN, but
> does not add it to the keytab? To make ssh GSSAPI logins work I had to
> manually add the SPN to the keytab.

Sounds like sshd passes an explicit principal when accepting the ticket, you could probably workaround it by setting ignore_acceptor_hostname=true in krb5.conf but this sound like a good reason to add "additional dns hostnames" entries to the keytab. I have reopened bug #1828354 for that matter.

Otherwise, I can think of adding an option to the net-join command, like dnshostname to specify an alternative dNSHostName and SPN, do you think that would be more helpful?

I would still very much like to know if this change which is incompatible with decades of common practice of using FQDNs (including the uses of FQDNs by one of the major KDC providers, Microsoft's Active Directory) was really necessary and worth the breaks compared to the problem it solves? (We have been running like this for 10(!) years, with RHEL 5, 6, 7 and 8, no problems. I hate to be a tester of this in our production environment!)

But yes, I would prefer a (clearly documented) option for the net-join command.

As explained, samba will no longer implicitly use machine fqdn at join time as decided upstream to make the join process more reliable.

I'll be looking into adding it as an option to net-join command.

Alright, if the change was correct, then the problem must be in the way ssh uses GSSAPI? Any way then that that can be fixed then so that ssh GSSAPI logins once again work "out-of-the-box" without requiring a change in the way we roll out our installations?

If the fqdn differs as in this case, you'd still need the new net-join option (not implemented yet) or use "additional dns hostnames" (once it is fixed to add entries to the keytab, per #1828354).

Should the '[domain_realm]' mappings in krb5.conf not somehow make this work?

Or is the new "best practice" thus to have the realm identical to the domain?

Not sure I follow, no need for krb5.conf changes.

*** Bug 1835681 has been marked as a duplicate of this bug. ***

*** Bug 1832111 has been marked as a duplicate of this bug. ***

*** Bug 1846068 has been marked as a duplicate of this bug. ***

Summary of the fix to be released:
We recently changed the dnsHostName attribute at join time to be netbios+realm instead of implicitly using machine fqdn.
As an alternative, we provided "additional dns hostnames" smb.conf option to allow specifying additional hostnames.
In addition, this bug fix provides a new net-ads-join dnshostname=fqdn option to allow specifying the dnsHostName at join time.

Then will the fix be released?

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: samba security, bug fix, and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2020:3981

Hello Team,

"Will "net" option "dnshostname" also adopted by command "realm join" ?" It seems samba-4.10.16-7 does not consider dnshostname option by realm command


Thanks & Regards,
Pallavi Soni

(In reply to PALLAVI from comment #26)
> Hello Team,
> 
> "Will "net" option "dnshostname" also adopted by command "realm join" ?" It
> seems samba-4.10.16-7 does not consider dnshostname option by realm command
> 
> 
> Thanks & Regards,
> Pallavi Soni

Hi,

see https://bugzilla.redhat.com/show_bug.cgi?id=1867912, please note that realmd in RHEL-8.3 will not use the 'dnshostname' command line option but the 'additional dns hostnames' smb.conf option.

HTH

bye,
Sumit