I am trying to link flow with office 365 outlook, every time I try and authorise the connection I get;
OAuth2Certificate authorization flow failed for service 'Office 365
(Discovery, Certificate)'. O365 discovery endpoint returned status code 401
(Unauthorized). Response:\r\n{"error":{"code":"-2147024891,
System.UnauthorizedAccessException","message":"Access denied. You do not have
permission to perform this action or access this resource."}}
I am the owner of the office 365 and this is a home account not a business one, I am not sure if this makes a difference.
Hope someone can help
I've also faced the same issue and now it's working fine after switching to "Outlook.com". The below is from the official documentation:
> For Azure work or school accounts, select Office 365 Outlook.
> For personal Microsoft accounts, select Outlook.com.
So, I think one need to use "Outlook.com" for the home account.
Related
I'm having a server with power-bi reporting service installed and configured on it, and from my front-end that hosts the application, i've got angular 7 with proper power-bi components installed.
Since the report is on the server and it needs authentication to login, i get a user and password fill-in prompt in my website whenever i try to access this report, and after logging in, i can see the data of my report.
I'm wondering how to use Kerberos authentication so that i can set-up that username and password to login automatically without asking the user to enter them every time.
What i've done so far :
I've made and set a few SPN in my active directory, made a user in Active Directory Users and Computer and in it's Delegation tab, i've set it to Use any authentication protocol and added MSOLAPDisco and MSOLAPSvc.3 to it. i've added the user account credentials that i've made to service account and execution account in power bi Report server then i modified the rsreportserver config file to use the RSNegotiate before NTLM.
After trying to solve the issue with the mentioned above methods, i still get a NTLM method in network monitor which is installed in the Active Directory.
Any suggestions how to solve this issue? Thanks in advance.
I am setting up a service tier for MS Dynamics NAV 2009, but am unable to connect due to a login failure.
Login failed for user 'DOMAIN\ANONYMOUS LOGON'. Reason: Token-based server access validation failed with an infrastructure error. Check for previous errors.
Error: 18456, Severity: 14, State: 11.
I have the following servers:
SQL Server: sql-dev
Dynamics service tier: dynamicsService
The SQL and Dynamics services are both running under the same domain account.
I have four spns setup:
MSSQLSvc/sql-dev.mycompany.com:1433
MSSQLSvc/sql-dev:1433
MicrosoftDynamicsNAVServer$Dev/dynamicsService.mycompany.com:7046
MicrosoftDynamicsNAVServer$Dev/dynamicsService:7046
Finally, I have Delegation setup for the domain account for both the Dynamics and SQL service. This looks to be the correct setup according to the MS documentation, but it is not working. Any thoughts to where I have gone wrong? Thanks.
Just setting SPNs is not enough. Service Account of SQL Server and Dynamics NAV Service Tier are important. Also their permissions, enabling the Object Change Listener and delegating Access to the SQL Server Service.
If you did all the setup described in this MSDN Article Walkthrough: Installing the Three Tiers on Three Computers, it should work. I did 60+ Setups of NAV 2009 Service Tier that way in the past.
Unfortunately, Delegation Setup in Dynamics NAV 2009 is complex. I suggest get help from Microsoft Support if you are Microsoft Partner or get help from your Dynamics NAV Partner if you are a customer.
When I try to access Office 365 Group Connectors, either in the Outlook web or via Teams app, I receive an error message similar to the one below. Is there some permission missing from my account that prevents me from using connectors?
:-(
Something went wrong.
Message=The remote server returned an error: (403) Forbidden.:ErrorDetails=Operation=GetJoinedGroups:HttpStatusCode=Forbidden:ErrorCode=ErrorAccessDenied:ErrorMessage=Access to OData is disabled.:InnerErrorType=:InnerErrorMessage=:CorrectiveAction=NoAction
RequestId: 2988daef-51e0-4ccb-9145-109b0f806bf8
Server: DM5PR02MB2409
Date: 2016-11-17 16:10:36 -0600
Please escalate this issue to Office 365 Support. This is related to a setting your Tenant Admin has configured.
I try to use Outlook mail api connector but it not work for me. I cannot manage to connect. I follow the documentation and I still stuck, I receive a http 401.1 error . In the init component, I fill client_id and secret_id, but I don't Know where to find access token. I try with oauth sand box, I generate an token and fill it to init conponent in the esb connector and it work.
But never manage, to make it work without aouth sand box.
Any help, thks
You can refer here to associate an Azure subscription with Office 365 account (Azure AD) or create a new Azure subscription and associate it with your Office 365 account.
For getting an access_token, you have to associate an Azure subscription with Office 365 account (Azure AD). You may refer here.
once you get cliend_id and client_screte, you may refer here (step two and three) to get an access_token and refresh_token.
We're having a hard time figuring how these credentials objects work. In fact, they may not work how we expected them to work. Here's an explanation of the current issue.
We got 2 servers that needs to talk with each other through webservices. The first one (let's call it Server01) has a Windows Service running as the NetworkService account. The other one Server02 has ReportingServices running with IIS 6.0. The Windows Service on Server01 is trying to use the Server02 ReportingServices WebService to generate reports and send them by email.
So, here's what we tried so far.
Setting the credentials at runtime (This works perfectly fine):
rs.Credentials = new NetworkCredentials("user", "pass", "domain");
Now, if we could use a generic user all would be fine, however... we are not allowed to. So, we are trying to use the DefaultCredetials or DefaultNetworkCredentials and pass it to the RS Webservice:
rs.Credentials = System.Net.CredentialCache.DefaultNetworkCredentials
Or:
rs.Credentials = System.Net.CredentialCache.DefaultCredentials
Either way won't work. We're always getting 401 Unauthrorized from IIS. Now, what we know is that if we want to give access to a resource logged as NetworkService, we need to grant it to DOMAIN\MachineName$ (http://msdn.microsoft.com/en-us/library/ms998320.aspx):
Granting Access to a Remote SQL Server
If you are accessing a database on another server in the same domain (or in a trusted domain), the Network Service account's network credentials are used to authenticate to the database. The Network Service account's credentials are of the form DomainName\AspNetServer$, where DomainName is the domain of the ASP.NET server and AspNetServer is your Web server name.
For example, if your ASP.NET application runs on a server named SVR1 in the domain CONTOSO, the SQL Server sees a database access request from CONTOSO\SVR1$.
We assumed that granting access the same way with IIS would work. However, it does not. Or at least, something is not set properly for it to authenticate correctly.
So, here are some questions:
We've read about "Impersonating Users" somewhere, do we need to set this somewhere in the Windows Service ?
Is it possible to grant access to the NetworkService built-in account to a remote IIS server ?
Thanks for reading!
All details you need are included in this very old article
In short, when you find it confusing to troubleshoot issues like this, you should first review the technical details behind ASP.NET impersonation carefully.
Here are some things you could check out:
- set an SPN (Service Principal Name) for the reporting service; you can find good examples in google;
- Allow delegation (ClientCredentials.Windows.AllowImpersonationLevel)
Is the problem that you're failing to authenticate to IIS, or failing to authenticate to SSRS? The DOMAIN\MachineName$ account may need to be granted permission in SSRS to run the report you're trying to automate.
SSRS usually does a pretty good job of getting IIS configured correctly, so you shouldn't need to mess with those settings. I double-checked my installation (which is SSRS 2005, things may have worked differently in SSRS 2000 and you didn't say which version you're running), and it's set to use Windows authentication and has impersonation enabled. That means IIS should basically just be authenticating your credentials (validating a correct username/password), not authorizing (determining whether that user has permission to run the report in question). IIS then passes the credentials on to SSRS, which has its own settings for determining what accounts have permission to view reports.
Also, you can automate sending reports on a scheduled basis directly in SSRS, so you may not need the Windows service at all if your scheduling is fairly basic (i.e., daily, weekly, etc.).