I want to have a windows service that can received unread mail from my O365 account every 3 minutes and have different action depends on Mail subject. I choose EWS managed API instead of Graph is because maybe I would use this program on Exchange Server in the future. I'm following this tutorial Authenticate an EWS application by using OAuth and I have some question about permission control, in this case I use Application permissions which run without a signed-in user present. for example, apps that run as background services or daemons and can access multiple mailboxes.
Now I can access my mailbox with the applicationID, tennatID and Client-secret. But I have to inpersonate someone within my tennat(domain) and than I can send mail by the Mail Account. My question is Is it have any permission control can set that this application only can access or inpersonate part of tennat user rather than all user within my tennat? (in Azure AD Api permission setting I only seen full_access_as_app - Allows the app to have full access via Exchange Web Services to all mailboxes without a signed-in user.) I think its not make sense if this application have permission that can impersonate ALL user of my organization, that would be a big deal if this application client-secret exposes.
Sorry for my poor English.
You can use Application access policies to scope your application so it only has access the mailboxes it needs. see https://learn.microsoft.com/en-gb/graph/auth-limit-mailbox-access.
Related
How do third party mailapps like samsung email and many others get access to exchange data without being registred as a application in the azure ad?
Every guide about exchange authentification (OAuth) i found online had the requirement to register your application in the azure active directory before it can be used to read mails etc. But if that's the case, how do widespreaded mailapps like samsung deal with this problem? They are never listed as an registerted application, yet they have full access on your mails, calendar etc. In real-time too.
I try to solve this with an app that is written in c# using the .net framework. I dont know if that is already a problem in that regard.
How do third party mailapps like samsung email and many others get
access to exchange data without being registered as a application in
the azure ad?
Samsung have their own Azure Application registration that must be consented to its generally done once by the tenant admin.
There is a good reason for the consent framework to allow both control of what applications can access data but also to allow for the correct auditing of the access. If you want to know what App registration a particular mail client is using just look at the Azure Signin logs. Another recent case was around this Apple's mail app see https://practical365.com/microsoft-auto-update-apple-mail-app-profiles/
I have a Windows Service which currently sends emails of office 365 users using their email and password via the older smtp method.
Microsoft is turning this ability off very soon.
Currently I use mailkit and c# within a windows service
The only details I have are the users smtp username and password
My app has no user interaction ability as it runs on another box
I have read many ways about how to send email with oauth2 and ms and it seems a lot of people do it differently, and their is no clear path. I have seen such as using ms azure registered applications and different azure library's.
So my question is, what is the easiest route to take regarding a new non user inactive service being able to still send email on behalf of a user.
Most of the users I deal with are not able to setup up azure and it's products as their are small companies with limited it support.
I feel like I have perhaps gone down the wrong path of trying to use azure graph
So what is the correct, most similar to smtp and simple route to recreate a simple email sending windows service using c#
Thank you for your time in reading this
As far as I know Microsoft usually recommends the use of the GraphApi for this stuff.
The preferred way would be to use delegated permissions, i.e. your application has the permission to send an email in the name of the logged in user. If I understood you correctly that is not an option for you because you want to send the mails from a non-interactive background service.
That means that you application itself needs the permission to send an email in any users name. Obviously this is a much broader permission and you should think about if you really want to do it this way. Also, if you are in some kind of corporate context, you might also have to involve and get consent from the data protection officer or the like.
On the technical side such a permission is called an "application permission" thus you need the Mail.Send application permission which requires admin consent i.e. not the individual users of your application decide if they what to give you permission to send mail in their name (this would be delegate permissions) but an AAD admin has to consent for all of them at once.
See https://learn.microsoft.com/en-us/graph/api/user-sendmail?view=graph-rest-1.0&tabs=http#permissions
and https://learn.microsoft.com/en-us/graph/permissions-reference#application-permissions-38
I have started to research how to send a mail with Microsoft Graph, but I'm not sure if my scenario is supported.
I need to send a mail at a certain time from a service for a certain user in our company.
I have an application configured in Azure that has the permission for using the Microsoft Graph to send an mail as a user, delegated or not delegated.
I know how to send a mail through the API with a logged-in user.
Is it possible to do this for a user that isn't logged in on the machine at that time or didn't provide an accestoken to my backend server ( bearer token)
Is it possible to do this for a user that isn't logged in on the machine at that time or didn't provide an accestoken to my backend server?
No, you need an access token to access the service on behalf of someone else. There is no way to circumvent that so you can perform actions as a user that hasn't authenticated against the service.
// How to get different user / meeting room calendar events?
We are trying with the graph REST API to get calendar events of another user (shared calendar to the authenticated user) or a meeting room (should be an Active Directory user with shared calendar to all users within the organization).
We still get "Forbidden" response.
We can successfully get the user(himself) authenticated calendar events.
We can also get user details of the authenticated user and even of another user (user authenticated as John.Doe#company.com and can get user details of elise#doe.company.com) but we cannot get details of the meeting room user even though it should be a normal user in our AD.
We tried to setup all delegated and even app permission scopes, nothing helped.
Example:
var endpoint = "https://graph.microsoft.com/v1.0/users/"+userId+"/calendarView";
Is there a way to retrieve this information?
The problem is that your token does not have the correct scope. To be able to access shared calendars, you need the Calendars.Read.Shared (or Calendars.ReadWrite.Shared). How you get that scope into your token depends on where you registered the app (which answers your first question!)
Does it matter where or how the application was registered?
Yes, this matters. Both methods will work, but where you register affects how you request authorization and tokens. Also, apps registered in Azure Management Portal can only authenticate Office 365 users, not Outlook.com users. More on this in #2.
Does it matter what authentication URL we use?
Yes! The URL you use is directly related to which place you registered your app. I'm going to break this down below.
App scope permissions vs delegated scope permissions - does it matter which ones we set up in the application? Will our desired functionality work with delegated permissions?
Yes it matters. App permissions are granted to the app, and for Outlook APIs, these are global to the entire organization. So if you grant an app Mail.Read, it can read mail for all users in the org. The app acts as itself, and does not authenticate a user. Because of this, the auth method requires a certificate instead of a client secret. This method is meant for daemon-type apps. You most likely want delegate permissions since you want to authenticate users and then give them access to just those other mailboxes/calendars they are allowed to view.
Do AD permissions somehow influence the permissions user has in the application?
Well yes, in the sense that if you include a .Shared scope in your permissions, what the user has access to is set by what other users have shared with them (and this ties back to AD).
How do I add a shared scope
As I said above, this matters on how you registered your app.
Azure Management Portal
Apps registered in the Azure Management Portal use the "v1" version of Azure's OAuth2 implementation. Under this model, you have to specify the permissions for your app "up front" on the app registration itself. To add a shared permission, you have to modify the app registration in the portal. The permissions are shown in the portal as "Read user and shared calendars" (for Calendars.Read.Shared) and "Read and write user and shared calendars" (for Calendars.ReadWrite.Shared).
If your app is registered here, then you MUST use the v1 auth and token endpoints:
https://login.microsoftonline.com/common/oauth2/authorize
https://login.microsoftonline.com/common/oauth2/token
Additionally, under the v1 scheme, if you add new scopes to your app registration, you MUST have the user's reconsent. Otherwise, the next time they sign in to your app, they will just get the same permissions they had before. To do this, when sending the users to the authorize endpoint, add a prompt=consent parameter to the authorize URL.
Application Registration Portal
Apps registered here use the v2 Azure implementation and gain a few benefits. First, you can authenticate Microsoft accounts (Outlook.com) as well as Office 365 users. Second, adding scopes doesn't require modifying your app registration. And last, you don't have to manually reconsent users, the auth endpoint will detect the change and prompt for you.
Apps registered here use the v2 auth and token endpoints:
https://login.microsoftonline.com/common/oauth2/v2.0/authorize
https://login.microsoftonline.com/common/oauth2/v2.0/token
Scopes are specified in the scope URL parameter in the auth endpoint. So to add the shared scopes, you would just replace your existing Calendars.Read and/or Calendars.ReadWrite with the .Shared equivalent.
When a user runs an on-demand workflow in Microsoft CRM 2011, is it possible to access their credentials?
I am creating a custom workflow activity designed to access a sharepoint server with shared Active Directory accounts. I would like to be able to use the user who runs the on-demand workflow's credentials for Sharepoint authentication. Is it possible to access these credentials in custom code? If so, how (C# if possible)?
Unfortunately it is possible to get the credentials but you won't be able to use them to authenticate to the Sharepoint Server, at least in the online versions.
We had a similar scenario but in the end we had to use a special user to do all the work in sharepoint, we were triggering the code with a plugin and using the REST Endpoint to do the work.
You can access the the User Credentials from the localContext, but you won't be able to retrieve the password.
Is your environment onpremise or online?/