Bug 1487145
Summary: | Bad smb.conf generated by "realm join" when forced to use winbind | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Giuseppe Ragusa <giuseppe.ragusa> |
Component: | realmd | Assignee: | Sumit Bose <sbose> |
Status: | CLOSED DUPLICATE | QA Contact: | BaseOS QE Security Team <qe-baseos-security> |
Severity: | high | Docs Contact: | |
Priority: | unspecified | ||
Version: | 7.4 | CC: | pkis |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2017-09-11 08:25:21 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Giuseppe Ragusa
2017-08-31 10:23:46 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 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 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). 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 *** |