LDAP Authentication method(s)

[Curt Blank <curt@uwm.edu>]

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.

--
Curt Blank