Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 1487145 - Bad smb.conf generated by "realm join" when forced to use winbind
Summary: Bad smb.conf generated by "realm join" when forced to use winbind
Keywords:
Status: CLOSED DUPLICATE of bug 1484072
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: realmd
Version: 7.4
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: rc
: ---
Assignee: Sumit Bose
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-08-31 10:23 UTC by Giuseppe Ragusa
Modified: 2017-09-11 08:25 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-09-11 08:25:21 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Giuseppe Ragusa 2017-08-31 10:23:46 UTC
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):
realmd 0.16.1-9
samba-winbind 4.6.2-8

How reproducible:
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
3. testparm

Actual results:
Winbind unable to start and errors in /etc/samba/smb.conf detected by testparm.

Expected results:
Winbind starts correctly and testparm validates the smb.conf file.

Additional info:
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

Comment 2 Sumit Bose 2017-08-31 10:52:24 UTC
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?

bye,
Sumit

Comment 3 Giuseppe Ragusa 2017-08-31 14:36:24 UTC
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.

Bye,
Giuseppe

Comment 4 Giuseppe Ragusa 2017-09-05 05:51:47 UTC
Further (authoritative and up-to-date) info on Winbind configuration:

https://wiki.samba.org/index.php/Idmap_config_ad

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).

Comment 5 Sumit Bose 2017-09-11 08:25:21 UTC
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 ***


Note You need to log in before you can comment on or make changes to this bug.