Using Entra to log into an application without SAML/OAUTH/OIDC

I've shown some examples of integrating apps into your Entra login, however that assumes you are using a modern-ish app. For some legacy apps you still need to enter a separate username/password or worse they use a shared credential that needs to be rotated when someone is offboarded.

Let's see the solution Entra has for this.

For the purpose of this I'm going to use Wazuh, an open source XDR/SIEM that I run in my homelab so that I can navigate to it's dashboards, stroke my non-existent beard, and nod sagely. Wazuh supports several auth methods, but I'm doing it this way as a demonstration.

This setup requires a Windows Server VM that can reach your application as well as internet accessible, and Private Access enabled in Entra which requires an Entra P1 bundle license or the standalone SKU.

In the Entra portal drop down into the Applications -> Enterprise Application and then Private Network Connectors. Make a new connector group if there isn't one, and make sure to Enable Private Network connectors.

Download the connector service executable and get it onto your Windows Server and run it, auth'ing with credentials when necessary. You should see the server name and public IP show in your Connectors blade similar to the above once everything is running.

With that legwork out of the way we go to the Identity -> Applications -> Enterprise applications and New Application

Enter the name of the App we want and select the Application Proxy option and hit create.

Fill out the Name field that will be user-facing, if it's different from your internal. Internal Url will be either the FQDN or IP:Port that your Windows Server can reach the application at. External Url will be what users can visit the application direct, you can enter a CNAME for your DNS to this later if you'd like a better FQDN than what's attached to your tenant. Change Pre-Authentication to Passthrough for now. Make sure the Connector Group matches the one you installed earlier if you have multiple, and then hit Create.

Now if we go to that External URL direct, we should see the landing page.

Back in the Entra Application, navigate to Single sign-on and select the Password-based method.

In the next field, I put the full URL that is the actual login page and Save.

Hopefully, your application detects the fields correctly. It claims it does in this instance for Wazuh, but I'll show later what to do if it doesn't. It does however, report the fields in a potentially confusing manner, let's clean that up.

Check the Advanced: View and edit sign in field labels and click on Edit Sign in field labels put in Username for param_1 and Password for param_2.

You should see it updated now.

Now while in the application still, navigate to User and groups section. Add either your specific user(s) or group to this. Click on the Unknown under assign credentials, flip the toggle to Yes and enter the shared credential here for user/pw and click OK.

Go to Application proxy and change the Pre-Authentication from passthrough to Microsoft Entra ID and hit save.

Testing with a user we granted access, we visit myapps.microsoft.com and see that the Wazuh tile is there. Click on it, verifying which user we are using.

If it works for your app, you should be logged in now and can leave this blog if it was a success. Note that they have to launch the website from the myapps tile, it will not automatically login if they bookmark and go to the url that way.

What happens if it doesn't detect the field properly? We need to revisit the Single sign-on section.

Click on the Configure Single Sign-on Settings. Change it to manual and then Capture Sign-in fields.

You should then be prompted to install the My Apps Secure Sign-in Extension if not, click the link in this sentence and do so, relaunching the workflow above.

Once you get the extension installed and running you should now be all set to continue. Manually go through the login process, typing in credentials and pressing the Login.

You should see the following notifications (done in Edge) to confirm capture and that it was done successfully.

After this, visit the User and Groups of the application and set the credentials again with the new fields. Test the myapps.microsoft.com launch again and everything should work now.

We're done! Or not, because we now depend on this extension being installed for the user. Let's create an Intune policy that pushes this extension to only the users that need it.

In the Intune portal we go to Devices -> Windows.

Configuration -> New Policy

Select Windows 10 and later and Setting catalog.

Type in the name and description.

Add Settings and find the "Control which extensions are installed silently" in Microsoft Edge\Extensions. I'm doing this for Edge, Chrome has a similar setting and Firefox you'll need to add their admx before this.

Add the app id that edge looks for, in this case gaaceiggkkiffbfdpmfapegoiohkiipl and press next.

Assign the specific users or groups who will need this extension in the Assignments and Create the policy.

Now we are all set. Whenever those users are on an MDM device, they'll be able to have the extension installed silently and there should be no user workflow disruption from clicking the tile in myapps, to being logged into the app.

Overall it's clunkier than pure SSO, but if you're familiar with the Okta portal and logging into individual tiles, this is Microsoft's version with a similar workflow.