Is it possible?
If yes, how?
Thanks a lot,
Meg
Hello Meg,
yes and no: the gapps/o365 user accounts are fully functional, and the SSO configuration can be disabled. But they have a random password is set.
The users password in UCS is not known to the system, so it cannot be synced. So in its current state, the gapps/o365 admin will have to set a new password on the gapps/o365 user account. After doing that, the account can be used like a regular gapps/o365 account.
Greetings
Daniel
1 Like
Thanks a lot.
But afaik the config wizard has no possibility to end without sso setup. And even when disabling the sso at google site, the synced users where redirected to the ucs-sso when try to change there password on google.
Also some users get forwarded to the ucs-sso when try to change their passwords at google.
Is there a way to switch off sso at ucs side?
Not yet tried o365, cause it needs an inbound connection to the ucs system, right?
Thank again,
best,
meg
That shouldn’t happen. Setup SSO with third party identity provider has to be disabled in the Google Admin Console (https://admin.google.com/AdminHome?pli=1&fral=1&chromeless=1#SecuritySettings:flyout=sso). 
I just tested it. I can then login and change password of a new user.
Maybe wait a few minutes/hours for the Google directory to catch up with the configuration change?
Both connectors do not need a connection from the internet to UCS.
SSO needs a connection from the client to the master though (can be through a proxy).
Greetings
Daniel
Yep, was done.
That happens more than 14 days later. But not on every user. Didn’t know, why this happens on that user.
That sounds very good. So in that case, could you check Thread Klicken Sie auf ENDPUNKTE ANZEIGEN und kopieren Sie den Wert VERBUNDMETADATENDOKUMENT?
Thanks a lot,
best,
Meg
Hmm… if it works for some, but not all users - could you send a query to the Google support and ask them why those users behave differently?
I have replied there.
Greetings
Daniel
It feels that this happens on some but not all accounts which are in sync with ucs (created via ucs).
SSO is disabled:
UCS 4.2-3, Gapps for work 1.4
Is this fixed in actual builds? (at least for google?)
Have now upgraded to 4.3-1 with gapps 2.2.
Thanks a lot,
best,
meg
No, because in the way the connector apps work, this is not a bug. The use case is, that the userpassword never leaves the UCS system, and Single sign-on is used to authenticate users against UCS.
so when I’m enabled google for an already existing user the password will be overwritten with a random password. Didn’t get why this is necessary. (sure, its a feature, but for me one, which creates more work than solving one)
Setting a password is necessary because google requires a password attribute value to be set when a user is created.
I had a quick glance at the code. You may be successful by blacklisting the password attribute from being synced. It should be filtered out from the attributes that will be synced to google. Try appending ‘password’ to the attribute list of UCR google-apps/attributes/never. This has the drawback that you will be able to only manage existing users in the google directory. You will not be able to create new users via UCS, because google will not allow users to be created without a password.
1 Like
Thanks for that suggestion.
So at the end, the best would be to alter the code and remove the password in the upgrade procedure and leave it in the create?
That is the general idea. I am not sure how easily the current code can be adapted for that scenario.
1 Like
We’ve still had this bug.
UCS 4.3-1
Gapps 2.3
Didn’t get any support from google 
Redirecting users to change passwords happens on Googles interface, though. Make sure SSO is deactivated for the company account. Maybe it helps to delete the “Change password URL” in the single sign on settings in the G-Suite admin console.
So disable the sync of password, sync all existing users, reenable it would be the way? Did such attribute also exist for o365?
But which attribute will be synced? Tried password and userPassword … both didn’t work.
Could the following solution also applies to users:
?
Just adding The ObjectID and PrimaryEmail?