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.org/thread/3OYJXJBNNXZWGJ2RENTSOQKUPE2TEV2Q/ 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-and-realmd-based-setup-and-resolution/ 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_ADUC 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 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.org_______________________________________________ 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.org