On 09/06/2018 11:21 AM, Erinn Looney-Triggs wrote: > > 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. After even more digging into this, the situation is a bit more complicated than it at first appears.
The only time that winbind handles machine account password changes is when 'kerberos method = secrets only' (https://bugzilla.samba.org/show_bug.cgi?id=6750), and winbind will NOT update /etc/krb5.keytab. net ads changetrustpw can be used to update the password and the keytab however it appears to not be reliable, as I was able to reproduce (https://www.linux.ncsu.edu/blog/2018/03/30/potential-conflict-between-samba-and-realmd-based-setup-and-resolution/). As such the only real solution to the machine password conundrum at the current moment is to disable ALL automatic changes of the password, so adding 'ad_maximum_machine_account_password_age =0' to sssd.conf and having 'kerberos method' != 'secrets only' should disable all password changes. This is not a problem per se, the AD does not enforce password changes: https://blogs.technet.microsoft.com/askds/2009/02/15/machine-account-password-process-2/ BUT your organization may scavenge hosts they believe are dead by looking at the time stamp on of the last password change. Something to be aware of. -Erinn > -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 -- [email protected] >>>>> To unsubscribe send an email to [email protected] >>>>> 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/[email protected] >>>> _______________________________________________ >>>> sssd-users mailing list -- [email protected] >>>> To unsubscribe send an email to [email protected] >>>> 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/[email protected] >>> _______________________________________________ >>> sssd-users mailing list -- [email protected] >>> To unsubscribe send an email to [email protected] >>> 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/[email protected] >> _______________________________________________ >> sssd-users mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> 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/[email protected] _______________________________________________ sssd-users mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected]
