Not Authorized to access this resouce/api ?

4,937 views
Skip to first unread message

Andy Helsby

unread,
Aug 31, 2016, 10:40:38 AM8/31/16
to gshell-discuss
I'm brand new to the powershell/gshell interaction, so please bear with me.

Last week on Thursday I got the intergration working and was able to successfully create users in Google apps from a Powershell script as part of our userprovisioning script.
However somehow it stopped working but not sure why.

I checked into the developers console this morning and couldn't see any of my projects that previously existed. Putting the reason why aside for the moment, I recreated a new project and added the admin.directory sdk api 
Created a new OAuth 2.0 credential with a new client id and secret.
Clicking on Dashboard I can verify the Admin SDK is enabled. I am assuming this is the correct SDK - the getting started refers to the Admin Directory API but that does not show up in the list when you search.

I copied the secret and client id into my script, attempted to select a user and get the following error message:-

10:00:46PS C:\andy\scripts> Set-GShellClientSecrets -ClientId "myclientidhere.apps.googleusercontent.com" -ClientSecret "ogmysecrethere"
10:10:45PS C:\andy\scripts> Get-GAUser et...@mydomain.com mydomain.com

Get-GAUser : Google.Apis.Requests.RequestError
Not Authorized to access this resource/api [403]
Errors [
    Message[Not Authorized to access this resource/api] Location[ - ] Reason[forbidden] Domain[global]
]
At line:1 char:1
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Get-GAUser], GoogleApiException
    + FullyQualifiedErrorId : Google.GoogleApiException,gShell.Cmdlets.Directory.GAUser.GetGAUserCommand

When I did this i was not prompted to set the scope, which I was the first time I ran this (under the original clientid/secret combo)

I ran the invoke-scope just in case, set the scope settings up (snipped below) to show that the Directory is the API listed.

admin:directory_v1 - The Admin SDK Directory API lets you view and manage enterprise resources such as users and groups, administrative notifications, security features, and more.


Please confirm the scope(s) you'd like to grant gShell permission to:

[ ] 0   All - All scopes in this list.
[√] 1   https://www.googleapis.com/auth/admin.directory.customer - View and manage customer related information
[√] 2   https://www.googleapis.com/auth/admin.directory.customer.readonly - View customer related information

Now still getting the Not Authorized to access this resource.
get-module shows that I'm running v1.0 (which probably needs to be corrected). The dll shows I'm running 0.9.5.0

Running the Directory API test for users tryit page at https://developers.google.com/admin-sdk/directory/v1/reference/users/get#try-it and enabling the same scopes, I was able to successfully get my test user information.



get-gshelluser returns the following - is this correct or should I have the clientSecrets filled in?
10:28:35PS C:\andy\scripts> get-gshelluser


userName            : googleadmin
domain              : mydomain.com
email               : mya...@mydomain.com
tokenAndScopesByApi : {[admin:directory_v1, gShell.dotNet.Utilities.OAuth2.OAuth2TokenInfo]}
clientSecrets       :


My gshell_oauth2.json file is dated today, has the new client secret in it and looks good.Directory scopes are listed. (shown below)
 "tokenAndScopes": {
            "admin:directory_v1": {
              "scopes": [
              ],

This does look suspiciously similar to Allieway's issue at https://github.com/squid808/gShell/issues/4 that was posted 6 days ago - the same time mine worked and possibly stopped working - co-incidence/problem?

Note that I have the module installed in my c:\andy\powershellmodules\modules\gshell directory (as roaming profiles will default modules to a network share so my powershell modules are stored locally. the psd1 file was edited appropriately (on day1 when this all worked)



Hopefully that is enough information to go on?


Andy

Spencer Varney

unread,
Aug 31, 2016, 10:45:34 AM8/31/16
to Andy Helsby, gshell-discuss
Hey Andy,

I'll take a look at this as soon as I can, but it might be a few days - I've barely had time to come up for breath recently. That said, if anyone else here can take a look at it and help out in the meantime that'd be great!

I hope to be able to help asap - I just didn't want you to think I'm brushing you off!

Regards,

Spencer

--
You received this message because you are subscribed to the Google Groups "gshell-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gshell-discus...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Andy Helsby

unread,
Aug 31, 2016, 10:48:32 AM8/31/16
to gshell-discuss, andy.he...@gmail.com
Thanks Spencer, I appreciate the fast response. Let me know if you want to continue the conversation here, on github or privately.

Andy

googl...@tlsohio.edu

unread,
Sep 8, 2016, 4:49:57 PM9/8/16
to gshell-discuss, andy.he...@gmail.com
Today I looked at this again.
Ran through the steps of
import-module gshell
set-gshellclientsecrets -clientid "adads" -clientsecret "adasfsadsa"
get-gshelluser
Shows me my admin username, domain, tokens as previous, clientSecrets is blank (as before).


Run
get-gauser user...@domain.com domain.com and now I get
get-gauser : Value cannot be null.
Parameter name: task


At line:1 char:1

+ get-gauser user...@domain.com domain.com
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Get-GAUser], ArgumentNullException
+ FullyQualifiedErrorId : System.ArgumentNullException,gShell.Cmdlets.Directory.GAUser.GetGAUserCommand


So this is worse than last week where I was getting a 403 access denied, now I'm getting value cannot be null

As before, entering just the users email address at https://developers.google.com/apis-explorer/?hl=en_US#search/directory/admin/directory_v1/directory.users.get?userKey=user%2540mydomain.com&_h=3&
works fine.

Deleting the gshell_oauth2.json and rerunning set-gshellsecrets repopulates the file again.

Very weird.....

Spencer Varney

unread,
Sep 14, 2016, 1:22:17 AM9/14/16
to googl...@tlsohio.edu, gshell-discuss, Andy Helsby
Ok! So, to touch on what you wrote in order:


Clicking on Dashboard I can verify the Admin SDK is enabled. I am assuming this is the correct SDK - the getting started refers to the Admin Directory API but that does not show up in the list when you search.

That's correct, they call it the Admin SDK now. I'll look in to updating the Getting Started, or if you'd like you update it as well if I don't get to it in time. That's my bad.

When I did this i was not prompted to set the scope, which I was the first time I ran this (under the original clientid/secret combo)

This is most likely because the first time you ran it there was nothing saved in the config file. The second time you ran it, that info already existed and therefore didn't prompt you (it doesn't know if the information is accurate or not, however).

 I ran the invoke-scope just in case, set the scope settings up (snipped below) to show that the Directory is the API listed.

As a side note, you don't have to choose both a scope and it's read-only pair, for instance https://www.googleapis.com/auth/admin.directory.customer is the read-write scope for the directory.customer bits, and https://www.googleapis.com/auth/admin.directory.customer.readonly is just the read-only version of the same scope. If you include both, it's going to include read-write and essentially ignore the read-only scope you provided.

get-module shows that I'm running v1.0 (which probably needs to be corrected).

Agreed! I'll look in to that, thanks.

get-gshelluser returns the following - is this correct or should I have the clientSecrets filled in?

In this case no - that's for a future possible use case where one might have separate client secrets for each individual domain and/or user, but that never went live. You looked behind the curtain! Looks accurate, otherwise. The client secrets fall on the same level in the json file as the domain, since it's a generic setup for all domains and users at this time.

 This does look suspiciously similar to Allieway's issue at https://github.com/squid808/gShell/issues/4 that was posted 6 days ago - the same time mine worked and possibly stopped working - co-incidence/problem?

I haven't yet reviewed that issue in detail, however it does sound like it has something to do with the scopes and permissions. In your case, when in doubt - kill the gShell_OAuth2.json file (is that showing up in c:\andy\powershellmodules\modules\gshell like you mentioned?) and start from scratch - make sure to close and relaunch PowerShell to clear it's memory. Does that help at all? [Edit: upon further reading, you said it repopulates the file... and it sounds like no, it doesn't help?]

Today I looked at this again.... So this is worse than last week where I was getting a 403 access denied, now I'm getting value cannot be null

Ok, so that's really strange. If I run the same command (with a valid user) I get no issue. On the flip side, whatever domain you used when you signed in with gShell is your default domain, and you can omit that. So instead of this:
get-gauser user...@domain.com -Domain domain.com #you'd need to explicitly supply the parameter for Domain, I believe

Try this:
get-gauser username

See if that helps any?

Summary: So, the only thing I can think of right now is when you're getting to the point where it opens the browser for you to accept, you may be logged in with a different account? For instance, if you're logged in to your gmail account and you don't realize it (in the top right) and you hit accept, that can really get things screwy. If you have the time, remove the OAuth file and start over. This time, when the browser opens, make super sure that the account you're accepting the information for is the account for the Apps domain you want to work with. Also, try sticking with just the read-write or just the read-only permissions, and see if that helps any.

If that doesn't help, let me know and we can go from there.

Thanks again for your patience!

Regards,

Spencer

--
You received this message because you are subscribed to the Google Groups "gshell-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gshell-discuss+unsubscribe@googlegroups.com.

Andy Helsby

unread,
Sep 15, 2016, 2:52:17 PM9/15/16
to gshell-discuss, googl...@tlsohio.edu, andy.he...@gmail.com
So I tried all that today...

signed out of my personal gmail account and closed all browser windows.
Deleted C:\Andy\PowershellModules\Modules\gShell\gShell_OAuth2.json

Ran 
import-module gshell
set-gshellclientsecrets....blah blah.
json is repopulated.

14:29:25PS C:\andy\scripts> Get-GAUser et...@domain.edu 
I'm prompted to set my scope.
Selected write and options 1,5,6,7,9,10,11,12,13,14,15
browser opens, prompted to enter my username and gmail password.
Entered them.
Data returned successfully.

I'm guessing that I must have had cached credentials or something that was using my personal credentials originally instead of my google admin.

I was able to follow the steps above on another (previously "broken") computer and again was able to retrieve my user, so problem solved!

Thanks for the assistance and patience

Andy




To unsubscribe from this group and stop receiving emails from it, send an email to gshell-discus...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages