In BizTalk 2016, when I enable a Receive Location using the adapter "Office365 Outlook Email", it raises an error message in the Application Event Log:
Details "Service account does not have sufficient privileges. Please
make sure the service account is a member of the SSO Administrators
account.".
All our host instances run under an account that is BizTalk Admin, but probably not SSO Admin (I will get some with AD to verify). If I remember, that is the minimal security needed. Seems like a bad practice to add that user to SSO Administrator group.
So if I understand, the best practice might be to create another HostApp user account with BizTalk Admin and SSO just for this one adapter. This sounds kind of crazy and overkill to me - but is that what would have to be done?
Related
I am developing a web application that uses Microsoft accounts to sign in. How can I safely and reliably grant external users access to this application by email address without requiring that I train users on Azure administration or have to implement some approval mechanism via API?
I believe that it is dangerous to use the ClaimsPrincipal.Identity.Name, which returns an email address. It uses the "preferred_username" claim behind the scenes, which along with the "email" claim are documented to not be a safe and reliable way to identify a user, so I assume that's user configurable and thus can be spoofed by a creative user.
It seems like if the user knows the email address or account name that they use to sign into their Microsoft account, that should be enough to authorize that user to access the application without requiring that they go through an additional step of verifying an email which I trust they use to sign in, but I can't seem to find a way to do this.
Here is the process of creating and granting the external users access to the application:
Please go this document for more details:https://learn.microsoft.com/en-us/graph/api/invitation-post?view=graph-rest-1.0&tabs=http
Hope this helps.
Regarding BizTalk 2016, this seems like it should be dead simple, but failing with a security error.
Documentation basically says "Enter the username and password of a user that's a member of the SSO Administrators group."
https://learn.microsoft.com/en-us/biztalk/core/install-and-configure-biztalk-tms-for-fp
I ran BizTalkTMS.msi (to install the Token Manager Service) under my userid (which is also a member of the SSO Admin group as defined in the BizTalk configureation.exe program. It prompts for user/pass to under which the service should run. I put the exact same account "domain\user" that is running the Enterprise SSO and supposedly the correct password.
It returns the error: "BizTalk Server TMS failed to start. Verify that you have sufficient privileges to start system services."
If I'm using the exact same account that is running Enterprise SSO, how could this happen? We've tried about 3 other IDS, and they all give the same error. What could be missing?
Trying to set this up to resolve issue: "Office365 Outlook Email - Sign-In button on Receive Location does nothing" (similar to here)
You have to use both the user that is in the SSO group, and run BizTalkTMS.msi as an administrator. Either do "run as admin" on it, or open a command prompt as admin, then run it from there.
My company just finish set up a reporting services server 2017.
The service run under a domain name.
At the same server, an IIS has been setup to run a web application in ASP.NET which will server the report from a report viewer. The IIS is currently running with default App Pool.
GOAL : We want client to be able to access the report from the web application without having to fill in the username and password from anywhere be it on intranet or internet.
Before this, we have ssrs 2008 with similar setup but for authentication we go with anonymous authentication, which is what we want, they can view report from anywhere.
But from microsoft site, they stated that authentication isn't supported anymore in the latest version, and we have tried doing it which results in error 401: Unauthorized.
Currently, I'm trying to do a kerberos authentication,
Things that I have done :
SPN for reporting services account.
Delegation for reporting services account.
Web application web.config I've added authentication mode="Windows" identity impersonate="true"
On IIS, I've enabled windows authentication and impersonate.
But when I try to request a report from the web application, I still got the prompt for username and password, when I fill in my domain and password, I still got the same error 401: Unauthorized.
Am I doing something wrong? Is Kerberos really suitable for my GOAL?
Thanks in advance.
EDIT : Sorry, If I am posting in the wrong section. I don't know where is the correct section for this question.
When you are planning to deploy the reporting service on the internet its batter to use the custom authentication instead of the windows authentication. Creating a custom authentication extension requires custom code and expertise in ASP.NET security.
If you do not want to code a custom authentication extension, you can use Microsoft Active Directory groups and accounts, but you should greatly reduce the scope of a report server deployment. The following guidelines describe how to support this scenario:
Create a low-privileged domain user account with read-only permissions. The account must have access to the computer hosting the report server. Provide a custom Web form so that users can log on using the low-privileged domain account.
Create role assignments that map the user account to specific items in the report server folder hierarchy. You can limit access to read-only operations by choosing as the role assignment the Browser predefined role.
Configure reports to use stored credentials to get data for the report. This approach is useful if you want to query the external data source using an account that is different from the account that allows access to the report server.
you could refer to the below links for more detail:
https://learn.microsoft.com/en-us/previous-versions/sql/sql-server-2005/bb283249(v=sql.90)?redirectedfrom=MSDN#configuring-authentication-for-extranet-and-internet-access
https://learn.microsoft.com/en-us/sql/reporting-services/security/authentication-with-the-report-server?view=sql-server-ver15
https://forums.asp.net/t/2095478.aspx?401+Unauthorized+SSRS+authentication+from+NET+IIS
https://forums.asp.net/t/1273411.aspx?Setting+up+Reporting+Services+with+IIS+Access+Denied+Error
I have been working on a server to server google calendar integration, where by it connects, reads and writes to a user's calendar.
This is working perfectly fine, however I have a question regarding permission scope. Using a service account with domain wide delegation, it means that this account has access to calendars for every single users in the organisation from the CEO to me...
Is there a way of limiting this scope from Google's side, so that the service account can only access specific accounts, similarly to how EWS allows delegation rules.
One idea I had was to create a separate organisational unit and create the project under that (not tested this theory, but it also doesn't feel very scaleable).
Any ideas?
Thanks
The service account only has access to whatever is shared with the account, as per Delegating domain-wide authority to the service account:
an administrator of the G Suite domain can authorize an application to access user data on behalf of users in the G Suite domain
This means that the service account only has access to data from the account the application is impersonating.
In your case, using Org Units would not fulfill your requirements.
These controls have to be implemented on the application level. AKA by you.
One of the ways you could do this is, before impersonating any account, use the service account to query which Org Unit that account belongs to, and then based on that allow or deny the impersonation.
Of course, you can also do this type of filtering in multiple ways. You could simply check if the account you wish to impersonate is on a blacklist and abort the impersonation if that's the case, or you could use other criteria.
Hope this helps!
First and foremost: A service account is technically a superadministrator once DWD (domain wide delegation) is enabled and the client ID authorized by any admin in the Admin Console.
That translates to: a service account can impersonate any user including any administrator and performing any action allowed by the declared scopes.
In this case: A service account with allowed scope https://www.googleapis.com/auth/calendar.readonly can read any domains calendar.
Now there's a somewhat nasty workaround:
A service account is basically a gmail account without access to the web UI. So you can indeed share a calendar with a service account if and only if external calendar sharing is enabled. Then you do not use DWD. In this case the service account can only act as the sharing permissions dictate. However this is not how a service account is supposed to be used.
I'm writing service which will use for sending emails in my ASP.NET project. I tested two approaches for autentification on Exchange:
Since my service is running under
local user I allowed for it an
anonymous access and pass login and
password to Exchange Server.
Another way is domain authorization
on Exchange: before I invoke
smtpClient.Send() method I
impersonate(in code) an exist domain
user with access rights to sender
mailbox.
All of this ways works well but I really little confused how it should be as a good scenario. If I have a feature for sending mail on my ASP.NET site and Exchange Server -- what type of autentification on Exhcange user policy is preferable (1 or 2, ...)?
Option 3: Configure your service to run with a domain user account.
If so, this would be the preferred option, IMHO. Exchange can then be configured to allow access to a know domain user, avoiding the need to require anonymous access and, importantly, you don't have to secure away credentials in your service configuration in order to impersonate a domain user.
Indeed, you could configure your service to run under the security context of the user that you're impersonating.