Hello,
I've got the smbk5pwd and ppolicy modules working, but I'm not entirely sure I've got them working together.
I say this because clients joined to the domain (run by a Samba PDC with an OpenLDAP backend) can change their passwords and it updates the NT/LM passwords in LDAP, thus verifying the functionality of smk5pwd, but it does not appear to enforce ppolicy restrictions. On the flip side of the coin, the user can change their LDAP password by invoking ldappasswd from a shell on the server, and are bound by the restrictions set forth by ppolicy (password length, strength, historical passwords, etc.).
But, I cannot seem to get ppolicy and smbk5pwd to operate in conjunction with one another - when changed from a Windows client, only smbk5pwd seems to work. I was initially thinking this was maybe because Windows was sending the passwords already hashed to OpenLDAP, but if I send a password such as 'a', I get this message:
"Your password must be at least 5 characters, cannot repeat any of your previous 0 passwords and must be at least 0 days old. Please type a different password. Type a password that meets these requirements in both text boxes."
However, I have no idea where it's getting those requirements or that text from, though I'm wondering it's a Windows policy. In any case, it's certainly not what ppolicy requires, as is the case from a shell on the server.
I also see this in the sambaPasswordHistory attribute, which (possibly?) indicates that ppolicy isn't working properly in conjunction with smbk5pwd, and possibly explains why isn't not triggering on the historical passwords:
sambaPasswordHistory: 0000000000000000000000000000000000000000000000000000000000000000
That doesn't explain, though, why the strength and length checks aren't working. I've ramped up the debugging on the back end, but all I see is Samba happily updating with weak passwords and no mention of password lengths (even when that dialog pops up on the Windows client side). I'd appreciate any insight anybody might have.
Thanks, Ryan
Here is what I know on this, wiser minds may feel free to correct everything I have to say.....
replies are inline.
On Tue, 2008-04-01 at 15:46 -0400, Ryan Steele wrote:
Hello,
I've got the smbk5pwd and ppolicy modules working, but I'm not entirely sure I've got them working together.
I say this because clients joined to the domain (run by a Samba PDC with an OpenLDAP backend) can change their passwords and it updates the NT/LM passwords in LDAP, thus verifying the functionality of smk5pwd, but it does not appear to enforce ppolicy restrictions. On the flip side of the coin, the user can change their LDAP password by invoking ldappasswd from a shell on the server, and are bound by the restrictions set forth by ppolicy (password length, strength, historical passwords, etc.).
The ppolicy overlay is adding extra functionality to the password extended operation. ldappasswd uses this. The restriction is not present if you update the password hash via the ldapmodify command. The key is in the extended operation. As an added tidbit only userPassword is monitored not any other attribute.
Samba does password changes via an ldapmodify rather than an ldappasswd (unless you have ldap passwd sync = Only which I have never personally used so I have no tests to back this up). This would explain why LDAP has the policy enforcing and Samba does not.
But, I cannot seem to get ppolicy and smbk5pwd to operate in conjunction with one another - when changed from a Windows client, only smbk5pwd seems to work. I was initially thinking this was maybe because Windows was sending the passwords already hashed to OpenLDAP, but if I send a password such as 'a', I get this message:
"Your password must be at least 5 characters, cannot repeat any of your previous 0 passwords and must be at least 0 days old. Please type a different password. Type a password that meets these requirements in both text boxes."
I would recommend reading the information at http://www.linuxtopia.org/online_books/network_administration_guides/samba_r... for an answer to this. It should, by inference explain the questions you have below as well. Questions on this should be aimed at the samba list.
However, I have no idea where it's getting those requirements or that text from, though I'm wondering it's a Windows policy. In any case, it's certainly not what ppolicy requires, as is the case from a shell on the server.
I also see this in the sambaPasswordHistory attribute, which (possibly?) indicates that ppolicy isn't working properly in conjunction with smbk5pwd, and possibly explains why isn't not triggering on the historical passwords:
sambaPasswordHistory: 0000000000000000000000000000000000000000000000000000000000000000
That doesn't explain, though, why the strength and length checks aren't working. I've ramped up the debugging on the back end, but all I see is Samba happily updating with weak passwords and no mention of password lengths (even when that dialog pops up on the Windows client side). I'd appreciate any insight anybody might have.
Thanks, Ryan
Hi Pat,
I didn't actually receive the copy of my message from the list.... hopefully there hasn't been any other correspondence on this that I've missed. My replies are inline as well.
Pat Riehecky wrote:
Here is what I know on this, wiser minds may feel free to correct everything I have to say.....
replies are inline.
On Tue, 2008-04-01 at 15:46 -0400, Ryan Steele wrote:
Hello,
I've got the smbk5pwd and ppolicy modules working, but I'm not entirely sure I've got them working together.
I say this because clients joined to the domain (run by a Samba PDC with an OpenLDAP backend) can change their passwords and it updates the NT/LM passwords in LDAP, thus verifying the functionality of smk5pwd, but it does not appear to enforce ppolicy restrictions. On the flip side of the coin, the user can change their LDAP password by invoking ldappasswd from a shell on the server, and are bound by the restrictions set forth by ppolicy (password length, strength, historical passwords, etc.).
The ppolicy overlay is adding extra functionality to the password extended operation. ldappasswd uses this. The restriction is not present if you update the password hash via the ldapmodify command. The key is in the extended operation. As an added tidbit only userPassword is monitored not any other attribute.
Samba does password changes via an ldapmodify rather than an ldappasswd (unless you have ldap passwd sync = Only which I have never personally used so I have no tests to back this up). This would explain why LDAP has the policy enforcing and Samba does not.
My 'passwd program' in my smb.conf is "passwd program = /usr/bin/ldappasswd -x -W -S -D uid=%u,ou=Users,dc=example,dc=com" - so it should be using ldappasswd, which is bound by ppolicy, correct?
I've tried 'ldap passwd sync = only', after my failures with 'ldap passwd sync = yes' lead me back to the documentation, however this yielded no success.
But, I cannot seem to get ppolicy and smbk5pwd to operate in conjunction with one another - when changed from a Windows client, only smbk5pwd seems to work. I was initially thinking this was maybe because Windows was sending the passwords already hashed to OpenLDAP, but if I send a password such as 'a', I get this message:
"Your password must be at least 5 characters, cannot repeat any of your previous 0 passwords and must be at least 0 days old. Please type a different password. Type a password that meets these requirements in both text boxes."
I would recommend reading the information at http://www.linuxtopia.org/online_books/network_administration_guides/samba_r... for an answer to this. It should, by inference explain the questions you have below as well. Questions on this should be aimed at the samba list.
Dually noted.
However, I have no idea where it's getting those requirements or that text from, though I'm wondering it's a Windows policy. In any case, it's certainly not what ppolicy requires, as is the case from a shell on the server.
I also see this in the sambaPasswordHistory attribute, which (possibly?) indicates that ppolicy isn't working properly in conjunction with smbk5pwd, and possibly explains why isn't not triggering on the historical passwords:
sambaPasswordHistory: 0000000000000000000000000000000000000000000000000000000000000000
That doesn't explain, though, why the strength and length checks aren't working. I've ramped up the debugging on the back end, but all I see is Samba happily updating with weak passwords and no mention of password lengths (even when that dialog pops up on the Windows client side). I'd appreciate any insight anybody might have.
Thanks, Ryan
I say this because clients joined to the domain (run by a Samba PDC with an OpenLDAP backend) can change their passwords and it updates the NT/LM passwords in LDAP, thus verifying the functionality of smk5pwd, but it does not appear to enforce ppolicy restrictions. On the flip side of the coin, the user can change their LDAP password by invoking ldappasswd from a shell on the server, and are bound by the restrictions set forth by ppolicy (password length, strength, historical passwords, etc.).
The ppolicy overlay is adding extra functionality to the password extended operation. ldappasswd uses this. The restriction is not present if you update the password hash via the ldapmodify command. The key is in the extended operation. As an added tidbit only userPassword is monitored not any other attribute. Samba does password changes via an ldapmodify rather than an ldappasswd (unless you have ldap passwd sync = Only which I have never personally used so I have no tests to back this up). This would explain why LDAP has the policy enforcing and Samba does not.
My 'passwd program' in my smb.conf is "passwd program = /usr/bin/ldappasswd -x -W -S -D uid=%u,ou=Users,dc=example,dc=com" - so it should be using ldappasswd, which is bound by ppolicy, correct?
You shouldn't need a "passwd program" when using an LDAP SAM.
I've tried 'ldap passwd sync = only', after my failures with 'ldap passwd sync = yes' lead me back to the documentation, however this yielded no success.
I'm pretty sure if you have "ldap passwd sync = yes" that your "passwd program" directive is irrelevant since this means Samba is doing an ldapmodify to set the NT, LM, and userPassword attributes - your passwd program isn't doing anything. If "only" doesn't work then I strongly suspect that your smk5pwd module is *not* working, otherwise "only" would be the only mode to make any sense. By setting "ldap passwd sync = yes" your, at best, doing the work of smbk5pwd twice.
Adam Tauno Williams wrote:
I say this because clients joined to the domain (run by a Samba PDC with an OpenLDAP backend) can change their passwords and it updates the NT/LM passwords in LDAP, thus verifying the functionality of smk5pwd, but it does not appear to enforce ppolicy restrictions. On the flip side of the coin, the user can change their LDAP password by invoking ldappasswd from a shell on the server, and are bound by the restrictions set forth by ppolicy (password length, strength, historical passwords, etc.).
The ppolicy overlay is adding extra functionality to the password extended operation. ldappasswd uses this. The restriction is not present if you update the password hash via the ldapmodify command. The key is in the extended operation. As an added tidbit only userPassword is monitored not any other attribute. Samba does password changes via an ldapmodify rather than an ldappasswd (unless you have ldap passwd sync = Only which I have never personally used so I have no tests to back this up). This would explain why LDAP has the policy enforcing and Samba does not.
My 'passwd program' in my smb.conf is "passwd program = /usr/bin/ldappasswd -x -W -S -D uid=%u,ou=Users,dc=example,dc=com" - so it should be using ldappasswd, which is bound by ppolicy, correct?
You shouldn't need a "passwd program" when using an LDAP SAM.
You're right. In reading the Samba documentation, I see that's only for updating Unix passwords, not LDAP passwords (though I suppose it's relevant if PAM is using LDAP and you set 'unix passwd sync = yes'; however, this is not my situation).
I've tried 'ldap passwd sync = only', after my failures with 'ldap passwd sync = yes' lead me back to the documentation, however this yielded no success.
I'm pretty sure if you have "ldap passwd sync = yes" that your "passwd program" directive is irrelevant since this means Samba is doing an ldapmodify to set the NT, LM, and userPassword attributes - your passwd program isn't doing anything. If "only" doesn't work then I strongly suspect that your smk5pwd module is *not* working, otherwise "only" would be the only mode to make any sense. By setting "ldap passwd sync = yes" your, at best, doing the work of smbk5pwd twice.
I realize that 'only' is what I want and that's what I'm using, however I think smbk5pwd is working. The two snippets below are show the differences after a Windows user changes his password (from the ctrl+alt+delete menu):
sambaPwdCanChange: 1207134133 sambaPwdMustChange: 2147483647 userPassword:: e1NTSEF9UkxaOUdIZnVhNkV2ejBzS0JKNVVWQ2pVOHNnR29Ma1Q= sambaPwdLastSet: 1207134133 sambaLMPassword: d85774cf671a9947aad3b435b51404ee sambaNTPassword: baac3929fabc9e6dcd32421ba94a84d4 pwdChangedTime: 20080402110213Z entryCSN: 20080402110213Z#000001#00#000000 modifiersName: cn=admin,dc=example,dc=com modifyTimestamp: 20080402110213Z
sambaPwdMustChange: 2147483647 sambaPwdCanChange: 1207137250 userPassword:: e1NTSEF9NWMveHkxSkVtZDcvcnZuWFZ4a3dtMVJsUnAzUGdEQW4= sambaPwdLastSet: 1207137250 sambaLMPassword: 614a6376feed376daad3b435b51404ee sambaNTPassword: d01b4a346f59e594f299a41a48126188 pwdChangedTime: 20080402115410Z entryCSN: 20080402115410Z#000001#00#000000 modifiersName: cn=admin,dc=example,dc=com modifyTimestamp: 20080402115410Z
Unless my test or logic (or both) are fundamentally flawed, it seems like the NT and LM passwords are being changed, along with the other attributes listed above. Interestingly enough, however, the modifiersName is admin (who isn't bound by the ppolicy restrictions) - perhaps that is what's causing the circumvention of ppolicy? Should I be investigating a way to force the modifier to be the user themselves?
Thanks as always for advice and constructive criticisms.
Ryan
Ryan Steele wrote:
I realize that 'only' is what I want and that's what I'm using, however I think smbk5pwd is working. The two snippets below are show the differences after a Windows user changes his password (from the ctrl+alt+delete menu):
Don't guess. Turn up the slapd debug level and show what it logs when you perform the actual password change.
Also, don't make us guess - post the relevant portion of your slapd configuration.
sambaPwdCanChange: 1207134133 sambaPwdMustChange: 2147483647 userPassword:: e1NTSEF9UkxaOUdIZnVhNkV2ejBzS0JKNVVWQ2pVOHNnR29Ma1Q= sambaPwdLastSet: 1207134133 sambaLMPassword: d85774cf671a9947aad3b435b51404ee sambaNTPassword: baac3929fabc9e6dcd32421ba94a84d4 pwdChangedTime: 20080402110213Z entryCSN: 20080402110213Z#000001#00#000000 modifiersName: cn=admin,dc=example,dc=com modifyTimestamp: 20080402110213Z
sambaPwdMustChange: 2147483647 sambaPwdCanChange: 1207137250 userPassword:: e1NTSEF9NWMveHkxSkVtZDcvcnZuWFZ4a3dtMVJsUnAzUGdEQW4= sambaPwdLastSet: 1207137250 sambaLMPassword: 614a6376feed376daad3b435b51404ee sambaNTPassword: d01b4a346f59e594f299a41a48126188 pwdChangedTime: 20080402115410Z entryCSN: 20080402115410Z#000001#00#000000 modifiersName: cn=admin,dc=example,dc=com modifyTimestamp: 20080402115410Z
Howard Chu writes:
Don't guess. Turn up the slapd debug level and show what it logs when you perform the actual password change.
Except, take care not to mail any actual passwords around if they turn up in the log:-) They do with at least loglevel 16 (log BER packets), unless someone has added some heavy magic since last I looked.
Hey Howard, Adam, and List:
I'm not even sure this is the path I ought to be going down. If smbk5pwd has no knowledge of ppolicy, and password changes from Windows clients won't adhere to those restrictions with any combination of configuration options in any currently known universe, perhaps what I really need is an alternate strategy. I'm open to suggestion; my only requirements are that password changes from a Windows workstation be subjected to the ppolicy constraints, and that the LDAP and Samba passwords all be in sync.
However, here are the logs entries and relevant slapd configuration options - pastings inline below:
Howard Chu wrote:
Ryan Steele wrote:
I realize that 'only' is what I want and that's what I'm using, however I think smbk5pwd is working. The two snippets below are show the differences after a Windows user changes his password (from the ctrl+alt+delete menu):
Don't guess. Turn up the slapd debug level and show what it logs when you perform the actual password change.
Note that although the logs seem to indicate (at least to my untrained eyes) that access to userPassword, sambaLMPassword, and sambaNTPassword is denied, Windows tells me it's been updated, and I can in fact log out and log back in with the new password.
Apr 3 07:27:00 ldapmaster slapd[1012]: => access_allowed: read access to "uid=tester,ou=Users,dc=example,dc=com" "userPassword" requested Apr 3 07:27:00 ldapmaster slapd[1012]: => acl_get: [1] attr userPassword Apr 3 07:27:00 ldapmaster slapd[1012]: access_allowed: no res from state (userPassword) Apr 3 07:27:00 ldapmaster slapd[1012]: => acl_mask: access to entry "uid=tester,ou=Users,dc=example,dc=com", attr "userPassword" requested Apr 3 07:27:00 ldapmaster slapd[1012]: => acl_mask: to value by "", (=0) Apr 3 07:27:00 ldapmaster slapd[1012]: <= check a_dn_pat: self Apr 3 07:27:00 ldapmaster slapd[1012]: <= check a_dn_pat: * Apr 3 07:27:00 ldapmaster slapd[1012]: <= acl_mask: [2] applying auth(=xd) (stop) Apr 3 07:27:00 ldapmaster slapd[1012]: <= acl_mask: [2] mask: auth(=xd) Apr 3 07:27:00 ldapmaster slapd[1012]: => access_allowed: read access denied by auth(=xd) Apr 3 07:27:00 ldapmaster slapd[1012]: send_search_entry: conn 5 access to attribute userPassword, value #0 not allowed
Apr 3 07:27:00 ldapmaster slapd[1012]: => access_allowed: read access to "uid=tester,ou=Users,dc=example,dc=com" "sambaLMPassword" requested Apr 3 07:27:00 ldapmaster slapd[1012]: => acl_get: [1] attr sambaLMPassword Apr 3 07:27:00 ldapmaster slapd[1012]: access_allowed: no res from state (sambaLMPassword) Apr 3 07:27:00 ldapmaster slapd[1012]: => acl_mask: access to entry "uid=tester,ou=Users,dc=example,dc=com", attr "sambaLMPassword" requested Apr 3 07:27:00 ldapmaster slapd[1012]: => acl_mask: to value by "", (=0) Apr 3 07:27:00 ldapmaster slapd[1012]: <= check a_dn_pat: self Apr 3 07:27:00 ldapmaster slapd[1012]: <= check a_dn_pat: * Apr 3 07:27:00 ldapmaster slapd[1012]: <= acl_mask: [2] applying auth(=xd) (stop) Apr 3 07:27:00 ldapmaster slapd[1012]: <= acl_mask: [2] mask: auth(=xd) Apr 3 07:27:00 ldapmaster slapd[1012]: => access_allowed: read access denied by auth(=xd) Apr 3 07:27:00 ldapmaster slapd[1012]: send_search_entry: conn 5 access to attribute sambaLMPassword, value #0 not allowed
Apr 3 07:27:00 ldapmaster slapd[1012]: => access_allowed: read access to "uid=tester,ou=Users,dc=example,dc=com" "sambaNTPassword" requested Apr 3 07:27:00 ldapmaster slapd[1012]: => acl_get: [1] attr sambaNTPassword Apr 3 07:27:00 ldapmaster slapd[1012]: access_allowed: no res from state (sambaNTPassword) Apr 3 07:27:00 ldapmaster slapd[1012]: => acl_mask: access to entry "uid=tester,ou=Users,dc=example,dc=com", attr "sambaNTPassword" requested Apr 3 07:27:00 ldapmaster slapd[1012]: => acl_mask: to value by "", (=0) Apr 3 07:27:00 ldapmaster slapd[1012]: <= check a_dn_pat: self Apr 3 07:27:00 ldapmaster slapd[1012]: <= check a_dn_pat: * Apr 3 07:27:00 ldapmaster slapd[1012]: <= acl_mask: [2] applying auth(=xd) (stop) Apr 3 07:27:00 ldapmaster slapd[1012]: <= acl_mask: [2] mask: auth(=xd) Apr 3 07:27:00 ldapmaster slapd[1012]: => access_allowed: read access denied by auth(=xd) Apr 3 07:27:00 ldapmaster slapd[1012]: send_search_entry: conn 5 access to attribute sambaNTPassword, value #0 not allowed
The only other references I found to these attributes in the logs (which are at loglevel 128) are:
Apr 3 07:27:00 ldapmaster slapd[1012]: <= root access granted Apr 3 07:27:00 ldapmaster slapd[1012]: => access_allowed: read access to "uid=tester,ou=Users,dc=example,dc=com" "sambaLMPassword" requested Apr 3 07:27:00 ldapmaster slapd[1012]: <= root access granted Apr 3 07:27:00 ldapmaster slapd[1012]: => access_allowed: read access to "uid=tester,ou=Users,dc=example,dc=com" "sambaNTPassword" requested
Also, don't make us guess - post the relevant portion of your slapd configuration.
include /etc/openldap/schema/ppolicy.schema
# Dynamic modules moduleload smbk5pwd.la
rootdn "cn=admin,dc=example,dc=com" rootpw {SSHA}tFEA391Y3ZLHXkQDDk6f0t1ZkJEuMwIj
# Overlays - ppolicy for enforcing password restrictions and smbk5pwd for syncing LDAP and Samba passwords overlay smbk5pwd overlay ppolicy ppolicy_default "cn=Password Policy,ou=Policies,dc=example,dc=com" ppolicy_use_lockout
# ACL's access to attrs=userPassword,sambaNTPassword,sambaLMPassword,shadowLastChange,shadowMax,sambaPwdLastSet,sambaPwdMustChange by self write by * auth
access to * by * read
The relevant output from slapcat is below.
sambaPwdCanChange: 1207134133 sambaPwdMustChange: 2147483647 userPassword:: e1NTSEF9UkxaOUdIZnVhNkV2ejBzS0JKNVVWQ2pVOHNnR29Ma1Q= sambaPwdLastSet: 1207134133 sambaLMPassword: d85774cf671a9947aad3b435b51404ee sambaNTPassword: baac3929fabc9e6dcd32421ba94a84d4 pwdChangedTime: 20080402110213Z entryCSN: 20080402110213Z#000001#00#000000 modifiersName: cn=admin,dc=example,dc=com modifyTimestamp: 20080402110213Z
sambaPwdMustChange: 2147483647 sambaPwdCanChange: 1207137250 userPassword:: e1NTSEF9NWMveHkxSkVtZDcvcnZuWFZ4a3dtMVJsUnAzUGdEQW4= sambaPwdLastSet: 1207137250 sambaLMPassword: 614a6376feed376daad3b435b51404ee sambaNTPassword: d01b4a346f59e594f299a41a48126188 pwdChangedTime: 20080402115410Z entryCSN: 20080402115410Z#000001#00#000000 modifiersName: cn=admin,dc=example,dc=com modifyTimestamp: 20080402115410Z
Ryan Steele wrote:
Hey Howard, Adam, and List:
I'm not even sure this is the path I ought to be going down. If smbk5pwd has no knowledge of ppolicy, and password changes from Windows clients won't adhere to those restrictions with any combination of configuration options in any currently known universe, perhaps what I really need is an alternate strategy. I'm open to suggestion; my only requirements are that password changes from a Windows workstation be subjected to the ppolicy constraints, and that the LDAP and Samba passwords all be in sync.
However, here are the logs entries and relevant slapd configuration options - pastings inline below:
Howard Chu wrote:
Ryan Steele wrote:
I realize that 'only' is what I want and that's what I'm using, however I think smbk5pwd is working. The two snippets below are show the differences after a Windows user changes his password (from the ctrl+alt+delete menu):
Don't guess. Turn up the slapd debug level and show what it logs when you perform the actual password change.
Note that although the logs seem to indicate (at least to my untrained eyes) that access to userPassword, sambaLMPassword, and sambaNTPassword is denied, Windows tells me it's been updated, and I can in fact log out and log back in with the new password.
This is syslog output, not debug output. I said to bump up the debug level.
Apr 3 07:27:00 ldapmaster slapd[1012]: => access_allowed: read access to "uid=tester,ou=Users,dc=example,dc=com" "userPassword" requested
The only other references I found to these attributes in the logs (which are at loglevel 128) are:
Apr 3 07:27:00 ldapmaster slapd[1012]:<= root access granted Apr 3 07:27:00 ldapmaster slapd[1012]: => access_allowed: read access to "uid=tester,ou=Users,dc=example,dc=com" "sambaLMPassword" requested Apr 3 07:27:00 ldapmaster slapd[1012]:<= root access granted Apr 3 07:27:00 ldapmaster slapd[1012]: => access_allowed: read access to "uid=tester,ou=Users,dc=example,dc=com" "sambaNTPassword" requested
As already mentioned, ppolicy doesn't restrict the rootDN. If you want your policy constraints to work, you have to bind with some other DN to make the changes. That will of course mean that you have to give that DN write access to the selected attributes in your ACL.
Also, don't make us guess - post the relevant portion of your slapd configuration.
include /etc/openldap/schema/ppolicy.schema
# Dynamic modules moduleload smbk5pwd.la
rootdn "cn=admin,dc=example,dc=com" rootpw {SSHA}tFEA391Y3ZLHXkQDDk6f0t1ZkJEuMwIj
# Overlays - ppolicy for enforcing password restrictions and smbk5pwd for syncing LDAP and Samba passwords overlay smbk5pwd overlay ppolicy ppolicy_default "cn=Password Policy,ou=Policies,dc=example,dc=com" ppolicy_use_lockout
# ACL's access to attrs=userPassword,sambaNTPassword,sambaLMPassword,shadowLastChange,shadowMax,sambaPwdLastSet,sambaPwdMustChange by self write by * auth
access to * by * read
Howard and others,
Let me ask two theoretical questions, before I submit my comments below. Windows XP/2000/et. al. send their passwords via SMB hashed. So, without configuring those workstations to send the passwords plaintext over the wire, is there any way for ppolicy to act on the ldapmodify initiated by Samba from Windows clients attempting to change their passwords?
Furthermore, if the above change is made so that ppolicy can evaluate the plaintext password, what exactly will the interaction between LDAP and the clients be if it fails to clear ppolicy constraints?
Additional comments below....
Howard Chu wrote:
Ryan Steele wrote:
Hey Howard, Adam, and List:
I'm not even sure this is the path I ought to be going down. If smbk5pwd has no knowledge of ppolicy, and password changes from Windows clients won't adhere to those restrictions with any combination of configuration options in any currently known universe, perhaps what I really need is an alternate strategy. I'm open to suggestion; my only requirements are that password changes from a Windows workstation be subjected to the ppolicy constraints, and that the LDAP and Samba passwords all be in sync.
However, here are the logs entries and relevant slapd configuration options - pastings inline below:
<snip>
This is syslog output, not debug output. I said to bump up the debug level.
Maybe I'm misunderstanding. From the slapd.conf manpage:
loglevel <integer> [...] Specify the level at which debugging statements and operation statistics should be syslogged (currently logged to the syslogd(8) LOG_LOCAL4 facility).
I thought "debugging statements" is what you wanted? When I start slapd with the -d option, I seem to get the same output as when I specify 'loglevel N' in the slapd.conf.
<snip>
As already mentioned, ppolicy doesn't restrict the rootDN. If you want your policy constraints to work, you have to bind with some other DN to make the changes. That will of course mean that you have to give that DN write access to the selected attributes in your ACL.
Ok - I'll create an LDAP user specifically for changing passwords, and set that as my "ldap admin dn" in the smb.conf, so the change won't be done by the rootdn, as recommended by Adam and yourself. I'll then create an entry in the slapd.conf like the one below and give that a shot.
# ACL's access to attrs=userPassword,sambaNTPassword,sambaLMPassword,shadowLastChange,shadowMax,sambaPwdLastSet,sambaPwdMustChange
by self write by * auth
access to attrs=userPassword,sambaNTPassword,sambaLMPassword,shadowLastChange,shadowMax,sambaPwdLastSet,sambaPwdMustChange,pwdChangedTime,pwdHistory by dn="cn=pwchanger,dc=example,dc=com" write
access to * by * read
Let me ask two theoretical questions, before I submit my comments below. Windows XP/2000/et. al. send their passwords via SMB hashed. So, without configuring those workstations to send the passwords plaintext over the wire, is there any way for ppolicy to act on the ldapmodify initiated by Samba from Windows clients attempting to change their passwords?
You do *NOT* need to configure the clients to use cleartext password - which BTW would break domain functionality anyway.
Samba has a cleartext equivalent of the password when you do a password change, else how would password chat scripts work?
Furthermore, if the above change is made so that ppolicy can evaluate the plaintext password, what exactly will the interaction between LDAP and the clients be if it fails to clear ppolicy constraints?
Ok - I'll create an LDAP user specifically for changing passwords, and set that as my "ldap admin dn" in the smb.conf, so the change won't be done by the rootdn, as recommended by Adam and yourself. I'll then create an entry in the slapd.conf like the one below and give that a shot.
Excellent, I'm very interested to see what happens at that point.
# ACL's access to attrs=userPassword,sambaNTPassword,sambaLMPassword,shadowLastChange,shadowMax,sambaPwdLastSet,sambaPwdMustChange by self write by * auth
access toattrs=userPassword,sambaNTPassword,sambaLMPassword,shadowLastChange,shadowMax,sambaPwdLastSet,sambaPwdMustChange,pwdChangedTime,pwdHistory by dn="cn=pwchanger,dc=example,dc=com" write
access to * by * read
Adam, Howard, and list,
Upon Howard's suggestion, I went and re-read the docs on ACL's for slapd.conf. What I came up with is the following (I'll change the first asterisk to the specific attributes once I've actually got it working...):
# ACL's access to * by dn.exact="cn=pwdchanger,dc=example,dc=com" write by * break
access to attrs=userPassword,sambaNTPassword,sambaLMPassword,shadowLastChange,shadowMax,sambaPwdLastSet,sambaPwdMustChange by self write by * auth
access to * by * read
I also set the 'ldap admin dn' to be cn=pwdchanger,dc=example,dc=com in my smb.conf, and added him to the smbpasswd database.
I'm happy to report that my initial testing shows that ppolicy indeed is being adhered to now. A big thank you to Howard, Adam, Pat, and others who assisted me. I have noticed, as Thierry Lacoste pointed out, that Windows reports a successful password change when the password fails ppolicy restrictions - but ONLY if I have logging set to 0. I have no idea why the two are related. If I have logging turned on (even to 1), Windows reports "The system cannot change your password now because the domain DOMAINNAME is unavailable", but at least it's confirmation on the user end that the change didn't take. However, this is a Samba issue, not an LDAP issue, so I'll take my findings to their mailing list.
Again, thanks to those who helped me.
Best Regards, Ryan
On Thu, Apr 3, 2008 at 8:17 PM, Ryan Steele rsteele@archer-group.com wrote:
Howard and others,
Let me ask two theoretical questions, before I submit my comments below. Windows XP/2000/et. al. send their passwords via SMB hashed.
For authentication (broadly speaking, as AFAIK a challenge and response is sent, I don't think the hashes are sent directly over the wire) yes, for password changes, no.
So, without configuring those workstations to send the passwords plaintext over the wire, is there any way for ppolicy to act on the ldapmodify initiated by Samba from Windows clients attempting to change their passwords?
Samba can already generate different (incompatible) hashes, or run the password program, so it must have the clear text at this point. Whether it supplies the clear text to OpenLDAP or not is the issue (and I haven't had time to check myself yet, and can't remember off-hand). If it does not, it would be worthwhile requesting an option enabling this (or, support for changing with an ldap password change extended operation). I note that Heimdal would benefit from a similar option as well (which I will take up on the Heimdal list).
Furthermore, if the above change is made so that ppolicy can evaluate the plaintext password, what exactly will the interaction between LDAP and the clients be if it fails to clear ppolicy constraints?
slapd will fail the operation, with a suitable error code and error text. Whether samba will send a useful error to the client (so that the client workstation displays an appropriate error message) is the next question.
The third question is, what will happen to the samba password expiry attributes, for both the case of changing via samba (should be fine) and changing via ldap (won't be updated, samba passwords will still appear to be expired). I also haven't had a chance to look at fixing that (and again, the Heimdal equivalent also applies).
Regards, Buchan
Buchan Milne wrote:
Furthermore, if the above change is made so that ppolicy can evaluate the plaintext password, what exactly will the interaction between LDAP and the clients be if it fails to clear ppolicy constraints?
slapd will fail the operation, with a suitable error code and error text. Whether samba will send a useful error to the client (so that the client workstation displays an appropriate error message) is the next question.
According to Thierry's post http://www.openldap.org/lists/openldap-software/200804/msg00066.html there's a problem there as well, but that's certainly a Samba or Windows issue, and nothing we can address in LDAP.
The third question is, what will happen to the samba password expiry attributes, for both the case of changing via samba (should be fine) and changing via ldap (won't be updated, samba passwords will still appear to be expired). I also haven't had a chance to look at fixing that (and again, the Heimdal equivalent also applies).
Current CVS smbk5pwd already takes care of these Samba attributes. What version are you looking at?
Ryan Steele wrote:
Howard and others,
Let me ask two theoretical questions, before I submit my comments below. Windows XP/2000/et. al. send their passwords via SMB hashed.
That is not true for a password change request, so the rest of this question is irrelevant.
So, without configuring those workstations to send the passwords plaintext over the wire, is there any way for ppolicy to act on the ldapmodify initiated by Samba from Windows clients attempting to change their passwords?
Furthermore, if the above change is made so that ppolicy can evaluate the plaintext password, what exactly will the interaction between LDAP and the clients be if it fails to clear ppolicy constraints?
When you get it working you'll know. Questions of the form "what will happen if" will always get answered by "try it and see."
This is syslog output, not debug output. I said to bump up the debug level.
Maybe I'm misunderstanding. From the slapd.conf manpage:
loglevel<integer> [...] Specify the level at which debugging statements and operation statistics should be syslogged (currently logged to the syslogd(8) LOG_LOCAL4 facility).
I thought "debugging statements" is what you wanted? When I start slapd with the -d option, I seem to get the same output as when I specify 'loglevel N' in the slapd.conf.
As I've said countless times - syslog is not a debugging tool. It is lossy; when the syslog daemon gets too busy it discards messages. If it could be used for everything there would be no need for us to provide a "-d" option. But in fact, we *do* provide a "-d" option, and debugging is its only purpose.
<snip>
As already mentioned, ppolicy doesn't restrict the rootDN. If you want your policy constraints to work, you have to bind with some other DN to make the changes. That will of course mean that you have to give that DN write access to the selected attributes in your ACL.
Ok - I'll create an LDAP user specifically for changing passwords, and set that as my "ldap admin dn" in the smb.conf, so the change won't be done by the rootdn, as recommended by Adam and yourself. I'll then create an entry in the slapd.conf like the one below and give that a shot.
# ACL's access to attrs=userPassword,sambaNTPassword,sambaLMPassword,shadowLastChange,shadowMax,sambaPwdLastSet,sambaPwdMustChange
by self write by * authaccess toattrs=userPassword,sambaNTPassword,sambaLMPassword,shadowLastChange,shadowMax,sambaPwdLastSet,sambaPwdMustChange,pwdChangedTime,pwdHistory by dn="cn=pwchanger,dc=example,dc=com" write
You need to re-read the ACL docs.
I'm not even sure this is the path I ought to be going down. If smbk5pwd has no knowledge of ppolicy, and password changes from Windows clients won't adhere to those restrictions with any combination of configuration options in any currently known universe, perhaps what I really need is an alternate strategy. I'm open to suggestion; my only requirements are that password changes from a Windows workstation be subjected to the ppolicy constraints, and that the LDAP and Samba passwords all be in sync. rootdn "cn=admin,dc=example,dc=com" rootpw {SSHA}tFEA391Y3ZLHXkQDDk6f0t1ZkJEuMwIj
Are you still using the rootdn as the Samba bind DN? If so, don't.
I'm not even sure this is the path I ought to be going down. If smbk5pwd has no knowledge of ppolicy, and password changes from Windows clients won't adhere to those restrictions with any combination of configuration options in any currently known universe, perhaps what I really need is an alternate strategy. I'm open to suggestion; my only requirements are that password changes from a Windows workstation be subjected to the ppolicy constraints, and that the LDAP and Samba passwords all be in sync.
I did some experiments last summer but it was quite disapointing. Even if a password change is rejected by the LDAP server, the windows workstation reports success, in addition it caches the suposedly new password which poses some further problems. Please let me know if you make some progress.
BTW be careful with 'ldap passwd sync = only' https://bugzilla.samba.org/show_bug.cgi?id=4901
Regards, Thierry.
Pat Riehecky wrote:
Here is what I know on this, wiser minds may feel free to correct everything I have to say.....
replies are inline.
On Tue, 2008-04-01 at 15:46 -0400, Ryan Steele wrote:
Hello,
I've got the smbk5pwd and ppolicy modules working, but I'm not entirely sure I've got them working together.
I say this because clients joined to the domain (run by a Samba PDC with an OpenLDAP backend) can change their passwords and it updates the NT/LM passwords in LDAP, thus verifying the functionality of smk5pwd, but it does not appear to enforce ppolicy restrictions. On the flip side of the coin, the user can change their LDAP password by invoking ldappasswd from a shell on the server, and are bound by the restrictions set forth by ppolicy (password length, strength, historical passwords, etc.).
The ppolicy overlay is adding extra functionality to the password extended operation. ldappasswd uses this. The restriction is not present if you update the password hash via the ldapmodify command. The key is in the extended operation. As an added tidbit only userPassword is monitored not any other attribute.
That's not entirely true. The ppolicy overlay also intercepts regular Modify requests. But the sticking point is that if the incoming password is already hashed, then most of the policy checks cannot be performed. Typically, clients that use ldapmodify on the userPassword hash the value before sending it to the server, and so the overlay can't do anything.
Samba does password changes via an ldapmodify rather than an ldappasswd (unless you have ldap passwd sync = Only which I have never personally used so I have no tests to back this up). This would explain why LDAP has the policy enforcing and Samba does not.
Howard Chu wrote:
Pat Riehecky wrote:
Here is what I know on this, wiser minds may feel free to correct everything I have to say.....
replies are inline.
On Tue, 2008-04-01 at 15:46 -0400, Ryan Steele wrote:
Hello,
I've got the smbk5pwd and ppolicy modules working, but I'm not entirely sure I've got them working together.
I say this because clients joined to the domain (run by a Samba PDC with an OpenLDAP backend) can change their passwords and it updates the NT/LM passwords in LDAP, thus verifying the functionality of smk5pwd, but it does not appear to enforce ppolicy restrictions. On the flip side of the coin, the user can change their LDAP password by invoking ldappasswd from a shell on the server, and are bound by the restrictions set forth by ppolicy (password length, strength, historical passwords, etc.).
The ppolicy overlay is adding extra functionality to the password extended operation. ldappasswd uses this. The restriction is not present if you update the password hash via the ldapmodify command. The key is in the extended operation. As an added tidbit only userPassword is monitored not any other attribute.
That's not entirely true. The ppolicy overlay also intercepts regular Modify requests. But the sticking point is that if the incoming password is already hashed, then most of the policy checks cannot be performed. Typically, clients that use ldapmodify on the userPassword hash the value before sending it to the server, and so the overlay can't do anything.
Well, if the 'passwd program' defined in the smb.conf is ldappasswd, then the ldapmodify doesn't come in to play, correct? The two things I'm confused about is
1. why there is a sambaPasswordHistory attribute if it's using ldappasswd (ldappasswd should modify the pwdHistory attribute, no?), and
2. why ppolicy wouldn't come in to play in my situation. I have 'ldap passwd sync = only' set, so smbk5pwd should just set the NT/LM passwords based on what userPassword is, which is set by ldappasswd (the 'passwd program'), which in turn is supposed to be regulated by ppolicy.
The only explanation I can see here is that Windows is sending the passwords already hashed to ldappasswd. However, the Windows clients can change their password from 'foobar' to 'foobar', so the hash shouldn't change and thus ppolicy should complain - but it doesn't.
If Windows encrypting the passwords is the problem, then is my only recourse to edit the Windows registry settings on the intranet machines to send SMB passwords across in plaintext to the domain controller, and edit the Samba configs such that 'encrypt passwords = no' is set, so that ppolicy can act on the plaintext password? I'm open to whatever suggestions make sense.
Samba does password changes via an ldapmodify rather than an ldappasswd (unless you have ldap passwd sync = Only which I have never personally used so I have no tests to back this up). This would explain why LDAP has the policy enforcing and Samba does not.
The ppolicy overlay is adding extra functionality to the password extended operation. ldappasswd uses this. The restriction is not present if you update the password hash via the ldapmodify command. The key is in the extended operation. As an added tidbit only userPassword is monitored not any other attribute.
That's not entirely true. The ppolicy overlay also intercepts regular Modify requests. But the sticking point is that if the incoming password is already hashed, then most of the policy checks cannot be performed. Typically, clients that use ldapmodify on the userPassword hash the value before sending it to the server, and so the overlay can't do anything.
Well, if the 'passwd program' defined in the smb.conf is ldappasswd, then the ldapmodify doesn't come in to play, correct? The two things I'm confused about is
The passwd program doesn't matter when using an LDAP SAM. Hopefully it is just ignored. Safe move would be to remove it altogether.
- why there is a sambaPasswordHistory attribute if it's using
ldappasswd (ldappasswd should modify the pwdHistory attribute, no?), and
? sambaPasswordHistory is part of the Samba schema and assumes that Samba is managing password integrity, repeated use, etc... But if you are using ppolicy I'd suspect you just don't care about sambaPasswordHistory.
I'd really like ppolicy & smbk5pwd to play nicely together and theoretically they should but I suspect you will run into one very interesting problem - what happens when Samba tries to change the password and ppolicy says "no"? What kind of meaningless error message will the end-user see?
Samba does password changes via an ldapmodify rather than an ldappasswd (unless you have ldap passwd sync = Only which I have never personally used so I have no tests to back this up). This would explain why LDAP has the policy enforcing and Samba does not.
Is your Samba server binding as your manager/admin DN? Don't do that, ever. Create a bind context for Samba and use ACLs to give that context the access it requires. I don't know if it will fix Samba +ppolicy but it is the correct thing to do either way.
Adam Tauno Williams wrote:
Is your Samba server binding as your manager/admin DN? Don't do that, ever. Create a bind context for Samba and use ACLs to give that context the access it requires. I don't know if it will fix Samba +ppolicy but it is the correct thing to do either way.
Correct. As the slapo-ppolicy(5) manpage states, the admin DN bypasses most policy restrictions.
openldap-software@openldap.org
-
Adam Tauno Williams -
Buchan Milne -
Hallvard B Furuseth -
Howard Chu -
Pat Riehecky -
Ryan Steele -
Thierry Lacoste