Subdomains with Google Apps and OD

This year we decided to roll both our student and staff domains together in GoogleApps with the aim of making sharing and collaboration between our staff and students easier. Since Google now allows services to be enabled / disabled at the subdomain level as opposed to the domain level, it didn’t make a whole lot of sense to have two domains. While the administration did not entail much overhead, teachers and students sharing documents with each other required entering the full address, including the domain, and this was a bit more work than really was necessary.

The way in which the SAML process works with OD is to check an attribute and password against the LDAP database.  In our case, we used the uid attribute.  This is the same username format students and staff login to the computer.  Once the attribute and password is verified, another attribute is then passed to Google as the GoogleApps username.  Our original configuration was to check uid (rsaeks) against LDAP, then to pass that same attribute to Google Apps.  This works well when the domain structure is flat; that is, when there are no subdomains.

After rolling in our student domain, the problem arose where student accounts did not exist in our parent GoogleApps (staff) domain, and thus, could not login as GoogleApps didn’t do a subdomain search on user accounts.  After doing a bit of digging and playing around, we found out rather than pass uid to Google, we could pass another attribute including the domain.  For this, we went with the LDAP attribute mail.  This was already matching the GoogleApps domain for our staff members (rsaeks@ourstaff.domain).  However, students did not have a value in the mail attribute.  By adding in the value matching our student domain logins (studentname@student.domain) we could now successfully pass to Google the user / domain combination allowing all users to successfully login.

To make this change with simplesamlPHP, the saml20-sp-remote.php configuration file had the ‘simplesaml.nameidattribute’ value changed from uid to mail.  This change is global across the SAML installation for the Google entry in the metadata configuration.

The beauty with a system like this is flexibility to utilize attributes to authenticate the user and attributes to identify the user to Google.  If you don’t wish to use an OpenDirectory attribute, you can modify your LDAP schema to include a custom attribute and value for Google or other services.