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...
Related
We have a windows service that collects mail from via an imap connector and then processes that email and attachments into a database. Is there a way that we can do this using OAuth2 when exchange online removes support for basic authentication? There is no user interface to the service or user access to teh system when it is running beyond the start and stop of the service.
We are currently using Chilkat's excellent Imap component.
Yes, Microsoft have finally released support and documentation for this in Exchange Online. See the following Microsoft document:
Authenticate an IMAP, POP or SMTP connection using OAuth
Let's assume we can not get password of the current user, only username and domain if necessary. Is it possible to get a session token or something similar to authenticate with remote service using LDAP authentication?
UPDATE
I am writing a c# app that would get info from a web service written in Python.
Remote web service uses python LDAP module to manage LDAP users and authentication. I'd like to use logged in windows user identity info to log into remote service. I can modify the authentication logic in remote web service if "token based" or similar authentication is possible.
You didn't say what type of application you're using, but the only way to do this is with Windows Authentication. For a web application, the web server (IIS, Apache, etc) would handle the authentication and give you the name of the authenticated user.
In ASP.NET, the implementation also depends on if you're using the .NET Framework or .NET Core.
To give you any more information, you will need to specify what type of application you're working on and on which OS.
I have an on-premise CRM 2016 system that uses Active Directory and when I attempt to access the OData API from a desktop app, using network credentials, I get an un-authorised message.
After looking into this it would appear that I need to authenticate using OAuth which in turn would require installing AD Federation Services.
Before going down this path I would like to know if this is the correct approach to take?
I've been able to find plenty of examples on how to acheieve this using CRM online/Azure AD, but not much for on-premise 2016.
If your desktop app built on .NET framework and runs in the same local network as your CRM server then you can use XRM Tooling SDK instead.
https://learn.microsoft.com/en-us/previous-versions/dynamicscrm-2016/developers-guide/dn689057%28v%3dcrm.8%29
This SDK lets you create a CrmServiceClient object using a connection string from your configuration file. This object implements the IOrganization interface which means it has the CRUD methods you can use against your CRM.
CrmServiceClient service = new CrmServiceClient(ConfigurationManager.ConnectionStrings["mycrmconnstr"].ConnectionString);
Yes, that's the way to make it work with CRM On-Premise.
You will have to install and configure ADFS (according to documentation ADFS 3.0 is the latest version supported). Once everything is set up, the overall process is quite similar to when you're doing it in Online with AAD:
Register application
Add-AdfsClient -ClientId <CLIENT_ID> -Name <APP_NAME> -RedirectUri <REDIRECT_URI>
Grant application permission to CRM
Grant-AdfsApplicationPermission -ClientRoleIdentifier <CLIENT_ID> -ServerRoleIdentifier <CRM_URI>
Connect using Authorization Code Grant
Authorization Code is the only flow implemented in ADFS 3.0 (that's why I mentioned it before) so don't waste 4 o 5 hours trying to use Implicit like I did :(. ADFS 4.0 implements it (along with Client Credential and Resource Owner Password Credentials but in theory is not supported (although I've seen it working).
As you said the process is not well documented but you'll find some questions on forums or some blog post that will help you. I found THIS one very helpful, even though is not Dynamics related.
I am to be having a lot of problems, misinformation and confusion when attempting to find out the plausibility and viability of attempting this.
The requirement is for a remote client, accessing our website to be auto signed in with their Active Directory User account.
We have the option to setup a WCF service (or something similar) on their remote server for authentication purposes. Which from my little understanding is how this problem will be tackled.
So, my question after a little background is this.
CAN this be done, and HOW can it be done?
Instead of hosting a WCF service on their domain, I would look into installing ADFS on their domain.
You can change your website to accept security tokens from ADFS using the WS-Federation protocol. You can use classes from the System.IdentityModel namespace for that. An example of how to implement this in ASP.NET can be found here.
An alternative would be to use Azure Active Directory as your identity provider and have your client sync accounts to their AAD directory (or federate between AAD and ADFS). An example can be found here.
I am setting up an API for a mobile app (and down the line a website). I want to use oAuth 2.0 for authentication of the mobile client. To optimize my server setup, I wanted to setup an oAuth server (Lumen) separate from the API server (Laravel). Also, my db also lives on its own separate server.
My question is, if using separate servers and a package like lucadegasperi/oauth2-server-laravel do I need to have the package running on both server?
I am assuming this would be the case because the oAuth server will handle all of the authentication to get the access token and refresh access token functions. But then the API server will need to check the access token on protected endpoints.
Am I correct with the above assumptions? I have read so many different people recommending the oAuth server be separate from the API server, but I can't find any tutorials about how the multi-server dynamic works.
BONUS: I am migrating my DB from my API server, so I would assume I would need the oAuth packages migrations to be run from the API server also. Correct?