Ateeb,

We have the same issue and have not found an elegant solution to this. Though, I still hope that there is one. This is the single biggest drawback to SAML SSO and not something that you realize until you are well on your way implementing. It works great for the 95% of the cases where it's a 1:1 relationship between Okta and G-Suite. But for shared resources with multiple team members it's a royal pain.

Also problematic, getting access to a former employee's account which takes a lot of effort. If a manager wants to sign into the former employee's G-Suite account, now they have to manage multiple Okta accounts. That typically means either using incognito or private browsing for one or using separate browsers to maintain separate sessions. It get's pretty confusing for the end user.

The best I have come up with, and these are far from perfect....

1) If I need to set up a forward in the user's G-Suite account, make that account a super user temporarily. G-Suite will always let a super user sign in directly. Just don't forget to set it back.

2) Temporarily turn off the SAML requirement in the G-Suite security admin area. Then sign into the user account and set up the forward. Again, don't forget to turn it back on.

So things work amazingly wonderfully well for the routine case. The syncing off accounts is really fast and reliable for instance. But if you are sharing resources or off boarding team members regularly, there is some overhead. I really hope that the community has better solutions than I have provided above.

Good Luck!

pew

Hello Ateeb,

Thanks for posting your inquiry in Okta Community Portal.

If you really liked your answer, please help readers find it by marking it the best answer. Hover over the answer and click "Best Answer." 

Thank you,

Mike Davie

We ran into the same issue and have found a work around, although it is not an elegant solution. We created a secondary G Suite organization that is not SAML enabled. We then create matching mailboxes (same name) in the secondary domain. We then forward all messages from the individual shared mailbox in the primary domain to the secondary domain. We then use SWA to retrieve the messages from the shared mailbox in the secondary domain. This allows end users to email the mailbox using the primary domain but 3rd party resources that need to log in with username/password can retrieve the messages.

I ran into this problem recently and wanted to share a couple things I learned that will hopefully help others.

• Like Spencer mentioned, you can add a secondary domain in Google and move the user's primary email into the secondary domain. This will stop Google from redirecting the login page to Okta, and then you can access the account with a password.
• You can rename the primary email for the Google user, and then create a new Okta user using the new primary email. That way, you can set a new security question and password that you control. Then grant this new Okta user GSuite SAML, and you will then sign into their Google account.
• You can also delegate the google user's email to another admin using a commandline tool like GAM (Google Apps Manager). If delegation doesn't seem to be working, make sure the google user is added to a sub organization that has delegation active in GSuite Admin > Apps > GSuite > Gmail > User Settings > Delegation.

I'm looking to setup SAML on my gsuite and we have a few support@ type emails. I'm thinking I should be able to use GSuite delegation as the work around. Maybe I need an Okta account for the support@ email but I think that would solve this issue, no? Does GSuite delegation break when enabling SAML? It appears that once one account is trusted by the other that passwords are not required to log in if logging in through the trusted account.

We ended up finding a pretty good middle ground without compromising security.

​

First, for shared accounts, we simply delegated access to users from those accounts. We have BetterCloud so we were able to do it for the back end but you can also have users do it from the mailbox settings screen.

​

Second​, we had shared accounts that used Google authentication for certain Google products. Delegation does not allow you to auth against services.For those few mailboxes, we created individual G Suite apps, assigned the users that needed access to the mailbox to the app, and then changed the mapping for each user to use the shared mailbox email. That way when they clicked on the second Gmail icon on their dashboard, they were directed to the shared mailbox.

​

With​ these methods we were still able to maintain a single org that was rid of (shared) passwords.