I'm learning and testing different ways of configure my LDAP to handle multiple apps. I gave up on groupofnames because I couldn't get searches to pull out the Users in a Group. I have probably 6 or so apps that will use the LDAP. I am leaning towards a simple structure, where each app has it's own branch in the LDAP. My reasoning is: it's easy to configure, may make ACL's easier to setup and manage, it will make searches easier to setup and test, and...why not...after all this isn't a database and duplicated "people" records don't matter. We may end up with 2 synching LDAPS, one for our network and email, and the other for our other apps, simply because the email system requires a very specific structure.
Just curious to hear from the more experienced what they do in their structure to handle multiple apps, and how sound my thinking is.
On 29-9-2011 2:26, criderkevin@aol.com wrote:
I'm learning and testing different ways of configure my LDAP to handle multiple apps. I gave up on groupofnames because I couldn't get searches to pull out the Users in a Group. I have probably 6 or so apps that will use the LDAP. I am leaning towards a simple structure, where each app has it's own branch in the LDAP. My reasoning is: it's easy to configure, may make ACL's easier to setup and manage, it will make searches easier to setup and test, and...why not...after all this isn't a database and duplicated "people" records don't matter. We may end up with 2 synching LDAPS, one for our network and email, and the other for our other apps, simply because the email system requires a very specific structure.
Just curious to hear from the more experienced what they do in their structure to handle multiple apps, and how sound my thinking is.
To have the same user listed more than once, just because he uses more apps, is against all my believes (and against any directory's as well, I guess): what happens if a user wanted to change their password?
Right now I'm using LDAP for routing inbound email, IMAP authentication, logon on my unix systems and authentication in web apps.
And all of them use the same userID.
Having users duplicated is a problem for password reset, as someone has just pointed out to me...so then how do you setup your LDAP to allow access to one application and not others?
Say I want to allow a user access to Email but not Network...how is your LDAP setup to handle this? Maybe a bad example...I suppose you'd do this with the deliviered schemas...OK but what about access to Email ON and access to a homegrown app OFF? Perhaps using an attribute from a custom schema?
-----Original Message----- From: criderkevin criderkevin@aol.com To: openldap-technical openldap-technical@openldap.org Sent: Wed, Sep 28, 2011 8:44 pm Subject: How do you have LDAP Setup for Apps
I'm learning and testing different ways of configure my LDAP to handle multiple apps. I gave up on groupofnames because I couldn't get searches to pull out the Users in a Group. I have probably 6 or so apps that will use the LDAP. I am leaning towards a simple structure, where each app has it's own branch in the LDAP. My reasoning is: it's easy to configure, may make ACL's easier to setup and manage, it will make searches easier to setup and test, and...why not...after all this isn't a database and duplicated "people" records don't matter. We may end up with 2 synching LDAPS, one for our network and email, and the other for our other apps, simply because the email system requires a very specific structure.
Just curious to hear from the more experienced what they do in their structure to handle multiple apps, and how sound my thinking is.
On 29/09/11 09:46 -0400, criderkevin@aol.com wrote:
Having users duplicated is a problem for password reset, as someone has just pointed out to me...so then how do you setup your LDAP to allow access to one application and not others?
Say I want to allow a user access to Email but not Network...how is your LDAP setup to handle this? Maybe a bad example...I suppose you'd do this with the deliviered schemas...OK but what about access to Email ON and access to a homegrown app OFF? Perhaps using an attribute from a custom schema?
In my experience, authorization is not at all consistent across devices and applications. Those that are LDAP aware usually provide an LDAP filter as one component, in which case you can typically do:
(&(uid=$1)(someAccessAttr=email))
Some devices/applications provide for RADIUS authentication, which you can backend with LDAP to authenticate based on group membership, or the existence of a specific attribute.
Another approach is to configure your applications to use PAM authentication, and then make use of an ldap pam module.
On Thursday, 29 September 2011 02:26:07 criderkevin@aol.com wrote:
I'm learning and testing different ways of configure my LDAP to handle multiple apps. I gave up on groupofnames because I couldn't get searches to pull out the Users in a Group.
Then it seems your applications are brain-dead.
Almost all applications supporting LDAP authentication support LDAP authorization, with multiple models for retrieving group information and memberships. Most of them support all of the following: 1)groupOfNames-type groups 2)posixGroup-type groups 3)members indicated by memberOf attributes
In case the application only supports the last one (typical of applications written for a specific LDAP server implementation, not for any standards- compliant LDAP server implementation), OpenLDAP has the slapo-memberof module, whcih can make (1) look like (3).
I have probably 6 or so apps that will use the LDAP. I am leaning towards a simple structure, where each app has it's own branch in the LDAP.
Don't.
My reasoning is: it's easy to configure,
But impossible to maintain / scale.
may make ACL's easier to setup and manage, it will make searches easier to setup and test, and...why not...after all this isn't a database and duplicated "people" records don't matter.
They do, and there are no solutions to all the problems that this introduces that are supported any better by applications that can't figure out group memberships.
We may end up with 2 synching LDAPS, one for our network and email, and the other for our other apps, simply because the email system requires a very specific structure.
Ouch.
Just curious to hear from the more experienced what they do in their structure to handle multiple apps, and how sound my thinking is.
At work, we have LDAP-based authorization for at least the following applications/tools, all using single accounts and single groups:
RADIUS (for EAP-PEAP and IPSEC-based VPN) Apache (web apps, subversion etc.) Squid Samba PAM / OpenSSH (with LPK patch) MediaWiki Bugzilla Tomcat
(I am sure there are a few more, but I'm too lazy to look in the wiki)
Regards, Buchan
On Thu, Sep 29, 2011 at 11:46 AM, Buchan Milne bgmilne@staff.telkomsa.net wrote:
On Thursday, 29 September 2011 02:26:07 criderkevin@aol.com wrote:
I'm learning and testing different ways of configure my LDAP to handle multiple apps. I gave up on groupofnames because I couldn't get searches to pull out the Users in a Group.
Then it seems your applications are brain-dead.
Almost all applications supporting LDAP authentication support LDAP authorization, with multiple models for retrieving group information and memberships. Most of them support all of the following: 1)groupOfNames-type groups 2)posixGroup-type groups 3)members indicated by memberOf attributes
We have application that even use the position of an element within the DIT for Authorization (e.g. user X is in department Y, or reports Z) We also use other attributes like user is external or internal. I mean, just in the regular schemas there are so many attributes ! any of these can be used for Authorization.
You can also create your own custom auxiliary objectClass that you can use as an addition filter.
for example:
objectClass ( your_custom_OID_here NAME ‘yourcustomPerson' DESC ‘My Custom User INFO' SUP top AUXILIARY MUST ( customUserPriv $ customAuthApp1 $ customStaffMember $ customRemoteAccess $ customEnabled ) MAY ( ) )
then you would need to define your custom attributeTypes and load the whole thing into LDAP.
The custom attribute types can then be used as an addition filter.
Scott
On Sep 29, 2011, at 9:38 AM, Alejandro Imass wrote:
On Thu, Sep 29, 2011 at 11:46 AM, Buchan Milne bgmilne@staff.telkomsa.net wrote:
On Thursday, 29 September 2011 02:26:07 criderkevin@aol.com wrote:
I'm learning and testing different ways of configure my LDAP to handle multiple apps. I gave up on groupofnames because I couldn't get searches to pull out the Users in a Group.
Then it seems your applications are brain-dead.
Almost all applications supporting LDAP authentication support LDAP authorization, with multiple models for retrieving group information and memberships. Most of them support all of the following: 1)groupOfNames-type groups 2)posixGroup-type groups 3)members indicated by memberOf attributes
We have application that even use the position of an element within the DIT for Authorization (e.g. user X is in department Y, or reports Z) We also use other attributes like user is external or internal. I mean, just in the regular schemas there are so many attributes ! any of these can be used for Authorization.
-- Alejandro Imass
openldap-technical@openldap.org
-
Alejandro Imass -
Buchan Milne -
criderkevin＠aol.com -
Dan White -
Peter Boosten -
Scott Classen