Technology Blog

Home » Posts tagged 'Active Directory Federation Service (ADFS)'

Tag Archives: Active Directory Federation Service (ADFS)

Microsoft Azure AD Identity Solution – Part-3 !!!


Microsoft Identity as a Service (IDaaS) for Enterprise Architects

What IT architects need to know about designing Microsoft identity solution for customer while they deployed any public and private cloud (hybrid) with all types of cloud services such as IaaS, PaaS and SaaS

Brief Introduction

In my previous article “Microsoft Azure AD Identity Solution – Part-2 !!!”, we discussed about Microsoft Azure AD as an identity solution in detail and how Azure identity (IDaaS) solution provides seamless SSO and MFA solution for SaaS and on-premises apps. Apart from that, we also discussed on how an Azure AD collaborates with B2B and B2C scenarios and then finally we talk about the use cases of Azure AD application proxy for accessing on-premises hosted applications.

In this article, we will talk about specific industry use cases scenarios such as identity authentication & authorization for applications hosted in IaaS cloud platform. Here we will discuss on how on-premises Active Directory Domain Services (generally called corporate or enterprise AD DS) and Active directory Federation Services (AD FS) are getting extended into IaaS platform and provides authentication and authorization to applications/workloads hosted in Infrastructure as a Service (IaaS).

In case of customer does not have the on-premises AD DS or AD FS exist into their corporate landscape then customer can leverage the Microsoft managed Azure Active Directory Domain Services (Azure AD DS) for providing authentication and authorization to applications or workloads hosted in Infrastructure as a Service (IaaS).

These are most common scenario used in industry for legacy and modern apps which are either migrated from on-premises into IaaS or directly hosted in IaaS as a fresh build.

Azure AD domain service (Azure AD DS)

Azure AD domain service is a cloud-based domain services that’s completely managed by Microsoft and provide below features:

  • This cloud-based domain services provide certain features of on-premises AD such as domain join, group policy, LDAP & Kerberos/NTLM authentication in Azure laaS
  • Remember that Azure AD DS has certain limitations as compare to on-Premises AD
  • Customer can join their Azure VMs to a domain without deploying DC’s because Azure AD DS is part of customer existing Azure AD tenant and users can login using the same credentials, they use for Azure AD.

Note: This Azure AD managed domain is a standalone domain and is not an extension of on-premises AD domain/forest infra. However, all user accounts, group memberships, and credentials from on-premises AD are available in this via Azure AD tenant

Below figure shows how an Azure AD domain services provides the authentication and other domain services to customer line of business applications running under Azure infrastructure as a service (IaaS)

Figure-1: Azure AD Domain Services

Synchronize on-premises AD accounts to Azure AD

This solution provides access to all of Microsoft SaaS and cloud-based identity options for Azure PaaS & laaS apps, two below approaches are recommended, choose either one

A. Directory & password synchronization

B. Identity federation

Directory and password synchronization
This is a simplest and recommended option for most enterprise organizations, below figure shows how an Azure AD directory, password sync and MFA can be achieved Azure AD connect tool:

  • User accounts are synchronized from customer’s on premises directory to their Azure AD tenant. The on promises directory remains the authoritative source for accounts
Figure-2: Azure AD Connect (directory and password sync)
  • Azure AD performs all authentication for cloud-based services and applications
  • Supports multi-forest synchronization

Note: Using cloud-only accounts is not recommended for enterprise-scale customer unless Windows AD is not already used on premises

Password synchronization: Users enter the same password for cloud services as they do on-premises. user’s passwords are never sent to Azure AD instead a hash of each password is synchronized

Multi-factor authentication (MFA): Apps in Azure can take advantage of the Azure MFA service whereas directory sync does not provide integration with on-premises MFA solutions

Identity federation

Federation provides additional enterprise capabilities, but It is also more complex & introduces more dependencies for access to cloud services as shown in figure below:

  • All authentication to Azure AD is performed against the on-premises directory via Active Directory federation services (AD FS) or another federated identity provider
  • Works with non-Microsoft identity providers
  • Password hash sync adds the capability to act as a sign-in backup for federated sign-in (f the federation solution fails)
Figure-3: Azure AD identity federation

Use identity federation if
AD FS s already deployed or using a third-party identity provider

Having an on-premises integrated smart card or other MFA solution

Require sign-in audit and/or disablement of accounts

Compliance with Federal Information Processing Standards (FIPS)

Federated authentication requires a greater investment in infrastructure on premises

  • The on-premises servers must be Internet-accessible through a corporate firewall Microsoft recommends the use of federated proxy servers deployed in a perimeter network, screened subnet, or DMZ
  • Requires hardware, licenses, and operations for AD FS servers, AD FS proxy or web application proxy servers, firewalls, and load balancers
  • Availability and performance are important to ensure users can access cloud applications

Placing directory components in Azure IaaS

Consider the benefits of deploying directory components i.e. AAD Connect/AD DS/AD FS to Azure laaS, as shown in figure, especially if customer plan to extend their on-premises AD to Azure virtual machines for their line of business apps

If customer hasn’t already deployed AD FS on-premises, consider whether the benefits of deploying this workload to Azure makes sense for the organization –

  • Provides autonomy for authentication to cloud services (no on-premises dependencies) and reduces servers and tools hosted on-premises
  • Use a S2S VPN gateway on a two-node duster or ExpressRoute to connect Azure
  • Uses ACLs to ensure that Web App Proxy servers can only communicate with AD FS, not AD DCs or others server directly
Figure-4: Placement of on-premises AD components in Azure IaaS

Extending On-premises AD to virtual machines into Azure IaaS

Refer to the figure which shows the configuration of hybrid deployment on-Premises AD extension to Azure AD and It requires:

  • A virtual network (VNet) in Azure laaS
  • A S2S VPN or ExpressRoute connection.
  • Extending customer on-premises to virtual machines in the virtual network
  • Deploying one or more DC in Azure VNet designated as a GC to reduces egress traffic

When to use this solution?

  • Schema extensibility and need to write to existing directory identities.
  • Support for apps in Azure VNet where network isolation is a requirement
  • Support across multiple Azure subscriptions.
  • Certificate or smartcard-based authentication for apps
Figure-5: on-premises AD extension to Azure IaaS

Note: On-Premises AD extension covers lots of limitation of Azure AD DS Below Microsoft FAQ covers features and limitations of Azure AD DS as compare to on premises AD DS: https://docs.microsoft.com/en-us/azure/active-directory-domain-services/faqs

To have further more insight on my previous articles on “Microsoft Azure AD Identity Solution – Part-1 & 2!!!” , Refer to below article:

Microsoft Azure AD Identity Solution – Part-1 !!!

Microsoft Azure AD Identity Solution – Part-2 !!!

Rajeev Ujjwal has more than 18 years of transformation delivery experience in cloud computing, infrastructure, directory service, and cyber security with larger global customers. He is a senior cloud consultant and successfully delivered various kind of global project delivery such as greenfield, consolidation, separation and migration. 

Managing and Securing Employee’s Personal Devices (BYOD) through Active Directory 2012 R2 !


Now Managing of BYOD (Bring Your Own Device) through Microsoft Active Directory 2012 R2-

Few weeks back, I have published my blog “Microsoft Windows Server 2012 R2 Top 20 Released Features!” and two of important features are “Workplace Join” and “Multitenant VPN gateway“. Today, Lets discuss on these features in more detail.

As per Microsoft TechNet Article:

“One of the most prevalent IT industry trends at the moment is the proliferation of consumer devices in the workplace. Employees and partners want to access protected corporate data from their personal devices, from checking email to the consumption of advanced business applications. IT administrators in organizations, while wanting to enable this level of productivity, would like to continue to ensure that they can manage risk and govern the use of corporate resources.”

In Windows Server® 2012 R2, Active Directory has been enhanced with the below value propositions to connect employee’s personal devices to internal corporate network to access their application from anywhere anytime in a secured manner. It enables IT to empower their users to be productive from a variety of devices:

  • Workplace Join – IT administrators can allow devices to be associated with the company’s Active Directory and use this association as a seamless second factor authentication.
  • Single Sign-On (SSO) from devices that are associated with the company’s Active Directory
  • Managing Risk – Enable users to connect to applications and services from anywhere with Web Application Proxy
  • With Multi-Factor Access Control and Multi-Factor Authentication (MFA), manage the risk of users working from anywhere, accessing protected data from user’s devices.

Workplace Join:

Though “Workplace Join” feature is self-explanatory but let me explain here – Employee can “join” his/her own devices to his/her own “workplace” (Internal Corporate Application/Data). In simple terms, Employees can access their applications and data everywhere, on any device.

In this case, Employees require to registering their devices with their AD domain so that device will reflect in AD with associated owner and will be trusted when requesting and running company-secured applications, accessing company-secured data, or accessing company-secured resources.

To get more detail on Workplace Join – Join to Workplace from Any Device for SSO and Seamless Second Factor Authentication Across Company Applications Overview

Single-Sign-On (SSO):

When user joins a device to the workplace, it becomes “a known device and will provide seamless Second Factor Authentication and Single-Sign-On (SSO) to workplace resources and applications.” And once the device is “known”, IT Administrator can leverage that knowledge to apply/enforce additional configurations/policies (example: pushing company polices settings to the device). Administrators can control who has access to company resources based on application, user, device, and location.

Practically speaking, Device Registration Service (DRS) is the new feature and part of Active Directory Federation Service (ADFS) role which allows users to register their devices in AD Domain, tracks the associated device’s certificate in order to represent the device’s identity and provides on-board mechanism for Single Sign-On (SSO) with appropriate/conditional access.

Single Sign-On (SSO) is the functionality that reduces the number of password prompts the end user has to enter when accessing company resources from known devices. This implies that Users will be prompted only once during the lifetime of SSO when accessing company applications and resource. For example, A User wants to access their different applications (SharePoint, Exchange and HR) from their devices – without SSO, user would be prompted for a login with every application user try to access. But with SSO, user will only be asked one time.

As above mentioned, Device Registration Service part of ADFS role allows claims-based authentication to occur based on trusted certificates. Once the user is authenticated (username + password + trusted device along with certificate), the claim is trusted/validated, can be used to launch company applications or access company data.

To get more detail on Single Sign-On – Join to Workplace from Any Device for SSO and Seamless Second Factor Authentication Across Company Applications Overview or Single sign-on Wikipedia, the free encyclopedia

Managing Risk through Web Application Proxy:

The Web Application Proxy is a new service part of Remote Access Role. Web Application Proxy “provides reverse proxy functionality for web applications inside corporate network to allow users on any device to access them from outside the corporate network. It pre-authenticates access to web applications using ADFS, and also known as an ADFS proxy.”

So, now SSO facilitated through DRS, the authenticated AD user with his/her own device can access applications on the corporate network and manage the risk with a reverse proxy secure layer without having a 3rd party VPN connection.

To get more detail on Managing Risk through Web Application Proxy – Connect to Applications and Services from Anywhere with Web Application Proxy Overview

Multi-Factor Access Control and Multi-Factor Authentication (MFA):

ADFS in Windows Server 2012 R2 supports more than just the permitted (or denied) user in ADFS claims. Microsoft added “Multiple Factors Authentication”, including user, device, data and location. Authorization claim rules have a greater variety of claim types.

“In ADFS in Windows Server® 2012 R2, Administrator can enforce multi-factor access control based on user identity or group membership, network location, and device (whether it is workplace joined)”

To get more detail on Multi-Factor Access Control and Multi-Factor Authentication (MFA) – Manage Risk with Additional Multi-Factor Authentication for Sensitive Applications Overview

%d bloggers like this: