I've got a situation that may be unique to our site and I'm wondering if anyone might have an idea on how to accomplish something. I'll have to set the ground work with a bit of an explanation first.

A long time ago we chose to allow/deny authentication on the whole by allowing/denying access to the userPassword attribute. This is done by an accountActive attribute set to "Y" or "N" which is then used in an ACL filter statement for auth access to the userPassword attribute. This gave us the capability to allow/deny access across the board from a single point.

As time went on we added application based attributes set to "Y" or "N" that would allow a DN to authenticate even though the accountActive attribute was set to "N". This again was accomplished by an ACL filter statement for auth access to the userPassword attribute when the requesting source was known server (DNS) running/hosting that application.

This has worked well for us.

But now we need to be able to authenticate a DN that has the accountActive attribute set to "N". We can't use the above method with an application based attribute in conjunction with a known server so we're looking for an alternative.

Using a privileged admin type DN that is allowed auth access to the userPassword attribute along with an ACL filter statement seems like the way to go. But implementing this technique appears easier said then done.

The original thought was to bind as the privileged admin DN and then do a, for lack of a better term, sub-bind as the users DN in hopes that the original bind as the privileged admin DN would then allow this restricted authentication to succeed. Well, we have not been able to accomplish this for probably one of two reasons. We're either doing something wrong, or it's just not possible.

So anyone out there that knows of a possible way to accomplish this type of authentication or, for those that like a challenge, I like to hear any and all ideas on how to possibily accomplish this.

It's already been purposed and a successful proof of concept was done were we encrypt the users password and then pass it to LDAP doing an ldapcompare and use the results to determine successful/failed authentication but that method was not warmly received, mainly due to having to do it in code. So I guess one of the constraints to accomplish this is to use only established LDAP calls and/or functions, i.e. pass the DN and password without any manipulation of the password.

Thanks for taking the time to read this and considering this.