#AzureAD Mailbag: Hybrid Identity and ADFS Part 2

[Alex Simons (AZURE)]

First published on CloudBlogs on Jul, 29 2016

Hey there, Ramiro Calderon back for another post on Hybrid Identity and ADFS. This is really a part 2 from last weeks post which can be found here . Let’s pick up right where we left off!

Question 1: Both AD FS and Azure AD give me SaaS App SSO. What should I use when?

Answer 1: Azure AD is an Identity and Access Management (IAM) platform that brings additional capabilities for Software as a Service (SaaS) applications beyond Single Sign On (SSO).

In general, it is recommended to use Azure AD for SaaS apps SSO configuration because it provides:

1. Automated provisioning for SaaS applications that support it (Salesforce, ServiceNow, etc.). This provides a simple and secure way to manage identities in various SaaS applications.
2. User friendly portals https://myapps.microsoft.com/ for information workers (IW) to discover and launch applications they have access to. Similarly, SaaS apps are available for users from the office portal ( https://portal.office.com ), which is a great option for users who are already used to it.
3. The application gallery enables simpler configuration wizards optimized for each application. You can also “bring your own” federated applications that support SAML protocol or WS-Federation.
4. Azure AD Provides built-in reports for SaaS applications including:  Logins to the applications, and anomalous logins using machine learning powered by the cloud backend.  Without Azure AD, you need additional logic and complex parsing of the IdP audits to replicate (a) above. The machine learning models and techniques to produce (b) are not cost effective to produce on premises.
5. Azure AD Identity Protection provides risk-based conditional access, evaluating risk of logins evaluation from multiple data sources using machine learning at cloud scale in addition to supporting conditional access based on location and MFA.
6. Common management control plane with:
   1. Microsoft services such as Office 365
   2. Password SSO application, in addition to federation
   3. Internal applications using Azure AD Application proxy
   4. Custom Azure AD line of business (LOB) applications
7. Independent token signing certificates per app, reducing the rollover impact.
8. When combined with group management features, Azure AD provides more options to assign access to the SaaS apps:
   1. Delegate a business owner to manage user assignment
   2. Allow users to self-service requests for access with optional approval process
   3. Provides attribute based control using groups with dynamic membership

In an on premises deployment, the capabilities above are usually available with 3 rd party solutions.

1. Setting up Azure AD as the trust decouples the application from the on-premises credential approach in your tenant, which gives you flexibility to move from federation to Azure AD password hash sync and reduce on-premises infrastructure in the future.

In addition to the functional reasons above, there are also some practical considerations:

1. As a cloud service, Azure AD is continuously releasing fixes, new features and enabling new scenarios for administrators, developers, and end users.
2. When Apps in the Gallery change or break their API’s, Azure AD engineers wake up in the middle of the night to fix it, not you
3. The SaaS application gallery is constantly updated with new applications. As a customer, you can submit requests to the  Azure AD team to add new applications.
4. You can keep adding applications without worrying about upgrading your on-prem capacity.

So, when should you keep the SaaS application RP trusts in AD FS? Simply, when Azure AD does not support it. There are some advanced use cases that can only be implemented by AD FS such as:

1. Advanced claim transformations such as transformation of attributes, regular expressions, or claim extractions from LDAP, SQL Server, or custom attribute stores
2. Token customizations such as SHA256 signatures, specific NameID policies, etc.
3. Support for SAML 1.1 tokens for WS-Federation applications.
4. Custom triggering of multifactor authentication rules that are not supported by conditional access.
5. Custom authorization logic that can’t be modeled as a security group or conditional access policies.

As mentioned above, Azure AD is constantly releasing more capabilities to close the SSO functional gaps with AD FS, especially around conditional access capabilities.

Question 2: I am confused. On premises Web Application Proxy (WAP) and Azure AD Application Proxy give me internal application publishing. What should I use?

Answer 2: In general, we recommend using Azure AD Application proxy to publish on-premises applications. As I mentioned in my previous answers, Azure AD provides a lot of capabilities beyond the endpoint publishing:

1. User friendly portals https://myapps.microsoft.com/ for information workers (IW) to discover and launch applications they have access to. Similarly, SaaS apps are available for users from the office portal (https://portal.office.com), which is a great option for users who are already used to it.
2. Azure AD Provides built-in reports for applications including: Logins to the applications, and anomalous logins using machine learning powered by the cloud backend.
3. Common management control plane with:
   1. Microsoft services such as Office 365
   2. SaaS applications
   3. Custom Azure AD line of business (LOB) applications
4. When combined with group management features, Azure AD provides more options to assign access to the internal apps:
   1. Delegate a business owner to manage user assignment
   2. Allow users to self-service requests for access with optional approval process
   3. Provides attribute based control using groups with dynamic membership

In an on premises deployment, the capabilities above are usually available with 3 rd party solutions.

1. Conditional access policies based on network location, device state (in preview), and Risk-Based (in preview). The later one is uniquely possible in the cloud due to the scale of risk evaluation and signal processing engine from multiple data sources using machine learning.

Additional capabilities specific to internal applications including:

1. Azure AD Application Proxy connectors simplify the on premises footprint. No DMZ or inbound ports are needed since there is only outbound traffic.

2. Azure AD provides SSL termination so reduces exposure to vulnerabilities like heart bleed

3. Azure AD ensures that your servers on premises are not exposed directly to the internet so no port scanners and other similar tools are not a threat

4. With pre-authentication, Azure AD will ensure that only authenticated requests are sent to your on-premises servers, mitigating DDOS attacks

5. Alternate login ID is very straightforward to configure for Kerberos applications. So, when should you publish your internal applications in WAP? Simply, when Azure AD does not support it.

There are some advanced use cases where WAP is a better fit such as:

1. If you already have hundreds or thousands of applications published, WAP provide better scripting capabilities.
2. Public or consumer facing websites
3. WAP in Windows Server 2016 will support additional pre-authentication methods such as Basic and Client Certificate Authentication
4. WAP in Windows Server 2016 will support publishing of endpoints based on wildcards (example map: https://*.contoso.com )

Question 3: So, if I move my SaaS apps and my internal apps to Azure AD, can I shut AD FS Down? What are the tradeoffs if I move from federation to Password Hash Sync?

Answer 3: AD FS has a very important place in an overall identity solution to meet specific use cases that might be part of your requirements:

1. Support for authentication methods other than username/password. This includes:

1. Integrated windows authentication (IWA) for IWs using domain join computers in the internal network.
2. Support for Smart Card user authentication.
3. Use of 3 rd Party MFA providers such as RSA SecurID, Vasco, YubiKey, etc.

2. Support for auto-registration of Windows 7 and 8.1 domain joined devices for device-based conditional access.

Question 4: I have MFA on premises with AD FS, but Azure AD attempts to do MFA in the cloud again. How can I fix that?

Answer 4: Azure AD recognizes the MFA authentication on premises based on claims from the identity provider (AD FS in your case). To set it up with AD FS you need to do the following:

1. Configure the domain authentication properties to indicate MFA is supported on premises:

2. Then, configure AD FS to pass through the authentication method references claim in the issuance transform rules: The underlying claims language is: 3. Then, any requests that Azure AD deems requiring MFA (for example Conditional access policies), will result on a request like this when using WS-Federation. Note the wauth parameter 4. Then, Azure AD will look for the authentication method references claim in the highlighted claim types and value, which is sent to Azure AD with the rule created in step 2.

Note that steps 1,3,4 apply to other identity providers as well. If you have the same requirements for 3rd party identity provider, consult with your provider to produce the claims described here.

Question 5: I have MFA on prem with AD FS, and want to move to Azure MFA. How can I phase in my users?

Answer 5: This is a tricky one because the “MFA on premises support” is a per-domain setting, and you can’t slice it by groups of users. However, here's the trick: Reading View. Alt Shift A for Accessibility Help. * The “SupportsMFA” flag means that Azure AD to send the request back to AD FS with the MFA request parameter. * As a decoupled behavior, Azure AD will honor the authentication method references claim from on prem if it sees it.  

In other words, if you issue the MFA claim on premises then Azure AD will use it. This is an example: Let’s say your MFA requirement is to prompt multifactor when outside the corporate network, then it is possible to phase users from an on-premises MFA to Azure MFA as follows:

1. Create a security Group on-premises called AzureMFAUsers

2. In AD FS, create a rule so request MFA for requests coming from outside the corporate network for users who are not members of AzureMFAUsers

3. In Azure AD, disable the “SupportsMFA” property of the federated domain: 4. In Azure AD, set the MFA service to skip MFA for on-premises requests for federated users: 5. Then, make sure that the members of the “AzureMFAUsers” and set Azure MFA to be “enforced” in the cloud. You can do this in the management portal, or at scale with a quick powershell function as follows:   function Set-AzureADEnforcedMFAToGroup { [CmdletBinding()] param ( [Parameter(Mandatory=$true)] [string] $GroupName ) $groupId = Get-MsolGroup -SearchString $GroupName | Select-Object -ExpandProperty ObjectId $members = Get-MsolGroupMember -GroupObjectId $groupId $st = New-Object -TypeName Microsoft.Online.Administration.StrongAuthenticationRequirement $st.RelyingParty = "*" $st.State = "Enabled" $sta = @($st) foreach($member in $members) { $memberObjectGuid = $member.ObjectId Set-MsolUser -ObjectId $memberObjectGuid -StrongAuthenticationRequirements $sta } }   So, with the trick above you can play with the AD FS rules to phase users from On prem MFA to Azure MFA.   We hope you’ve found this post and this series to be helpful.

For any questions you can reach us at AskAzureADBlog@microsoft.com , the Microsoft Forums and on Twitter @AzureAD , @MarkMorow and @Alex_A_Simons

-Ramiro Calderon and Mark Morowczynski