[unisog] LDAP access for 3rd parties

Oscar Knight knightod at appstate.edu
Wed Feb 13 18:15:45 GMT 2008


Hello Brian,

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 
this issue.

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.

Comments?

Thanks,
odk


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  
> access.
> 
> 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".
>>
>> Comments.
>>
>> Thanks,
>> odk
>> -- 
>> 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
>> https://lists.sans.org/mailman/listinfo/unisog
> 
> 
> 
> 
> 
> 
> _______________________________________________
> unisog mailing list
> unisog at lists.dshield.org
> https://lists.sans.org/mailman/listinfo/unisog


-- 
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 mailing list