Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

answered 2014-06-19 14:08:49 -0600

wyllys gravatar image

After more digging, I got a little further and discovered some potential bugs:

NOTE: Any operation involving the password must be done over TLS (i.e. LDAPS), otherwise AD will reject the request. This should be noted in the documentation.

  1. the "UNWILLING_TO_PERFORM" response from AD is because keystone attempts to first create a user with the userAccountStatus value of 512, but is not providing a password. AD will not allow accounts with no password to have that status value (NORMAL_ACCOUNT).

  2. The correct password field to use when setting or changing a user password in AD is "unicodePwd", and it must be encoded correctly:

    unipwd = base64.b64encode(unicode("\"AnExamplePassword1!\"").encode('utf-16-le'))

Ex: unicodePwd:: IgBBAG4ARQB4AGEAbQBwAGwAZQBQAGEAcwBzAHcAbwByAGQAMQAhACIA (NOTE: the double colon "unicodePwd::" is correct,not a typo).

It appears that keystone uses "userPassword", which AD seems to ignore in favor of "unicodePwd". Also, the 'unicodePwd' attibute is read-only and will never be given back in a query response.

  • keystone should either put the proper unicodePwd value in the initial create request along with the userAccountStatus of 512 - or - leave the password and userAccountStatus out of the create request, and issue a subsequent "update" request to set the password and set the accountStatus fields correctly.