Description of problem:
When forcing the realm join command to use winbind as AD client software, the generated smb.conf file is wrong (even testparm catches it) and winbind dies as soon as it is started.
Version-Release number of selected component (if applicable):
Simply try to join an AD domain with "realm join" forcing the use of winbind as client software.
Steps to Reproduce:
1. realm join -v --automatic-id-mapping=no --client-software=winbind my.ad.domain
2. systemctl status winbind -l
Winbind unable to start and errors in /etc/samba/smb.conf detected by testparm.
Winbind starts correctly and testparm validates the smb.conf file.
The following problems are present in the automatically generated /etc/samba/smb.conf file:
*) idmap config lines are written in the deprecated old style: convert them to the "idmap config domainname" new style
*) the default idmap backend cannot be "ad" (it's readonly!): use tdb or (better yet) autorid with proper range (this seems to be the fatal error, actually)
*) automatically determined idmap range for "ad" backend goes all the way from 500 up to the full unsigned 32 bit range: at least leave a small buffer over RHEL default of 1000 (for non-system accounts) and also leave some room for the default (tdb/autorid) backend
*) winbind is not a suitable provider for the shadow map in /etc/nsswitch.conf: do not add winbind at the end of the "shadow:" line in /etc/nsswitch.conf
Thank you for the detailed report.
For the main issue, the old style idmap config, there is already ticket https://bugzilla.redhat.com/show_bug.cgi?id=1484072.
About the 'ad' backend. '--automatic-id-mapping=no' tells realmd to assume that UIDs and GIDs are already set in the user an group objects in AD and in this case 'ad' is imo the right backend and is it ok that it is not writable because all data is coming from AD. If you do not use '--automatic-id-mapping=no' realmd will use the 'tdb' backend (but currently still in the old style).
realmd does not add the winbind entries to /etc/nsswitch.conf but calls authconfig which adds them. Imo adding winbind to the 'shadow' line does not do any harm and a missing entry might even cause irritation. But feel free to open a ticket for authconfig about it.
That said I'd like to close this ticket as a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=1484072. Do you agree or are some of your concerns not covered?
Many thanks for your quick follow-up.
Thanks for notifying me of the already existing bug on the configuration format (I've added myself to the CC list on that bug).
I understand that without RFC2307bis attributes in AD the chosen backend becomes "tdb" which is writable; if the resolution of bug #1484072 will make realmd create a default ("*", catch all) idmap section or a dedicated one ("DOMAIN") plus a default one ("*", catch anything else) but always using a writable backend, either way I agree that this issue will not exist.
But I respectfully dissent on the fact that, in presence of RFC2307bis attributes in AD, it is ok to have only that readonly idmap backend, because:
*) first of all it is detected as an invalid smb.conf by testparm and winbind does not start at all
*) anyway, the main reason for using winbind instead of sssd is better support for trusted AD domains/forests (which users could come from), and those domains could have no RFC2307bis attributes, so a default ("*", catch all) idmap section really should be writable (and, thinking of other domains/forests, really "autorid", not "tdb" nor "rid", is the only reasonable choice for the default idmap section, imho)
Lastly, I will follow-up with a ticket on authconfig (since Samba docs explicitly discourages adding winbind to the shadow line, even warning of possible "harm").
To sum it up: if you agree with my reasoning above and if you think that the remaining issue will be taken care of during resolution of bug #1484072 then feel free to close this one as a duplicate.
Many thanks again.
Further (authoritative and up-to-date) info on Winbind configuration:
It is explicitly stated that an "ad" backend *must* be supplemented with a default writable backend: the BUILTIN local users/groups are always present and must be taken care of (besides any considerations on further trusted domains that I added above).
I copied your comments for easier reference to https://bugzilla.redhat.com/show_bug.cgi?id=1484072 and close this as duplicate.
*** This bug has been marked as a duplicate of bug 1484072 ***