Google Connector - existing Google user accounts

Apps & App Center
,
#1

Just setup the G-Suite connector for a client that has a number of user accounts already. The first test user created in UCS sync’d to Google worked just dandy.

None of the existing users were pulled in. I presume this is by design as the goal here is to keep all accounts local to UCS.

This will mean pulling all account info out of G-Suite and importing into UCS. What is that process and best practice when dealing with passwords (I’m presuming there is no mechanism to securely pull passcodes from G-Suite)?

#2

Yes, and because it’s designed as a one-way-sync. No change in google users will be copied to UCS, only from UCS to gsuite.

The only way is to create UCS users and connect them to the existing Google users.
The data (firstname, lastname, email etc) will have to be copied manually - sorry.
I think - and sincerely hope - it’s impossible to extract passwords from Google users. They should keep only hashes, like UCS does. That’s why it’s also impossible to sync passwords from UCS to Google (regardless whether desirable or not).

To “connect” existing Google users to UCS users, you’ll have to retrieve two attributes from the Google user and write its value into the UCS users LDAP object (they can be retrieved from Google using GAM and set in UCS using UDM):

  • Google users id attribute goes into the UCS users univentionGoogleAppsObjectID LDAP attribute.
  • Google users primaryEmail attribute has to be written into the UCS users univentionGoogleAppsPrimaryEmail LDAP attribute.

After doing that and then enabling the gapps support for the user, any change to a mapped attribute of the UCS users object… like the firstname, will trigger a synchronization. You can observe those in the log file /var/log/univention/listener.log.

Greetings
Daniel

#3

I did expect this response, so no need to apologize! I was hoping to learn there was something more than relying on my not-so-reliable (read 'non-existent) ldif/bash skills to pull in a CSV generated list of users + attributes.

Is there a script or tool already available in the UCS suite to handle an import of users?

#4

Not really. If you’re OK with Python or Bash, you can use UDM to create them… there is a thread on how to do this: Bulk add / import / enroll users

1 Like
#5

Nice.

Though this flag popped up in the thread: here, where Gohmann is recommending the S4 connector service be stopped prior to running any scripts for import. It appears the OP was interested in maintaining G\UIDs consistent with SAMBA G\UIDs.

Other than people suffering from an Obsessive Compulsive Disorder, I’m having a hard time understanding why it should matter.

What say you?

#6

The reason why I wanted to keep UIDs was because of the permissions set from the previous OS before converting to UCS and it is not OCD related, please don’t make such flippant remarks. It was a great hassle to have to fix a few thousand mac home folders because of the UID change. Certain folders in Mac OS homes don’t like being tampered with and keeping things “the same” would have been easiest but it didn’t work out that way.

#7

Please don’t be offended. It is meant purely as a tongue-in-cheek comment.

I was serious in wanting to know the motivation behind it specifically to understand what problem you needed to solve in order to avoid what you had to live through with that transition. I have a handful of clients who run Macs (it’s my primary machine too) but not in the thousands of machines as you.

I do appreciate your response.

#8

AFAIR this also works without these attributes cause of mailPrimaryAddress. Except that the password will be overwritten on first sync.

#9

OMG yes - I forgot to mention that!
That might be a blocker for you. The app assumes you will use SAML to log into Gapps.
The advantage of SAML is, that your users passwords will not be known to Google, because they will only authenticate to UCS, and Google will trust you UCS to check their logins.
A possible disadvantage may be, that your master or backup will have to be exposed to the internet, if your users should use the UCS-login when out of office. There are safe solutions for that, but you should be aware of that requirement.
You should definitively test the migration/user-connection part with a test user, before applying it to a production user.

1 Like
#10

I don’t know about the GUID problem. In UCS@school we do something similar (stopping the notifier) to a) improve performance and b) to reduce the situations in which deletions and modification in very quick succession raise the probability of hitting a (in theory non-existent :wink: ) bug in a connector.

#11

:astonished: what bugs? Say it ain’t so!

#12

All software has bugs. There is not a single one without. Of course I could do some marketing talk about that in UCS are non, but that’d be just that: marketing talk.
That’s why I wrote: raise the probability
In the past there has been a bug, when in very quick succession users were created, modified and deleted (aka import). AFAIK it has been fixed, but the the probability is IMHO still higher to hit another bug in such scenarios, than in others.
As there is a simple way to avoid them, it is recommended to use it :slight_smile:

#13

Okay, I’ll stop being snarky!

I activated the connector for three users (already in USC) to start testing.

An interesting issue arose for one of the users (who is also an Administrator in G-Suite) where the redirect to ucs-sso URL was completely bypassed and he landed on https://accounts.google.com. Google recognized a change to the user account password, however, I was unable to get the ucs-sso page to display without manually entering the URL. Once on the ucs-sso, authentication failed for the user.

Ultimately, I had the user update his password directly in the G-Suite login page to match the password on the UCS account - then authenticate through the G-Suite portal to gain access to those resources.

Is this expected behavior for admin users or is there more digging I need to do for this particular user?

#14

Admin users are treated differently in a few other aspects as well. They will for example not be redirected to a change password URL, while normal users are sent there, when they should change their password etc…

Experiences Google Apps for Work Connector
#15

image
Found the following option in 4.4. Is it possible to sync/write the passwords to google now?

Thx a lot,
best,
meg

#16

Hi all,

The topic is already older. I wrote a script to link users which already exist in Google with the UCS.

#!/bin/bash

admin="username"
mail="$1"

LDAPMODIFY="ldapmodify -H ldaps://localhost:7636 -x -D uid=$admin,cn=domain,cn=tld -W"

if [ -z "$mail" ]; then
        echo "mail not set!"
        exit 1
else
        echo "search DN for: $mail"
fi

dn=$(univention-ldapsearch mail="$mail" | grep dn: | awk '{print $2}')
if [ -z "$dn" ]; then
        echo "could not set DN, exit"
        exit 1
else
        echo "DN found: $dn"
fi

id=$(/usr/share/univention-google-apps/print_google_users_and_groups \
        | grep "$mail" | head -n1 | awk '{print $1}')

if [ -z "$id" ]; then
        echo "could not set ID, exit"
        exit 1
else
        echo "ID found: $id"
fi

cat << EOF | $LDAPMODIFY
dn: $dn
changetype: modify
add: univentionGoogleAppsObjectID
univentionGoogleAppsObjectID: $id
EOF

cat << EOF | $LDAPMODIFY
dn: $dn
changetype: modify
add: univentionGoogleAppsPrimaryEmail
univentionGoogleAppsPrimaryEmail: $mail
EOF

cat << EOF | $LDAPMODIFY
dn: $dn
changetype: modify
add: univentionGoogleAppsEnabled
univentionGoogleAppsEnabled: 1
EOF
1 Like
Q&A: Can I Sync Existing Google Users To UCS?
Mastodon