On 08/30/2018 12:59 AM, Sumit Bose wrote: > On Wed, Aug 29, 2018 at 10:33:30AM -0600, Erinn Looney-Triggs wrote: >> On 08/29/2018 02:48 AM, Sumit Bose wrote: >>> On Mon, Aug 27, 2018 at 05:18:01PM -0600, Erinn Looney-Triggs wrote: >>>> I have a system that is joined to an AD domain via SSSD, it was happily >>>> running samba and serving shares using either kerberos or password >>>> authentication, with the update to Samba 4.7.1 in the RHEL 7.5 release, >>>> all of that stopped working. >>>> >>>> samba config file: >>>> >>>> [global] >>>> log level = 5 >>>> >>>> password server = * >>>> realm = AD.EXAMPLE.COM >>>> encrypt passwords = yes >>>> kerberos method = system keytab >>>> workgroup = AD >>>> server string = %h samba >>>> security = ADS >>>> map to guest = Bad User >>>> interfaces = <valid IP> >>>> hosts allow = <valid IP blocks> >>>> load printers = no >>>> passdb backend = tdbsam >>>> dns proxy = no >>>> max log size = 5000 >>>> bind interfaces only = no >>>> >>>> restrict anonymous = 2 >>>> >>>> #============================ Share Definitions >>>> ============================== >>>> [images] >>>> comment = example images >>>> path = /var/eng/ >>>> guest ok = no >>>> printable = no >>>> write list = >>>> create mask = 0664 >>>> directory mask = 0775 >>>> read only = no >>>> valid users = +valid-example-group >>>> force group = >>>> browseable = yes >>>> >>>> Now samba will not even start without either libwbclient or >>>> sssd-libwbclient installed with the above configuration. After >>>> installing sssd-libwbclient and modifying valid users to: >>>> >>>> valid users = AD\valid-example-group >>>> >>>> kerberos based connections will work just fine. However password based >>>> connections for windows systems that are not AD joined, or smbclient >>>> without kerberos, does not work. I believe this is falling back to NTLM >>>> and NTLM is simply not supported by SSSD correct? >>>> >>>> Oddly, what used to work, with basically a call to getgrnam() no longer >>>> works in 4.7.1 release of samba and there seems to be no mention that I >>>> can find as to why. Any thoughts? >>>> >>>> It looks an awful lot like, if we need to support both krb and password >>>> based connections we will need to use winbind, correct? Or is there >>>> another way to make this thing work? If I have to use winbind it looks >>>> like I need to use 'net ads join' or 'realm join >>>> --client-software=winbind' but it then seems to me that the system will >>>> be joined to the AD twice, once to use SSSD, and once for winbind is >>>> this correct? Is there a way to make winbind and SSSD work together? >>>> >>>> Further it looks like, according to this: >>>> https://bugzilla.redhat.com/show_bug.cgi?id=1558560 that RHEL 7.6 with >>>> Samba 4.8.1 will require winbind to be running period. I believe that >>>> statement to be a bit of an oversimplification because sssd-libwbclient >>>> should still work, or am I misunderstanding? >>>> >>>> Any guidance here would be great, this seems to be a fairly murky area, >>>> or my google fu is weak. >>> Yes, if you want to use password authentication (NTLM) you have to run >>> winbind with recent versions of Samba. The reason is that some old >>> fallback code was removed from the smbd binary mainly for security >>> reasons and to simplify the code in general. >>> >>> If you only need Kerberos authentication sssd-libwbclient can still be >>> used. >>> >>> For all other cases where winbind must be running install Samba's >>> libwbclient and I would recommend to use SSSD's idmap plugin for >>> Samba/Winbind, see man idmap_sss for details. >>> >>> Since idmap_sss is read-only from the winbind perspective it is >>> recommend to have a read-write plugin as well so that the actual imap >>> config for smb.conf might look like: >>> >>> idmap config * : backend", "tdb" >>> idmap config * : range", "10000-99999" >>> >>> idmap config MYDOMAIN : backend = sss >>> idmap config MYDOMAIN : range = 200000-2147483647 >>> >>> If you have a forest with multiple domains you should add a >>> configuration for each domain with suitable ranges. >>> >>> This way both SSSD and Winbind will talk to AD with the same credentials >>> but SSSD still does all system authentication (no need to add >>> pam_winbind to the PAM configuration) and user group lookup. Winbind >>> will only serve the needs of smbd and other direct users of libwbclient >>> but gets all information about idmapping from SSSD so that both Winbind >>> and SSSD will always use the same UIDs and GIDs for the same AD object. >>> >>> HTH >>> >>> bye, >>> Sumit >>> >> Sumit, >> Much appreciated, you confirmed a lot of what I suspected. >> >> The final piece that I am trying to put together then is in effect, how >> to get winbind and sssd both functioning together. Remember this is on a >> RHEL 7.5 system. >> >> If I simply join the system using 'realm join' winbind will not start >> throwing this error: >> Could not fetch our SID - did we join? >> >> Running 'net ads testjoin' I end up getting prompted from the machine's >> kerberos password, which of course I don't have, I assume SSSD has it >> squirreled away somewhere. >> >> If however, I join the system with 'realm join >> --client-software=winbind', 'net ads testjoin' works just fine, but I am >> very unsure as to whether SSSD will work in this configuration. > Please use --membership-software=samba instead of > --client-software=winbind. realmd can either use adcli or 'net ads join' > to join an AD domain. adcli will only create a keytab with Kerberos key > generated from the host password. But Samba and Winbind require also the > plain text password in an internal database together with the domain SID > and some other settings. This data is currently only added by 'net ads > join' so you have to tell realm to use it is you want to use Samba or > Winbind. > > What puzzles me a bit is that realmd on RHEL-7.5 should pick 'net ads > join' by default. Any chance you have changed the default configuration? > >> Specifically I am concerned about the password updates for the keytab >> that occur and whether winbind will handle those, or sssd will try and >> both will step on each other. This configuration also leaves me with >> having to manually pull together a sssd.conf, which is fine. > You are right, only only should handle them. I would suggest to disable > the renewal on the SSSD side and let winbind do the job because of the > plain text password issue (see above). If you set 'kerberos method' in > smb.conf to 'system keytab' or 'secrets and keytab' I'd expect that > winbind will update the keytab entries as well. Sadly, winbind doesn't appear to 'do the job', see here: https://www.linux.ncsu.edu/blog/2018/03/30/potential-conflict-between-samba-and-realmd-based-setup-and-resolution/ and even the workaround doesn't seem to work (though I am testing now). Further, https://bugs.freedesktop.org/show_bug.cgi?id=100118 is an RFE asking for adcli to update the password in the secrets.tdb which would go a long way toward fixing this overall issue. However, it doesn't seem to be getting much traction.
-Erinn > > HTH > > bye, > Sumit > >> I'll be investigating whether this is possible today, but any feedback >> is sure welcome on this. >> >> As to ID mappings, we are actually lucky there, the AD schema has been >> extended with rfc2307 so UID /GID lookups can occur that way in a sane >> manner that is consistent across winbind and sssd. >> >> -Erinn >> >>>> -Erinn >>>> >>>> >>>> _______________________________________________ >>>> sssd-users mailing list -- sssd-users@lists.fedorahosted.org >>>> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org >>>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html >>>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >>>> List Archives: >>>> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org >>> _______________________________________________ >>> sssd-users mailing list -- sssd-users@lists.fedorahosted.org >>> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org >>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html >>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >>> List Archives: >>> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org >> _______________________________________________ >> sssd-users mailing list -- sssd-users@lists.fedorahosted.org >> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org >> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org > _______________________________________________ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
