Active Directory:  Authentication and Authorization Evolution

Access to the internet, as well as the internet itself, became faster as broadband became cheaper.  Access to homes and through WiFi became widely and affordably available.  Telephone access withered and died.  Laptops and home computers could now access network resources off network at tolerable speeds.  Yes, it was still slower than accessing it in the office, but the drive-to-the-office time was no longer the quicker way to get work done.  

VPN to the rescue!  Add some software to the home computers and laptops.  Set up authentication to the router VPN server (which could eventually be tied into AD).  Add some routing rules so the distant endpoint could see the AD server.  Boom!  Done!

Then came tablets and phones.  IOS and Android operating systems.  Sure, VPN works.  But how do the tablets access the authorized resources?  Well, that’s an application end problem, right?  If the applications were hosted on an internal web server, all was well after connecting.  Not bad.  But wait – was AD doing any authentication and authorization in this instance?  If AD was connected to the VPN server, then, yes, it was authenticating to network access.  But was the AD server and its services actually involved beyond that?  No.

Then came software-as-a-service (SaaS).  Users were now accessing applications, like Office 365, without the AD server involvement.  The login to Office 365 did the authentication and subsequent authorization.  The same was true for other outside the network services like SalesForce, NetSuite and more.  Dropbox, OneDrive and Box made internal file serving less relevant.  

The authorization role of AD diminished with the decline in the internally hosted applications and services.  Meanwhile the need to maintain authentication and authorization directories in SaaS applications soared.

Active Directory and Access to User Resources on Endpoint Computers

The question:  if AD is not authorizing access to anything, then why have authentication?  

You still need a way to control access to the endpoint.  AD provides a means to control this with computers which are joined to the domain.  AD does not do this for phones and tablets, other than serving as a VPN authentication source.  So if there was another way to control authentication, would you need AD?

One answer was to keep AD relevant by keeping it as the authoritative source for authentication.  AD connectors to the SaaS services provided a means to loop in the SaaS environment somewhat.  An example of this is Azure Connect.  The care and feeding of the connectors became a new setup and maintenance task.  If you had few SaaS services, this might not be too much of a time demand.  If you still had internal network based resources and a small number of SaaS services, this might be justified.  Many environments, however, were able to move out all their internal services to SaaS providers.

How about the authorizing access to the resources on a computer?  That still needs authentication.  The local resources need protection even if the computer does not access local network resources.

The process for authentication to a computer looks like this:

1. you create a local user in the local computer users and groups directory
2. you give the user access rights (standard, administrator, or something else you create)
3. you give the user a password

When an AD domain is involved, the process is the same except:

1. you join the computer to the AD server (domain controller) if it is not already part of the domain.
2. AD creates a local user in the local computer users and groups directory.  The local user is has the user name from AD and is designated as being part of the domain
3. the domain sets the access rights.  This can include custom rights using group policy.
4. the domain inserts the password for the user from AD

The benefit of the AD domain approach is central identification management. This beats having to setup and maintain user identities on each computer.

When the user logs in using an AD user name and password, the identification connects to the AD domain controller.  The passed credentials are compared to the credentials in AD for the user.  If it matches and the account is enabled, access is granted to the computer resources for that user. If not, access is denied.  If the account is disabled, a token is placed on the local computer denying further access.  Should the AD domain controller not be available (the computer is off network), the credentials in the user and groups directory local to the computer is used to authenticate and authorize local resources use.

Central authentication and password management controlling local computer (not phone or tablet) access.  That is the pay-off of AD authentication and local computer resource authorization.  The central administration provides a means of denying access and maintaining passwords.  Yes, the authentication could be done through the user and groups directory local to the computer.  As noted, this would be a lot of work.  That is, unless there is a centralized means to maintain the user and groups local directory.  For this to work, the centralized means must provide the same functions as AD:

• authentication – granting or denying access
• setting and changing passwords
• polling for changes in above, preferably at login

It must do this without a trip to the computer.

Azure Active Directory (AAD)

Azure Active Directory (AAD), by it’s name alone, would seem to be the answer.  You setup users and their passwords.  The credentials provide access to Microsoft 365, if you have subscriptions.  You can enable access to other SaaS services.  Using AAD to authenticate online can provide authorization beyond simply Microsoft 365.    You can enable access to other SaaS services.

How about authenticating to user resources on a local computer?  No. AAD does not add a user to the local users and groups directory.   You can simplify SaaS access by using the Connect capability in ‘Access work or school’ under Account Settings.  This does not impact the local users and groups.  For that, you need to go to Family & other users.  AAD will not do that for you like AD does.  

How about authenticating to internal network resources?  No.  For that you (if you still have internal network applications), you still need AD if you want to have central management capacity.  You could provide local computer / local user authorization to network resources, but that would be a lot of work on both the user computers and the application servers.

InTune (and other MDM solutions)

InTune provides the ability to load Group Policies without AD.  AD authorized connection for computers to control local computer capabilities.  Once a computer was joined to an AD domain, the machine policies were authorized and applied.  One a domain user logged in, the group policies for the user were applied.  This provided a degree of control on what the computer and user on the computer could do.  

InTune (and other MDM solutions) update the local group policy.  Just like AD group policy, you can regulate what the user can do on the local computer.  InTune, however, does more.  InTune extends policies to tablets and phones.  InTune also can enforce policies concerning local users and groups.  It can set password complexity requirements.  In the case of tablets and phones, it can do that and detect whether a password is required. 

InTune relies on and is integrated with AAD.  Like AAD, what it does not do is create and maintain local users.  

Directory as a Service (DaaS):  JumpCloud

JumpCloud is an example of a Directory as a Service provider.  At login on a JumpCloud joined computer , authentication occurs, as always, from the local users and group directory.  The login grans authorization to access the user resources on the computer.  What is different is what happens before the login:  JumpCloud handles the maintenance of the users and groups on the local machine.  

How does JumpCloud handle the magic which AAD and InTune do not?  The JumpCloud client makes it possible.

IMPORTANT:  you cannot have a machine joined to JumpCloud AND to AD.  It is one or the other.  When you have a computer with the JumpCloud client loaded that is unattached to the domain, authentication happens with local users exclusively.  When you load the JumpCloud client, it takes over remote management of the local users and groups.  When you do not have internet access, cached credentials are used at login (just like when you cannot reach the AD domain server).

Joining with the JumpCloud client adds the computer to the JumpCloud directory.  You can:

• place the machine in a group.  The group can have settings assigned, like with group policy, to manage what the machine can do regardless of the assigned user.
• assign users to a computer.  This pushes the credentials for the user to the machine.
• assign a group of users to a computer.  This pushes the credentials for the group members to the machine.

A computer can have multiple users assigned to it.  

When connected to the internet, the JumpCloud client checks once a minute for changes in the password and enabled permission to use the computer.  This keeps the maintenance of password centralized while keeping the local credentials up to date.

Maintaining the users and groups directory on each joined computer is the basic function of DaaS.  JumpCloud provides much more capabilities than just handling authentication.  JumpCloud overlaps with InTune by providing group policy configuration and other MDM capabilities.  JumpCloud shares capabilities with AAD in enabling single sign on to other SaaS applications.  

JumpCloud can maintain access credentials for other SaaS services.  If your organization used Dropbox, SalesForce and NetSuite, you would need to create users and their password in each service.  When the password changed, you would enter each service to update the password.  If users maintained their own password, they would need to do this to keep their passwords in sync.  Authentication to each service stands alone.  

JumpCloud provides System for Cross-domain Identity Management (SCIM) ability to maintain the directories in other SaaS applications.  For hybrid environments, where you still need access to internal network applications using AD, JumpCloud provides the SCIM equivalent client program to keep AD in sync with JumpCloud.  Using JumpCloud’s SCIM functionality, you can reduce maintenance for password changes and granting/’restricting access. 

While JumpCloud provides broad functionality, the DaaS capability provides a centralized ability to control access to user resources on local computers.  This includes changing and updating passwords and granting/denying authorization to access.  No connection to an AD domain is required.  JumpCloud can provide authorization to use SaaS resources as well as maintain the SaaS resources authorization directories.  Using the AD Sync client, JumpCloud can keep AD in sync with JumpCloud (or JumpCloud in sync with AD) to allow continued use of internal network resources.

Azure Active Directory / Intune and JumpCloud:  Authentication and Authorization Revolution

Does computer endpoint access still need central password control and authorization level setting?

Dismissing the administration of computer end point access controlled through centrally managed passwords would be a revolution.  This long question highlights the approach difference between the AAD/InTune and JumpCloud solutions.  In both solutions, AD is not necessary.  Both rely on non-domain joined computers. 

AAD and InTune take the approach that the local user can setup whatever local user name and password the user wants.  After joining InTune, group policy will load.  Enforcement of password requirements will begin.  Restrictions on what the user can do will engage.  If the user leaves the company, InTune can wipe the machine.  If the user needs help, the help desk can use the user’s credentials which are already administrator.  If you need a policy blocked capability to address a problem, you can update the policy temporarily.

As long as the user can reset their own password, access to the local machine is assured and no central password control is needed.  However, keeping password in alignment with other SaaS services is on the end user.

For JumpCloud, you can also apply policies.    You can set the access level as standard or administrator.  This may be easier.  If the user leaves the company, you can deny access rather than wipe the machine.  Help desk can provide password assistance.  Password changes are pushed to SaaS services when they occur.

Summary of the Alternatives

The bottom line is that control of computer endpoint access, though time-honored, is not needed.  With an InTune/AAD solution, you can achieve a level of control.  Perhaps the answer is driven by whether JumpCloud provides the functionality and a means of managing access to user resources on computer endpoints fits how you want to handle computer endpoint management.   If you want centralized management like in AD, then JumpCloud matches.  I really comes down to how much you want to be revolting.

In both cases, to the overall question, you do not need AD if you don’t have any services on the local network to authorize.  In that situation, InTune/AAD or JumpCloud provide means to handle authentication and authorization in an SaaS environment.