The Samba-Bugzilla – Bug 9391
Passwords with special characters
Last modified: 2014-07-23 18:32:29 UTC
Samba version - Version 3.5.11-cdc-4.5.3-573
CentrifyDC version - CentrifyDC 5.0.2-396
I am using Centrify Express to connect to my work domain, and I am using
their version of Samba, hence the version listed above. I already posted
this query to them, and they directed me to here, stating that this may be
a Samba issue: Centrify forum
When I try to connect to my share in Windows (XP/7/8) via Windows Explorer,
I get the user/password prompt. My password has a special character in it
(!), and it is not accepted; the prompt never goes away. For users that do
not have special characters in their passwords, the connection is instant.
I noticed that almost always, if I reboot my Windows machine and try to
connect to the share again, it is successful, and I never get the
user/password prompt. So it's as if the server finally accepts the password.
Below is my smb.conf, with company info removed:
# This file was generated by Centrify ADBindProxy Utility
security = ADS
realm = ***.**.**.***
workgroup = ****
netbios name = shockwave
auth methods = guest, sam, winbind, ntdomain
machine password timeout = 0
passdb backend = tdbsam:/etc/samba/private/passdb.tdb
log level = 2
# Samba versions 3.4.0 and newer have replaced "use kerberos keytab"
# with "kerberos method". The directive "kerberos method = system
# enables Samba to honor service tickets that are still valid but were
# created before the Samba server's password was changed.
kerberos method = system keytab
# Setting "client use spnego principal" to true instructs SMB client to
# trust the service principal name returned by the SMB server.
# client cannot be authenticated via Kerberos by the server in a
# domain even though the two domains are mutually trusted.
client use spnego principal = true
# Setting send spnego principal to yes .
# Otherwise, it will not send this principal between Samba and Windows
send spnego principal = Yes
# If your Samba server only serves to Windows systems, try server
signing = mandato$
server signing = auto
template shell = /bin/bash
winbind use default domain = Yes
winbind enum users = No
winbind enum groups = No
winbind nested groups = Yes
ignore syssetgroups error = No
idmap uid = 1000 - 200000000
idmap gid = 1000 - 200000000
enable core files = false
# Disable Logging to syslog, and only write log to Samba standard log
syslog = 0
path = /samba-test
public = yes
# if set public = No, we should set parameter valid users .
# and when the user or group is in AD , the setting syntaxes is:
# valid users = ****\username +****\group
writable = yes
comment = Home directories
read only = No
browseable = No
root preexec = /home/driller/Scripts/mkhomedir.sh %U
comment = drilled files
path = /mnt/shares/files
# valid users = ****\hkashouli
create mask = 777
force create mode = 777
directory mask = 777
force directory mode = 777
writable = yes
I'm guessing it's a charset encoding issue somewhere? I will try to add the
following options in smb.conf, but if anyone knows why passwords with
special characters are not accepted, it would be a great help:
display charset = UTF8
> unix charset = UTF8
If you need more logs, please let me know.
This is a modified version of Samba? If so, please make Centrify do further diagnosis of the ntlm authentication and make them post their results here. Thanks.
(In reply to comment #1)
> This is a modified version of Samba? If so, please make Centrify do further
> diagnosis of the ntlm authentication and make them post their results here.
From Centrify: "Samba does its own authentication. We have no hand in this process.
Centrify distro of samba only provide assisntance in uid/gid and group membership resolution."
I am going to try their proposals, and see if it makes sense/fixes the problem.
Question: How do I tell Samba to forget that my account logged in? So I can retry the password.
Please upload the Samba sources you are using somewhere so that we can make sure Centrify does really not modify it. To disconnect the client, just kill the smbd you find with smbstatus or reboot your client.
no feedback. most probably not a samba issue also. closing this bug.