Entries tagged [services]

Monday February 22, 2010

The ASF LDAP system

When we decided some time ago to start using LDAP for auth{n,z} we had to come up with a sane structure, this is what we have thus far. 

 dc=apache,dc=org
      | ---  ou=people,dc=apache,dc=org
      | ---  ou=groups,dc=apache,dc=org
           | ---  ou=people,ou=groups,dc=apache,dc=org
           | ---  ou=committees,ou=groups,dc=apache,dc=org

 As well as other OUs that contain infrastructure related objects.

So with "dc=apache,dc=org" being our basedn, we decided we needed to keep the structure as simple as possible and placed the following objects in the respective OUs:

  • User accounts -  "ou=groups,dc=apache,dc=org"
  • POSIX groups - "ou=groups,dc=apache,dc=org"
  • User Groups  - "ou=people,ou=groups,dc=apache,dc=org"
  • PMC/Committee groups - "ou=committees,ou=groups,dc=apache,dc=org"
Access to the LDAP infrastructure is connection limited to hosts within our co-location sites.  This is essentially to help prevent unauthorised data leaving our network. 

LDAP, groups and SVN - Coupled together

The infrastructure team have now completed the next stage of the planned LDAP migration.
We have migrated our old SVN authorisation file, and POSIX groups into LDAP data.  SVN access control is now managed using these groups.

This means to change access the Subversion repositories is now as simple as changing group membership. We use some custom perl scripts that build the equivalent authorisation file meaning that we dont need to use the <location> blocks nasty hack to do this.  It also means that all changes, including adding new groups and extending access control is made simple.

ASF PMC chairs, are now able to make changes to their POSIX, and SVN groups whilst logged into people.apache.org - using a selection of scripts:

  • /usr/local/bin/list_unix_groups.pl
  • /usr/local/bin/list_committees.pl
  • /usr/local/bin/modify_unix_groups.pl
  • /usr/local/bin/modify_committees.pl

All of these scripts have a '--help' option to show you how to use them.

What's next?  We are now working on adding a custom ASF LDAP schema, that will allow us to record ASF specific data such as ICLA files and date of membership etc.
We will also be looking at adding support for 3rd party applications such as Hudson, and building an identity management portal where people can manage their own account.

Thursday May 21, 2009

It's official, we now have LDAP running!

Earlier this week the Infrastructure team rolled out phase one of the planned LDAP services.  

We are using LDAP for authentication of shell accounts.  For now this is the extent of the implementation, however the next phase should follow this quite quickly.

The next phase will involve moving to LDAP to manage access to our subversion repositories. This is a slightly more complicated migration as we currently use an SVNAuthz file, that contains the appropriate groups and their memberships.  We are currently working on a new template system where by changes to LDAP will trigger a build of the SVNAuthz file based on groups in LDAP.  This means we must watch LDAP changes, work on a template system, and if a new version of the template is checked into Subversion we need to trigger a build again.  This is a work in progress at the moment. 

If you find yourself in the position of needing to change your shell account password you can do it by doing this on the command line "ldappasswd -W -S -A -D uid=availid,ou=people,dc=apache,dc=org"  -- Where availid is your ASF username.   For example  "ldappasswd -W -S -A -D uid=pctony,ou=people,dc=apache,dc=org".  This is far from an elegant solution, but for now it works.  You will be required to enter and confirm your current password, and then enter and confirm your new password choice, followed by your LDAP password (this is your old password) .

We are working on a web portal that will allow users to edit attributes, such as forwarding address, password, etc.  This will be made available as soon as it is ready.  If you don't know your current password, then you will need to email  root@ as per usual. 

You can follow the trials and tribulations of the rollout on my personal blog  

Calendar

Search

Hot Blogs (today's hits)

Tag Cloud

Categories

Feeds

Links

Navigation