I've been following Caroline's blog to setup a multi-user composer rest server. So, I have two servers viz. Admin Server and the User Server.
As mentioned in the tutorial I:
Started the Admin Server with no authentication and single user mode. I started this server with Admin's card.
Started the User Server with JWT authentication in multi-user mode. I started this server with Admin's card as well.
Created a User participant and generated a card for user from the admin server.
Exchanged the first JWT token for this user on the User Server. So now the user has an access token.
Using this access-token I imported the user's card generated in #3 into the User Server.
Checked the Wallet status using user's access-token and was able to see the card to be set as default. i.e. default:true
This seems to have worked fine. However, now I'm trying to ping the network using User Server and User's access token. And it results in:
Error: Error trying login and get user Context. Error: Error trying to enroll user or load channel configuration. Error: Calling enrollment endpoint failed with error [Error: connect ECONNREFUSED 127.0.0.1:7054]
I tried setting this card to be default again but with no luck. When I list the identities issued from the admin server, I'm able to see this identity. But the status of this identity is "ISSUED". While the status of admin identity is "ACTIVATED". Is this an issue?
Or am I missing out on any of the important step here?
Related
We have application on compute engine that is using oauth2(Using GCP credentials) to authorize users to access application and it was working all fine. Suddenly since last two days we are getting 401 not authorize message from google authenticator instead of access token.
Have verified that the service account is active and APIs access enabled on GCE.
We tried rotating GCP API credentials but that did not work, even one of the environment was allowing to login again but go broken again in the morning.
Here is the sequence of incidents:
User hit url to access web app
That redirects to -> google auth page, requesting user to login consent
Credential provided user and accepted by google.
Instead of providing authentication token google is giving message access denied.
Not sure which logs can give clear picture to see the errors.
If your App is External Facing but is still in test mode (not verified), the token will expire after 7 days (source)
I have installed the Dynatrace client and I've been using if for months. After a Windows password reset I am getting this error. I have tried entering the new and old password.
Error on Login - The login failed because either the specified user name or password is incorrect, or you are not allowed to access this Dynatrace Server.
Thank you
This could be cache issues or something at the AppMon server:
If the LDAP server is down completely, LDAP users cannot log in.
However, successful user authentications are cached on the AppMon
Server for 10 minutes by default. If the same user logs in within this
time frame, no LDAP request is sent again and the user's
authentication timeout is prolonged. The user's group membership is
not verified or updated within this time frame.
You can configure the authentication timeout by changing the value of the following system property in the dtserver.ini file:
-Dcom.dynatrace.diagnostics.ldapAuthenticationTimeout=600
Reference: Dynatrace AppMon Documentation
We are experiencing problems with Authentication of Service Accounts for domain-wide delegation.
The main problem is it's hard to investigate and debug the auth configuration so
we would like to ask for some tips how to debug the configuration.
Or maybe we are missing some configuration options and you can point us to them.
Our process is:
Create SA(=Service Account) with enabled domain-wide delegation.
Authenticate SA in GSuite admin console(https://support.google.com/a/answer/162106?hl=en).
use client_id from the credentials file. (now email)
scopes are comma-separated without spaces between.
Ensure the "Security > API Reference > API Reference -> 'Enable API Access'" is checked.
For some GSuite domains this is working configuration, but we got some domains where this configuration results in:
google.auth.exceptions.RefreshError: ('unauthorized_client: Client is unauthorized to retrieve access tokens using this method.', '{\n "error": "unauthorized_client",\n "error_description": "Client is unauthorized to retrieve access tokens using this method."\n}')
In our understanding, this is the error saying the client_id and scopes were not added to the "Manage API client access" page. (=List of authenticated clients)
We really ensured that the GSuite domain we are requesting has the proper client_id and scopes added in the list of authenticated clients + has the 'Enabled API Access'.
We even created Shared Desktop with them and did it by ourselves to be fully sure of it.
But the error still persists.
However, we are not able to replicate this problem on our test GSuite domain.
We tried couple of options using same SA as the client:
The impersonated account hasn't permissions to access the resource.
This result in:
googleapiclient.errors.HttpError: https://www.googleapis.com/admin/directory/v1/users?customer=my_customer&alt=json returned "Not Authorized to access this resource/api">
The scopes are just partial:
google.auth.exceptions.RefreshError: ('access_denied: Requested client not authorized.', '{\n "error": "access_denied",\n "error_description": "Requested client not authorized."\n}')
The 'Enabled API Access' is not checked.
googleapiclient.errors.HttpError: https://www.googleapis.com/admin/directory/v1/users?customer=my_customer&alt=json returned "Domain cannot use apis.">
The error we are receiving from the client("Client is unauthorized to retrieve access tokens using this method."), we are able to replicate only if the client_id is not in the list of authenticated clients at all.
But we are sure, the problematic GSuite domains have the SA authenticated in "Manage API client access" page.
We are using these scopes: https://www.googleapis.com/auth/userinfo.profile,https://www.googleapis.com/auth/userinfo.email,https://www.googleapis.com/auth/gmail.readonly,https://www.googleapis.com/auth/plus.login,https://www.googleapis.com/auth/calendar.readonly,https://www.googleapis.com/auth/contacts.readonly, https://www.googleapis.com/auth/admin.directory.user.readonly
Do you have any ideas how to debug/solve this issue?
Here is what you need to do. Double check each step. If in doubt, start over.
Enable "Admin SDK API. This is enabled on a per project basis.
Create a service account. Do not add or remove any privileges. Don't change the service account in any way. If you do you will get an error that you are not authorized.
Enable Domain-wide Delegation on the service account.
Follow this document to delegate domain-wide authority to your service account:
Delegate domain-wide authority to your service account
When creating the service account credentials (from the downloaded Json) you will need the following scopes for full G Suite management:
"https://www.googleapis.com/auth/admin.directory.group",
"https://www.googleapis.com/auth/admin.directory.user"
Impersonate a user account which creates new credentials. The user account needs to be a G Suite superadmin. This account must have logged into G Suite at least once and accepted the Terms of Service.
Create your client using the credentials from step #5.
Working Python Example:
from googleapiclient.discovery import build
from google.oauth2 import service_account
# This is the service account credentials file
credentials_file = 'google-directory-api.json'
# In this example I only need to send email
credentials = service_account.Credentials.from_service_account_file(
credentials_file,
scopes=['https://www.googleapis.com/auth/gmail.send'])
# This user is a G Suite superadmin
impersonate = 'username#example.com'
credentials = credentials.with_subject(impersonate)
service = build('gmail', 'v1', credentials=credentials)
I think we are going to need to take this in stages. Lets start with your first error and see if that fixes your issue.
Background info
There are several types of clients that you can create in Google developer console. Here are the top three.
Browser client: Used for web applications
Native client (other): used for installed desktop applications
Service account: used for server to server communication.
The clients are different the client.json file you download is different and the code used to authenticated to the authentication server is also different.
Error 1: code / client missmatch
unauthorized_client: Client is unauthorized to retrieve access tokens using this method.
Can mean one of two things. Either you have created a service account client and you are not using service account code to authenticate or you are are using the code to authenticate with a service account but you have not created a service account client. You haven't posted what language you are using or any code so I cant tell you if the code you are using is intended to be used with a service account or not. Your going to have to look into this one a bit.
Check in developer console make sure your client is like this If it is check your code. If it isnt then create a real service account client and try again.
I am trying to implement server-to-server integration with Dynamics CRM Online 2016 and BizTalk 2013 R2. I am using the WebHttpBinding to call the CRM web API, which requires a bearer token supplied as an http header:
Authorization: Bearer [base64string]
I have written a client message inspector which calls Azure AD using ADAL to acquire an access token. This is secured with a client assertion certificate, which is assigned to the registered app in our AD tenant:
var token = context.AcquireTokenAsync(this.ResourceUri, assertionCert).Result;
ResourceUri is https://[myorganisation].crm4.dynamics.com
assertionCert is a ClientAssertionCertificate created using the app registration application ID and an x509 certificate in the machine certificate store that is registered to the app as a KeyCredential
This 'works' in that it returns a token and I can decode this token to inspect the claims - there are a fair number of them, I have no way of telling whether this is the set of claims that CRM requires.
The AD app registration is configured with delegated permissions to the CRM instance.
I have set the application ID in the CRM local user to that of the app registration.
Upon calling the webAPI and supplying this token, CRM responds with 401 unauthorized.
I have repeated the same process in a powershell script and in PostMan, all of which appear to show the same behaviour.
What else am I supposed to do to make CRM accept my access token?
edit #1: Tried hardcoding the authority URI to https://login.windows.net/[my-tenant-id]/oauth2/token rather than what comes out of dynamically acquiring the authority through AuthenticationParameters - this is the same value except ending with /authorization instead of /token. This makes zero difference.
edit #2: An administrator I am working with pointed out to me that the application user I am expecting to use had no user roles assigned - this has been amended to have a role which should allow API access, but this also made no difference.
edit #3: Set oauth2AllowImplicitFlow to true in the manifest for the app registration. This doesn't make any difference.
edit #4: Made some progress by creating a new app registration, this time as a Native app rather than a web app. I managed to get a token using a client secret, and this was accepted - BUT when assigning a certificate to the app, and presenting a ClientAssertionCertificate as before, I get the response from the authority:
Error validating credentials. AADSTS50012: Client is public so a client_assertion' should not be presented.
WHY? What does 'Client is public' mean? Just work!
Hrrrmph!
Turns out that the original situation I had tried and failed with, now works.
Web application registration with delegated permissions to CRM Online
Install a client certificate on the client machine, and register this same certificate to the app using New-AzureADApplicationKeyCredential
Link the app registration to a CRM Application User created for this purpose (they are fundamentally different to interactive users) - n.b. this screen is not easy to find
Call AcquireTokenAsync() from ADAL
Just works
I am at a loss to explain why this didn't work the first time I tried it, as CRM doesn't supply any information as to why token validation failed.
I am trying to build an AzureAD access app. I have to enable this app for external tenants. I have enabled external access on this app and it is configured to use the Graph API also. I have tested the app in the tenant in which it was created and everything(auth+ graph api access) works. Now here is the flow for the external tenant
I take the external tenant user to the grant consent URL of my app, the user(who is an admin of the external tenant) grants the access and i get the correct response
Now i want to get the authorization token for this user, so i take the user through the normal Oauth process via
https://login.windows.net/common/oauth2/authorize
followed by
https://login.windows.net/common/oauth2/token/
At this point Azure throws the following error
{"error":"invalid_grant","error_description":"AADSTS50000: There was an error issuing a
token. AADSTS65005: No permission to access \u0027https://graph.windows.net\u0027
resource is configured for \u0027d2037ff7-24e4-4cac-8e5e-16e370b36238\u0027 application,
or it is expired or revoked.\r\nTrace ID: 472aa92f-35a2-4ed9-ab07-
12488cc9e6f5\r\nCorrelation ID: b163dde5-eac5-4c82-99ad-0e1100487cb9\r\nTimestamp: 2013-
09-23 05:28:41Z","error_codes":[50000,65005],"timestamp":"2013-09-23
05:28:41Z","trace_id":"472aa92f-35a2-4ed9-ab07-12488cc9e6f5","correlation_id":"b163dde5-
eac5-4c82-99ad-0e1100487cb9"}
Why this error even when the app has been granted access. I tried to lookup the STS errors
but found no explanation. Any ideas?
[update]
SAML process continues to work for the external tenant however i.e I can use the app for SAML(SSO) login for this external tenant. The problem only seems to be coming for getting access to the graph API.
Try adding &prompt=consent or &prompt=admin_consent to the full authorize URL to re-request the user consent. My experience has been that the consent will be randomly revoked (maybe a bug) and will not ever be automatically re-requested (definitely a bug).