Enabling conditional access for azure active directory applications

I’m in the process of updating my Managing Identities in Azure Active Directory course on Pluralsight. One of the demos in the course is configuring Conditional Access for an Azure Active Directory integrated application. The idea is that you can set up a Conditional Access policy that restricts users from logging into the application from outside the US. When I went to go record the updated demo, the application I had created in Azure AD was missing. What followed was a journey into the bowels of Azure AD to find what triggers the appearance of an app in Conditional Access.

Update: Microsoft has fixed the bug. Hurray!

Earlier in the course I create an application called Marketing App using PowerShell and the AzureAD module. The commands I run are as follows:

$app = New-AzureADApplication -DisplayName "Marketing App"  -IdentifierUris "http://marketing.contosoned.xyz"
New-AzureADServicePrincipal -AppId $app.AppId

The commands will successfully create an application in Azure AD and give it a Service Principal to be used for SSO.

In a later module, I walk through the process of configuring a Conditional Access policy to control access to an Azure AD application. In the original demo I used the Marketing App, but this time when I got to the Cloud Apps section of the policy the Marketing App was not there. There is no indication of why some apps appear and others do not. Looking at the documentation on the Microsoft Docs site, the guides walk you through adding an application, but they presuppose that the application already appears in this Cloud Apps menu.

I sent out a Tweet to the Microsoft MVP peeps. I sent an email to the MVP distribution lists. There were some nice suggestions, but nothing panned out. I stepped away from the keyboard for a bit. It occurred to me that it might be a licensing issue. Conditional Access for Azure AD apps requires at least an Azure AD Premium 1 license. When I created the Marketing App, I had not yet purchased the Azure AD Premium license. That was something I did a day or two later. Maybe there was something in the application creation process that checks to see if you have an Azure AD Premium license in the tenant, and flags the application as licensed for Conditional Access? To test my theory, I deleted the existing app from the portal and created a new Marketing App from the portal.

Huzzah! Now my Marketing App appeared in the Cloud Apps list. It must have been the missing Azure AD Premium licensing when I created the first app. Well that’s just dumb, and there should be a way to fix it without deleting the app. But at least I had the solution right? Right?

No.

Eagle-eyed observers will notice that the first time I created the application it was using PowerShell, and the second time was through the portal. Suffice to say, those workflows do not produce the same results. This occurred to me later in the day, so I decided to test my theory. I created a new Marketing App v2 using PowerShell, and sure enough that application did not appear in Cloud Apps. I also noticed that the Marketing App I created with the portal had Conditional Access available when viewing it as an Enterprise Application, and v2 of the Marketing App did not.

Clearly there was some difference between how the portal was creating my application, and how the commands in PowerShell were doing it. Essentially, the portal was making some implicit assumptions, without telling me. The first one I discovered was in the configuration of the Service Principal. When you register an application in the portal, it automatically creates a Service Principal for you. When using PowerShell, you first create the application in one command and then the Service Principal in a separate command. I compared the properties of the Marketing App and Marketing App v2 Service Principals and determined that the former had the entry WindowsAzureActiveDirectoryIntegratedApp in the Tag property. The v2 Service Principal had no entry in its Tag property. Sure enough, looking at the docs for the New-AzureADServicePrincipal command it notes the following for the -Tags parameter:

Note that if you intend for this service principal to show up in the All Applications list in the admin portal, you need to set this value to {WindowsAzureActiveDirectoryIntegratedApp}

Wow, so that’s not obvious at ALL, but there it is in the docs. I recreated v2 of the application by running the following:

$app = New-AzureADApplication -DisplayName "Marketing App v2"  -IdentifierUris "http://marketingv2.contosoned.xyz"
New-AzureADServicePrincipal -AppId $app.AppId -Tags "WindowsAzureActiveDirectoryIntegratedApp"

Going back to the portal, I now see both versions of the application in the Enterprise Applications - All Applications view.

The v2 of the application was not in this view before, so basically the WindowsAzureActiveDirectoryIntegratedApp tag is what marks an application as an Enterprise Application. Good to know.

Looking at the v2 entry details, I now can see the Conditional Access tab. Great!

Things aren’t great though. If I click through on that Conditional Access button and try to create a policy for the application, I see this weird error on the Cloud App selection screen.

Huh? I’m going to quote the error so people can find this through web searching.

1 cloud apps configured in this policy have been deleted from the directory, but this doesn’t affect the other apps in the policy. The next time you update the application section of the policy, the deleted apps will be automatically removed from it.

What the hell? The application definitely has not been deleted. I got here from its details page. Something is - to use the technical term - hinky with this error. I went back and compared the properties of the two Service Principals again, and went down a few dead ends having to do with Oauth2 permissions.

I won’t bore you with the details. Suffice to say, it was a waste of time, but it did point me back at the Application objects. After comparing the properties of the two application objects, I realized that my original Marketing App had a ReplyURL set, whereas my v2 app did not. It appears that the Conditional Access portal needs the app to have an entry in the ReplyURLs property, or it won’t list the application in the Cloud Apps.

Basically, the details page for the Enterprise Application will show the Conditional Access link if the Service Principal Tags property has the WindowsAzureActiveDirectoryIntegratedApp value in it. The Cloud Apps selector appears to filter out any applications that do not have an entry in the ReplyUrls property. Using the Conditional Access link on the details page of the v2 application circumvented that check, but once it got to the actual policy the check was made and the application couldn’t be found due to it lacking a ReplyUrl entry. The Cloud Apps selector makes the logical assumption that the application was selected at one point, but it is now deleted, and so it shows the error above.

This was a pretty easy fix. I deleted the v2 application and recreated it with the following commands:

$app = New-AzureADApplication -DisplayName "Marketing App v2"  -IdentifierUris "http://marketingv2.contosoned.xyz" -ReplyUrls @("https://marketing.contoso-ned.xyz/.auth/login/aad/callback")
New-AzureADServicePrincipal -AppId $app.AppId -Tags "WindowsAzureActiveDirectoryIntegratedApp"

Now the application shows up in the Cloud Apps selector, and I can finish my demo.

To sum up. When you create an application and Service Principal using PowerShell, you must include at least one entry in the ReplyUrls property of the application and set the Tags property of the Service Principal to be WindowsAzureActiveDirectoryIntegratedApp. It’s weird, completely non-intuitive, and poorly documented. Hopefully, I’ve saved some others a couple hours of banging their head against a wall.