Hi Andrew (and the rest of the group!)

Perhaps it might help if I explained what I was trying to accomplish then, if I've made any mistakes in my thinking, they can be corrected :-).

What I want to do is use the LDAP store for two purposes: Linux authentication and syncing with Google Apps for profile/group information and SSO. To that end, and specifically focussing on groups, I need a group in LDAP to serve two purposes: to act as a security group (i.e. it needs a gidNumber and be a posixGroup so that Linux will use it for group membership and ACLs) and to act as an email group (at a minimum have a list of members, an owner, a description and an email address).

In my approach to the choice of classes to use here, I find myself being somewhat constrained by the tools I want to use. Atlassian Crowd is being used as the means of providing Google SSO and OpenID functionality. When it comes to groups, Crowd "prefers" groupOfNames or groupOfUniqueNames. Although I can reconfigure Crowd to "see" posixGroup entries instead of groupOfUniqueNames entries, it doesn't see the members, presumably because they are UIDs and not DNs.

I'm also using LDAP Account Manager as the primary tool to allow administrators and staff manage information stored in LDAP. For group management, it supports both posixGroup and groupOfUniqueNames.

I can, in theory at least, add extensibleObject to the groups defined as posixGroup so that I can then add description, displayName, mail and owner. That gives me a different problem when it comes to syncing the groups up to Google, though, because it also (like Crowd) seems to be expecting attribute values for members to be DNs.

So, I'm open to suggestions here. I thought I had a fairly straightforward requirement but the LDAP world doesn't seem to have anything that meets the requirement.

Thanks for any feedback.

Philip



On 9 January 2013 18:36, Andrew Findlay <andrew.findlay@skills-1st.co.uk> wrote:
On Wed, Jan 09, 2013 at 04:21:43PM +0000, Philip Colmer wrote:

> I'm using OpenLDAP on Ubuntu 12.04. The installation of OpenLDAP automatically
> installs the schemas for core, cosine, nis and inetorgperson.
>
> In the nis schema, posixGroup is defined as structural but I need it to be
> auxiliary.

It is a very very bad idea to change the definitions of
standard types. There may be code out there that will break in
interesting and unpredictable ways. I would agree that many of
the standard types seem a bit haphazard these days, but they
are still standard...

Why do you 'need it to be auxiliary'?

Would it be better to say that you want to make some entries
that have gidNumber and memberUid and some other attributes
that are not in the posixGroup list? If so, why not define your
own auxiliary class that allows you to add the other attributes
to a posixGroup entry?

If you really cannot add a new aux class to the entries
concerned, you could consider using a DIT Content Rule to
permit more attributes. This would be standards-conformant, but
unfortunately many LDAP browsers don't understand it so editing
such entries could be a bit awkward.

Andrew
--
-----------------------------------------------------------------------
|                 From Andrew Findlay, Skills 1st Ltd                 |
| Consultant in large-scale systems, networks, and directory services |
|     http://www.skills-1st.co.uk/                +44 1628 782565     |
-----------------------------------------------------------------------