Password-less 5 of 5: Enabling password-less for 3rd party applications – Part 2

Migrating 3rd party applications to the Azure Active Directory

In my previous blog post I’ve described how you can discover 3rd party web-based applications which are used in your environment and what options in general are available to connect them to the Azure AD to make them password-less. This blog will continue this story and will tell you how to connect these apps to the Azure AD, of course with a few examples.

After you’ve discovered the applications in your environment and listed them, the next step is migrating these applications to the Azure AD. For this, as described in my previous blog post, there are a few options. If your application was connected to AD FS you can either use the gallery app (preferred) or if your application isn’t listed in the gallery the non-gallery option. For all other apps you need to check what SSO methods are available for your application to make the appropriate decision.

The list below can help you out in what Azure AD supports at the time of writing this blog post:

  • Azure AD Gallery applications support:
    • SAML protocols – Single Sign On via SAML;
    • OpenID Connect protocols – Single Sign On via OpenID Connect;
  • Non-Gallery applications support:
    • SAML protocols – Single Sign On via SAML;
    • OpenID Connect protocols – Single Sign On via OpenID Connect;
  • On-premises applications with Application Proxy support:
    • SAML protocols – Single Sign On via SAML;
    • Password-based – Same Sign On by pasting the credentials which you used on Azure AD to logon to a different app with the same credentials.
    • Windows Integrated Authentication – Single Sign On via kerberos constraint delegation to on-premises applications connected to Active Directory;
    • Header-Based Authentication – Requires Ping Identity to work properly;
  • Custom-developed applications support:
    • App Registrations – Provides permissions to online resources (which can be for example data, user information or apps) based on the permissions set on the App Registration within Azure AD. This requires the user to consent access or the admin to consent for the whole organization;

Now you know what your app supports and what mechanism is available for it in the Azure AD, it’s time to map the application to an option within the Azure AD.

NOTE: If you have test environments for all or some applications I would highly recommend to start migrating those test environments first. This as you can document the steps required for production to make sure downtime for production applications is as short as possible. If you don’t have those test environments it’s important that you communicate to your end users that there will be scheduled application maintenance / downtime. This as you’re about to ‘move’ the authentication from AD FS based, App Based, Active Directory based to Azure Active Directory based.

To support you through this process I’ve made two examples, one app (Slack) which I’m going to connect via an Azure AD gallery App to the Azure AD and another app (webpage hosted on IIS) which I’m going to connect via the Azure AD application proxy to the Azure AD with SSO.

Example 1: Connect slack to the Azure AD

Open the Azure AD Portal and go to the ‘Azure Active Directory‘ blade, in there go to ‘Enterprise Applications’ and hit ‘New Application‘. In here search for the Slack application and select the application. The screen below will open.

By selecting the application from the gallery you can exactly see what the application supports in terms of Single Sign-On and Provisioning (Provisioning is covered in Part 3 of this blog). Now give the Application a ‘Name’ as how you would like it to appear on the My Applications portal and hit ‘Create’.

Once the application is created you are able to find it within the Enterprise Application list within the Azure AD, as you can see below.

When we open the created ‘Slack’ application we need to make sure it can be used by slack and the users within your organization. For that within the ‘Properties‘ of the application, make sure that the application is ‘enabled for users to sign-in‘, make sure it’s ‘visible to users‘ and set the ‘user assignment required‘ to either yes or no. In our example we will use the Yes value, meaning only users who are assigned within the app beneath Users and groups are allowed to use the application and are able to see it within the My Applications Portal. Once all set correctly don’t forget to hit ‘Save’.

Next step is to make sure the application is assigned correctly so only users who should have access to Slack are allowed to use it. For that I’ve created a group in Azure AD and assigned that group beneath the ‘users and groups‘ settings within the slack Enterprise Application in Azure AD.

Now the basic settings on the Enterprise Application of Slack in the Azure AD are configured let’s go to the ‘Single Sign-on‘ option and select ‘SAML‘ (which is supported as we saw that once we added the application from the gallery).

Now we are getting somewhere 🙂 and we are able to configure SAML for slack on the Azure AD end, configuring SAML always consists of 4 phases:

  • Basic SAML configuration;
  • User Attributes & Claims;
  • SAML Signing Certificate;
  • Set up Slack;

Let’s start with the basic SAML configuration by hitting the ‘Edit’ button, wait before editing the information as we need to get some details from the slack portal to complete this process.

Therefore open a separate tab and login as an admin to the slack admin portal and open the ‘Settings & Permissions’ beneath Administration.

In here go to the ‘Authentication’ tab and hit the ‘Configure’ button next to SAML authentication.

Keep this page open and hit ‘Custom SAML Instructions’ to be opened in a separate tab or window.

In here you will find the exact details Azure AD needs to service a logon request of slack.

Now going back to the basic SAML configuration page in Azure AD, please fill in the following configuration:

Once finished hit ‘Save’.

As you can see the basic SAML configuration in Azure AD is now configured correctly for Slack!

Now as not all of my users do have an email address I need to edit some claims, this as slack requires this information. For that reason I’ve decided to change some claims to not check the user.mail value in Azure AD but the user.userprincipalname value and send that to Slack as the email address.

This can easily be achieved by hitting the ‘Edit’ button. And select the claims we need to edit, those are marked in the print screen below.

In here in the ‘source attribute’ value make sure to change the value from user.mail to user.userprincipalname and hit ‘save’.

Once you’ve executed this in the ‘User Attribute & Claims’ overview you should see that the value user.mail isn’t used anymore.

Now it’s time to verify the SAML Signing Certificate, as you can see the notification email which is set is based on the admin account used to configure the app. This isn’t very helpful as that account doesn’t have a mailbox, meaning I won’t receive a notification if the certificate is about to expire. Therefore hit the ‘Edit’ button.

The screen below will open, in here change the notification email address to an email address which is in use and actively being monitored. You can also add more email addresses if you want or use a distribution group (tip). Once done and ready hit ‘Save’.

NOTE: Please be aware that this certificate needs to be changed on both ends, Azure will warn you via several emails (60, 30, and 7 days before the SAML certificate expires). If you don’t respond to those mailings the SSO functionality will break for sure.

Once save verify the correct email address is used and hit the ‘Download’ button after the Certificate (Base64) to download the certificate to your local PC in .cer format. This is the first thing which we need to configure the Slack application side

The other two points which we need are the ‘Login URL’ and ‘Azure AD Identifier’ which are listed at point 4 in the setup wizard. Both URL’s are identical for each application, therefore you can’t use these for other SAML configurations.

Now head back to the ‘Authentication’ tab within Slack under ‘Settings & Permissions’ and hit the ‘Configure’ button next to SAML authentication. In here enter the following information:

  • SAML 2.0 Endpoint (HTTP) – This is the Login URL copied in the step above.
  • Identity Provider Issuer – This is the Azure AD Identifier copied in the step above.
  • Public Certificate – This is the certificate file which you download in text format (open the .cer in notepad and use copy / paste).

Now open the ‘Advanced Options’ within slack,  as we are going to use a password-less behaviour with slack we need to modify the ‘AuthnContextClassRef’ value. The default setting is ‘PasswordProtectedTransport’ which basically means that you’re forcing the IDP (AzureAD) to login the user via username/password protected by SSL/TLS. This is exactly not what we want to use so in this case we need to set this value to ‘Don’t send this value’. This will leave the IDP (Azure AD) to determine the authentication method, which in our case would be password-less!

Once done the last step is to customize (if you want to) the ‘Sign In Button Label’ in our case we have set this to Azure AD. Once all configuration is done don’t forget to hit ‘Save configuration’ to apply the configuration on the Slack side.

NOTE: If you’re logged on with an identity which will be transformed to SSO (based on an existing UPN in Slack which matches a UPN in Azure AD), please verify all settings as you’re risking to loose access (preferably make sure you have created a separate Identity which won’t be SSO based which you can use as a break the glass account).

After you’ve saved the settings the following message should appear.

We are now almost ready to make test the behavior, first make sure the account which you’re using to test is a member of the group we created earlier. In our case we make sure that Johny Bravo is a member of the ‘Slack-Users’ group.

When we now visit the slack site ‘’ and hit the ‘Sign in with Azure AD’ button we can login to the Azure AD with the password-less behavior we enabled in the phone sign-in blog for Johny Bravo. As you can see based on the ID in the URL, this is matching the Login URL of the application configured in Azure AD.

After we have logged on we can see all the details which are provided within the claims are available on the account.

You’ve now enabled password-less for one of the Gallery Apps in Azure AD. The steps you need to take with SAML for a non-gallery app is (more or less) the same, you only need to configure the claims per application on your own instead of pre-defined claims. Next to that user provisioning (based on SCIM) is something you have to check yourself for non gallery apps. Unfortunately not all apps do support provisioning based on SCIM these days. More on that will be shown in part 3 of this blog :-).

Example 2: Connect website hosted on IIS to the Azure AD

Now you’ve seen how simple it is to integrate and provide SSO with a password-less experience to applications via the Azure AD with SAML the next questions comes up very often. What if my web application doesn’t support SAML (or OpenID Connect)? Well in that case the Azure AD App proxy is here to the rescue.

The Azure AD App Proxy offers all kinds of (SSO) functionality as described earlier, in this example I will connect a simple IIS website which is secured via Windows Integrated Authentication and will make the logon to the website password-less via the Azure AD & Azure AD App Proxy.

For that the first step would be to install the Azure AD Application proxy software. The server on which you install the Azure AD App Proxy must be domain joined if you want to provide SSO based on Windows Integrated Authentication (WIA), if you just want to publish a site without SSO via WIA this isn’t needed. Furthermore the Azure AD App Proxy doesn’t need any open inbound ports from the internet, this as the server will keep a tunnel open (based on port 443) with the Azure AD on which it can also receive incoming traffic. So the only connection the Azure AD App Proxy needs is outbound traffic based on HTTPS (443) and of course need to be able to communicate to the Domain Controllers and sites which you want to publish via the Azure AD App Proxy.

Once the connector is installed, please first check if it’s active in Azure AD, this can be done by going to the Azure Portal and opening the ‘Azure Active Directory’ blade. In there hit the tab ‘Application Proxy’. In here you should see the connector which is by default added to the ‘Default’ group.

As you can see in our case the machine is domain joined as that’s required because of the SSO we want to build based on WIA and the proxy connector is active. We are now ready to create an application, for this please go to the ‘Azure Active Directory’ blade, go to ‘Enterprise Applications’ and hit ‘New Application’. From here select the ‘Add an on-premises Application’.

Now fill in the Name, Internal URL, External URL, Pre Authentication and Connector Group settings. In our case we are going to publish an IIS Website (Friendly Name) which is reachable internally via http://im-admt01.identityman.local (internal URL) on the external URL (External URL). The website will be secured with Pre Authentication via the Azure Active Directory and will be published via the ‘default’ App Proxy connector group.

Once all done hit ‘Add’.

The application is now reachable via the URL, this URL can of course be changed to your own domain. This can be done by selecting a different domain in the drop-down in the external URL section. Please be aware that this also does requires a certificate for the domain name which you’re trying to publish, in our case that would be (when selecting the domain).

Now as the website within IIS is using Windows Integrated Authentication, let’s make sure that the application in Azure AD can delegate the logon within IIS as the logged in users in Azure AD. For that within the ‘IIS Website’ application in Azure AD, which we just created, go to the tab ‘Single sign-on’. In here hit ‘Windows Integrated Authentication’.

Now within the ‘Windows Integrated Authentication’ settings, please configure the SPN as is configured within Active Directory, in our case that is http/im-admt01.identityman.local (the configuration in Active Directory will be shown in a later step). Once done, select the ‘User principal name’ as the delegated logon identity and hit ‘Save’.

Now go to the ‘Properties’ of the IIS Website application in the Azure AD, in here you can apply a logo to the application and make sure that everyone can use the application by hitting ‘No’ at ‘User assignment required?’.

NOTE: If you don’t disable ‘User assignment required?’, it means that you have to assign the application to users or a user group via the ‘Users and Groups’ option beneath the ‘IIS Website’ application in Azure AD.

Now we have finished the Azure AD Configuration it’s time to double check our IIS configuration to make sure it’s ready to be used with ‘Windows Integrated Authentication’ via the Azure AD App Proxy. The first thing to check is the ‘Authentication’ on the ‘Default Web Site’. In here make sure that ‘Anonymous Authenticaton’ is disabled and ‘Windows Authentication’ is enabled (this as anonymous has a higher precedence than Windows Authentication).

NOTE: Please keep in mind that if your application is only using a virtual directory beneath the ‘Default Web Site’ to make the above changes only on the mentioned virtual directory and not on the root as that can affect all virtual directories.

Once ‘Windows Authentication’ is the only enabled authentication method for the IIS Website, hit ‘Providers’ on the right end.

In here make sure that ‘Negotiate’ is available and added and is on top of this list. Reason that Negotiate must be added and be available on top of this list is that we are going to use Kerberos Constraint Delegation (KCD). KCD requires Negotiate to be added in here and available on top of the list of ‘Enabled Providers’. Once done please hit ‘OK’.

Now the last step to make sure KCD is working based on the machine (computer) account, open the ‘Configuration Editor’ on the ‘Default Web Site’ within IIS and go to the section ‘system.webServer/security/authentication/windowsAuthentication’. In here make sure that ‘useKernelMode’ is set to ‘True’.

NOTE: If you are planning to use KCD based on a service (user) account (i.e. this would be needed if you’re load balancing the same website over two or more servers), alternate configuration is required which is described here.

Now the IIS configuration is finished it’s time to configure the servicePrincipalName (SPN) within Active Directory. As described above we are going to configure the SPN on the computer account of the web server as we are using a single server setup. For that go to the computer account in Active Directory which is hosting the web server, go to the ‘Attribute Editor’ tab and search for the ‘servicePrincipalName’ Attribute. In here add the value ‘HTTP/IM-ADMT01.identityman.local’ where IM-ADMT01.identityman.local is the URL which you also have used within the Internal URL during the Azure AD App Proxy setup and which your internal users are using to access the web server. Once done don’t forget to apply the configuration to the computer account.

The next step is to configure ‘Delegation’ on the computer object(s) which is / are running the Azure AD App Proxy service. For that within Active Directory search for the Azure AD App Proxy server(s) and go to the ‘Delegation’ tab. In here select ‘Trust this computer for delegation to specified services only’ and select ‘Use any authentication protocol’. Once done hit the ‘Add’ button.

Within the ‘Add services’ window search for the computer object hosting the IIS Webiste and SPN configuration and select the (HTTP) value we just added. Once selected hit ‘OK’.

As you can see right now the ‘Delegation’ is configured, which means that the Azure AD App Proxy server can delegated authentication requests for the IM-ADMT01 server which is hosting the IIS Website. Click ‘Apply‘ to save the configuration.

Now it’s time to test the sign in and see if we made this IIS Website login password-less. As you can see below when we go to URL we are prompted with a password-less sign-in.

After this successful password-less logon the default IIS Website is shown, which means my WIA logon works properly :-).

Apply additional Security

Now besides that we’ve made these applications password-less we can also apply additional security measures to these applications. This can be done via Conditional Access, as these apps are connected to your Azure Active Directory you can select them within the Cloud Apps section to apply security measures as you can see below (think of requiring Multi-Factor Authentication or requiring device compliance via Microsoft Endpoint Manager before being able to use the application).

NOTE: Please be aware that each app you just connected to the Azure AD is also matching to policies which do include ‘All Cloud Apps’. If an app doesn’t need to match a specific conditional access rule where it’s included via ‘All Cloud Apps’ make sure it’s excluded.

You now know what options you have to connect 3rd party web-based applications to the Azure AD and have seen two examples how to connect them. With all this information you can, besides making sure your users are working password-less, also make sure that those 3rd party web-based applications are secured via Conditional access.

In my next and closing blog of this password-less series I will describe how you can provision and deprovision users to those 3rd party web-based applications form the Azure AD. Again I hope you enjoyed reading my blog and stay tuned for more password-less love;-)!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s