I try to write console app with crm service and I get this error:
Unable to connect to CRM: An error occurred when processing the
security tokens in the message:You are using Ws-Tust authentication
which has been deprecated and no longer supported in your environment.
Please use oAuth2.0 authentication.
how I can to solve it?
Try this connection string:
"AuthType=OAuth;
Username=jsmith;
Password=passcode;
Url=https://xxx.crm4.dynamics.com;
AppId=51f81489-12ee-4a9e-aaae-a2591f45987d;
RedirectUri=app://58145B91-0C36-4500-8554-080854F2AC97;
TokenCacheStorePath=c:\MyTokenCache;
LoginPrompt=Auto"
Where Username is your CRM login and Password is your password accordingly.
Url is the link to your crm instance.
AppId and RedirectUri should be yours Ids from AzureAD but I've took them at official documantation page Use connection strings in XRM tooling to connect to Dynamics 365 Customer Engagement (on-premises) and it worked for me :-).
Related
I am using ADFS 3.0 for SSO on SharePoint 2013, I have followed the instructions at http://info.summit7systems.com/blog/beginners-guide-to-claims-based-authentication-ad-fs-3-0-and-sharepoint-2013-part-ii-installing-and-configuring-ad-fs-3-0
but every time I login using the ADFS login page I receive the below error
No strong authentication method found for the request from urn:sharepoint:ontrack.
at Microsoft.IdentityServer.Web.Authentication.AuthenticationPolicyEvaluator.
this is the configuration of authnetication policies
Enabling ADFS tracing will likely give you further insight. I received this error and it related to not having a custom multifactor authentication provider installed on a particular ADFS node.
Is your SharePoint RPT setup for multifactor authentication? If so, you may ensure that the appropriate MFA provider displays and is enabled on the Multi-factor tab.
Hi I'm trying to develop an for GSuite admin which enables to migrate their google drive data to another cloud service. But in the process of authentication i'm getting the below error.
{
"error": "unauthorized_client",
"error_description": "Client is unauthorized to retrieve access tokens using this method."
}
Below are the api's that are enabled in developer console.
1. Admin SDK
2. Contacts API
3. G Mail API
4. Calendar API
5. Drive API
Please guide me if done anything wrong in creating an app.
The main thing what i missed here is Authorizing my service account client ID with the GSUITE admin.
And I have been trying to generate access_token for the expired domain of mine.
After clearing all these i have to success in generating and getting user data.
This solution worked for me. I hope it works for you tooo....
Thank you community.
I can see the message using network capture tool Microsoft Message Analyzer. I can see the I receive Kerberos error "KDC_ERR_C_PRINCIPAL_UNKNOWN: Client not found in Kerberos database".
I can see all parts of the message, I have been searching online and tried a few things and did not work.
But in order to understand the problem, what does the "client" mean here?
- Is it the Server / Computer that is requesting
- Is it the Application that is requesting
The error is for KRB_TGS_REQ which means that its requesting for a token.
Would be great if anyone could help understand, which I believe can lead to a resolution.
Added more Details:
We have a SharePoint farm setup with SQL Reporting Services (SharePoint Integrated mode) and Excel Services. We have a datasource defined in Sharepoint which are used in SSRS Reports and Excel Reports. We use Windows Authentication from Sharepoint to SQL. When we test connection on Sharepoint datasource we get an error which says Cannot convert Windows token to Claims token. On opening the reports in SSRS we also receive error.
Strange part is that it works for some users which is why I'm not sure how to tackle this issue. If its SQL Server previlage issue, we have assigned sys admin role, this user also added as admin in SSRS. If AD or SPN issue it must not work for all users not for individual users.
I can see successful KRB_TGS_REQ for an admin user but fails for a normal user. No clue what to look for.
Kerberos Message :
KRB_TGS_ERROR, KDC_ERR_C_PRINCIPAL_UNKNOWN: Client not found in Kerberos database, Cname: nothing, Realm: SUB.DOMAIN.COM, Sname: SP_SVC_ACT
Does this mean that the delegation is not working?
I have setup SSO with Netsuite and Azure using the following instructions:
https://azure.microsoft.com/en-us/documentation/articles/active-directory-saas-netsuite-tutorial/.
The SSO works for users from Office 365 to NetSuite, however if a user clicks on a NetSuite link in an email they receive an invalid SAML protocol message from Azure during authentication.
For example:
Email Link is
"https:\system.netsuite.com/app/accounting/transactions/purchord.nl?id=167770&c={ACCOUNT_ID}"
Get redirected to (by NetSuite)
"https:\login.windows.net/9621cdc8-e1c4-4a3c-849e-35be6db5a45e/saml2"
which then redirects to :
"https:\login.microsoftonline.com/9621cdc8-e1c4-4a3c-849e-35be6db5a45e/saml2?RelayState=https%3A%2F%2Fsystem.netsuite.com%2Fapp%2Faccounting%2Ftransactions%2Fpurchord.nl%3Fid%3D167770%26c%3D{ACCOUNT_ID}"
which generates error:
Sign In
Sorry, but we’re having trouble signing you in.
We received a bad request.
Additional technical information:
Correlation ID: a8ceee9f-8507-4f55-aa56-e65266bf7d92
Timestamp: 2016-04-13 05:18:07Z
AADSTS75005: The request is not a valid Saml2 protocol message.
Does anyone have any ideas how to get further details on the error, or fix it?
I recently came across this issue and found a solution that works for me.
Try using the following format
https://account.activedirectory.windowsazure.com/applications/signin/{AZURE NETSUITE - APPLICATION_ID}?RelayState=https%3A%2F%2F{NetSuite_Account#}.app.netsuite.com%2Fapp%2Faccounting%2Ftransactions%2Fpurchord.nl%3Fid%3D{Purchae_Order_Record_ID}
I hope this helps.
Recently I faced this issue with Azure SSO, link does not work it fails # the SSO provider's(Azure) login URL. Issue is not with the Netsuite it is sending the request for authentication to Azure but Azure could not authenticate the user even though user is logged into the AD. You can resolve this issue by syncing Azure AD and source of authority. Also make sure your Azure SSo is setup correctly -by running zure Active Directory Module for Windows PowerShell as an admin.
Good luck
I am trying to write an WPF client which uses ADAL to authenticate against ADFS on a Windows Server 2012 R2. I have successfully implemented this using "Forms Authentication" where the user is prompted for the domain username and password. However, I want to take advantage of SSO and use the currently logged on domain user to authenticate against the ADFS.
Unfortunately, I'm only getting an error message saying:
This method overload is not supported by '< ADFS servername>'
I have done a lot of searching, but find some of the information contradictive:
This SO post about a Windows Store App (any differences to WPF?) where Vittorio Bertocci links to a blog on how to achieve it:
ADAL for Windows Store SSO
This SO post where Vittorio Bertocci claims that silent authentication is only possible with Windows Server 2016:
Authenticate with ADFS inside Console App silently
Is it a fact that Windows Server 2016 is required to perform SSO in conjunction with ADAL?
Is there any other way to do it?
EDIT:
After upgrading to the latest alpha of ADAL (3.9.302111717-alpha) I'm getting the more detailed error message
MSIS9611: The authorization server does not support the requested 'grant_type'. The authorization server only supports 'authorization_code' or 'refresh_token' as the grant type.
The code I'm executing is this:
string authority = "https://myServer.com/adfs";
string resourceURI = "http://myApp/";
string clientId = "XXXX-XXX-XXXX-XXXX-XXXXX";
string clientReturnUri = "http://anarbitraryreturnuri/";
var ac = new AuthenticationContext(authority, false);
var token = await ac.AcquireTokenAsync(resourceURI, clientId,new UserCredential());
I was able to implement a working solution using WS-Trust, so I am confident that the machine I'm running on has the privacy settings to enable the app to find the currently logged on user.
The Oauth2 endpoint looks as follows:
Also, my global authentication policy is set up like this:
Windows Server 2016 is only required for the password grant - in which you provide raw username and password. Your question seems to suggest you want to sign on with the currently signed in user, which would leverage Kerberos instead.
Kerberos based authentication should work with ADFS "3" and ADFS 2016 indifferently - as long as your client is connected to the domain network, the local machine does not have privacy settings that prevent your app from finding out the domain user currently logged in and the correct endpoints are enabled on the ADFS instance.