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-sam...
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'
(
), 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
(
).
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:
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 -- sssd-users(a)lists.fedorahosted.org
>>>> To unsubscribe send an email to sssd-users-leave(a)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.fedorahoste...
>>> _______________________________________________
>>> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
>>> To unsubscribe send an email to sssd-users-leave(a)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.fedorahoste...
>> _______________________________________________
>> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
>> To unsubscribe send an email to sssd-users-leave(a)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.fedorahoste...
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)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.fedorahoste...