#4171 save_group.cgi should not send userPassword if no group pwd

closed-fixed
5
2012-12-12
2012-12-05
No

The save_group.cgi always sends the userPassword attribute, even if no group password is specified. E.g. :

# Update group properties
$rv = $ldap->modify($newdn, replace =>
{ "gidNumber" => $gid,
"cn" => $group,
"userPassword" => $pass,
@members ? ( "memberUid" => \@members ) : ( ),
@props,
"objectClass" => \@classes },
'delete' => \@rprops);

Similar code exists for ->add operation.

Using LDAP Server OpenDJ with a password policy to enforce minimum password complexity, this causes the LDAP server to reject the ->modify or ->add operation with an error stating that the password does not meet the minimum complexity requirements. Note this error is specific to my password complexity policy

The provided password value was rejected by a password validator: The provided password did not contain enough characters from the character set 'ABCDEFGHIJKLMNOPQRSTUVWXYZ'. The minimum number of characters from that set that must be present in user passwords is 1

Please only include the userPassword attribute for a group when the group actually has a password.

Thanks!
-- Pat

Discussion

  • Patrick Spinler

    Patrick Spinler - 2012-12-11

    I also note this issue when modifying user accounts to have no password. Instead of sending a ldap modify, delete userPassword, webmin is apparently sending a empty userPassword attribute. My LDAP server with a password policy set rejects this modification.

     
  • Jamie Cameron

    Jamie Cameron - 2012-12-11

    Sorry for the delay in responding to this bug - I actually implemented a fix (for groups), but never updated the bug.

    How does your LDAP server treat a posixAccount object with no password set? Is that user allowed to login without needing to enter a passowrd?

     
  • Patrick Spinler

    Patrick Spinler - 2012-12-12

    Thanks for the response Jamie. Is the update in the recent webmin 1.6.1 I see is available? If so, please let me know and I'll download it and test it.

    As far as an behavior of an entry with no userPassword attribute, my LDAP server (opendj-2.4.5) with it's default security settings won't perform a successfull bind for an account with no password. Here:

    # Verify account has no password attribute:

    [root@calgb-auth1 ~]# ldapsearch -LLL -x -D "cn=Directory Manager" -y /local1/amadmin.creds -b ou=ad,dc=calgb,dc=org uid=cxliu
    dn: uid=cxliu,ou=People,ou=AD,dc=calgb,dc=org
    objectClass: person
    objectClass: inetuser
    objectClass: organizationalPerson
    objectClass: inetOrgPerson
    objectClass: shadowAccount
    objectClass: posixAccount
    objectClass: top
    uid: cxliu
    cn: Xianhua Lie
    shadowLastChange: 15686
    loginShell: /sbin/nologin
    sn: Xianhua Lie
    gecos: Xianhua Lie
    homeDirectory: /home/cxliu
    uidNumber: 500249
    gidNumber: 65534

    # Try binding to this account with no password:

    [root@calgb-auth1 ~]# ldapsearch -LLL -x -D "uid=cxliu,ou=People,ou=AD,dc=calgb,dc=org" -b ou=ad,dc=calgb,dc=org uid=cxliu
    ldap_bind: Server is unwilling to perform (53)
    additional info: Unable to process the simple bind request because it contained a bind DN but no password, which is forbidden by the server configuration

    # Try binding to this account with an empty passsword:

    [root@calgb-auth1 ~]# ldapsearch -LLL -x -D "uid=cxliu,ou=People,ou=AD,dc=calgb,dc=org" -w "" -b ou=ad,dc=calgb,dc=org uid=cxliu
    ldap_bind: Server is unwilling to perform (53)
    additional info: Unable to process the simple bind request because it contained a bind DN but no password, which is forbidden by the server configuration

    thanks!
    -- Pat

     
  • Jamie Cameron

    Jamie Cameron - 2012-12-12
    • status: open --> closed-fixed
     
  • Jamie Cameron

    Jamie Cameron - 2012-12-12

    Ok, in the next Webmin release I will have it not set the userPassword attribute for users or groups if there is no password.

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks