1. Overview

Active Directory Federation Services (ADFS) is a component of Microsoft® Windows Server™ 2003 R2 (or higher versions) that provides authentication technologies. This document will show how to connect DNN with AD FS using the ‘ADFS-Pro Authentication’ plugin.

1.1. What is the problem

As the number of web applications (Office 365, DNN, Box, Salesforce) grows, it becomes challenging for the corporate administrators and employees to manage accounts and access rights.

For example if company employee works with three web apps (eg. Office 365, DNN and Salesforce), each employee has to remember three sets of different credentials (username and password). In practise, for simplify he’s using same username and passwords for all accounts, which creates security hole.

On the other hand corporate administrator must keep an eye on all these identities, what creates extra work and is less secure.

1.2. Solution - a Big Picture

AD FS is an identity mechanism that allows access for people that are outside of the corporate boundary. In the secure way Active Directory resources (like identities) are exposed for web apps, that are hosted somewhere in the Internet. One of the possible scenarios is described on the figure below. There is an on premise Active Directory placed in the corporate Intranet, and the web apps hosted outside of the corporate. Web apps are on the Internet whereby their access is opened for all. But in this case if someone wants to sign in to that app, his credentials are validated against the AD user store. This validation happens in a secure manner.


In this approach client applications (Sharepoint, DNN, etc.) are not gathering user credentials and they don’t manage user credentials. They don’t have to handle password resets, multi-factor auth and so on.

‘Claims Aware Apps’ rely on the AD FS that is responsible to deliver these identities in compliance with the industry’s best practices. In that case one set of identity credentials can be reused across all ‘Claims Aware Apps’. And that’s just a few advantages if you want know more please read chapter below.

1.3. Benefits

Below are described most important advantages of scenario where identities are stored in Active Directory and exposed via Federation Service.

  1. Users can use their primary organizational accounts to sign in to DNN. Now one set of user credentials allows sign in to: on premise Active Directory, Office 365, DNN, Salesforce, and more.
  2. From a company perspective, in just a few steps you can install vanila CMS, where company users can sign-in using their current credentials. There is no need to create new username/password for employees.
  3. If your DNN will become compromised or something bad happens, your user credentials are safe. It’s because DNN is no longer responsible for authenticating users and storing user accounts and passwords, user passwords are never stored on DNN web server. DNN will hold only copy of the user profile.
  4. Employees are more productive when they have to remember a single username and password.
  5. At the sign in process AD user profile is copied to DNN website data store.
  6. User can enjoy Seamless Single Sign-On (Seamless SSO), this mean user doesn’t needs to go through login process for each ‘Claims Aware App’. If the user sign-in is successful, he’s able to access all ‘Claims Aware Apps’, without entering username and pasword again.
  7. Resetting a forgotten password or requesting access to an application without waiting for assistance from the helpdesk. Everything is happening on AD and DNN system is not involved in that process.
  8. ‘Conditional access’, it’s a capability that enables you to define conditions under which authorized users can access DNN, for example in easily way you can force multi-factor authentication.
  9. Multi Factor Authentication (MFA), you can quickly configure list of users that needs MFA. Second authentication factor, that will verify user by: an automated phone call or a text message. For example administrator can mandate the use of more secure authentication methods for access requests from the extranet.
  10. Restrict access for mobile devices that doesn’t meet company standards for security and compliance.
  11. Additionally you have centralized view of your user access to the all apps.
  12. ADFS requires users to have an account in Active Directory or in one of the Identity Provider (IdP) that ADFS trusts. However, users may have no access to an Active Directory, but have accounts with other well-known IdP. These issuers typically are social networks and email providers. In this approach you can sign in to DNN using Facebook, Google or Windows Live account. For that scenarios an Microsoft Azure™ Access Control Service (ACS) must be implemented.

1.4. Target audience

Solution described in this document is targeted to:

  • Active Directory admins who want’s quickly add DNN website to their existing web app ecosystem.
  • Companies that want to have good CMS website for their employees.

1.5. ‘Company Blog’ simple use case

Blogs are valuable marketing tool for companies. Blogs can educate customers, build trust, and even bring in new leads.

Let say that we have a big company. Company has employees whose identities are located in the Active Directory. It’s an on-premise Active Directory system and access from the Internet is protected by the firewall. Security is very important for that company. Company want’s to have a blog. Blog will be for employees, customers and potential clients. Corporate admin doesn’t want to create new accounts for users who needs add blog posts or blog comments. On the other hand employees doesn’t want to have another username and password just for using company blog.

Solution must meet following requirements:

  • cost-effective solution,
  • easy to maintain,
  • accessible from corporate Intranet and from Internet (outside of the office),
  • accessible from mobile devices (mobile friendly),

To achieve all these goals we can create solution described on the figure below.


We have a DNN website that has a blog plugin and it’s hosted outside of the company. All users employees/customers have access to that blog out of the box, because they using their actual AD identities to sign-in to DNN and add content to the blog (posts or comments). What is most important: corporate admin doesn’t need to create any new accounts on the DNN for users that want’s to add blogs, posts or comments.