Entries tagged [ldap]

Sunday January 01, 2017

blogs.a.o moved, upgraded and improved

Hi All,

blogs.apache.org   - the site you are reading now! has had a bit of an update.

1. We moved it from an aged VM Host to the Cloud (thanks LeaseWeb!)

2. We puppetised the entire service, from install to deploy (see our Github Mirror )

3. We upgraded the Apache Roller software from 5.0.3 to the latest 5.1.2

4. We enabled LDAP for logins. That's right! Every single ASF Committer can now just login! No more creating an INFRA Jira ticket just to get a Roller account on blogs.apache.org

Other stuff remains the same - meaning if you are a Blog Administrator you still need to invite committers into your blog, you still need to choose to make them an Author or Admin etc - Roller doesnt support anything more than login auth for LDAP currently - but I bet the project would love to see the LDAP integration extended and improved if you feel the need!.

Anyhow, our first new year present to our ASF Committers, a shiny updated blog instance,

 Enjoy, and have a great 2017!!


Thursday February 24, 2011

Changes to email service for all committers

In the near future the Infrastructure team will be implementing a change to the way we handle emails for all committers.

Historically we have allowed users to choose how to handle their apache.org email. However we will be making the following changes:

  1. Making LDAP authoritative for all mail forwarding addresses.
  2. Users will no longer be allowed to store their apache.org email locally on people.apache.org (minotaur)
  3. The Infra team will take the mail address currently held in either your .qmail or .forward file (.qmail is authoritative if they both exist) and inject this into LDAP
  4. We will no longer allow users to configure mail filtering, but you can configure your SpamAssassin threshold as per our recent blog post.
  5. We will make committers ~/.forward and ~/.qmail files read-only, there will still be at least one of these files, but it will be owned by the mail daemon user.

This means that all committers will be required to forward their apache.org email to an email address outside of the foundation.

We are doing this to simplify the email infrastructure, and to help reduce the current level of complexity of maintaining people.apache.org. Also, making LDAP authoritative means we can move some of the work straight out to the MXs, and thus avoid sending it through several mail servers. In the new architecture if someone emails you directly at your apache.org mail address it will only be handled by one apache.org MX.

Of course, we wont delete any email you currently have on people.apache.org. Should you want to edit your LDAP record you should use https://id.apache.org to do this.

Friday January 14, 2011

https://id.apache.org -- New Password Service

Folks,

The infrastructure team are pleased to announce the availability of id.apache.org the new password management tool for all ASF committers and members. This new service will allow users to:

  1. Reset forgotten LDAP passwords themselves, no need to contact the Infra team anymore.
  2. The ability to change their LDAP password.
  3. The ability to update your LDAP record, i.e. change forename, surname or mail attributes. [1].
Users should note that this service will only allow you to manage your LDAP password, thus controlling access to those resources currently protected by LDAP authnz.

Once logged in you will note that some fields are not editable, this is by design and are there merely to show you your LDAP entry. You are currently only allowed to edit your Surname, Given name (Forename), and Mail attributes. This list may be extended as we make more features available, and they will be announced as and when.

Users of this service should note that we have a few small bugs to iron out, and this will be done as soon as possible. For example if you attempt to modify your details and do no re-enter your password you will currently see a generic HTTP 500 error.

Thanks must go to Ian Boston (ieb), and Daniel Shahaf (danielsh) for making this work. Ian provided the initial code (his first ever attempt at Python too). Daniel then took it and implemented several changes and generally improved the backend.

[1] - It should be noted that updating your mail record in LDAP will not currently have any affect on where your apache.org email is forwarded on too. This is planned to take place later this year.

Friday December 17, 2010

LDAP and password policy

As of approximately 03:00 (UTC) today the infrastructure team have enabled a password policy for all LDAP accounts.
This policy has been implemented at the LDAP infrastructure level and will affect all users. It has been deployed using OpenLDAP's password policy schema, and overlay.

At the time of launch we will be enforcing the following policy.

  • At the time of a given users 10th successive login failure the account will be locked.
  • The account will then be automatically unlocked 24 hours later, or until a member of root@ unlocks it for you.
  • If the user successfully completes a login before the tally reaches 10, the counter for failed logins is reset back to 0.

We are enabling this to try and prevent any brute force attempt at guessing passwords. It will also highlight potential issues with accounts.

As with all account related queries, you should be contacting root@ - We will be able to unlock your account for you, allowing you to gain access.

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  

Thursday March 26, 2009

LDAP - It's getting closer

As of this afternoon whilst at ApacheCon Europe 2009, we have gotten our initial LDAP platform in place ready for testing.  This will allow us to move to a centralized AAA system. 

Calendar

Search

Hot Blogs (today's hits)

Tag Cloud

Categories

Feeds

Links

Navigation