anyone can help me understand how to authenticate to exchange server for a server application on behalf of a user? My use case is to sync the mails of a user's mailbox and update the read state and deleted states with our server. Exchange online has rest API and Oauth to authenticate but that does not work with On Premise account? Is there a way I can authenticate for all the different deployments[exchange online and on premise] and access the Outlook mail?
We need to way to authenticate the user without trying to getting any credentials, so that our service can access mailbox without any need for prompt.
Seems your best bet would be to use impersonation, which would work in either EXO on on-prem. Your sever would require a service account in Exchange, then authenticate with the creds for that single account. Before synching mailbox, it would set the impersonation ID to the MB it was synching. Of course an Exchange admin would need to set up impersonation rights for your service account for every MB your service would examine, but that's easily done with a little PowerShell, and willingness on their part, of course.
Related
Microsoft will end support for basic authentication in Exchange Online remote powershell October 13th, 2020.
Server-to-server communication can be done using the System.Management.Automation.Runspaces.WSManConnectionInfo class with basic authentication. What is the supported way for an on-premise daemon application to run remote powershell in Exchange Online when basic authentication is no longer supported?
If you don't want to rewrite your remote PowerShell code to use the new V2 Exchange Online Management module shown by #stukey above, you can use an alternative workaround by using ADAL (or a similar library) to fetch an access token from AzureAD, then use the token as password when constructing your PSCredential.
If you add ?BasicAuthToOAuthConversion=true to the connection URI, the server will then pull the token from the basic auth header and use modern authentication with the token instead.
The workaround is outlined here and semi-documented by Microsoft here.
Assuming your daemon application is using a Service Account ID without MFA, then you can utilise the new V2 Exchange Online Management PowerShell module to connect to EXO using Modern Auth. It handles everything for you, so you can still initiate a connection using your Service Account username and password credentials, and the module will use those creds to get a token from Azure AD and then authenticate to EXO using Modern Auth. Works great if your Service Account creds are managed by a separate password vault solution. If you can’t use credentials-based auth, then Microsoft are working on an update to the EXO module that will allow you to authenticate to EXO using a registered Azure AD app together with certificate-based auth. That should be coming soon...
I am connecting to CRM Online v9.0 using XRM Tooling Connector.
I am trying to update a Contact using WebAPI. Once the contact is updated, the a workflow is triggered that sends an Email to the Contact. However I am getting - User does not have privilege send as. When I check in the Code, CallerID for service object is set to {00000000-0000-0000-0000-000000000000}. I think this is the reason why my workflow does not execute successfully.
Can someone please help me with this.
Thank you in Advance.
I think this is a Security issue. There are specific security privileges required to act on behalf of or send emails on behalf of other users.
These privileges are on the Business Management tab in the Security Role.
In addition to this, the impersonated user must have also authorised emails to be sent on their behalf.
This setting is located in the the impersonated users personal settings
Google API Server To Server service account key is a simple json or p12 file which can be compromised in some scenarios. Is there a way to limit its use to specific IPs or domains from Google Developer Console? The support topics there are not helpful at all.
No service accounts cant be restricted to IPs or Domains. Currently if you have the correct credentials then you can use them.
This is why you need to keep them safe. However that being said i think its a good idea. I am going to see if i can find someplace to add it as a feature request.
Note for openid signin
Signin returns an id token this id token can be verified verify the hd claim matches your domain name. Again this only works if you are authenticating with the openid scope.
Response from Google
I contacted one of the developers on Google identity this was his response.
IP restrictions had some value many years ago. Now, most of the apps are hosted in the cloud and traffic can move around the world thus making the IP restriction not very useful. If service account credentials are compromised, it is time to get a new credential or they were used in an incorrect way.
I need to be able to store a user's Exchange password so I can use it to perform some task later on, using EWS. I know storing passwords in plain text is a horrid crime, so what options do I have?
In my case, my application will have access to an administrative account that will have the ability to use impersonation to work with users' Calendars. I need to store the password of this admin account so I can use it while authenticating with the Exchange server at a later time. I am not planning on using the EWS Managed API.
I have a user that created a calendar app with similar requirements. By default, an account that has these permissions globally is horrible and not recommended. Impersonation roles were granted by department that required access to the app to reduce risk scope. However if you require this globally, here's what I recommended for mitigating the account/password exposure:
Restrict the accounts functionality to Exchange services only. Features like log on locally and other general domain user privileges are not needed for an EWS service account that only needs mailbox access and impersonation roles. In this case, the account cannot log onto a computer nor can it be used for RDP. This limits exposure for malicious use.
The user/pass can be stored in your applications database and the connection string would also be stored outside of your application, there's a lot here: https://security.stackexchange.com/questions/22817/how-to-encrypt-database-connection-credentials-on-a-web-server and encrypting the password within the database; further reading: http://www.darkreading.com/safely-storing-user-passwords-hashing-vs-encrypting/a/d-id/1269374
Restrict DB server and management access. This is a larger issue than it should be if the database server is shared between groups. Audit the database server access, and re-restrict if you have too many cooks in the kitchen. The database server should also not be directly accessed by user networks but that may be a larger issue to tackle.
Restrict access to the application. As in, is it available externally or only available inside your perimeter? Either way, the application should also include authentication just to access, using Kerberos or some other SSL auth, make sure the application cannot be used to DoS the EWS services from over-access.
Create a one-off throttling policy on Exchange for this user and assign accordingly to prevent the application from breaking EWS or limiting regular user functionalities. This is something Blackberry admins learned the hard way if they didn't follow recommendations. When BES server wouldn't properly tear down connections, web services would start dropping valid client requests. As such BES had to instruct users to create a one off throttling policy for various Exchange features. I did the same for the user that created my EWS app. And a few times it saved me.
Really it will boil down to good application design and coordinating requirements with the Exchange team.
Don't's:
Don't store the username/password in Apache/IIS pages or the connection string
Don't grant global permissions for the account if you don't have to
Don't allow unauthenticated access to the application and allow unlimited connection times
Hope this helps.
This page states that before an application can access the API (I'm particularly interested in the Calendar API), it must be registered with Azure AD. Is this also true for organizations that may host their own Exchange servers?
Could someone provide a breakdown of what's necessary for me to get started with accessing the API to access the users' Calendar? I'm aware of the API reference, but I'm not entirely sure what's necessary to do before I can use the API.
That page is for Office365, not self hosted ones.
You can access your local/self hosted Exchange server with Exchange Web Services by using username/password, or even your local AD if you set it up correctly.
The API it is talking about is not available to on-premise Exchange Server, it is only available to Exchange Online in Office 365. This may change in the future, but currently you cannot use it in on-premise. Exchange Web Services is the way to go for on-premise.