Enable credential-free deployment #86
Conversation
Users should have access to view their own LDAP records and change their own passwords, so if user credentials are available, use them. This allows self service password to be deployed without credentials of its own and without permitting anonymous binds. This may not work in some situations, like if the user's account is expired, but if that's the case there's not much we could do without manager credentials.
|
Hi, why just don't allow anonymous search on LDAP directory to find user? Is this only a security issue? |
|
Yes, for security reasons we'd prefer not to have anonymous searches enabled. My thought was: if the user is already providing creds that can do the search, why open it up to everyone? |
|
We only have user credentials when user is changing password. For a reset, we don't have user password, so it won't work. You can have a SSP account that has only search rights on directory. |
|
True, there's no way you would be able to do a reset without the app having its own credentials. We're getting around that by just having resets disabled, but I certainly acknowledge that resets are a nice feature that is missing when deployed this way. An SSP account with only search rights would work for us, though it still wouldn't allow resets. I don't really see the advantage, though - fewer secrets makes it easier to deploy and the app still gets all the access it needs to do self-service changes. (Although I've just realized that a bad Anyway, no pressure. I realize the tradeoffs we've picked might not make sense for everyone. But if you like the idea and want any fixes to the code like the error message issue mentioned above, I'm happy to make them. |
|
I will see if we can include this in a future release, as this can only work with change password feature, and an LDAP directory with a single user branch |
|
Hi @LiptonB
What about allowing anonymous searches only from SSP's IP address ? |
In my environment I would like to be able to deploy Self Service Password without storing any LDAP credentials on the box where it's running, and I realized that in many cases the user's own credentials should be enough. This modifies the tool so that
ldap_binddnandldap_bindpwcan be left unset. Just thought I would share this in case you think it would be useful to others. Thanks for a great tool!