Jakub, I see. Thank you.

Simo, Is this gssntlmssp package meant to work on CentOS 7.5 / Samba 4.7? If so, is there any configuration needed? I would like my Samba server to be able to handle NTLMSSP authentication for windows' clients, while using SSSD as the authentication layer, if possible. Thanks in advance.

Em sexta-feira, 12 de outubro de 2018 05:03:29 BRT, Jakub Hrozek jhrozek@redhat.com escreveu:

On 11 Oct 2018, at 02:08, Reinaldo Souza Gomes reinaldosouzagomes@yahoo.com.br wrote:

I know that this is an old topic, but I've seen contradictory answers in different places.

Some topics say that SSSD has no support for NTLM due to its inherently unsecure nature, and will never have.

Currently SSSD cannot handle NTLM. We thought about a long time about handling NTLM, but it’s a lot of work for not so much gain…

But others such as this topic(https://bugzilla.redhat.com/show_bug.cgi?id=963341) seem to state that it could be possible through gssntlmssp package.

Since Simo commented on the bug some time ago, maybe he still remembers how gssntlmssp was supposed to help there?

The reason for my question is that I'm trying to use Samba with SSSD, and its authentication fail when the windows client falls back from kerberos to NTLMv2 for any reason:

[2018/10/10 20:43:32.382948,  2] ../source3/auth/auth.c:332(auth_check_ntlm_password)   check_ntlm_password:  Authentication for user [myusername] -> [myusername] FAILED with error NT_STATUS_NO_LOGON_SERVERS, authoritative=1 [2018/10/10 20:43:32.382989,  2] ../auth/auth_log.c:760(log_authentication_event_human_readable)   Auth: [SMB2,(null)] user [MYDOMAIN][myusername] at [Wed, 10 Oct 2018 20:43:32.382980 -03] with [NTLMv2] status [NT_STATUS_NO_LOGON_SERVERS] workstation [NTB005] remote host [ipv4:192.168.1.1:1914] mapped to [MYDOMAIN][myusername]. local host [ipv4:10.1.1.1:445]

Is there anything I can do to make SSSD able to deal with NTLMv2/NTLMSSP?

---

sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.o...

_______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.o...

On 10/12/18 7:30 AM, Simo Sorce wrote:

On Fri, 2018-10-12 at 13:21 +0000, Reinaldo Souza Gomes wrote:

...

Jakub, I see. Thank you.

Simo, Is this gssntlmssp package meant to work on CentOS 7.5 / Samba 4.7?

Yes to authenticate as a domain member you need to have winbind installed, configured and working correctly on the system.

I just spent a very large chunk of time getting exactly this configuration working. It is not as straight forward as one would like. Let me settle into a more comfortable spot and I will detail what I found needs to occur in order for you to have SSSD and winbind work at the same time while serving SMB shares that can use either Kerberos or NTLM (password based) authentication.

...

If so, is there any configuration needed? I would like my Samba server to be able to handle NTLMSSP authentication for windows' clients, while using SSSD as the authentication layer, if possible. Thanks in advance.

Em sexta-feira, 12 de outubro de 2018 05:03:29 BRT, Jakub Hrozek <jhrozek@redhat.com> escreveu:  

...

On 11 Oct 2018, at 02:08, Reinaldo Souza Gomes reinaldosouzagomes@yahoo.com.br wrote:

I know that this is an old topic, but I've seen contradictory answers in different places.

Some topics say that SSSD has no support for NTLM due to its inherently unsecure nature, and will never have.

Currently SSSD cannot handle NTLM. We thought about a long time about handling NTLM, but it’s a lot of work for not so much gain…

...

But others such as this topic(https://bugzilla.redhat.com/show_bug.cgi?id=963341) seem to state that it could be possible through gssntlmssp package.

Since Simo commented on the bug some time ago, maybe he still remembers how gssntlmssp was supposed to help there?

...

The reason for my question is that I'm trying to use Samba with SSSD, and its authentication fail when the windows client falls back from kerberos to NTLMv2 for any reason: [2018/10/10 20:43:32.382948,  2] ../source3/auth/auth.c:332(auth_check_ntlm_password)   check_ntlm_password:  Authentication for user [myusername] -> [myusername] FAILED with error NT_STATUS_NO_LOGON_SERVERS, authoritative=1 [2018/10/10 20:43:32.382989,  2] ../auth/auth_log.c:760(log_authentication_event_human_readable)   Auth: [SMB2,(null)] user [MYDOMAIN][myusername] at [Wed, 10 Oct 2018 20:43:32.382980 -03] with [NTLMv2] status [NT_STATUS_NO_LOGON_SERVERS] workstation [NTB005] remote host [ipv4:192.168.1.1:1914] mapped to [MYDOMAIN][myusername]. local host [ipv4:10.1.1.1:445]

Is there anything I can do to make SSSD able to deal with NTLMv2/NTLMSSP?

---

sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.o...

---

sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.o...

So the very very short version is, yes you can make this work, you need to join the system using the samba tools (winbind), you then need to manually configure sssd to work. Basically as long as they /etc/krb5.keytab is there and valid you are golden BUT there are a lot of bugs and RFEs in this area.

The much longer version is this:

I had a lot of back and forth on this list discovering issues with doing exactly what you are asking for, you can view that conversation here: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o... just in case I forget something in the course of laying this out.

The way that I have gotten this whole thing to work together is the following (Note this is on RHEL 7.5 systems):

- Configure realmd to work, you can do all of this via the command line, but I prefer to use the /etc/realmd.conf file, if you use realmd.conf issue a systemctl stop realmd after you have edited the file as realmd may not pick up the configuration otherwise.

- Join the system to the AD (I am assuming here) using realm, on RHEL 7.5 realm will use winbind/samba to join the AD (this changes in newer versions of Fedora to using adcli, you can be explicit about the meber software it uses with the '--membership-software=samba' flag given to realm join).

- Sadly the /etc/samba/smb.conf file that realmd generates does NOT work with samba >= 4.6 (RHEL 7.4 or later, see here: https://bugzilla.redhat.com/show_bug.cgi?id=1484072) so you need to manually configure the /etc/samba/smb.conf file, this can vary heavily based off of the environment, but for reference mine is here:

[global]   realm = AD.EXAMPLE.COM   password server = *   encrypt passwords = yes   kerberos method = system keytab   workgroup = AD   server string = %h samba   security = ADS   map to guest = Bad User   load printers = no   passdb backend = tdbsam   dns proxy = no   max log size = 5000   bind interfaces only = no

restrict anonymous = 2     idmap config * : backend = tdb     idmap config * : range = 20000001-20001000     idmap config AD:backend = ad     idmap config AD:schema_mode = rfc2307     idmap config AD:range = 1000-20000000

The really important parts are:

- kerberos method = system keytab

This will stop samba from attempting to rotate the password for the machine every 7 days and of course tells it to use the keytab. Any setting other than 'secrets only' should be safe, but you do not want Samba rotating the password as the keytab will get out of sync with the machine password, there are workarounds for this like here: https://www.linux.ncsu.edu/blog/2018/03/30/potential-conflict-between-samba-... but they do not work reliably enough for production use.

- idmap config * : backend = tdb   idmap config * : range = 20000001-20001000

Samba needs some space in which to map internally used users, so give it some space where the UID range does not conflict with your UID space.

-    idmap config AD:backend = ad      idmap config AD:schema_mode = rfc2307      idmap config AD:range = 1000-20000000

The above needs to exist but is very specific for our environment, most generic AD environments will not have rfc2307 attributes in place. If you have rfc2307 attributes in place you should see something like the following: https://wiki.samba.org/index.php/Maintaining_Unix_Attributes_in_AD_using_ADU... if not you are probably going to want to use a version of automatic ID mapping like 'man idmap_autorid'. Unfortunately this stuff is complicated... I wish it were easier but it isn't.

- At this point you hopefully have a working Samba configuration that will allow smbd to start as well as winbind. Again Samba should NOT be configured to automatically change the machine password as havoc will ensue. To test run the following:

wbinfo -P

- We now need to configure sssd to work, much like smb.conf this configuration can be extremely site specific, especially when it comes to the UID/GID maping from SIDs or from RFC2307 but the one directive you really need right now is:

-  ad_maximum_machine_account_password_age =0'

This directive will stop SSSD from attempting to rotate the keytab (by default every 30 days) as SSSD   uses adcli for the keytab rotation and adcli does not yet support updating the machine password in the samba secrets.tdb file, see here: https://bugs.freedesktop.org/show_bug.cgi?id=100118 . I am told the patches are done but it has not been pushed upstream.

To expand on this a bit the basic problem right now is that samba/winbind can not reliably update both the keytab and the secrets.tdb file and adcli does not update the secrets.tdb at all, so either the keytab or the machine password stored in secrets.tdb will be out of sync with one another if either of these mechanisms are enabled, so we disable them both.

There seems to be a lot of confusion around whether machine passwords need to be rotated, and even Microsoft gives two different answers, but from all of my research it appears that the AD does NOT have any requirement that machine passwords are changed, so disabling them should be safe.

- Make sure to remove the sssd-libwbclient in preference to libwbclient (or you can use the alternatives system to set libwbclient to be a higher priority than sssd-libwbclient as sssd-libwbclient doesn't handle NTLM as you have found).

- 'realm join' using winbind helpfully tries to configure the pam stack to use winbind to login to the system, we don't want that, we want sssd to handle that so run the following:

'/usr/sbin/authconfig --update --disablewinbind --disablewinbindauth --enablemkhomedir --nostart'

- Configure SSSD in the pam stack as you see fit, you can probably use authconfig to simply insert it, but I manually modify the files and it is very specific to my environment so I can't help here.

- Finally there is a bug in SELinux wherein if you use kerberos for SSH access to the host Samba and SSH will not play well together with regards to the credential cache, see here: https://bugzilla.redhat.com/show_bug.cgi?id=1477900 using PrivateTmp as suggested in comment 7 works, however I would recommend doing it for smb and not for ssh as is suggested in the comment as using privatetmp for ssh just led to chaos in my environment, whereas privatetmp for smb seems to work fine. If you don't care about kerberos use for ssh, then you can skip this and samba will happily take control of that file via SELinux and you won't need to worry.

Whew! That is rather a lot isn't it? I wish it were simpler, but there be a lot of dragons down in the depths of this. I believe I have covered all of the pertinent steps. I know nothing about the gssntlmssp package you reference so maybe that is an easier way to get this going? Do let the group know here if you get something working as I'll be interested to know.

I'll try to help if you have questions, I wanted to write all of this up somewhere, but as you can see a lot of it is very site specific and as such doesn't really lend itself to a blog post for general consumption.

Good luck, you will probably need it on this.

-Erinn

On 10/12/18 7:30 AM, Simo Sorce wrote:

On Fri, 2018-10-12 at 13:21 +0000, Reinaldo Souza Gomes wrote:

...

Jakub, I see. Thank you.

Simo, Is this gssntlmssp package meant to work on CentOS 7.5 / Samba 4.7?

Yes to authenticate as a domain member you need to have winbind installed, configured and working correctly on the system.

...

If so, is there any configuration needed? I would like my Samba server to be able to handle NTLMSSP authentication for windows' clients, while using SSSD as the authentication layer, if possible. Thanks in advance.

Em sexta-feira, 12 de outubro de 2018 05:03:29 BRT, Jakub Hrozek <jhrozek@redhat.com> escreveu:  

...

On 11 Oct 2018, at 02:08, Reinaldo Souza Gomes reinaldosouzagomes@yahoo.com.br wrote:

I know that this is an old topic, but I've seen contradictory answers in different places.

Some topics say that SSSD has no support for NTLM due to its inherently unsecure nature, and will never have.

Currently SSSD cannot handle NTLM. We thought about a long time about handling NTLM, but it’s a lot of work for not so much gain…

...

But others such as this topic(https://bugzilla.redhat.com/show_bug.cgi?id=963341) seem to state that it could be possible through gssntlmssp package.

Since Simo commented on the bug some time ago, maybe he still remembers how gssntlmssp was supposed to help there?

...

The reason for my question is that I'm trying to use Samba with SSSD, and its authentication fail when the windows client falls back from kerberos to NTLMv2 for any reason: [2018/10/10 20:43:32.382948,  2] ../source3/auth/auth.c:332(auth_check_ntlm_password)   check_ntlm_password:  Authentication for user [myusername] -> [myusername] FAILED with error NT_STATUS_NO_LOGON_SERVERS, authoritative=1 [2018/10/10 20:43:32.382989,  2] ../auth/auth_log.c:760(log_authentication_event_human_readable)   Auth: [SMB2,(null)] user [MYDOMAIN][myusername] at [Wed, 10 Oct 2018 20:43:32.382980 -03] with [NTLMv2] status [NT_STATUS_NO_LOGON_SERVERS] workstation [NTB005] remote host [ipv4:192.168.1.1:1914] mapped to [MYDOMAIN][myusername]. local host [ipv4:10.1.1.1:445]

Is there anything I can do to make SSSD able to deal with NTLMv2/NTLMSSP?

---

sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.o...

---

sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.o...

My first experience with SSSD for SFTP authentication was having a higly critical system's authentication going off because I didn't know about adcli, so I didn't install it. After exactly 30 days, the AD server changed that machine account's password, but the linux server didn't. Those were rough days. So,  I'm pretty sure that updating the machine account's password is a must unless you disable password age on your AD domain:https://support.microsoft.com/en-us/help/154501/how-to-disable-automatic-mac...

Regarding the smb.conf, for some reason I never got "kerberos method = system keytab" to work. I had to set either "kerberos method = dedicated keytab"or "kerberos method = secrets and keytab" along with the keytab's path. Looks like samba can't find the "system tab", even though it's in /etc/krb5.keytab. I will consider this set up and let you know if I ever get it working.

Em sexta-feira, 12 de outubro de 2018 17:23:01 BRT, Erinn Looney-Triggs erinn.looneytriggs@gmail.com escreveu:

Also as another data point there is another thread currently going on in this mailing list: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o... that seems to imply that the machine password DOES need to be changed periodically.

I honestly don't know the answer on this one, again from my research it appears unless there is custom software in the AD that removes systems if their entries are not 'fresh' enough then machines should not need to have their passwords changed, it appears to be a client requirement in windows not an AD enforced requirement, see here: https://blogs.technet.microsoft.com/askds/2009/02/15/machine-account-passwor...

I certainly hope I am right on this one, otherwise I am going to have ~600 systems that are going to have a hell of a time logging in very soon :). I hope that adcli patches come through to RHEL soon so I can just have both the keytab and the secrets.tdb updated by one program and everything will be kept in sync. It would seem to me that it is a really good idea to change the machine password, but as mentioned right now there appears to be no reliable way to do that.

-Erinn _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.o...

And finally I wanted to follow up to say that I am now 34-36 days (systems joined in a staggered fashion) in since I disabled password changes on the clients and there have been, so far, no ill effects, and no lock outs. Just another data point, it has worked for me so far.

-Erinn