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?
Ciao, Michael.
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.
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))"
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
On 29/09/11 17:51 +0200, Buchan Milne wrote:
On Wednesday, 28 September 2011 16:24:35 Dan White wrote:
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 ....
Do you mean?
userPassword: {CRYPT}$1$...
Presumably that would fail since ILOM is requesting userPassword and comparing it locally, and would balk at the '{CRYPT}' substring.
I have the same ACLs configured for both userPassword and cryptedUserPassword (custom attribute).
I don't have a business relationship with Oracle to open a ticket. Does anyone have a point of contact at Oracle to submit feature requests to?
On Thu, 29 Sep 2011, Dan White wrote:
On 29/09/11 17:51 +0200, Buchan Milne wrote:
On Wednesday, 28 September 2011 16:24:35 Dan White wrote:
We had a similar problem where Sun ILOM requires userPassword to be in a Solaris compatible crypt format. We created a custom attribute, called
[...] I don't have a business relationship with Oracle to open a ticket. Does anyone have a point of contact at Oracle to submit feature requests to?
The manual clearly states that passwords must be crypted (MD5 IIRC; I'm not going to open the PDF now to check). However, our experience (ILOM v3) is that an LDAP Simple Bind with SSL works, for loose values of "works." Yes, this directly contradicts the documentation. I didn't bother filing a support request. (They might break it as not matching specs!)
I forget whether there was some sort of configurable filter on the ILOM. My hazy recollection was that it performed a search, ignored the results entirely, and then blindly binded as "$ATTR=$INPUT,$SUFFIX" where $ATTR and $SUFFIX were configurable and $INPUT must be known, out-of-band and precisely, by the end user (as the search results were ignored).
This presented us with nervous laughter and an issue; we (essentially) wanted only users with primary gid wheel to get in to the ILOMs. In less time than it would have taken me to submit a change request I wrote up:
database relay suffix "o=rightPrimaryGid" overlay rwm
rwm-rewriteEngine on # all dataflow from client to server referring to DNs rwm-rewriteContext default rwm-rewriteRule "(.+,)?o=rightPrimaryGid$" "$1o=posixAccounts" ":" # add a gidNumber=12345 filter to anybody here -- of course the ILOMs ignore searches, how lame rwm-rewriteContext searchFilter rwm-rewriteRule "(.+)" "(&$1(gidNumber=12345))" ":" # all dataflow from server to client rwm-rewriteContext searchEntryDN rwm-rewriteRule "(.+,)?o=posixAccounts$" "$1o=rightPrimaryGid" ":" rwm-rewriteContext searchAttrDN alias searchEntryDN rwm-rewriteContext matchedDN alias searchEntryDN # misc empty rules rwm-rewriteContext referralAttrDN rwm-rewriteContext referralDN # only allow binds to gidNumber=12345 uid=.* dns ... this could possibly be optimized? rwm-rewriteMap slapd oneGid "ldap:///o=posixAccounts?dn?sub?(&(gidNumber=12345)" rwm-rewriteContext bindDN rwm-rewriteRule "^(uid=[^,]+),.*" "${oneGid(($1)))}" ":@I"
and now the ILOMs and I have an uneasy truce.
On 09/27/2011 06:59 PM, 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).
I guess the purpose is to authenticate. In that case, the app should use the bind operation (simple bind, in this case).
An overlay would basically need to take the value from the compare request, put it into a bind request structure, call the frontend's bi_op_bind() hook. The custom overlay would probably be 10 to 100 lines of code, and most of the headache would come from trading code duplication (rewrite simple bind code) with having to deal with intercepting bind responses, which is a mess (successful ones are delegated to the frontend, unsuccessful ones are directly dealt with by the hook).
The application would need how many lines of code? two? three?
p.
Pierangelo Masarati writes:
An overlay would basically need to take the value from the compare request, put it into a bind request structure, call the frontend's bi_op_bind() hook.
And save the connection's BindDN before Compare and restore it after. And serialize operations for the entire connection during the Compare, since Bind expects to be the lone active request on the connection while most other operations do not.
The custom overlay would probably be 10 to 100 lines of code, (...)
Rather more than that, I'd say.
I wrote:
And save the connection's BindDN before Compare and restore it after.
Duh, never mind - the frontend does that, I think.
And serialize operations for the entire connection during the Compare, since Bind expects to be the lone active request on the connection while most other operations do not.
Wondering about this one though.
Pierangelo Masarati wrote:
On 09/27/2011 06:59 PM, 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).
I guess the purpose is to authenticate. In that case, the app should use the bind operation (simple bind, in this case).
An overlay would basically need to take the value from the compare request, put it into a bind request structure, call the frontend's bi_op_bind() hook. The custom overlay would probably be 10 to 100 lines of code, and most of the headache would come from trading code duplication (rewrite simple bind code) with having to deal with intercepting bind responses, which is a mess (successful ones are delegated to the frontend, unsuccessful ones are directly dealt with by the hook).
The application would need how many lines of code? two? three?
Pierangelo I really appreciate that you double my arguments... ;-)
But decisions are sometimes influenced by other priorities beyond pure technical aspects.
Anyway the guy who's supposed to implement such an overlay will appreciate your technical hints above.
Ciao, Michael.
On Tuesday, 27 September 2011 18:59:52 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.
Wouldn't it be more beneficial to everyone if you asked the vendor to provide a version of their software that was standards-compliant?
Regards, Buchan
Buchan Milne wrote:
On Tuesday, 27 September 2011 18:59:52 Michael Ströder wrote:
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.
Wouldn't it be more beneficial to everyone if you asked the vendor to provide a version of their software that was standards-compliant?
As said in another posting that is my own first and preferred recommendation. But sometimes it's not so easy...
Ciao, Michael.
openldap-technical@openldap.org
-
Aaron Richton -
Buchan Milne -
Dan White -
Hallvard B Furuseth -
Michael Ströder -
Pierangelo Masarati