Dear all,
We recently upgraded an old samba 3.0.10 to 3.4.6 due to broken quota when
moving from Veritas to NFS mounts from a Cellera EMC.
Anyway,
Our samba passwd backend is a smbpasswd file.
This file is generated from a database.
Recently we see that some PC clients manage to change the LANMAN field in
the smbpasswd file.
e.g.
userabc:108:364CBAE2BB8E8B05C2265B23734E0DAC:105F5CD7D6E85B97EDC2677D47C6B173:[U
]:LCT-4977B700:
get changed to
userabc:108:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:105F5CD7D6E85B97EDC2677D47C6B173:[U
]:LCT-4977B700:
Users do NOT have access to the smbpasswd binary, so it's via a client
request
(verified this via a Win 7 client trying the change his Samba passwd)
Can anyone shed some light on why this happens in the 3.4.6 version ?
We actually do not want this to happen as the smbpasswd file is getting
out of sync with our database.
As far as I understand all the smb.conf options with their default setting
should prevent changes in the smbpasswd file.
Here's our smb.conf:
# Global parameters
[global]
server string = ACME Samba
log level = 01
log file = /tmp/SAMBA/logs/log.%m
max log size = 200
name resolve order = lmhosts host wins bcast
socket options = TCP_NODELAY SO_KEEPALIVE
load printers = No
dns proxy = No
ldap ssl = no
create mask = 0600
directory mask = 0700
hosts allow = <obfuscated>
delete readonly = Yes
passdb backend = smbpasswd
[homes]
comment = Home Directories
read only = No
map system = Yes
map hidden = No
browseable = No
dos filemode = Yes
[printers]
comment = All Printers
path = /usr/spool/samba
printable = Yes
browseable = No
Thanks in advance
Regards,
--------------------------
Brussels University
Pleinlaan 2
Computer Center VUB/ULB (VUBnet)
Ing. Robert Jansen
B-1050 Brussels
Belgium (Europe)
email: rjansen at vub.ac.be
Tel: +32-2-650.36.94
Secr: +32-2-650.37.38
Fax: +32-2-650.37.40
--------------------------
Dear all,
We recently upgraded an old samba 3.0.10 to 3.4.6 due to broken quota when
moving from Veritas to NFS mounts from a Cellera EMC.
Anyway,
Our samba passwd backend is a smbpasswd file.
This file is generated from a database via some scripts.
Recently we see that some PC clients manage to change the LANMAN field in
the smbpasswd file.
e.g.
userabc:108:364CBAE2BB8E8B05C2265B23734E0DAC:105F5CD7D6E85B97EDC2677D47C6B173:[U
]:LCT-4977B700:
get changed to
userabc:108:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:105F5CD7D6E85B97EDC2677D47C6B173:[U
]:LCT-4977B700:
Remarkably the Windows NT password hash remains the same.
It seems that the LANMAN password hash get's "zeroed" somehow.
Users do NOT have access to the smbpasswd binary, so it's via a client
request
(verified this via a Win 7 client trying to change a Samba share passwd)
userabc@<samba_server> used.
Can anyone shed some light on why this happens in the 3.4.6 version ?
We actually do not want this to happen as the smbpasswd file is getting
out of sync with our database.
As far as I understand all the smb.conf options with their default setting
should prevent changes in the smbpasswd file.
Here's our smb.conf:
# Global parameters
[global]
server string = ACME Samba
log level = 01
log file = /tmp/SAMBA/logs/log.%m
max log size = 200
name resolve order = lmhosts host wins bcast
socket options = TCP_NODELAY SO_KEEPALIVE
load printers = No
dns proxy = No
ldap ssl = no
create mask = 0600
directory mask = 0700
hosts allow = <obfuscated>
delete readonly = Yes
passdb backend = smbpasswd
[homes]
comment = Home Directories
read only = No
map system = Yes
map hidden = No
browseable = No
dos filemode = Yes
[printers]
comment = All Printers
path = /usr/spool/samba
printable = Yes
browseable = No
Thanks in advance
Regards,
--------------------------
Brussels University
Pleinlaan 2
Computer Center VUB/ULB (VUBnet)
Ing. Robert Jansen
B-1050 Brussels
Belgium (Europe)
email: rjansen at vub.ac.be
Tel: +32-2-650.36.94
Secr: +32-2-650.37.38
Fax: +32-2-650.37.40
--------------------------
Added note: The lanmanager smbpasswd filed change seems to happen also with some client machines do NOT explicitaly change their password. It rather seems that a client seems to enforce a zero LANMAN passwd if a client has a higher than LANMAN protocol available. "I have a higher protocol than LANMAN, so forget the LANMAN method and scratch the unsafer password hash". A wild guess,... But the question remains, how to prevent this from happening ? Running on a Solaris 9 Ideas welcome. TIA