Description of problem:
When updating to the latest samba updates:
latest samba updates:
=== yum reports available updates:
libsmbclient.i386 3.0.33-3.41.el5_11 updates
samba3x.i386 3.6.23-12.el5_11 updates
samba3x-client.i386 3.6.23-12.el5_11 updates
samba3x-common.i386 3.6.23-12.el5_11 updates
samba3x-winbind.i386 3.6.23-12.el5_11 updates
ALL prior required updates have been performed prior to these.
This also comes after a Windows update. However, 2 PCs, one Win7 the other Windows 10, joined the domain and were able to login prior to the update. However, after the update neither Windows 7 or Windows 10 clients can log into the SME 8.2 Server as there is a NT_STATUS_TRUSTED_RELATIONSHIP_FAILURE during attempted login.
I've removed the client by force from the domain and added them back onto the domain and still I get this same error.
Rebooted the server and client PCs and still the same error.
I even performed a yum downgrade to remove these updates and I still see the same trust relationship failure error.
Version-Release number of selected component (if applicable):
replicated on EVERY PC accessing the domain
Steps to Reproduce:
3.error given = TRUST RELATIONSHIP FAILURE
TRUST RELATIONSHIP FAILURE
Log into domain
in the Messages file I see the following format for multiple users:
Apr 13 09:49:12 icarus smbd: [2016/04/13 09:49:12.254867, 0] rpc_server/netlogon/srv_netlog_nt.c:976(_netr_ServerAuthenticate3)
Apr 13 09:49:12 icarus smbd: _netr_ServerAuthenticate3: netlogon_creds_server_check failed. Rejecting auth request from client PC3 machine account PC3$
and still continues for each user logged into the domain
This bug should be against RHEL5. When running as an NT4 domain controller, last samba3x updates (RHSA-2016-0613) break trust relationship. Affects at least Windows 7 and Windows Server 2012R2 clients.
The very same issue also affects RHEL6 (after applying updates from RHSA-2016-0611)
In both cases, downgrading the various samba3x/samba packages makes everything working again
Sorry Daniel, wrong release. I downgraded but nothing has changed. Can you please give me the steps to downgrade?
Please provide log files with a higher log level. If I understand it correctly you have a Samba server running as a primary domain controller and Windows clients are joined to it.
Please read https://www.samba.org/~asn/reporting_samba_bugs.txt it will explain how to provide the information we need and find it quickly. See the info about the 'date' command.
I found a method to downgrade and roll back to the prior version and which fixed this issue.
The command I used:
yum downgrade samba\* libsmbclient
Workstations and other Microsoft servers can now properly interact with the domain.
We are also seeing this (on RHEL 6) after the upgrade. Downgrading helps. Versions of packages:
I did a run with the latest samba and the previous one (failing and working) with the logging turned up. I'll attach the files next, but I can point out this suspicious difference in the logs:
> [2016/04/14 15:56:46.986588, 10] ../librpc/rpc/dcerpc_util.c:606(dcerpc_sec_verification_trailer_check)
> SEC_VT check Bitmask1 client_header_signing failed
Created attachment 1147264 [details]
log file (working, 3.6.23-25.el6_7)
Created attachment 1147265 [details]
log file (failing, 3.6.23-30.el6_7)
The test case here is a RHEL 6 acting as a NT4 DC for a Windows 2008R2 machine. From a Fedora 23 machine I used smbclient to connect to the Windows machine:
> $ smbclient //tezava/C$
> Enter ossman's password:
> session setup failed: NT_STATUS_TRUSTED_RELATIONSHIP_FAILURE
(same problem occurs for any user authentication, but this was a simple command line test case)
Ok, so here are some more complete information for how to reproduce the problem.
Have a samba3x server running as a PDC, with windows stations joined on the domain
[root@el5 ~]# rpm -qa samba\* \*smb\* \*talloc\* \*tdb\* \*ldb\* \*tevent\* \*wbclient\*
See the attached smb.conf file for the relevant sections of my config (I just removed my shares definition as it most likely is not relevant)
One client is member of the NT4 domain. It's a Windows 7 pro box (name: win7, IP: 192.168.7.12)
I can log into this box with no problem, see the win7_ok.log file, which traces a successful login from this box using a domain account.
I now update the different packages:
yum update samba\* libsmb\*
libsmbclient i386 3.0.33-3.41.el5_11
samba3x i386 3.6.23-12.el5_11
samba3x-client i386 3.6.23-12.el5_11
samba3x-common i386 3.6.23-12.el5_11
samba3x-winbind i386 3.6.23-12.el5_11
[root@el5 ~]# rpm -qa samba\* \*smb\* \*talloc\* \*tdb\* \*ldb\* \*tevent\* \*wbclient\*
After restarting the smbd daemon, I can no longer open a session using a domain account. On the client computer, I get a message stating that the trust relationship between this station and the domain failed (the exacte message in french is "La relation d'approbation entre cette station de travail et le domaine a échoué.")
See the file win7_ko.log for the server-side logs when I try to login.
Created attachment 1147271 [details]
smb.conf of the PDC
Created attachment 1147272 [details]
Log file during a successful login (3.6.23-9.el5_11)
Created attachment 1147273 [details]
Log file during a failed login (3.6.23-12.el5_11)
here is my samba configuration file as well.
add machine script = /sbin/e-smith/signal-event machine-account-create '%u'
bind interfaces only = yes
case sensitive = no
deadtime = 10080
display charset = ISO8859-1
dns proxy = no
domain logons = yes
domain master = yes
dos charset = 850
encrypt passwords = yes
guest account = public
guest ok = no
hosts allow = 127.0.0.1 192.168.1.0/255.255.255.0 192.168.2.0/255.255.255.0 192.168.3.0/255.255.255.0 192.168.4.0/255.255.255.0 192.168.9.0/255.255.255.0
interfaces = 127.0.0.1 192.168.1.16/255.255.255.0
log file = /var/log/samba/log.%m
logon drive = Z:
logon path =
logon script = netlogon.bat
map to guest = never
max log size = 50
name resolve order = wins lmhosts bcast
netbios name = icarus
oplocks = true
kernel oplocks = true
level2 oplocks = true
os level = 65
passdb backend = smbpasswd:/etc/samba/smbpasswd
pid directory = /var/run
preferred master = yes
preserve case = yes
private dir = /etc/samba
security = user
server string = SME Server
short preserve case = yes
smb passwd file = /etc/samba/smbpasswd
smb ports = 139
socket options = TCP_NODELAY
strict locking = no
unix charset = UTF8
unix password sync = Yes
pam password change = Yes
passwd program = /usr/bin/passwd %u
(In reply to Bryan from comment #14)
> here is my samba configuration file as well.
This was prior to the downgrade from (3.6.23-9.el5_11)
Ok, thanks for the data. I can reproduce it here.
I've confirmed that this also affects RHEL7 clients (Samba 4.2) where I get either a NT_STATUS_CANT_ACCESS_DOMAIN_INFO reply or an NT_STATUS_ACCESS_DENIED when trying to connect to a RHEL6 PDC.
On the samba 3.6 PDC logs I see a:
"Rejecting auth request from client"
Which seems to indicate that there is a problem with the machine user account entry. Deleting the machine account and trying to re-create it also fails (the machine account is created but "net rpc join" fails). The PDC will also frequently set the flags of the machine account to Disabled, which I then have to manually unset.
I was also unable to connect from other RHEL6 clients until I added:
server signing = auto
to the smb.conf, which fixed that but did not fix connections from samba 4.2
I also tried all of the following to no avail:
raw NTLMv2 auth = yes
allow dcerpc auth level connect = yes
client ipc signing = auto
client signing = auto
server min protocol = LANMAN1
Rolling the PDC back from 3.6.23-30 to 3.6.23-25 completely fixed the problem.
I should note that samba 4.2 was able to accurately retrieve domain info:
net rpc info
but wasn't able to join the domain.
We identified the issue and have a working fix.
Anyone got working fix?
Me and my user all cant login to our domain.
If you are using Win 7 or Win 10, just unplug the network cable (or disable WiFi) then login. It's similar to a local login (versus a network login). Once you've logged in you can re-plug in the network cable and use your resources as normal. Also, turn off the sleep mode with password required so you're not forced to log back in each time your system goes to sleep.
If you require a hotfix until we are able to roll out an update please talk to your Red Hat support contact!
(In reply to Andreas Schneider from comment #21)
> If you require a hotfix until we are able to roll out an update please talk
> to your Red Hat support contact!
Are there any plans when this is going to be rolled out already? (A rough estimate would be enough, e.g. in two weeks, in a month...)
I have a fix for the issue. Sorting out how to do updates for all released versions.
I was affected too, my command for downgrade was:
yum downgrade samba3x samba3x-common samba3x-client samba3x-swat samba3x-winbind
I'm on RHEL 5.11 with samba NT4 style, mixed WinXP and Win7 clients.
After downgrade, the clients can login instantly, no reboot necessary.
(In reply to Martin from comment #22)
> (In reply to Andreas Schneider from comment #21)
> > If you require a hotfix until we are able to roll out an update please talk
> > to your Red Hat support contact!
> Are there any plans when this is going to be rolled out already? (A rough
> estimate would be enough, e.g. in two weeks, in a month...)
I also would like to know a rough estimate about the release date of this fix...
Is this the same as the RHEL 6 Bug#1327697 ?
(In reply to elhefe from comment #27)
> I also would like to know a rough estimate about the release date of this
Maybe some time this year... :-)
(In reply to Charlie Brady from comment #29)
> (In reply to elhefe from comment #27)
> > I also would like to know a rough estimate about the release date of this
> > fix...
> Maybe some time this year... :-)
Interestingly this seems to haven been fixed for RHEL 6 only the RHEL 5 updates seems to take a while.
(In reply to Martin from comment #30)
> Interestingly this seems to haven been fixed for RHEL 6 only the RHEL 5
> updates seems to take a while.
I'm still having the same issue with 3.6.23-35.el6_8 and there's nothing in the change log that would indicate this is fixed on RHEL6. How are you verifying a fix has been implemented?
(In reply to Michael Starling from comment #31)
> (In reply to Martin from comment #30)
> > Interestingly this seems to haven been fixed for RHEL 6 only the RHEL 5
> > updates seems to take a while.
> I'm still having the same issue with 3.6.23-35.el6_8 and there's nothing in
> the change log that would indicate this is fixed on RHEL6. How are you
> verifying a fix has been implemented?
Strange, the version you mentioned is working for me. Also see the here:
@Michael Starling: Same here 3.6.23-35.el6 does not solve the problem. I think we have to wait or upgrade to Rhel7 to get rid of the problem.
If you have regressions in RHEL6 please report them and do not capture other bugs. Thanks!
Andreas, I originally reported this for RHEL 6 and opened a case with Red Hat in the first week of April. They then opened a separate bugzilla for RHEL 6 but you marked the bug as a duplicate, closed it and attached attached my case to this bug.
I'm still able to join Windows systems to my NT domain but they are unable to authenticate. This isn't a new bug but it's the same issue that's been manifesting itself all along.
For anyone else on this mailing list still having issues with RHEl6.
After some more reading and troubleshooting I was able to fix domain logons by disabling TCP Chimney Offload in Windows
I've added the wrong bug id. I fixed it.
when is it planned to be released samba3x-3.6.23-13.el5_11, roughly?
(In reply to Maurizio Marini from comment #40)
> when is it planned to be released samba3x-3.6.23-13.el5_11, roughly?
IMO this should have "security" priority classification, since the regression is preventing the implementation of a critical security update for many users:
A response > 2 months is pretty disappointing.
thanks to Andreas patch
I was able to fix samba3x-3.6.23-12.el5_11.src.rpm and users on win7 clients are able to login again, nevertheless I wait for officially released package
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.