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:
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.
- 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.
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.