As part of our "off-boarding" process for employees leaving the company, as super admins we use the Google Apps Admin SDK Directory API to change the user's password so that they can no longer access their account. Then we log in to do a Google Takeout, reset passwords for their other accounts, etc.
However, we recently decided to enforce 2-Step Verification for all of our users. So now when we go to log in to their account, it sends a code to their phone.
Since 2-Step is enforced for their SubOrg, we can't even turn it off through the admin console. So all I can do now is to have the API move the user to a different SubOrg where the 2-Step enforcement setting is turned off, and then manually turn off 2-Step.
Is there any way to programmatically turn off 2-Step verification for an account?
I looked in the Google Apps Admin SDK Directory API Users:update documentation, but it doesn't seem to have anything to do with 2-Step.
The Reports API can find out the user's enrollment status, but it's read-only for reporting purposes.
What you are doing is the correct way to remove the 2-Step verification. As you mentioned if it is enforced under a Organization Unit, removing it would get against that rule and that's why you are not able to do it unless you move the user to another OU where this is not enforced.
I was not able to find some way to do this programmatically. However, you could Suspend the user. After that, the user won't be able to access to that account. The account will still be visible in your Admin Console and all the information in the different Google services will remain attached to that account until you finally delete the account.
While the user is suspended, as admin, you can use service account to impersonate that user. By doing so you can act as that user and edit permissions or transfer the ownership of the files contained in Drive to a different account so those files won't get lost.
I hope this helps.
The easiest way to do this is to create a Group for which 2FA is exempt (see here: https://support.google.com/a/answer/2370108). Then add the user to that group, then you can click "Disable 2FA" on the user page in the admin console. I'm assuming you can do the same through the API.
The only downside is that this means you'll have a group through which it is possible to exempt users from the 2FA enforcement option. So that's a risk you'll have to accept and a policy you have to carefully check.
Related
I'm trying to setup a Google OAuth consent screen but I have two separate google workspace accounts. The two accounts are completely separate.
I have the consent screen setup, working perfectly for the one workspace "domain-a.com" as an Internal User Type to make sure only users within "domain-a.com" can login.
I'd like to also allow "domain-b.com" accounts from the other google workspace to also be able to login.
I'm wondering if this is at all possible? Or is my only option to set the User Type to external and then vet the domains in my auth flow?
I was hoping it would possible to somehow authorise "domain-b.com" on the "domain-a.com" workspace without adding all the additional domain aliases to users etc? I do see the Domain Verification option under the APIs and Services screen, but this only mentions webhooks.
Any help would be appreciated
I think setting the type to external is the only way to achieve this.
Does your app use any sensitive scopes? If so, then setting the app to external means that your app might require verification unless you mark the app as trusted in both Workspace accounts.
We are setting up an "app" in Google Cloud Console for the sole purpose of single sign on - letting users sign into a WordPress site and a Moodle site using their Google accounts.
When setting up the "Oauth Consent Screen" - there is a "Submit for Verification" button which is disabled (grayed out). The verification Status is "not published".
The question: does it need to be verified? The documentation, such as there is, hints darkly at various limitations if it is not. Yet, there appears to be no path to get it verified.
It "works" in testing for allowing log in with Google account, but the organization has a large number of users. Are we going to hit limits if we go live with it?
We haven't added any scopes. Do we need to, just to get the ability to get it verified? It "works" in testing, without having added any scopes.
Any insight is welcome on how to get this app verified - or as whether we need to have it verified (maybe it can't be verified because it doesn't need to be?).
I just wanted to check my understanding here.
When I log into some applications e.g. Dropbox with my Google account, I get a consent dialog:
I can then revoke access in my Google account as I would expect.
However, when I sign into other apps e.g. SoundCloud, I don't get a consent dialog at all, it just takes me straight in. Neither does SoundCloud appear in my list of revocable apps in my Google account.
I am presuming that this is because SoundCloud does not require any information or rights with respect to my Google Account and therefore no consent is required. That is, all it requires is authentication, which does not require consent (presumably because entering your credentials is considered consent enough for this purpose).
I just wanted to confirm that I am correct in my assumptions.
You have found the answer to your question.
If you check Dropbox's login request, it contains a special scope value https://www.google.com/m8/feeds which stands for Mange your contacts (reference).
Dropbox scope parameter - scope=https://www.google.com/m8/feeds+email+profile
But if you check the same with SoundCloud, you only see profile specific scopes such as email profile openid
Soundcloud scope parameter - scope=email profile openid https://www.googleapis.com/auth/userinfo.email https://www.googleapis.com/auth/userinfo.profile https://www.googleapis.com/auth/plus.me
So yes, you get the consent page because of the special scope present in Dropbox authorization request. And consent page matches with scope value.
Further read this blog on default scopes and special scopes.
p.s - You can monitor these scope values with browser debugger. You must enable debugger for popups and navigations to see them. I used chrome to extract those values.
I want to connect the Users from my website with the TeamSpeak server, that i can automatically grant rights, ban users and so on.
At the moment the User has to enter his Ts UID on my website, so that i can search him in the TS database.
But for some time now, you can login to the TeamSpeak client with a TeamSpeak account.
Is there a way that the users can login on my website with this Teamspeak account like with Google, Facebook and so on?
And am I able to find them on my TS Server when they are logged in with that account?
TeamSpeak's myTeamSpeak system was definitely not designed for any oauth type functions. However TeamSpeak has a brilliant plugin SDK, serverquery and clientquery available to interact with teamspeak.
I would recommend you "link" users' TeamSpeak UID's like https://ts-n.net/ranksystem.php does via a user's IP address. From there you can simply accept the login, or you can take it a step further and sending a message with a "activation code" via one of the ways mentioned above to interact with teamspeak for additional security.
From what I understand, you want to find online user's that are logged in to your website through a form of authentication using teamspeak. I have no idea what you mean by "them", but teamspeak's serverquery lets you search through every single client in it's database, and whatever you are looking for is there or in your logs folder.
Sorry I could not be more helpful, I will edit this/respond when/if you clarify your question.
I'm using the Google Apps Provisioning API to synchronize user data with our internal database (MySQL). For every new user created through our site's backend, a corresponding user in created in the GoogApp system. Change is passwords are also synchronized accordingly.
I'm about to implement SSO, so that logins performed on our website automatically makes the user login into the google apps too.
My question is what happens IF the user happens to change his/her password using the Account > Settings in the googapps interface, instead of our own backend? Our system has no way of knowing about the change! Is there a way in Prov API or SSO with which I can turn off the password changing mechanism in googapp engine and let the user do it ONLY through our backend?
Anyone who's used / setup a similar system, please shed some light on it.
Thanks,
m^e
When you have SSO enabled in your Google Apps domain you have to provide a "change password" URL, that way when the users tries to go "Setting"->"Change Password" they will be redirected to your custom URL and make the password change in your backend.