I am trying to schedule an existing report after logging in to OKTA namespace.
However, it prompts for trusted credentials.
If I try to add/ renew credentials from profile—> preferences —> personal —-> credentials (renew).
It asks for the user id and password to be used. Even if I put in the correct credentials it shows authentication failure.
Can anyone guide me how to schedule a report with any OIDC namespace via trusted credentials
Related
Trying to setup an app with a sandbox account on PayPal. I already had a Business account with PayPal and have created a new application under the Sandbox.
I am provided with 3 credentials by PayPal:
Sandbox account which has the appearance of an email address
Client ID
Secret
However, using Omnipay with Laravel and it asks me for Username, Password and Signature in the config/env. I have some legacy prod credentials which look nothing like those provided by PayPal above, so can't even make an educated guess.
Thank you in advance.
Client ID/Secret are API credentials from a REST App (which if for sandbox mode will be tied to a particular sandbox account when the app is created)
For the old classic NVP/SOAP API Username/Password/Signature credentials, go directly to the sandbox account list and in manage accounts (...) select View/Edit account, second tab.
Our scenario: we create the user account in the portal but set the account to disabled. We then send an email invite to the user where it will take the user through a custom policy flow that will direct the user to set up phone mfa. If mfa is set, the user will become enabled and then will be able to sign in to the application.
However, I can not get PhoneFactor-InputOrVerify to execute in this scenario. However, during troubleshooting, if I enabled the account, sign in to the application and then sign out, and then run through the policy flow, it works as accepted. Can anyone provide any insight to this?
Create the account as enabled instead, and assign a random password.
Update the password after phone validation.
I am trying to understand the API's that #Microsoft provides. Its just so messy. My goal is to use the Exchange API to edit settings.
So, I have an APP, Access tokens and subscriptions.
When trying to login to https://outlook.office365.com/ I get the following error:
Your subscription is no longer active. Please contact your admin to activate your subscription.
X-ClientId: 05A0A74F610C432EA1AD48C77829580B
request-id 3088673c-f523-4e26-824f-1d0f7cb0a219
X-OWA-Error Microsoft.Exchange.Data.Storage.TenantAccessBlockedException
X-OWA-Version 15.20.2451.30
X-FEServer HE1PR05CA0360
X-BEServer HE1P190MB0508
Date:18/11/2019 09:11:34
But as you can see, I have a subscription:
What I understand is that I have to login to outlook.office365.com before using the API.
Update
Ok, so I can now login to https://outlook.office365.com/mail/inbox. It took a while............. But;
1) I can request: https://outlook.office365.com/api/beta/users/********************************/. It will return the specified user.
2) I can NOT https://outlook.office365.com/api/beta/users/********************************/mailfolders. I tells me 'access denied'. While my app has all Exchange, Office365 permissions. But delegate and application permissions.
The "Grant admin consent for your tenant" feature seems to have been updated yesterday.
However, something is wrong with the new "Grant admin consent for your tenant" feature based on my test.
If you use it to grant admin consent, it will probably not take effect on the back end although admin consent has been successfully completed on Azure Portal.
Currently you could grant admin consent through a URL request.
https://login.microsoftonline.com/{your tenant}/oauth2/authorize?client_id={app id of your Azure AD app}&response_type=code&redirect_uri={redirect uri of your Azure AD app}&nonce=1234&resource=https://outlook.office365.com/&prompt=admin_consent
Please note that you need to create a new Azure AD App currently because if you have used admin consent on Azure Portal, granting admin consent through a URL request will not take effect.
I am trying to run the active-directory-dotnet-webapi-onbehalfof sample in single tenant mode. I've registered the web app service and the native app client as global admin for the tenant. When I run the sample, as a user in the tenant, I can get a token in the client only after consent pops up (first-time for user), and then call makes it to the service, but there it fails with below. Why is that? Documentation says that when a tenant admin registers the application no further consent is needed? I don't think it is possible to give consent when a remote webapi tries to get OBO token. Something seems buggy... AAD team, please clarify how the OBO feature should be used.
AADSTS65001: The user or administrator has not consented to use the application with ID 'b824502e-fe8a-4770-bd98-8d65a07efcc3'. Send an interactive authorization request for this user and resource.
Trace ID: ad7843d0-be4e-4098-8f7c-43c8e5505cfc
Correlation ID: 140466a4-7250-429f-8843-dbd4f63dc60e
Timestamp: 2016-11-25 21:46:13Z
When you register an application using the Azure Management Portal (manage.windowsazure.com) as a tenant administrator, then yes you should not get consent, as long as subsequent tokens are being retrieved in that same tenant.
Because you are seeing consent for the native client app, and then getting that error message, we must assume that something is not being satisfied which would suppress consent for your app.
To resolve this issue, my recommendation is to simply initiate an interactive authorization request just like the error message implies. You can do this by generating a log-in url for your application, with a specific query string that will force prompt tenant wide consent (prompt=admin_consent).
Here is the skeleton for the URL you need to complete:
https://login.microsoftonline.com/<TenantID>/oauth2/authorize?client_id=<AppID>&response_type=code&redirect_uri=<RedirectURI>&resource=<ResourceURI>&prompt=admin_consent
You can do this for all the applications you registered, and you should not run into consent issues (assuming you are indeed signing in as a tenant admin).
I hope this resolves your issue.
I am using both GAM and the Google API PHP client library to integrate with Google for Work.
I am using a service account and I have authorized the Client ID in the Admin console to access the following two scopes:
https://www.googleapis.com/auth/drive
https://apps-apis.google.com/a/feeds/emailsettings/2.0/
I have also enabled the Drive API and Admin SDK in the Developers Console. There is no Email Settings API that I can see.
I have followed this page and granted GAM access to all scopes during testing - which does include the Email Settings scope.
I can successfully use GAM and the PHP client library to access the Google Drive API. However, I always get a 403 - Unauthorised when trying to do any of the Email Settings API functions detailed in https://developers.google.com/admin-sdk/email-settings/
I am fairly confident that I have the authorised the right Client ID in the Admin Console. When I remove the scope https://www.googleapis.com/auth/drive from the Admin Console it blocks my access to Google Drive from both GAM and the PHP client library.
Any suggestions on what to try?
GAM does not use service accounts for email settings API, it uses standard OAuth 2.0 for installed apps. Be sure you used a super administrator to authorize GAM access to the email settings API. If you didn't, run
gam oauth revoke
And then another command like:
gam all users show imap
And this time make sure you are logged in as a super admin.
Jay's post led me to the answer - namely that I should be logged in as a super admin when accessing the Email Settings API.
I therefore created a super admin account and authenticated GAM using that. That gave GAM access.
In order to get the PHP client library working, I had to impersonate the super admin account when I created the OAuth2 token. The code to impersonate the admin account is below:
$credentials = new Google_Auth_AssertionCredentials(
$service_account_email,
$scopes,
$private_key,
'notasecret', // Default P12 password
'http://oauth.net/grant_type/jwt/1.0/bearer', // Default grant type
$admin_email
);
where
$service_account_email is the email address of the service account created in the Developer's console - not the super admin account.
$scopes is an array of the API URLs that you need to access
$private_key is the contents of the P12 certificate created from the Developer's console.
$admin_email is the email of the super admin account.
Hope this helps someone else.