Google Apps, Domain and ITS Integration for SSO

I am a very new to the UCS and have downloaded it to start exploring its rich features. We are a private University based in Namibia with 06 campuses spread across the country catering to around 10k students by 250-300 staff members. The IT infrastructure is based on Windows & Linux mixed environment consisting of Sernet-Samba 4 Primary Domain Controller with 05 Read-only DC’s located at each branch, Google Apps for Education which is our E-mail Collaboration platform for Staff and Students, ITS Student Management system which is developed and implemented by a company named Adapt IT based in South Africa it is Red Hat Oracle 10g Linux based database management system with Java forms frontend, apart from this we also have different open-source systems like GLPI, FOG cloning, Proxmox KVM based on debian linux distro.

The purpose for testing UCS is to adopt and implement into our current environment which can be used as a centralised Single Sign On server for our three important IT services i.e. Domain, Google Apps and ITS.

  1. I have already tested Google Apps for Work Integration App for UCS which works fine for users signing in through the web browser but I like to find out how it will work when a user is using a Mail client like MS Outlook for syncing mails from his Google App account.

  2. I like to transfer my current PDC from sernet-samba 4 to the UCS so is there is any license requirements which I have to fulfill to continue or I can keep running the UCS Free Core Edition. Also how I can have a proper domain setup for all my small branches where I currently have sernet samba joined as RODC to the domain where the client PC experiences very slow logins. Can I setup UCS for at all branches and join it as a BDC to improve login performance for branch users. Please help with your advice on the best practices for setting up the domain in my environment.

  3. Currently the ITS systems uses OID ( Oracle Internet Directory) for maintaining user logons for the Staff and Student Portals. Is there any possibility to import all the student records from the oracle database into the UCS Ldap or UCS@School and run a sync script to fetch the Passwords from the ITS into the UCS at a regular interval. I am currently running a php script which imports all the students password from the oracle and update the freeradius mysql database which is used for wireless authentication. I like to have a single sign on for the students who can use their ITS PIN for ITS portal, Google Apps account and the Wireless Authentication. How can we make it happen?

  4. I like the UCS Interface which I definitely want to use in my environment. How I can add an option in Self service portal to retrieve the current password for the user to be sent as a text on the given cellphone number.

I am looking forward for a solutions to my queries above importantly for integration of Domain, ITS and Google Apps.



I have to admit that I haven’t used Google Apps with UCS yet. However, the single sign-on mechanism uses SAML where one place (Google Apps) delegates authentication (the act of verifying that a certain user account really has a certain password) to another place (UCS in this case). The point is that Google Apps never has access to the user’s password.

Traditional mail clients like Thunderbird, Outlook etc. all still use the traditional authentication mechanism of username + password or other local mechanisms such as Kerberos. They don’t support delegation schemes such as OAuth or SAML, and a quick search didn’t turn up anything either.

However, there do seem to be third-party products available that claim to support Thunderbird & Outlook with Google Apps and single sign-on mechanisms. I have no idea whether this is the right tool for the job, but you may want to take a look anyway.

The scenario of branch offices (to be more precise: of locations with a slow/unstable network connection to the UCS DC Master server) is exactly what the UCS server role “DC Slave” is meant for. A UCS DC Slave contains its own LDAP server which is synchronized with the DC Master (the Master pushes all changes towards the Slave). Additionally you usually install the Samba 4 role on the same DC Slave. Last you create an ActiveDirectory Site with the usual tools from Microsoft and move the UCS DC Slave there. That Samba 4 AD DC is usually a normal DC, not a RODC.

I don’t know of a solution ready to use for such a situation, but UCS itself (not just UCS@school) contains powerful command line tools that allow you to create, modify and delete all the objects you can also create, modify and delete from the web-based UI (the UMC, Univention Management Console). That tool is called the Univention Directory Management program (command line: “udm”). Its built-in documentation is usually enough to get you started.

I’ve often used this tool together with a handful of self-written shell and Perl scripts for moving accounts from old systems to a UCS system.

Synchronizing passwords is a rather difficult task. The problem is that the UCS LDAP directory contains three separate fields the password that contain the password hashed in different ways (“userPassword” for use with LDAP authentication, “sambaNTPassword” for the old NT-style SMB authentication and “krb5Key” for Kerberos authentication). All three fields have to be changed at the same time, otherwise users will encounter difficulties logging in with different methods.

If you have access to the plain-text (unhashed) password you can simply use the aforementioned “udm” tool for setting the three password fields in one go. However, if all you have is access to an already hashed version of the password you’ll probably be out of luck.

Another possibility would be to revert the direction of changes to “when the password changes in UCS then update the OID, too”. I’m not entirely sure how to do that, but there are two mechanisms one could look into:

[ol][li]UCS has a “notifier” component called “Univention directory notifier” with corresponding “listeners” (the one “notifier” on the DC Master sends notifications to all the “listener” components running on all UCS servers). The “listeners” in turn execute Python modules whenever certain LDAP objects change. This mechanism is widely used for populating other daemons with user information from the LDAP. If these modules are also executed when the password is changed then one could write a Python module that executes the required updates against the OID, too.[/li]
[li]The Linux PAM system (pluggable authentication mechanisms) is also involved in password changes. If the aforementioned notifier/listener mechanism doesn’t have access to the plain-text password then the PAM mechanism should. Writing a PAM module isn’t that hard either and can be done in Python, too, if I’m not mistaken. This might be an alternative.[/li][/ol]

All of these methods are quite complex and time-consuming to set up. But they are options.

I haven’t done this myself yet (I’ve only used the email-based method). But here’s a blog post from Univention themselves that describes sending tokens via SMS.

Kind regards,