2:48 p.m.
Hello
I am migrating an LDAP system from CentOS-Directory/8.1.0 B2009.134.1334 to
389-Directory/1.3.5.10 B2017.145.2037
We have an external app/too for user password management.
The tool binds as a special user when changing passwords in the "forgot
password" use case, and as the regular user in the "I know my password but want
to change it" use case.
In both use cases the tool has the behavior of generating an SSHA hash string and then
doing an ldapmodify to change the userPassword value to that string. When we tested the
tool against the new instances we got the error in the subject.
I had already defined the proper ACI for the special user. Digging around I found if I
provided the dn for special user in the passwordAdminDN attribute value in cn=config the
"forgot password" use case worked. However the application will of course
continue to fail when it binds as the regular users.
One additional item - the systems we are coming from do have a Password Policy configured,
but I have not explicitly configured one yet on the new systems, even though the relevant
per-user attributes came over in the db migration. However, the password policy is only
for when the passwords need to be changed/expired, as opposed to syntax/strength.
Is there a way around this without changing our app/tool to send the plain password over
SSL/TLS/STARTTLS?
Thanks
Kirk MacDonald
Eastlink
3:59 p.m.
New subject: LDAP: error code 19 - invalid password syntax - passwords with storage scheme are not allowed
Hi Kirk
I think that in newer versions of 389 you need a special permission to
adding already hashed passwords or change user password scheme:
http://www.port389.org/docs/389ds/design/password-administrator.html
Hope that helps you.
Cheers,
Alberto Viana
On Tue, Aug 29, 2017 at 4:48 PM, Kirk MacDonald <
Kirk.MacDonald(a)corp.eastlink.ca> wrote:
Hello
I am migrating an LDAP system from CentOS-Directory/8.1.0 B2009.134.1334
to 389-Directory/1.3.5.10 B2017.145.2037
We have an external app/too for user password management.
The tool binds as a special user when changing passwords in the "forgot
password" use case, and as the regular user in the "I know my password but
want to change it" use case.
In both use cases the tool has the behavior of generating an SSHA hash
string and then doing an ldapmodify to change the userPassword value to
that string. When we tested the tool against the new instances we got the
error in the subject.
I had already defined the proper ACI for the special user. Digging around
I found if I provided the dn for special user in the passwordAdminDN
attribute value in cn=config the "forgot password" use case worked. However
the application will of course continue to fail when it binds as the
regular users.
One additional item - the systems we are coming from do have a Password
Policy configured, but I have not explicitly configured one yet on the new
systems, even though the relevant per-user attributes came over in the db
migration. However, the password policy is only for when the passwords need
to be changed/expired, as opposed to syntax/strength.
Is there a way around this without changing our app/tool to send the plain
password over SSL/TLS/STARTTLS?
Thanks
Kirk MacDonald
Eastlink
_______________________________________________
389-users mailing list -- 389-users(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
4:49 p.m.
New subject: LDAP: error code 19 - invalid password syntax - passwords with storage scheme are not allowed
On 08/29/2017 04:59 PM, Alberto Viana wrote:
Hi Kirk
I think that in newer versions of 389 you need a special permission to
adding already hashed passwords or change user password scheme:
http://www.port389.org/docs/389ds/design/password-administrator.html
Using "directory manager" will also work
Hope that helps you.
Cheers,
Alberto Viana
On Tue, Aug 29, 2017 at 4:48 PM, Kirk MacDonald
<Kirk.MacDonald(a)corp.eastlink.ca
<mailto:Kirk.MacDonald@corp.eastlink.ca>> wrote:
Hello
I am migrating an LDAP system from CentOS-Directory/8.1.0
B2009.134.1334 to 389-Directory/1.3.5.10 <http://1.3.5.10>
B2017.145.2037
We have an external app/too for user password management.
The tool binds as a special user when changing passwords in the
"forgot password" use case, and as the regular user in the "I know
my password but want to change it" use case.
In both use cases the tool has the behavior of generating an SSHA
hash string and then doing an ldapmodify to change the
userPassword value to that string. When we tested the tool against
the new instances we got the error in the subject.
I had already defined the proper ACI for the special user. Digging
around I found if I provided the dn for special user in the
passwordAdminDN attribute value in cn=config the "forgot password"
use case worked. However the application will of course continue
to fail when it binds as the regular users.
One additional item - the systems we are coming from do have a
Password Policy configured, but I have not explicitly configured
one yet on the new systems, even though the relevant per-user
attributes came over in the db migration. However, the password
policy is only for when the passwords need to be changed/expired,
as opposed to syntax/strength.
Is there a way around this without changing our app/tool to send
the plain password over SSL/TLS/STARTTLS?
Thanks
Kirk MacDonald
Eastlink
_______________________________________________
389-users mailing list -- 389-users(a)lists.fedoraproject.org
<mailto:389-users@lists.fedoraproject.org>
To unsubscribe send an email to
389-users-leave(a)lists.fedoraproject.org
<mailto:389-users-leave@lists.fedoraproject.org>
_______________________________________________
389-users mailing list -- 389-users(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
2431
days inactive
2431
days old
389-users@lists.fedoraproject.org
2 comments
3 participants
participants (3)
-
Alberto Viana -
Kirk MacDonald -
Mark Reynolds