Badlock samba update breaks samba-AD login

Latest response

When we applied the badblock patch for samba, i.e. the following patches:
Updating:
libldb x86_64 1.1.25-2.el6_7 rhel-x86_64-server-6 113 k
libsmbclient x86_64 3.6.23-30.el6_7 rhel-x86_64-server-6 1.6 M
libtalloc x86_64 2.1.5-1.el6_7 rhel-x86_64-server-6 26 k
libtdb x86_64 1.3.8-1.el6_7 rhel-x86_64-server-6 43 k
libtevent x86_64 0.9.26-2.el6_7 rhel-x86_64-server-6 29 k
samba x86_64 3.6.23-30.el6_7 rhel-x86_64-server-6 5.1 M
samba-common x86_64 3.6.23-30.el6_7 rhel-x86_64-server-6 10 M
samba-winbind x86_64 3.6.23-30.el6_7 rhel-x86_64-server-6 2.2 M
samba-winbind-clients x86_64 3.6.23-30.el6_7 rhel-x86_64-server-6 2.0 M

it broke active directory authentication for samba. Our setup is to do account authentication with active directory. When we downgrade the patch to what it was, it restores our connectivity. Has anyone else seen this. This is with mounting shares on Windows 7 or on OS X.

Responses

I can confirm this behavior on several systems that are using SAMBA 3.6.23-30.el6_7 - a previously workding AD configuration is not working anymore.

Error: domain_client_validate: unable to validate password for user XXX in domain YYY to Domain controller ZZZ. Error was NT_STATUS_ACCESS_DENIED.

I just checked and it breaks AD authentication on Samba 4.2.3 as well on RHEL 7.

I have the same issue with samba3x-winbind-3.6.23-12.el5_11 samba3x-3.6.23-12.el5_11

I downgraded, and its working again, but it looks like from the Forums, we will need to fix our winbind implementation.

Can confirm on two separate instances. Also heard there was some discussion from the Scientific Linux community about the same thing occurring.

The patch broke authentication on our cluster running centos 6. We run slurm and some other products that require centos.

I saw an alert that indicated that if you include the following line in smb.conf that the connectivity is maintained: allow dcerpc auth level connect = yes

does not appear to work.

In our case starting winbind as additional service solved the issue.

In our environment we use LDAP as our authoritative login control for logging directly to the system and use AD for controlling log in to samba shares. I think I will be looking into using LDAP for samba authentication as well.

+1 for fixing this on RH6 by starting winbind. That works for me, too.

Ok, winbind helps with part of the redhat 6 problem. It doesn't help with access based on supplemental local group memberships. * on redhat 4 ELS, samba-3.0.33-3.37.el4 & friends, exported samba file shares work as before. * on redhat 5, samba-3.0.33-3.41.el5_11, exported samba file shares work as before. * on redhat 6, samba-3.6.23-30.el6_7.x86_64, shares don't work unless winbind is running. Even then, file access which should be allowed based on supplemental groups fails. Access based on owner or primary group succeeds. Interestingly enough, on redhat 6 systems using winbind integration to AD in PAM and NSS, although access based on local supplemental groups now fails (it used to work), access based on windows groups works (it used to fail).

One thing we have noticed once starting to use winbind is that it crashes with core files and connectivity will be lost until winbind is restarted. Has anyone else noticed this?

Does anyone know if this is in the process of being remedied?

Yes, several of us have tickets open, particularly about the inability to grant access to files via supplemental group memberships with security=domain. The file owner, primary group members, and windows group members seem to get access.

Redhat has explained the new need for winbindd in: https://access.redhat.com/solutions/2260591

Thank you James!

We're using security=ads and with the new settings suggested we can no longer use Unix groups to give access to shares. Also, we are now seeing the notice once per minute of rpc_client/cli_netlogon.c:848(rpccli_netlogon_set_trust_password) credentials chain check failed in the log file log.wb-{DOMAIN}

My one redhat 6 server with security=ads which I patched so far isn't giving me that error, but I too can only access samba shared files if I own them or they have my primary group; local supplemental groups don't work any more. Interestingly enough, windows global groups with unix attributes are now working for me - but that's where the owner and primary group are coming from, too.

What do you have in your krb5.conf file, as well as /etc/security/pam_winbind.conf. You can redact server names and replace them with a dummy name.

The error is in the log file in the samba logs log.wb-{DOMAIN} where DOMAIN is the name of your domain or workgroup.

My log files including /var/log/samba/log.wb-DOMAIN file don't have your error, though I've certainly been finding lots of other exciting symptoms from a variety of redhat 6 systems where access to files based on local unix supplemental groups broke. The less grandiose and more insecure fixes for samba 3.0 on redhat 4 and redhat 5 don't appear to have broken any of my use cases. On my "security=domain" redhat 6 servers local owners and local primary groups get access to samba file shares; local unix supplemental groups do not. On my "security=ads" redhat 6 servers, all windows groups work (file owner, primary group, other groups) but again, local unix supplemental groups do not. These latter servers have

/etc/krb5.conf:
...
[libdefaults]
 default_realm = XXX.YYY
 dns_lookup_realm = true
 dns_lookup_kdc = true
  ...
/etc/pam.d/system-auth links to:
   ...
  auth        sufficient    pam_winbind.so use_first_pass krb5_auth
  ...
  account     required      pam_access.so nodefgroup
  ...
  password    sufficient    pam_winbind.so use_authtok krb5_auth

/etc/security/access.conf has:
  + : root (wheel) : LOCAL
  - : root : ALL
  + : (localaccess) (user_SERVER) : ALL
   - : ALL : ALL

where local unix group "localaccess" is used to authorize some users to run cron jobs and the like, and windows global domain group "user_SERVER" is used to control who can log in or use Samba.

/etc/samba/smb.conf includes

   realm = XXX.YYY
   security = ads
   obey pam restrictions = yes
   idmap config * : backend = tdb
   idmap config * : range = 10000000-29999999
   idmap config XXX: backend = ad
   idmap config XXX: default = yes
   idmap config XXX: range = 3000-999999
   idmap config XXX: schema_mode = rfc2307
   template shell = /bin/bash
   winbind use default domain = yes
   winbind nss info = rfc2307
   winbind enum users = no
   winbind enum groups = no
   winbind offline logon = false
   winbind nested groups = yes

Using winbind we have partial success for AD authentication. We still have winbind crashing which results in failed authentications until it is restarted. We also have not found a solution to date for an error that shows up in the logs every minute: credentials chain check failed

We followed those directions and the advice and still are having issues.

Sorry to hear that, if possible, contact Red Hat support directly at https://access.redhat.com/support/contact/technicalSupport/

Added, if you haven't already, chkconfig winbind on, & turn on winbind service.

I had already turned on winbind and all. Also, the server did not reboot, it just seems to stop authenticating.

William, perhaps check any available logs... but the logs may give you errant red-herrings of symptoms and not true causes. Verify the user account (that you used to join samba) and the machine account (the server name) is in the proper OU in AD. At one time, we deleted the machine account, and we had to manually recreate the account, even though it appeared that we had success in joining AD. In our environment, we had to add specific groups to the machine account (the "machine account" being the samba server computer in active directory). Some/all/none of the above may or may not apply to you.

If needed, contact Red Hat support, or post back here and hopefully someone should be able to reply. Apologies, I'm a bit busy with various tasks. Thanks

We've been pouring over the logs and have gone so far as to deleting machine accounts and putting them back in. And yes, checking the ou and all.

Another system was a bit a-typical for us; when joining, we had to specify the server with net ads join -U NAMEOFADMIN -S DOMAIN_CONTROLLER_WITH_FQDN instead of omitting the "-S" portion, we had to add the "-S" portion, and it worked.

A bit of voodoo from 2011 on the samba mailing lists by one Volker Lendecke might help redhat 6 folks with samba "security = domain": Try adding "username map script = /bin/echo" to smb.conf, and see if your local supplemental groups start working again on your updated samba-3.6.23-30.el6_7 servers. You will still need to have winbind running, of course.

However, this breaks samba configurations with "security = ads", so we're still looking for local supplemental group access on those.

I just joined yet another samba server with the previous docs I mentioned (net ads join), but I had to play games with AD machine object, and dns entries were wrong for said samba server (now fixed) for the last system on a lesser-used network. I has to use the "-S" switch and specify the DC.

The ones we joined using "net ads join" reported dns update issues, but they =still= joined.

Can we try the following action plan , if you are using any version of samba3 ?

1 . service winbind stop;service smb stop 2 . Add the following to the [global] section in /etc/samba/smb.conf client ipc signing = auto

3 . Move the cache away from its default location : mkdir /tmp/samba_cache mv /var/lib/samba/* /tmp/samba_cache

4 . Start up services systemctl start smb winbind

5 . Re-Join to the AD domain net ads join -U administrator -I ip_of_AD_Server

6 . On top of the above steps, make sure we have the configurations parameters explained in the following kcs as well : https://access.redhat.com/solutions/2260591

7 . Afterthe above steps , restart winbind services service winbind restart

After this see if you are able to retrieve user information from AD. id ad_user

Good luck .

William, remember the good tips that Frank from Red Hat above is offering shows "systemctl" which is for RHEL7, and you're using RHEL 6.7 according to the rpms you've listed, so of course use appropriate service commands and make sure of course winbind is on persistently for reboots with chkconfig winbind on; chkconfig winbind --list, and put semi-colons between his mkdir & mv commands, wish you well.

Frank, We also followed the link (solution ID 226051) that we both posted. However, I did not see mention of "client ipc signing = auto" in the [global] section, and did not use it in my /etc/samba/smb.conf file and ti worked fine when I went through this early this week.

I did see in the upstream documentation for samba 4 this is, listed as a feature ("client ipc signing = auto"). Was this feature back-ported for RHEL 6.7 (what William and I are using) for the rpms he listed?

Should I use "client ipc signing = auto" in my RHEL 6.7 /etc/samba/smb.conf file? If so, I am curious the impact if it's use. Thanks

Greetings,

Correct. "client ipc signing" feature is available in RHEL 6.7

We have seen few customer running in to this issue in rhel 6.7 , in cases where we don't use this configuration. https://access.redhat.com/solutions/2263921

Should you use "client ipc signing = auto" in my RHEL 6.7 /etc/samba/smb.conf file? I would recommend you to use that confirmation parameter.

What this does ?

client ipc signing (G)

This controls whether the client is allowed or required to use
SMB signing for IPC$ connections as DCE/RPC transport. Possible
values are auto, mandatory and disabled.

When set to mandatory or default, SMB signing is required.

When set to auto, SMB signing is offered, but not enforced and
if set to disabled, SMB signing is not offered either.

Connections from winbindd to Active Directory Domain Controllers
always enforce signing.

Default: client ipc signing = default

Hope this helps.

Thank you Frank

We're having this issue as well, even though we started with winbind enabled and the settings in this article already enabled. Thank god someone didn't roll this out into prod.

Edit: Rollback was the only solution that functioned properly for us that functioned properly in the length of time we had to repair the issue. Hope new errata is released soon.

Here is a solution to the credentials check failed seen in the log. You need to update to samba version: "samba-3.6.23-35.el6_8"

https://access.redhat.com/solutions/1280493

We ran into this authentication issue after upgrading Samba from 4.1.12 to 4.4.4.

Our problem is that authentication works fine for the default domain, but doesn't work for a trusted domain.

We downgraded from 4.4.4 to 4.2.10 with no luck, so it really seems this regression appeared in 4.2.10 and this Badlock fix.

Applying the fix documented here doesn't help: https://access.redhat.com/solutions/2260591

A case has been opened and I'm waiting on Redhat now.

Hi Sébastien - did you get a fix from Redhat for this?

The only solution that has worked for me so far is to rejoin the domain (we're using sssd). This works for about 1 month, and then fails with the following errors

connect_to_domain_password_server: unable to open the domain client session to machine SERVER.COM Error was : NT_STATUS_ACCESS_DENIED.

For us we had to take it an extra step. while we had this setting security = ads We had to add this one ' ldap ssl = start tls ' and ensure that it was starting TLS since somewhere somehow ssl was no longer being used though our AD guy said that wasnt the case (the joy of large enterprises).

ldap ssl = start tls

No, I'm still waiting for Redhat on this.

Check these:

https://bugzilla.redhat.com/show_bug.cgi?id=1395967

https://bugzilla.samba.org/show_bug.cgi?id=8630

Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.