Google Suite Team Drive Impersonation

I have an issue with the impersonation on my domain with team drives.

Indeed, when I run: rclone -vv --drive-impersonate usr@domain.com lsf GDrive:, I get the following error:

Response: {
"error": "unauthorized_client",
"error_description": "Client is unauthorized to retrieve access tokens using this method, or client not authorized for any of the scopes requested."
}

My settings in three points:

  1. Here is my .rclone.conf:

[GDrive]
type = drive
scope = drive
service_account_file = /home/USER/Documents/sa-auth.json
client_id = XYZ

Where client_id matches the one in the service_account_file file. (I also tried without specifying the client_id in .rclone.conf, did not change anything).

  1. I made sure the service account has proper domain-wide delegation enabled

  2. The client_id has been granted https://www.googleapis.com/auth/drive rights.

You did this already? Enable the Drive api for the project that the service account is in?

https://developers.google.com/drive/api/v3/enable-drive-api

Yes I already did this!

Is there a client_secret in your config too?

No, there's no client_secret in the .rclone.conf nor the sa-auth.json.
But the latter has been generated by Google so I guess it can be assumed correct.

If you haven't got a client_secret that explains the unauthorized messages.

You need to add the client_secret which you would have got through following this procedure: https://rclone.org/drive/#making-your-own-client-id

Or remove the client_id setting.

But what is the point of using a service account login if I have to create my own app and do the OAuth procedure?
I am not sure this is actually the solution since in the sa-auth.json I have the private_key, client_id, auth_uri, token_uri...

Secondly, as I said in the original post, I also tried without specifying the client_id in .rclone.conf, it did not change anything.

I don't think you do, I think the two concepts are unrelated.

@thestigma - you are good at drive and service accounts - I'm out of my depth here - can you help?

Lordy lord! Nick is asking me for help? (let me get a photo of this :slight_smile: )

To be clear, I haven't set up a SA for domain-wide-delegation because I don't own a domain, but let's see if I can add anything here...

Well, let's get the basics out of the way:
Is the user you are trying to impersonate a member of the domain? This error will occur if you tried to for example impersonate an @gmail.com user or one in another domain than your own. Logically "domain-wide-delegation" permissions can't extend outside of that domain.


Done this?:

  • Go to example.com’s admin console
  • Go into “Security” (or use the search bar)
  • Select “Show more” and then “Advanced settings”
  • Select “Manage API client access” in the “Authentication” section
  • In the “Client Name” field enter the service account’s “Client ID” - this can be found in the Developer Console under “IAM & Admin” -> “Service Accounts”, then “View Client ID” for the newly created service account. It is a ~21 character numerical string.

Lastly - is it important for you to actually impersonate users for administrative purposes - or is all you really care about allowing the SA to access the files? If it is the latter we can use an alternate method for that if we do not figure out the initial problem.

1 Like

To be clear: If you have a service account in the config and the TD is shared with that service account (directly with SA email or SA email in a group) then you do not have to auth with client_id / secret.

Correct - that is the alternative method I mentioned.
But this does not really replace the impersonation feature as that has many administrative and organizational uses. It is just an alternative way to access files with an SA - which is often all that people were really looking to do in the first place.