All Identities

Identity and Access Management findings and best practices

Enterprise Baked Privileged Access for Microsoft Cloud (no-Hybrid)

Introduction

Many organizations in order to comply with information security standards keep some baseline security safeguards what includes privileged access management (PAM) and monitoring. In legacy pre-cloud environments, many PAM vulnerabilities i.e. weak passwords or creeping privileges, were identified with rather low/medium risk. With emerging cloud computing legacy security boundaries like firewalls, on-premisses directories etc does not reduce the risk of weak or simply missing PAM processes. Microsoft Cloud has attracted maybe not all but definitely majority of customers with large and complex environments. Some of the customers decided to move maintain Hybrid solution with Azure Active Directory Connect (AADConnect) synchronizing on-premises Active Directory Domain Services (AD DS) with cloud-based Azure Active Directory (Azure AD or WAAD). However, there are companies that decided to manage Azure AD as a separate target system, a security boundary with no on-premises systems impact (i.e. AD DS). These companies use pure-cloud (no-Hybrid) solutions (see Microsoft Cloud – Azure AD: doing it right) where legacy PAM processes are absent.

Cloud Privileged Access

In MS Cloud there are several activities related to privileged access. Easiest way to initially identify privileged access assignments in Office 365 is listing of all Directory Roles and Directory Role Templates. These give identities specific privileged rights across all MS Cloud systems.

Currently there are several directory roles and the number still grows:

  • Company Administrator
  • Exchange Service Administrator
  • Helpdesk Administrator
  • Device Join
  • Customer LockBox Access Approver
  • Security Reader
  • User Account Administrator
  • Directory Writers
  • Application Administrator
  • SharePoint Service Administrator
  • Billing Administrator
  • AdHoc License Administrator
  • Power BI Service Administrator
  • Directory Readers
  • Device Managers
  • Device Users
  • Privileged Role Administrator
  • Application Proxy Service Administrator
  • Device Administrators
  • Lync Service Administrator
  • Partner Tier2 Support
  • Service Support Administrator
  • Guest Inviter
  • Application Developer
  • Security Administrator
  • Compliance Administrator
  • CRM Service Administrator
  • Directory Synchronization Accounts
  • Partner Tier1 Support
  • Intune Service Administrator
  • Workplace Device Join

Security engineer may decide to use groups as another privileged access entities and dynamically provision various objects with these custom groups given higher permissions over newly provisioned objects. This approach might be used to control PAM over some privileged cloud resources (e.g. mailboxes) in different geographical locations and legal jurisdictions.

Creeping Privileges

First and the most important thing every security engineer does is assigning privileged roles to different operators so they can now continue doing they daily tasks same as in a legacy on-premises world …

eeh… let’s say this is the past and also not everywhere.

First of all security processes that aim to protect the on-premises systems have to be improved and adapted for cloud systems. It is important to remember that security boundaries protecting accounts with elevated rights are not the same or simply are absent in the cloud. Unprotected on-premisses privileged accounts with various rights over sensitive systems, productive servers and various highly privileged assignments had no direct exposure to attacker. Now adversary obtaining cloud privileged credentials can immediately access and manage O365 systems online.

This problem could be solved or the risk of compromising MS Cloud tenant could be reduced in context of creeping privileges. Most often corporate technical processes consist of change windows where operators roll-out system changes into productive environments strictly during scheduled change hours. This reduces visible failure impact and simplifies roll-back scenarios. Between change windows there are no individuals performing any operations requiring privileged rights in MS Cloud unless there is a security incident requiring emergency rights. Privileged or personal accounts having elevated rights assigned permanently fall into creeping privileges security vulnerability. Temporary access using either Temporary Privileged Access (TPA) or Break-Glass (BG) processes ensures that no single active account is exposed outside of a change window.

Temporary Privileged Access

By automating Identity and Access Management (IAM) for MS Cloud there are several processes that could be leveraged to govern access in more secure way. Great feature present in many off-the-shelf IAM systems are temporary requests or scheduled transactions. Temporary request behaves like two transactions Create – scheduled earlier or now and Delete – scheduled in the future.

Temporary Privileged Access (TPA) consists of two actions, granting and revoking privileged rights. This could be a group membership, a role assignment, or even a temporarily enabled privileged account.

Privileged Assignments

Access granted for a short time, i.e. 3 hrs – 14 days, after privileged resource, i.e. directory role or group assignment request (see Figure 1.). In O365 Company Administrator, Exchange Administrator, SharePoint Administrator, Lync Service Administrator are the roles that should not be assigned to anyone permanently. If there is an account having these rights permanently assigned this account should be controlled with TPA process for accounts, where accounts are disabled and passwords are randomly generated and not divulged to operators.

Privileged MS Cloud directory roles should have an owner or a group of owners assigned that are responsible for granting the access. Approval could be extended by local security authority, the individual that actually knows the requester and is aware of existing corporate security policies.

This process could replace existing permanent groups assignment model where employee is given permanently custom group memberships. The assignment time could be exceeded to couple months and prolongated if needed.

Organizations having dynamic Role-Based Access Control  (RBAC) or/and Attributes-Based Access Control (ABAC) in place could leverage this process (see RBAC UPSIDE DOWN) while all permanent group assignments respond to business changes and all custom requests are on temporary basis via TPA.

 

TPA-Assignment

Figure 1. TPA – Assignment

Privileged Accounts

Highly privileged accounts that are given elevated rights permanently should be protected with different safeguards. Security engineer may maintain two highly privileged accounts each for different PAM process. One disabled with password stored (printed out) in a physical highly protected vault and the other one disabled with password dynamically generated upon TPA account request (see Figure 2.).

In MS Cloud account with Global Administrator right, means account having all or most of the directory roles assigned should be protected and not used on daily basis. This account as any resource should have an owner or a group of owners that are responsible for granting the access. Approval could be extended by local security authority, the individual that actually knows the requester and is aware of existing corporate security policies.

TPA-Account

Figure 2. TPA – Privileged Account Activation

Break Glass

Privileged Assignments

This process is very similar to TPA processes, however there is no approval required every time access is required. Here operator or anyone requiring privileged access is assigned to a BG activator role. This role does not grant any access directly however makes any future temporary access requests possible (automatically approved).

MS Cloud Exchange Administrator or any group of activator roles once assigned gives potential for unrestricted time-constrained Exchange Administrator directory role assignment (see Figure 3.).

BG-Assignment

Figure 3. BG – Privileged Assignment

 

Privileged Accounts

Accounts protected with Break-Glass processes are normally highly privileged accounts e.g. Enterprise Admin accounts in Active Directory Domain Services or Global Administrator (multiple privileged directory roles) accounts in O365. Such account in MS Cloud may have assigned permanently Company Administrator, Exchange Administrator, Lync Service Administrator and SharePoint Administrator roles. Such accounts insufficiently protected compromise any security safeguards delivered by Cloud Service Provider (CSP) or that are present in cloud tenant.

Same as in TPA a security engineer may maintain two highly privileged accounts each for different PAM process. One disabled with password stored (printed out) in a physical highly protected vault and the other one disabled with password dynamically generated upon Break-Glass request.

In BG process operator or anyone requiring privileged account is assigned to a BG activator role (see Figure 4.). This role does not enables privileged account directly however makes any future temporary Break-Glass requests possible (automatically approved).

BG-Account

Figure 4. BG – Privileged Account Activation

 

Post-factum BG justification

Any Break-Glass implementation may or should introduce retrospective approval upon access request justification given by requester. This process is extremely useful when individual requires immediately access to highly sensitive resources. Request has to be justified and while access is granted simultaneously security incident is generated and is pending for approval (see Figure 5.). Security responsible within specific time (e.g. 48 Hrs) have to close the security incident by approving the access. Approval flow may be extended to include global security authorities, line managers and data custodians and others.

 

BG-Justification

Figure 5. Break-Glass justification

Cloud IAM

Multi-factor Authentication with Federated-Identity

MFA for cloud, i.e. MS Cloud can solve many problems with potential insufficient Azure AD accounts protection. Federated identity makes it possible to authenticate any identity against on-premises authentication authority. Furthermore, passwords are never verified against the cloud but against internal identity provider (IdP).

MS Cloud could be easily federated (joined for authentication) with MS Active Directory Domain Services (MS AD DS) using Active Directory Federation Services (ADFS). Every personal Azure AD account maintains credentials on-premises and with properly implemented PAM program have no effective rights assigned in the cloud.

Only bottle-neck of MFA is that automation is not easy especially if using Remote PowerShell to manage O365 systems. Only this year MS finally enabled MFA support for Exchange Online (EXO), however the PoSH flow still differs from other O365 systems what makes any automation complex and almost impossible for 3rd party vendors (O365 migration teams, etc).

Named-privileged accounts

Using named privileged accounts is not a new approach and almost every large organization uses dedicated administrative accounts assigned to employee to separate personal identity from technical privileged identities (see PRIVILEGED ACCOUNT – PASSWORD POLICY AUDIT).

One of the problem with named privileged accounts is fact that these are normally permanently assigned with privileged groups and roles in various target systems and that these are almost never disabled when unused. Furthermore, missing password policies and trivial  naming convention applied for these accounts makes environment enumeration prior attack easy (e.g. all admin accounts start with priv or admin key word).

In MS Cloud named privileged accounts are secure if combined with Federated Identity for MFA against on-premises IdP. Problem to be solved is Single Sign-on experience lost when operator uses named privileged account for scripting and automation. In order to use Remote PowerShell for O365 systems first of all individual has to impersonate the console with own privileged account and then start the Remote PowerShell authentication flow. EXO requires additional impersonation for Internet Explorer session as the PoSH session requires valid temporary certificate that could be leased only while visiting O365 Portal.

Unnamed-privileged accounts

Privileged accounts that don’t belong to one individual could be used by more than one operator. These accounts have permanently assigned highly privileged rights in a target system. Account should be disabled and if enabled only for one individual during scheduled operations. It is very important that only one person can obtain temporary password at time. By applying TPA – Account or BG – Account processes to unnamed privileged accounts it is possible to highly improve corporate security in MS Cloud.

Unnamed accounts could be federated, however most often these are accounts authenticated directly against Microsoft Online IdP.

Having no corporate security boundaries such accounts are exposed publicly and if enabled could be leveraged by adversary to compromise the MS tenant.

E.g. external operations team worker performing privileged changes in MS tenant was asked to leave the company. Security operations team ensured that all personal accounts of this individual are immediately locked, however this person still holds password for privileged MS cloud accounts. After leaving the building the fired individual still could try to leverage privileged unnamed account if proper PAM processes are not in place.

Technical non-interactive accounts

Technical non-interactive accounts, same as unnamed privileged accounts are used by more than one individual. Such service accounts / technical identities perform routine changes in automated manner. Federation of such accounts is not possible due to lack of generic support for scheduled Remote PowerShell for O365 systems. Of course advanced developer could simulate the MFA flow within a script, however with new EXO PowerShell MFA support there is no guarantee that libraries used for establishing remote sessions are not going to be changed (note that session is established upon visiting O365 Portal).

Using permanently permissioned technical non-interactive accounts with password stored in the cloud brings loads of security issues. First is the fact that service account passwords are rarely changed due to impersonated running processes that fail if account password has changed. Furthermore such accounts are always enabled.

Again, if an employee has to leave a company having knowledge of such accounts outside could compromise entire MS tenant from outside of the company.

There is still no certificates support for EXO PowerShell and other O365 systems might have this possibility but implementation is highly customizable. Only certificate could ensure proper technical non-interactive accounts usage and enforce where you are access principle.

Conclusions

PAM solutions presented here are designed for “pure” Microsoft Cloud in no-Hybrid scenario. Authors recommend implementation of these services for any large organization either for on-premises or cloud-based privileged access management. All individual group assignment could be a subject for TPA despite whether the group is privileged or not. Other non-discretionary access control models (e.g. RBAC and/or ABAC) could control permanent groups and roles assignments based on business structure. Temporary memberships simplify complexity of the environment in long term as well as highly improves audit points having no unnecessary rights assigned.

Break-Glass processes should be used only for privileged access due to rather higher complexity of the implementation requiring additional abstract layer for Activator Role giving actual privileged access potential to an individual.

Only with properly selected PAM and IAM techniques MS Cloud could be considered secure on a level comparable with legacy on-premisses systems. There are additional built-in Azure features and safeguards helping to improve the overall security condition of the MS tenant, however processes described here are absent or only partially implemented in the MS Cloud.

Advertisements

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