Bug 9220 - Connection fails with Server/Client Signing = Mandatory
Connection fails with Server/Client Signing = Mandatory
Status: RESOLVED INVALID
Product: Samba 3.6
Classification: Unclassified
Component: Config Files
3.6.5
All All
: P5 major
: ---
Assigned To: Stefan Metzmacher
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-27 12:45 UTC by bc1ibm
Modified: 2015-01-29 07:50 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description bc1ibm 2012-09-27 12:45:47 UTC
Hello,
When I add "server signing = mandatory" to my smb.conf file (AIX V6.1,
6100-04-11-1140 running Samba v3.6.5) that has "encrypt passwords = no", my
windows client no longer can connect. It fails with system error 64.

The windows system is running XP vers 2002 with service pack 3. The
security settings are set to:
		 Microsoft network client: Digitally sign communications (always)
		 		 Disabled
		 Microsoft network client: Digitally sign communications (if server
agrees)		 		 		 Enabled
		 Microsoft network client: Send unencrypted password to third-party
SMB servers		 		 Enabled
		 Microsoft network server: Amount of idle time required before
suspending session		 15 minutes
		 Microsoft network server: Digitally sign communications (always)
		 		 Disabled
		 Microsoft network server: Digitally sign communications (if client
agrees)		 		 		 Disabled
		 Microsoft network server: Disconnect clients when logon hours expire
		 		 Enabled

Like wise, when I add "server signing = mandatory" to my smb.conf file that
has "encrypt passwords = yes" (and "passdb backend = smbpasswd" with valid
id/password in the smbpasswd file), my AIX client no longer can connect.

I have added "client signing = mandatory" to smb.conf also and get the same
results (unencrypted: windows clients cannot connect. encrypted: aix
clients cannot connect).

Are there any known problems in v3.6.5 related to these connection
problems? Are there any fixes in newer releases?
Comment 1 bc1ibm 2012-09-27 14:28:09 UTC
It is worth mentioning our security exec's are threatening to shut down our environment if we cannot get this working. Any help on why the connections fail and if/when a fix is expected/available would be greatly helpful!
Comment 2 Stefan Metzmacher 2012-09-27 20:36:55 UTC
Does "encrypt passwords = no" means that the cleartext password
is send of the over the wire? If someone can get the password,
what is the point of doing signing?
Comment 3 Karolin Seeger 2012-09-28 06:57:43 UTC
Re-assigning to Metze.
Comment 4 Stefan Metzmacher 2013-09-12 06:58:04 UTC
(In reply to comment #2)
> Does "encrypt passwords = no" means that the cleartext password
> is send of the over the wire? If someone can get the password,
> what is the point of doing signing?

If there's still a problem with

Send unencrypted password to third-party => disabled
and removing "encrypt passwords = no"

please reopen the bug
Comment 5 Daniel Dickinson 2015-01-25 21:32:25 UTC
As a non-admin I cannot reopen this bug, however it exists even with encrypted passwords.

Basically Windows 8 intermittently fails to access the samba server when mandatory signing is enabled because manadatory signing prevents anonymous (guest) access to the server and windows 8 uses anonymous access to get share lists and even to recognize that the server is available.

The bug is frustrating to diagnose because windows sometimes uses stored credentials and sometimes guest access so you get a situation where access (but never visibility in icon in 'Network' in Explorer) sometimes works and sometimes does not.

If windows consistently used stored credentials there would be no issue because mandatory signing preventing guest access would not be an issue.

From mailing list I saw that the decision was made that mandatory signing would mean that guest access would result in an error instead of allowing guest access without signing, which is unforunately incompatible with windows decisions/usage.
Comment 6 Stefan Metzmacher 2015-01-29 07:50:33 UTC
(In reply to Daniel Dickinson from comment #5)

I just tested that we behave like a Windows 2012R2 DC.

Anonymous access to IPC$ is allowed, but a TCON to a file share
e.g. "netlogon" returns NT_STATUS_ACCESS_DENIED.