Fundamentals Of Active Directory– In the Cloud (Azure Active Directory) and On-Premises (Windows Server Active Directory) and Hybrid

1. The cloud has changed many things, but managing identity is still key

2. This post should help you get started

3. Let's start with a bunch of links

Links to learn more

Some introductory videos

More fundamentals

Developer Resources

Managing Active Directory

Application types and Scenarios

Azure Active Directory Code Samples

More Samples on GitHub

Authentication scenarios

Windows Azure Active Directory Authentication Libraries

Azure Active Directory Authentication Protocols

Integrating Applications in Azure Active Directory

Troubleshooting Azure Active Directory

SOME BASIC FACTS ABOUT ACTIVE DIRECTORY

1. Because there is some confusion around Azure active directory and Windows server active directory, this next section will provide some context

2. It is critical to understand that there are two products in the Active Directory space :

   • The two products are:

     • Azure Active Directory (public cloud)
     • Windows Server Active Directory (In a VM in the public cloud or on-premises in a private cloud)

   • They are not the same

   

   Figure 1: Azure AD and Windows Server AD

WINDOWS SERVER ACTIVE DIRECTORY

1. Active Directory is Microsoft's version of directory services

   • Directory services is a software system that stores, organizes, and provides access to information in a computer operating system 's directory.

   • A directory is a map between names and values. It allows the lookup of named values

   • Active Directory serves as a single data store for quick data access to all users and controls access to users based on the directory's security policy.

   • Active Directory is a directory service that authenticates and authorizes all users and computers in a Windows domain type network and in Windows Azure

     • It assigns and enforces security policies

   • Active Directory checks the submitted password** and determines whether the user is a system administrator or normal user

2. What protocols does Active Directory leverage?

   • Active Directory makes use of Lightweight Directory Access Protocol (LDAP)** versions 2 and 3, as well as Microsoft's implementation of Kerberos and DNS

   • The Lightweight Directory Access Protocol is an open, vendor-neutral, industry standard application protocol for accessing and maintaining distributed directory information services over an Internet Protocol (IP) network

   • Kerberos is a computer network authentication protocol which works on the basis of 'tickets' to allow nodes communicating over a non-secure network to prove their identity to one another in a secure manner

     • Its designers aimed it primarily at a client/server model and it provides mutual authentication for both the user and the server to verify each other's identity

   • The Domain Name System (DNS) is a hierarchical distributed naming system for computers, services, or any resource connected to the Internet or a private network

     • It translates easily memorized domain names to the numerical IP addresses needed for the purpose of locating computer services and devices worldwide

3. Single Sign On (SSO) is an important capability when software runs on-premises and in the cloud

   • A user logs in once and gains access to all systems without being prompted to log in again at each of them
   • The real value of SSO is that a user can login once and get access to on-premises applications as well as applications running the cloud (SharePoint, Office365)

4. The big challenge with SSO

   • The challenge is that different applications support different authentication mechanisms
   • Single sign-on must internally translate and store credentials for the different applications using the original login credentials

AZURE ACTIVE DIRECTORY

1. Azure Active Directory is a service that provides identity and access management capabilities in the cloud

2. You may not put all your on-premises directory information in the cloud

   • You decide who your users are, what information to keep in the cloud, who can use the information or manage it, and what applications or services are allowed to access that information

3. Companies can integrate their applications with Azure AD to provide single sign-on functionality for their users

   • This allows applications to be hosted in the cloud and to easily authenticate users with corporate credentials
   • This also allows service (SaaS) providers to make authentication easier for users in Azure AD organizations when authenticating to their services
   • There is a Graph API to the directory making it possible to manage users and groups
   • This makes it possible for companies and service providers to register and even brand their own applications for multi-tenant use

DEEP DIVE INTO AZURE ACTIVE DIRECTORY

1. Azure AD provides identity as a service

2. Supports OAuth 2.0 and OpenID Connect

3. More details can be found here

   • https://msdn.microsoft.com/en-US/library/azure/dn499820.aspx

4. Example Scenario - End user with a browser connected to a cloud hosted web application

   

   Figure 2: Web Browser to Web Application

5. Azure AD is the identity provider

   • Can verify identity of users and applications that exist in the company or service provider's directory

   • The company or service provider must register their application with Azure AD

   • Various authentication libraries can be used:

     • Windows Azure AD Authentication Library for .NET

     • Windows Azure Authentication Library for Windows Store

     • Windows Azure AD Node.js Module

       • Available on GitHub
       • https://github.com/AzureAD/passport-azure-ad
       • Passport strategy for authenticating with Windows Azure Active Directory using SAML

   • Various token formats are supported:

     • JSON Web Tokens (JWT)

       • See https://msdn.microsoft.com/en-us/library/dn205065(v=vs.110).aspx for more information

       • Supports JWT Token in a REST Web Service

         • Requests to the web service must be authenticated by Azure AD

     • SAML 2.0

   • The workflow of requests and responses for the authentication process is determined by the authentication protocol that was used, such as OAuth 2.0, OpenID Connect, WS-Federation, or SAML 2.0.

     • See https://msdn.microsoft.com/en-US/library/azure/dn151124.aspx

BASICS OF REGISTERING AN APPLICATION IN AZURE AD

1. Any application that outsources authentication to Azure AD must be registered in a directory

2. What a company or service provider must do in order to register with Azure AD:

   • Tell Azure AD about the application

     • The URL where it's located
     • The URL to send replies after authentication
     • The URI to identify your application, and more

3. An application must handle the exchanging of tokens and the sign-on process

   • You will need to provide a unique identifier for your application

   • You will need to provide a reply URL or a redirect URI

     • For web applications

       • You will need to provide a reply url, which is where the authentication response will be sent by Azure AD
       • The authentication response will include token, if successful

     • For native applications

       • You will need to provide a redirect URI, which is a unique identifier where a user agent will be sent in a OAuth 2.0 request

   • You will need to provide a client ID

     • This is automatically created by Azure AD when the application is registered

     • This client ID is sent along with the token during authentication

       • This ID uniquely identifies your application and associates with the token

   • You will need to provide a key

     • The key is sent with the client ID when authenticating for web applications

THERE ARE TWO TYPES OF APPLICATIONS - SINGLE TENANT AND MULTI-TENANT

1. Single tenant applications are used in a single organization, such as line of business applications

2. Multi-tenant applications support many organizations and are used primarily by software as a service companies

   • The application must be provisioned in each directory where it will be used, requiring an administrator to register them

   • Multi-tenant applications require extra work

     • Single tenant applications leveraging tenant specific endpoint

     • But multi-tenant applications are different. They will use a common endpoint that will need to identify a specific user from all the directories in Azure AD

       • That endpoint is https://login.windows.net/common

3. It is possible to transform a single tenant application and make it multitenant capable

4. A single signing key can be used for all tokens in all directories, regardless of single tenant or multitenant applications

   

   Figure Client Browser and Client Native apps accessing Cloud-based web apps: X

5. There are some excellent documentation and samples available at Github

   • https://github.com/AzureADSamples

   

   Figure 4: GitHub for code

The samples include:

• How to create a multitenant web applications using Open ID Connect

• How to use OAuth 2.0

• How to query the Azure AD using the graph API

• How to authenticate with native Android and iOS applications

• How to use Node.js with OAuth2

• And more, including support for Java, PHP, .NET

THE FOUR KEY SCENARIOS

1. A browser-based client signing into a web application, secured by Azure AD

2. A mobile client accessing resources using a web-based API, secured by Azure AD

3. Browser-based client accessing resources, using a web-based API, secured by Azure AD

4. A demon application or server application with no user interface accessing resources, using a web-based API, secured by Azure AD

PROTOCOL FLOW DIAGRAMS FOR THE FOUR SCENARIOS ABOVE

1. Can be found here, https://msdn.microsoft.com/en-us/library/azure/dn499820.aspx

KEY LEARNINGS FROM THE FOUR SCENARIOS

1. How the browser can access endpoints (WS-Federation or SAML)

2. Sign-ins getting redirected to the appropriate Azure directory

3. Security tokens getting posted to the Reply URL

4. Cookie creation to maintain session with the user

5. Application validation of the token (SAML, or JWT) by leveraging public signing key

A VERY COMMON SCENARIO - WEB BROWSER TO THE APPLICATION

1. How do you authenticate the user in a web browser to the cloud-hosted web application?

2. To start, the web application will need to immediately direct the browser to Azure active directory to begin the authentication process

3. A security token will be given to the browser so that future calls into the web application are already authenticated

4. This scenario supports sign-on using the WS-Federation, SAML 2.0, and OpenID Connect protocols

   

   Figure 5: Browser to Web Scenario

Conclusion

This post should help you get started understanding Active Directory.