On Wednesday, 28 September 2011 16:24:35 Dan White wrote:
On 27/09/11 18:59 +0200, Michael Ströder wrote:
HI!
We have {SSHA}-hashed passwords in attribute userPassword.
One application sends CompareRequests with the clear-text password instead of a BindRequest to validate the password which obviously fails. The application vendor claims it is too much effort to change that behaviour in the application. I guess this can only be solved in slapd by a custom overlay intercepting the CompareRequest (which is effort too).
Or is there any other solution I don't know of?
We had a similar problem where Sun ILOM requires userPassword to be in a Solaris compatible crypt format. We created a custom attribute, called cryptedUserPassword, and populate it for the users that need access to the device. Then we make use of slapd-relay and slapo-rwm, to present cryptedUserPassword as userPassword when our relayed tree (dc=example,dc=net,dc=ilom) is queried.
What benefit is this over having the userPassword be in CRYPT? In either case, you're exposing weak passwords to a specific account. If an attacker could gain access to userPassword, most likely they have easier access to the cryptedUserPassword attribtue?
Yes, we have the same problem (but, this seems to be about the only really irritating misfeature of the ILOM, compared to the manifold problems of HP iLO).
And yes, I would much rather find an avenue to escalate this to Sun/Oracle ....
Our slapd.conf config looks like:
database relay suffix "dc=example,dc=net,dc=ilom" overlay rwm rwm-rewriteEngine on suffixmassage "dc=example,dc=net" rwm-rewriteContext default rwm-map attribute userPassword cryptedUserPassword rwm-map attribute cryptedUserPassword userPassword rwm-rewriteContext searchFilter rwm-rewriteRule ".*uid=(.*)))" "(&(uid=$1)(someAccessAttr=ilom))"
Regards, Buchan