Become Part of our Team and Push Digital Sovereignty
- Teamleader IT / Project Manager (m/f/x)
- IT Consultant (m/f/x)
- Outbound Sales Represantative (m/f/x)
In this article, I would like to describe the installation and use of our new Google Apps for Work connector. In parallel we have also published a new connector for Microsoft Office 365, but I will be describing its installation in a separate blog article.
The integration of Google Apps for Work in UCS saves administrators the time-consuming creation of user accounts in the Google administration interface: They now simply need to place a check in the UMC, and a Google account is created and ready for use. This is also convenient for users, as they only need to remember one password. Thanks to the single sign-on (SSO) mechanism, you can log in to UCS locally and can work on the cloud immediately – your password never leaves the company.
For it to be possible for UCS to create Google accounts in the background without the intervention of an administrator, a secure connection to Google’s cloud needs to be configured. Luckily, there is a wizard to guide you through the whole process, which isn’t exactly straightforward.
If the configuration is successful, you can select the users for which you want to create Google accounts in the Univention Management Console (UMC).
As of this point, selected account attributes from the UCS accounts are synchronized to the accounts on Google’s cloud. The attributes to be synchronized (first name, surname, telephone number, etc.) can be configured via UCR. It is not only possible to configurable which attributes are synchronized, but also whether the values are anonymized, set statically to a certain value, or should be copied correctly.
The use of the Google Apps for Work connector requires a Google Apps for Work administrator account and a domain verified by Google.
A free Google Apps for Work account can be created for test purposes. However, the configuration of the SSO requires an individual Internet domain in which TXT records can be created.
If you still don’t have a Google Apps for Work account, go to https://apps.google.com/intx/en/setup-hub/ and click on “Start your free trial”. It is not possible to establish a connection to UCS with a private Gmail account.
You can see whether the ownership of your domain has been verified by Google by logging in to the Admin console and checking under “Domains” (click on “More Widgets”) and then “Add or Remove Domains”.
If not, you can add and verify your own domain here. To do so, it will be necessary to create a TXT record for your domain in the DNS. The procedure can take a little while.
If it is successful, you can install the app in the App Center and start the wizard.
The connector is ready for use as soon as the wizard has completed successfully. If Google Apps for Work is enabled for a UCS user account, a Google account is created automatically. You can view the user in the Google Admin console. It is only completely enabled the first time you sign in.
UCS users can now enjoy the ease of SSO – and there are two ways to do so: The username to be entered for the login on a Google login page is visible for enabled UCS users in the “Google Apps” tab. Once you’ve entered the username, you are forwarded on to the UCS single sign-on page.
The users log in there with their UCS access data and are returned to Google, where they can continue working directly. The user password is thus not provided to Google. The quickest, most reliable and simplest way is to allow your users to start on the overview page of your UCS server.
From there, they can access the UCS single sign-on page with a mere click of the mouse and thus avoid having to input their username twice.
The connector only works in one direction: Users are synchronized from UCS to the Google directory. Changes to users which are made in the Admin console can be overwritten with changes to the same attributes in UCS and therefore by the connector under certain circumstances.
Corresponding accounts are created in the Google directory for the UCS user accounts for which Google Apps for Work is enabled and selected account attributes synchronized with them. The synchronized information can be configured with the help of various UCR variables.
The UCR variables google-apps/attributes/mapping/.* are used to configure which LDAP attributes (e.g., first name, surname, etc.) of a user account are synchronized. The UCR variables and their values reflect the encapsulated data structure of the Google user accounts. The names following the ‘%’ in the values are the attributes in the UCS LDAP. Remove any UCR variables of attributes that you do not want to synchronize. If you remove all the UCR variables google-apps/attributes/mapping/.*, no data is synchronized apart from the primary e-mail address.
Changes to the UCR variables are only implemented the next time the listener is restarted: invoke-rc.d univention-directory-listener restart
The UCR variables google-apps/attributes/anonymize can be used to enter LDAP attributes separated by commas, which are saved for Google but completed with random values. If the percent sign is omitted in a value in google-apps/attributes/mapping/.*, the value following the equal sign is entered directly on the Google page. This makes it possible to complete attributes with predefined values for all users.
The UCR variables google-apps/attributes/never can be used to enter LDAP attributes separated by commas, which should never be synchronized even if they appear in google-apps/attributes/mapping or google-apps/attributes/anonymize.
You can enable the UCR variable google-apps/groups/sync to synchronize the groups of the user enabled for Google Apps for Work. If you experience any difficulties, the log file may be helpful. Enabling of the UCR variables google-apps/debug/werror elevates debug tasks to the “Error” class and records them in /var/log/univention/listener.log.
Daniel Tröder is Open Source Software Engineer. Currently, he is intensively taking care of the further development of the UCS mail stack.
This is really nice, however is there a way to flag groups that you don’t want copied to Google?
Eg, you might have a group for office / vpn, or a group for proxy1 / proxy2, and you don’t want all those groups to be on Google. However some groups it’s really useful that it synchronizes.Reply
I have created a feature request for ignoring a configurable list of groups: http://forge.univention.org/bugzilla/show_bug.cgi?id=45995
Thanks. I think that would be really helpful and make this become a truly useful tool, rather than one that feels useful but has quite annoying side affects. Just a flag on each group, like you do on each user would be great.
Keep up the good work, and thanks for the swift response,
Thanks for the amazing feature. I noticed that the passwords of the accounts created through UCS don’t get synced to G suite and one has to goto admin page to reset the password.
I investigated and there is no password attributes mapped for google-apps among the UCR variables. Is that done because of safety purposes? Is there a way to have all the passwords synced as well? Thx.Reply
There are two reasons:
One is security: the users password does not need to be synced to Google for a user to authenticate. Using SAML, Google refers the authentication to the UCS server. This also allows for single sign on.
The other reason is that the password _cannot_ be synced, because the UCS system doesn’t know it. It stored only hashes of passwords – never the cleartext password itself.
You can of cause deactivate SSO in the Google admin console and manually set the passwords on Google user accounts that have already been synchronized.
There are forum threads regarding such use cases: https://help.univention.com/tags/google-apps-for-workReply
Thanks for the info. Indeed, it makes sense.
email id sync not happening from LDAP server on google g-suite pls help me out we are going to seme step but facing sync issue.Reply