[Date Prev][Date Next]
LDAP Authentication method(s)
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
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.