[unisog] LDAP access for 3rd parties
knightod at appstate.edu
Wed Feb 13 18:15:45 GMT 2008
Thanks for replying.
I'm talking about just the ability to do a bind, ie to authenticate.
The username and raw password are required to do the bind. My issue
is the fact that the 3rd party has the raw password.
Password consolidation is the current rage. Our users have one password
that gets them access to state and federally protected information as
well as other information. Does it make sense for our users to enter
their password on an external server for which our institution has
absolutely no control and no checks or audits?
All it would take is a line or two of code at the 3rd party site to
store the username/password. I'm not accusing 3rd parties of
intentional malice, just pointing out the risk.
Here's a scenario:
There is a unauthorized access of protected information at the
institutional site. An investigation reveals that the user
changed their password then accessed institutional resources
and a 3rd party site. The compromise came hours later. Further
investigation does not reveal any problems at the institution.
How do you proceed, ie how do you investigate the 3rd party?
I understand business must take place. There are other solutions to
I really want to know if I'm off my rocker for thinking there is
problem with allowing 3rd parties to use ldap for authentication, ie
where they have access to the raw password.
Brian Friday wrote:
> Hello Oscar,
> I would be surprised if anyone gives full read access to their ldap
> tree to any vendors. You are correct that would be a huge security
> breach and would possibly allow raw access to the password attribute
> (depending on your LDAP systems acls in place).
> Every external vendor I have worked with takes the password supplied
> by the "user", connects to the authentication source (via ldaps) and
> at the simplest level requests an authenticated bind using the
> credentials supplied. If the bind fails the credentials supplied are
> incorrect, success means they are correct and the 3rd party continues
> to do what they want to do.
> Before refusing the 3rd party vendor's request out of hand it sounds
> like you need more information on exactly what they are wanting to do
> and what access level they require. Look at your LDAP application and
> see what you need to do to protect any/all attributes you consider
> private and then test it throughly internally before allowing them
> Overall I would argue that doing this (pending the acls used on your
> ldap tree to protect attributes) is no less secure than a user
> initiated IMAP, POP3, or SMTP Auth session.
> My 2c, hope that helps.
> Brian Friday
> Manager, La Sierra University's IT: Infrastructure Department
> Tel: (951) 785-2900 / Fax: (951) 785-2908
> Riverside, CA 92515
> On Feb 13, 2008, at 3:37 AM, Oscar Knight wrote:
>> Hello Everyone,
>> If you give a 3rd party access to your ldap for the purpose of
>> authenticating your users then they have access to your user's raw
>> password. To me this is a serious general controls issue.
>> We have other methods but are getting complaints from users that want
>> 3rd party applications and their vendor only seems to know ldap. In
>> part I'm getting a lot of "well, site A, site B,... are all
>> allowing us
>> to use their ldap service".
>> Oscar D. Knight knightod at appstate dot edu
>> ITS Voice: 828-262-6946
>> Appalachian State University, Boone, NC 28608 FAX: 828-262-2236
>> unisog mailing list
>> unisog at lists.dshield.org
> unisog mailing list
> unisog at lists.dshield.org
Oscar D. Knight knightod at appstate dot edu
ITS Voice: 828-262-6946
Appalachian State University, Boone, NC 28608 FAX: 828-262-2236
More information about the unisog