All Identities

Identity and Access Management findings and best practices

Microsoft Cloud – Azure AD: doing it right

Introduction

Recently Microsoft introduced a fully cloud-based product suite called Microsoft Office 365. Approximately at the same time other team of MS engineers delivered other, also cloud-based suite called Microsoft Azure. While MS O365 incorporates legacy flag products (i.e. MS Office, MS Exchange, MS RMS, MS Lync and SharePoint) used by most large enterprises, the Azure suite delivers more back-end services (i.e. MS SQL, Visual Studio, MS Active Directory, AIP – old SecureIslands and other) also previously used on-premises by many large enterprises. To manage access over this new cloud-based suite some of the products still leverage Microsoft Live ID, however all of the products use strategic solution called Azure Active Directory (AAD).

On-premises to Cloud with a single step

To simplify cloud on-boarding Microsoft ships a free tool called MS Azure Active Directory Connect (AAD Connect), previously called DirSync. Considering fact organizations integrated for access management with Microsoft Active Directory Domain Services (MS AD DS) would like to immediately start using cloud services, AADConnect is a tool that quickly make a copy of legacy AD and maintains this copy in the cloud respecting ongoing AD changes. Business considering move from legacy environment could be ensured about easiness of the migration process as well as stable coexistence possibilities (hybrid scenario) of both environments.

Id-Centric Identity Management

To illustrate how the MS off-the-shelf solution works one has to look at place of Identity and Access Management (IAM) in an organization. IAM system should translate business settings for technical systems. It should reduce a custom technical configuration for an employee during joiner and leaver process or during technical target system on-boarding (e.g. Linux server or O365). IAM program aims to reduce individual technical support per employee as well as provides global unified access management that could support Single Sign-On and other modern authentication methods.

id-centric_identitymanagement

Figure 1. Id-Centric Identity Management

Considering fact that business processes should be at the beginning of any technical access provisioning, the IAM translates business processes and enforces access management in target systems context. Mature centralized Identity and Access Management highly reduces complexity of provisioning processes that exist in many organizations since late 80′.

From perspective of identity provisioning and enablement after human resources (HR) officer submits new employee on-boarding form, the process triggers IAM to provision required identities in technical target systems (e.g. MS AD DS or MS AAD) and enable access for these employees across respective target systems (e.g. O365 license assignment, Enterprise Administrative role, etc). This process is transparent for HR, however is fully employee data driven.

Process of MS Cloud identity lifecycle should look as following:

  • HR registers a new employee
  • IAM system provisions cloud MS AAD account for the new employee
  • IAM system assigns correct O365 (other) licenses

Microsoft customers who already use Microsoft Identity Manager (MIM) as a central IAM system, can fully benefit from this architecture as MIM synchronizes directly with cloud using internal meta-directory and dedicated instance of a DirSync connector. All the customers who decided to use non-Microsoft IAM system have a possibility to leverage Microsoft Active Directory and a free AADConnect tool to move into cloud as an off-the-shelf approach. This approach have obvious advantageous, however to find its weak sides company architects and engineers should be prepared for an in-deep research.

Account-Centric Identity Management

The model proposed by Microsoft to ease the cloud enablement via AADConnect decentralized identity provisioning and shifted the responsibility from IAM system to MS Active Directory (MS AD). True is that in early directory implementations MS AD and LDAP kept employee information together with technical identity information. Furthermore many companies leveraged these directories as a central identity repository or an address book. Problem arose when technical infrastructures grew and business processes became distant from systems that ought to simplify enterprise management. Nowadays there is a clear line between Identity and Access Management and directories like MS AD.

MS AD is extremely efficient as a database for technical identities, however there is still loads of information that is relevant only for legacy systems and information that from data protection perspective should not leave the organizational boundaries just to simplify a cloud migration.

MS on-premises to cloud-enabler solution actually anchors to technical directory (i.e. MS AD DS) and synchronizes all information into the cloud. Functionally all existing accounts are automatically re-provisioned in MS Azure Active Directory with a technical legacy anchor and after correct license assignment employee could start using MS Cloud services (i.e. O365, etc), however the fully managed and controlled IAM architecture is lost (see Figure 2).

account-centric_identitymanagement

Figure 2. Account-Centric Identity Management

Process of identity lifecycle and MS Cloud enablement using AADConnect is following:

  • HR registers a new employee
  • IAM system provisions MS Active Directory account for the new employee
  • IAM system starts checking every n minutes if cloud MS AAD account is synched
  • MS AADConnect within t time synchronizes new account into cloud MS AAD
  • IAM system finds new MS AAD account and assigns correct O365 (other) license

Design Considerations

Identity Management for O365

Microsoft introduced completely new set of APIs to unleash the real power of its new cloud based suite. Complete identity and access management could be handled with Microsoft Azure Graph API. New identity could be provisioned with only required attributes what does align with data protection directives. Identity could be moved to recycle bin at the end of identity-lifecycle process. Engineers may decide to keep the identities after deletion without any identifiable attributes. Account names could be anonymized and renamed to unique GUID known only to IAM system.

To completely remove identities in Azure AD, the neither Microsoft Graph nor Azure Graph APIs  provide complete control over the recycle bin. Currently only MSOL PowerShell Module can automate recycle bin clean up.

Identity could be also provisioned with Microsoft Graph API the second interface that covers not only identity related operations but also O365 suite management.

Claim-based authentication with on-premises MS AD

Cloud services access could be controlled with authentication against an on-premises Microsoft Active Directory. Passwords and other credentials do not have to be stored directly in the cloud, furthermore Graph API could set all the attributes (i.e. immutableId) required for on-premises password verification. By default any authentication proxy, e.g. Microsoft Active Directory Federation Services (MS AD FS) could respond to MS Cloud claim using simple SAML token.

Azure AD and Messaging

From Exchange Online perspective the only attribute that could be controlled via Azure Graph API is a mail address but also not directly. It could be set upon provisioning using mailNickname (Alias) attribute. mailNickname is used to generate a new email address just after Exchange Online license is assigned to Azure AD account.

Azure Graph API and Microsoft Graph API at its current stage do not offer any Exchange Online related support. Although Microsoft Graph API Beta should provide support for proxyAddresses and mail attributes.

Remote PowerShell for Exchange Online opens all the settings that are still not fully available in Graph APIs. Remote PowerShell could be easily integrated into complete solution either with .Net or with Java code. The main and only bottle neck of Remote PoSH is that Microsoft introduced throttling limitation. However with a proper code design all logic could be handled on the core code side and PoSH could be used only at the end to execute simple (CRUD) commands. Each PowerShell pipe is counted towards throttling limitation so simple requests with a shared global Remote Exchange PowerShell session could suffice large number of requests executed within milliseconds after each other.

Worth mentioning that entire Exchange Online forwarding goes through Azure AD rather than dedicated Exchange Online directory partition.

Microsoft Cloud Insights

Microsoft Cloud is a set of products that were previously offered on-premises as a standalone installation. These products maintained own meta-directory for application meta-data using either Microsoft Active Directory (MS AD) or Microsoft Active Directory Lightweight Directory Services (MS AD LDS). Behind Exchange Online or Skype for Business resides fully operational MS AD infrastructure while Microsoft Azure Active Directory (MS AAD) leverages legendary MS AD LDS.  All the directories including Azure Active Directory (MS AAD) are interconnected under Multi-Master model with a quite buggy sync service. Using MS Cloud for a small enterprise this might be a minor issue to consider, however for larger enterprise fact that identity attributes are synced and might remain inconsistent across directories (e.g. ExternalEmailAddress changed in Exchange to a different value than PrimarySmtpAddress is overwritten by sync from Azure AD to mailAddress value; after second try it works) becomes a major problem.

Words from Author

Prior to writing this short post I completed an architectural design and development of Identity and Access Management connector between non-Microsoft IAM system and Microsoft Azure AD, and Exchange Online. Having around 70k employees (internal/external) that will use Microsoft Cloud it was simply impossible to make any compromises reducing quality of existing identity lifecycle processes.  We (my team and I) had a hard time with MS consultants and PFEs. It seemed that in Europe no one wanted to support this architectural approach for cloud enablement and Exchange migration. We spent hours explaining this solution to MS specialists having only one answer, “it’s not going to work!”. After the first successful pilot release we talked to MS developers and engineers behind Azure AD and Graph happy to hear from them that this approach is nothing Microsoft would discourage and that this is a 100% valid approach.

Note, that making the right architectural decision now might be easier as more and more people experience and describe various issues with wrongly chosen design for cloud enablement.

Apendixes

Useful links

Azure AD Graph API reference

Azure AD API Graph Explorer

Microsoft Graph

Calling the Microsoft Graph API

Microsoft Graph API Explorer

Exchange 2016 cmdlets

Documentation for the Microsoft Graph REST API

PRIVILEGED ACCOUNT – PASSWORD POLICY AUDIT

Introduction

Corporate information security policies among general personal data handling policies, acceptable encryption policies and others, often define privileged access policies. While most of the organizations aim to use one central identity many of them still maintain secondary privileged identities that are entitled to perform sensitive operations.

Privileged Digital Identity

One of the reasons why secondary identities are in use is that a single identity, when stolen gives attacker both un-privileged and privileged rights. One identity is often used to access all corporate systems without need of identity re-verification.

Central employee digital identity (account) because of its common use is exposed to several risks and secondary privileged identity, when properly used under well-defined privileged access security policies eliminates these risks.

Single sign-on (SSO) functionality together with single identity model simplifies access to corporate systems by eliminating a need of re-authentication although at the same time it leads to certain risks. E.g. when authenticated primary identity session is compromised attacker gains access to all SSO enabled systems.

SSO enabled systems hosting sensitive information should support additional safeguards including additional authentication factor or re-authentication of one of the authentication factors what would sufficiently verify legitimate access attempts.

Furthermore correctly implemented data protection program enforces Separation of Duties principle, which ensures that one physical person and one identity cannot perform sensitive operations.

MS AD DS Password Policies Issue

Privileged access policies define password policy for privileged accounts (identities). Unlike unprivileged identity here only strong passwords should be used.

Under Microsoft Active Directory Domain Services (MS AD DS) granular password policies can be defined for different accounts based on their location or security group membership. Employee privileged account, if properly configured will enforce use of only strong passwords making common attacks harder to perform.

Problem that arose here is how to enforce use of two different passwords for unprivileged and privileged accounts. Privileged account password, defined under stronger than unprivileged account password policy, can still be used by employee for both accounts. MS AD DS password policies can define password complexity but cannot enforce employee to use different passwords for each owned account.

Identity and Access Management (IAM) or Privileged Access Management (PAM) systems can perform such checking when employee initially sets account passwords in interconnected systems, however this introduces another risks related to actual implementation of such a functionality. These systems would need to store password hashes for each account therefore maintain another replica of password hashes. For an attacker this is another location where credentials related information could be stolen.

Privileged Account Password Audit

Here we would like to introduce rather static approach, which can be a part of an internal corporate information security audit program. Regularly reviewed account passwords can identify unprivileged accounts that share same password with privileged accounts. While most of the systems store passwords as a hash, the properly implemented privileged password audit process can be relatively secure as password verification can be scoped only to salted and unsalted hashes comparison.

Password Hash analysis

Background

Microsoft Active Directory Domain Services (MS AD DS) is build on top of a flat Extensible Storage Engine (ESE) database. ESE leverages NTDS.DIT to store directory tables. Internal MS AD DS database structure is not that different from what one can see using advanced GUI tools, although internal row numbering is implemented as low level Distinguished-Name Tags (DNT), unique and small values making MS directory capable to store and process approximately 2.15 billion objects during its lifetime.

While MS AD DS seems to be extremely efficient to deliver identity meta-data platform for large enterprises and global organizations it is not capable of storing identities with its underlying metadata of entire world population which currently reach something about 7.3 billion people.

Basically NTDS.DIT database file contains 12 tables:

  • MSysObjects
  • MSysObjectsShadow
  • MSysUnicodeFixupVer2
  • datatable
  • hiddentable
  • link_table
  • sdpropcounttable
  • sdproptable
  • sd_table
  • MSysDefrag2
  • quota_table
  • quota_rebuild_progress_table

Each table stores different directory partitions data, however identity (user) information is stored under datatable table.

Export ESE DB table data

To obtain datatable data we will need some tools and libraries that are dedicated to read directly ESE database file. For our Proof of Concept we will use libesedb library and Mac OS X 10.9 system. Additionally to simplify our data mining we will use Python and PyCrypto library.

Assuming we have the latest Xtools installed we need to compile libesedb project.

Figure 1. Configure libesedb project before compiling

Figure 1. Configure libesedb project before compiling

Figure 2. Initiate libesedb library compilation

Figure 2. Initiate libesedb library compilation

Figure 3. Complete libesedb library installation routine

Figure 3. Complete libesedb library installation routine

Next step is obtaining NTDS.DIT database file from one of our domain controllers. There are several ways to copy NTDS.DIT file. For large enterprises it is recommended to use Windows server backup, however for our testing we will use MS Volume Shadow Copy Service (VSS). By default NTDS.DIT file is located under %SystemRoot%\NTDS folder but due to security reasons engineers often place it on non-system disk.

Figure 4. Enable shadow copy for system drive

Figure 4. Enable shadow copy for system drive

Now NTDS.DIT file can be easily copied, however only from the shadow copy. It is important to make a copy of another SYSTEM file, which will be used in later stage to encrypt our password hashes.

Figure 5. Copy required files from shadow copy

Figure 5. Copy required files from shadow copy

Decrypt Password Hashes

Password hashes are still encrypted in our export file with DES algorithm using hive. Hive is a 16-byte long boot key used to encrypt various Windows objects meta-data. Hive in MS Windows systems is simply obfuscated in system registry. Tools we will use to select only security principals from our DB with respective hashes can derive hive from SYSTEM file (we have already copied together with our NTDS.DIT file).

Creddump Python toolset comes with an useful dsdump.py[1] script, which returns all the information we need to complete our analysis.

Figure 6. Retrieve accounts with password hashes using dsdump.py script

Figure 6. Retrieve accounts with password hashes using dsdump.py script

From filtered export data we can see two accounts: priv_user020012 and user020012 have the same password hash therefore employee uses the same password for both privileged and unprivileged account.

 

[1] Please note that dsdump.py in its current release uses dshashesdump.py script, which was created for Python 2.x. It has to be slightly modified for Python 3.x which throws an error on non trivial cross-data types casting.

E.g.

Line: if ((int(tmp[user_accountcontrol_index]) & 2) > 0) and (include_disabled == False)

Replace with: if tmp[user_accountcontrol_index] and ((int(tmp[user_accountcontrol_index]) & 2) > 0) and (include_disabled == False):

Summary

The highlighted security issue is a common problem in all types of organizations where additional privileged accounts are used to separate privileged operations from unprivileged ones. We shown that the problem can be addressed with a routine information security audit program supported by simple toolsets what has been shown in above PoC. Efficient implementation should automate all the steps required to verify accounts password compliance by identifying accounts and employees that do not comply with privileged accounts password policies.

RBAC UPSIDE DOWN

Introduction

RBAC is one of non-discretionary access control models responsible for execution of business processes in context of employee access within an enterprise.

Many large companies decide to implement Role-based Access Control model. Mostly, this is a result of technological changes management initiates to improve internal processes behind IT systems. Very often non-efficient technical processes, which hardly follow the business changes, are a direct cause of the decision to initiate RBAC implementation project.

When company starts long-term project aiming to implement new access control model there is a dedicated team focusing on RBAC architecture, design and implementation. This team and the project become independent from other teams and aim to improve corporate internal ecosystem.

Here we would like to show basic technicalities behind RBAC and explain why initiation of global independent project may fail if it does not fully integrate with existing legacy business processes and is not coordinated across several teams.

RBAC Prototype

Roles can be categorized in several ways, depends on business size and IT systems complexity. The model that suits most of the Large Enterprises (LE) defines two main role categories: Business (Organizational) Roles and Technical Roles (Groups). There is a space for different variations using nested roles of the same category. However the simplified model defines two main categories (see Figure 1).

Roles layering

Figure 1. Roles Layering

Core Business Roles assignment should be initiated directly or indirectly by HR department. This assignment should be dynamic so any business change has always impact on roles.

There are several techniques to integrate HR processes with Identity and Access Management (IAM) processes. HR system can have dedicated components responsible for access management enforcement, although most often we deal with heterogeneous implementations, where HR system is independent from IAM system. In this scenario, we assign Business Roles in IAM system to an employee through exposed properties (attributes) from HR system.

Figure 2. Business Roles assignment based on employee record properties in HR system

Figure 2. Business Roles assignment based on employee record properties in HR system

Next step is to assign Technical roles to corresponding Business Roles. Let’s assume we can leverage existing directory system, where groups are already permissioned over corporate resources. These legacy directory groups act as low level Technical Roles, however when it comes to large IAM infrastructures they actually align better with systems than business processes. Resources are permissioned via these groups by a resource owner like in discretionary access control model.

To better manage these specialized directory groups we can create additional Technical Roles layer in our IAM system, however we focus here on the most simplified scenario. The existing Technical Roles despite whether these are resource groups, application groups, network groups, system groups, policy groups, project groups or others are used by technical teams to permission employees. The common process of giving access rights to a newly hired person or an employee moved within an organization requires entitlements pattern. Support teams most often know these patterns or there is an existing process where either team manager delivers technical roles (groups) baseline or simply other employee entitlements are used as a rights provisioning baseline. This is the point where we turn our RBAC rollout model upside down. We should leverage these existing processes and deliver tools and education to these technical teams so they act as access management team responsible for building our roles. Every time new employee’s identity is provisioned into corporate systems, the team using IAM system instead of duplicating rights from other employee can save the rights baseline as a “profile”. This “profile” is our future candidate for Business Role. Next time employee joins the same team instead of rebuilding entitlements from scratch the “profile”, our Business Role can be applied.

RBAC Rollout

Many leading market companies decided to initiate RBAC project. Unfortunately, large amount of these companies either failed or still try to rollout the RBAC system. The main issue is that the roles model created, when reach maturity from business perspective, it is already behind the technical changes. Also when roles are tailored to suit the technical provisioning and access control processes, the business is already changed and the whole implementation phase should move back to design phase to align the design with business. In an enterprise, where number of applications and resources exceeds dozens of thousands, the team dedicated to identify granular access rights, assign it to Technical Roles and next assign these roles to right Business Roles cannot address all the changes as are actually not a part of a unit that coordinates or implements these changes.

Conclusions

Experience shows that RBAC implementation should be an on-going process coordinated across several teams and departments aiming to influence already existing processes related to access control. These teams should be provided relevant tools and competent advice aiming to improve existing state rather than change it too quickly. Tier 1 and Tier 2 level teams are the best candidates for the enterprise RBAC enablement initiation. They deal with access control requests on daily basis. They also adjust technical accounts after provisioning and revocation. The same teams probably already worked out the baselines for access entitlements across several teams, departments, resorts, countries, etc. If it is not a part of a corporate knowledge base yet then it should become by giving these teams tools and simple RBAC how-to to facilitate their daily tasks. This is the big step to build the Technical Roles and organize them based on various categories.

“Any design that’s not based on empirical data it’s a design that’s destined to fail!”
Kayne McGladrey – Centrify Corporation