Today Active Directory Security is mission-critical to organizational security worldwide and thus mission-critical to Cyber Security worldwide. On this blog, former Microsoft Program Manager for Active Directory Security, and today, CEO of Paramount Defenses, shares valuable technical insights on Active Directory Security.


Showing posts with label Microsoft Azure. Show all posts
Showing posts with label Microsoft Azure. Show all posts

Wednesday, October 11, 2017

A Paramount Question for Microsoft Azure CTO : he said 'Ask me anything'


Dear Mark,

You Sir, are Mark Russinovich, Chief Technology Officer (CTO) of Microsoft Azure, and for you I have the greatest of respect.

A few days ago at Microsoft Ignite, you said - "Ask me anything!" -


By the way, I must compliment you for doing so, because when you do so, you really have to be ready for any/every question!




So, I'd like to ask 1 Question

Mark, on behalf of 1000s of Microsoft's organizational customers, I'd like to most respectfully ask you just one simple question -

Question: How can/should organizations find out exactly who actually has what privileged access in their Active Directory ?


Specifically, how can organizations determine exactly who can do what on the 1000s of domain user accounts, domain computer accounts, domain security groups, containers, OUs, SCPs etc., including of course all their privileged and executive domain user accounts and groups that reside in their foundational Active Directory?


I only ask this question because as you too will likely agree, this 1 simple question directly impacts and thus is paramount to the foundational cyber security of over 85% of all organizations worldwide, all of whom operate on Microsoft Active Directory.


I really do hope that on behalf of Microsoft, you'll answer this question, for organizations worldwide look forward to the answer.

Most respectfully,
Sanjay

CEO, Paramount Defenses


PS: Sir, if you've ever heard of AccessChk.exe and know what it does,
(and I believe you have), then you know the answer to this question.

PS2: As former Microsoft Program Manager for Active Directory Security, I'd like to offer a hint. The answer to this question is also the (premise for, and thus the same as the) key to the ten questions below, and in essence it involves just two words -
1. What Constitutes a Privileged User in Active Directory?

2. How to Correctly Audit Privileged Users/Access in Active Directory?

3. How to Render Mimikatz DCSync Useless in an Active Directory Environment?

4. How to Easily Identify and Thwart Sneaky Persistence in Active Directory?

5. How to Easily Solve The Difficult Problem of Active Directory Botnets?

6. Why are the World's Top Active Directory Permissions Analysis Tools Are Mostly Useless?

7. Why is the Need to Lockdown Access Privileges in Active Directory Paramount to its Defense?

8. How to Attain (Lockdown) and Maintain Least Privileged Access (LPA) in Active Directory?

9. How to Securely Delegate and Correctly Audit Administrative Access in Active Directory?

10. How to Easily Secure Active Directory and Operate a Bulletproof Active Directory deployment?

In short, the answer is (something like) this -
Ans: To do so, all that organizations need to do is to accurately and adequately determine e******** p**********/a***** on their Active Directory objects. That's it.

Wednesday, September 13, 2017

What are the Security Implications of An Unauthorized User Being Able to Change the Properties of a Service Connection Point in Active Directory?


Dear Microsoft,

Today is Day-17 of our Active Directory Security School for you. Today, we'll take a closer look at a little known thing in Active Directory, the unauthorized modification of which could result in all kinds of havoc being wreaked in no time (, and no, I wont be talking about the 100s/1000s of objects that reside in the Configuration partition.) I'll be talking about Service Connection Points.


Note: You'll want to read this if your organization is using any one of Microsoft Exchange, Centrify Server Suite, Microsoft Rights Management Server (RMS), Microsoft Group Policy, Microsoft Terminal Server, Microsoft Azure, Quest Active Roles Server, Quest Change Auditor, Quest InTrust, Quest Privileged Password Manager, BeyondTrust PowerBroker for Windows, Citrix XenApp & XenDesktop, IBM DB2, to name a few.



A Quick Primer

For those who may not know, a Service Connection Point is a class of objects that can be instantiated in Active Directory, and their intended purpose is to enable the publishing of information specific to a service (in the Active Directory) that the service's clients can use to find instances of and bind to that service. The LDAP name of this object's class is serviceConnectionPoint.


A Service Connection Point in Active Directory


For example, consider a distributed service hosted on multiple servers, each of which reside in a separate geographical location (and in networking parlance is different IP subnets) and/or each of which vary in their availability, quality-of-service, priority etc.

To help the service's clients locate the most suitable instance of this service, each instance of this service could advertise itself in the Active Directory by publishing an object of class serviceConnectionPoint, and specifying instance-specific parameters / technical data in the class's various properties/attributes (e.g. keywords) that can be easily queried and located by its clients.

The service's clients could then locate the most suitable instance of the service to connect to by searching the Active Directory for all service connection points that meet a certain criteria, such as affinity, proximity, availability, quality of service etc.

For instance, if Paramount Defenses were to ship a distributed application that had both client and server components, such as White Knight, then each instance of the server component could publish a Service Connection Point in Active Directory with specific attributes (e.g. keywords) and its clients could easily locate specific service instances by searching Active Directory with an LDAP filter such as (&(objectClass=serviceConnectionPoint)(vendor=pd)(description=whiteknight)(keywords=master-svr-1)).


It is also worthy of mention that although the primary intended purpose of Service Connection Points is to help clients locate service instances, organizations that develop Active Directory integrated apps sometimes choose to use this object class for other purposes. Perhaps the best example of this is the Centrify Server Suite, the flagship product of Centrify, a company that offers identity access management and privileged identity management to secure access across computer network and cloud computing environments, which is not only completely integrated with Active Directory, it heavily relies upon the use of Service Connection Points in Active Directory to amongst other uses, represent UNIX user and group profiles, as detailed below.


Here are some commonly/frequently used attributes of the serviceConnectionPoint class - Keywords, Description, Managed-By, Vendor, Service-DNS-Name, Service-DNS-Name-Type, Service-Class-Name, Service-Binding-Information, Version-Number-Lo, Version-Number-Hi etc. In addition, vendors could also define sub-classes of this class with their own custom attributes.

Also, by default, Service Connection Points can be created under objects of class Computer, Container and Organizational-Unit.

In the interest of brevity as well as my time I'm not going to provide an elaborate backgrounder on Service Connection Points. Those who wish to learn more may feel free to independently research them. I'm going to assume you understand them well.





Security Implications

Organizations that use apps that rely on Service Connection Points for service location or other uses must consider the security implications of someone being able to make unauthorized modifications to the attributes of these Service Connection Points.


For instance, consider a mission-critical application, the clients of which rely upon the existence of Service Connection Points in Active Directory to locate specific service instances, and perform keyword-based LDAP searches to locate these unique Service Connection Points. If someone were to be able to modify the keywords attribute of any one of these Service Connection Points, he/she could impact the proper functioning of this critical application, because if the clients are no longer able to locate server instances, they may not be able to fulfill their intended function, which depending on the application could vary from protecting data to providing multi-factor authentication etc. and if thousands of clients cannot connect to a specific instance of the service, this could easily lead to a major IT disruption or a denial-of-service (DoS) and in some cases, result in a cyber security incident.



Thus, the unauthorized modification of the attributes of an application's Service Connection Point(s) in Active Directory could potentially have an adverse impact on that application, and by extension, on everything that relies on the proper functioning of that application.





An Important Question

Consequently and logically, yet another simple, elemental and fundamental question begs itself -

Question: Who can change the various attributes/properties of a Service Connection Point in  Active Directory ?

In fact, in addition, it also begs the following questions -
  1. Who can modify the ACL/permissions protecting a Service Connection Point? 
  2. Who can modify the owner of a Service Connection Point?
  3. Who can delete a Service Connection Point?
     That's because if you can do either one of the above, you can have the same effect on the service.


So, Microsoft, how should organizations answer these simple yet vital questions concerning their Service Connection Points?






Prominent Applications
That Rely on Service Connection Points

To appreciate the real-world security implications of what I have shared above, perhaps it may help to identify even just a few prominent applications that are today extensively deployed worldwide and depend on, and thus could be impacted by the unauthorized modification of, Service Connection Points.



Here are 10 such prominent applications that may likely be deployed at 1000s of organizations worldwide today -

  1. BeyondTrust PowerBroker for Windows - BeyondTrust's PowerBroker Identity Services (PBIS) centralizes authentication for Unix, Linux and Mac environments by extending Active Directory's Kerberos authentication and single sign-on capabilities to these platforms. As documented here, to store information about a group or a user, PBIS creates a serviceConnectionPoint object (in Active Directory) and stores information in its keywords attribute. 

  2. Centrify Server Suite - Centrify's Server Suite, beyond its core capability of integrating UNIX and Linux accounts into Microsoft Active Directory, supports privilege management capabilities, integrated cross-platform auditing, dynamic server isolation, and single sign-on to on-premises applications. One of the major strengths of the Centrify Server Suite, is that all UNIX identity and authorization data is stored as Active Directory objects. As documented here, it extensively creates and uses serviceConnectionPoint objects in Active Directory to represent computer profiles, UNIX group profiles and UNIX user profiles.

  3. Citrix XenApp and XenDesktop - Citrix's XenApp and XenDesktop application virtualization solutions optimize productivity with universal access to virtual applications, desktops and data from any device. As documented here, delivery controllers, the server-side component responsible for managing user access brokering and optimizing connections, are represented by serviceConnectionPoint objects in Site OUs in Active Directory. Each time a Controller starts, it validates the contents of its Service Connection Point. In addition, Windows Desktop Virtual Delivery Agents (VDAs) use OU-based controller discovery which relies on these service connection point objects.

  4. IBM DB2 - IBM's DB2 for Linux, UNIX and Windows is a next generation data platform for transactional and analytical operations that provides continuous availability of data to keep transactional workflows and analytics operating at maximum efficiency. As documented here, DB2 database servers are published in the Active Directory as ibm_db2Node objects, which is a subclass of the serviceConnectionPoint object class. Each such object contains protocol configuration information to allow client applications to connect to the DB2 database server. When connecting to a remote database, a DB2 client queries the Active Directory though the LDAP interface for these objects.

  5. Microsoft Exchange - Microsoft's Exchange Server is a messaging platform that provides email, scheduling and tools for customer collaboration and messaging service applications. As documented here, Exchange stores the configuration of Exchange Servers as well as information about user mailboxes in Active Directory. Its Autodiscover feature, that enables client applications and users to configure themselves with minimal input, uses Active Directory service connection points to store and retrieve a list of Autodiscover URLs for the forest in which Exchange is installed. When you install Exchange 2016, you need to update the SCP object to point to the Exchange 2016 server. This is necessary because Exchange 2016 servers provide additional Autodiscover information to clients to improve the discovery process.

  6. Microsoft Active Directory Rights Management Server - Microsoft's Active Directory Rights Management Server delivers Active Directory Rights Management Services (AD RMS), information protection technology that works with AD RMS-enabled applications to help safeguard digital information from unauthorized user, both online and offline, inside and outside of a firewall. As documented here, AD RMS publish Service Connection Points in Active Directory to hold the web address of the AD RMS certification cluster. AD RMS-enabled applications then use these Service Connection Points to discover the AD RMS service; it is the first connection point for users to discover the AD RMS web services.

  7. One Identity / Quest Privileged Password Manager - One Identity / Quest Software's Privileged Password Manager helps automate, control and secure the process of granting administrators the credentials necessary to perform their duties. Privileged Password Manager is a critical component of One Identity privileged account management solutions. As documented here, Privileged Password Manager publishes and relies upon Service Connection Points in Active Directory. In particular it modifies the serviceBindingInformation, displayName and keywords attributes of its Service Connection Points to store, amongst other pieces of information, your registered company name, Server URLs etc.   

  8. Quest Active Roles Server - Quest's Active Roles Server is a proxy solution designed to help organizations enhance account administration, directory management and security in Active Directory deployments. As documented here, as Active Roles performs operations on behalf of delegated users, the Active Directory service account requires adequate permissions. Quest recommends making Active Roles a member of Domain Admins. If organizational policies restrict its Domain Admin membership, then at a minimum, amongst a plethora of other permissions, since its service account must be able to publish itself in Active Directory, it will also require permissions to create serviceConnectionPoint objects.

  9. Quest Change Auditor - Quest's Change Auditor is an auditing solution that helps organizations track/audit changes to Active Directory, and thus helps ensure security, compliance and control of Active Directory content. As documented here, Change Auditor publishes Service Connection Points in Active Directory so that Change Auditor clients, agents and other third-party applications can automatically locate the Change Auditor coordinator. When clients or agents start up, they search Active Directory for these Service Connection Points to retrieve connection information for the Change Auditor coordinator such as hostname, listening port, and other authentication information.

  10. Quest InTrust - Quest's Intrust enables organizations to collect, store, search and analyze IT data from numerous data sources, devices and security information and event management (SIEM) solutions in one place. As documented here, Quest Intrust creates the following service connection point in Active Directory - <MyDomainName>/System/Quest In Trust/InTrustServer{<InTrustServerGUID>}.

Note - It must also be mentioned that the manner in which most of these applications have been integrated with Active Directory is consistent with Microsoft's recommendations, and in fact by integrating with Active Directory, these applications get to leverage its various capabilities, strengths and uses, and that is a good thing.

Speaking of which, of the applications above, perhaps the one that is most well-integrated with Active Directory, and thus one that uses and relies upon Service Connection Points most extensively may be Centrify Server Suite.


Oh, and the Azure AD Connect feature of Microsoft Azure also uses/relies on Service Connection Points in Active Directory.
( Specifically, as documented here, if you have an on-premises Active Directory environment and you want to join your domain-joined devices to Azure AD, you can accomplish this by configuring hybrid Azure AD joined devices. During their registration process, these domain-joined devices query the Active Directory for a Service Connection Point to discover Azure AD tenant information. Specifically they search for the object "cn=62a0ff2e-97b9-4513-943f-0d221bd30080,cn=Device Registration Configuration,cn=Services,cn=Configuration,dc=<forest-root-domain>" as it is this object's Keywords attribute that contains the organization's Azure AD tenant information. )


As you'll hopefully agree, most of these applications play a vital role in ensuring cyber security at organizations.

If you understand the role that these applications play in providing and ensuring security at organizations worldwide, then you know that the unauthorized modification of the attributes of their Service Connection Points could substantially impact security.





Reiterating The Question

Microsoft, in light of the above, i.e. considering that so many vital cyber security enhancing 3rd-party Active Directory-integrated applications publish and rely on Service Connection Points in Active Directory, let me again ask the simple, elemental and fundamental question I asked above -

Question: Who can change the various attributes/properties of a Service Connection Point in  Active Directory ?

So, Microsoft, how should organizations answer this simple yet vital question concerning their Service Connection Points?





Summary

Microsoft, today I just wanted to shed light on a simple facet of Active Directory-integration, the proper functioning of which too completely depends on Active Directory ACLs, of which there's an ocean in Active Directory, because it is the effective access that is actually permitted and thus gated by these ACLs that determines who can control these Service Connection Points.

If you consider the fact that most Active Directory deployments have been around for years, and that in most of them there has been an extensive amount of administrative delegation and access provisioning done over the years, then you'll find that in the ACL of each Service Connection Point in Active Directory there are numerous security principals for whom all sorts of access may be specified either directly (i.e. explicitly) or via inheritance, and in most cases, the number of individuals/services that currently possess sufficient effective access so as to be able to modify the keywords or other attributes of these Service Connection Points (far) exceeds the number of individuals/services who should be in possession of such effective access.

In essence, in all likelihood, at most organizations, many more individuals than should be authorized, likely possess sufficient effective access so as to be able to make unauthorized modifications to Service Connection Points in their Active Directory.


As I take your leave, I'll leave you with just one thought - imagine for a moment, if someone could make an unauthorized modification to the Service Connection Points of any one of these applications - Microsoft Exchange, Centrify Server Suite, Microsoft Rights Management Server, Microsoft Group Policy, Microsoft Terminal Server, Microsoft Azure, Quest Active Roles Server, Quest Change Auditor, Quest InTrust, Quest Privileged Password Manager, BeyondTrust PowerBroker for Windows, Citrix XenApp & XenDesktop, IBM DB2, resulting in an unforeseen situation wherein they might stop properly functioning.

What might be the impact of such an event on the organization?

Considering this, shouldn't organizations know exactly who can modify their Service Connection Points in Active Directory?


In my next post, I'll answer the question as to how organizations can easily and accurately make this vital determination today.

Best wishes,
Sanjay.


PS: For those who may want a hint as to the answer before I answer it, its in here (Slide #40.)

PS2: For those who may not yet know, and/or be curious to know just how many Service Connection Points there are in their Active Directory domains today (+ which vendors/apps they belong to), possibly the easiest way to do so is here (Report #94).

PS3: September 15, 2017 Update. The answer's here.

Tuesday, July 25, 2017

Active Directory Effective Permissions - Paramount to Cyber Security

Folks,

If you're into Cyber Security, and you could read only one piece this year, you'll likely want to read this post - its that important.

[ Some Context: Here is the associated press release - Paramount Defenses Skips Black Hat Conference 2017 to Educate World About Importance of Active Directory Effective Permissions to their foundational cyber security. ]

Today, I'll shed light on Active Directory Effective Permissions, a most vital topic that Microsoft (for reasons best known to them) apparently completely forgot to educate the world about, for a decade, even though it is paramount to cyber security worldwide.

Privileged Access in Active Directory

It is Active Directory Effective Permissions that determine who has what privileged access at 1000s of organizations worldwide.


(By the way, I find it astounding that even 17 years after Active Directory was shipped, 1000s of Microsoft's major organizational customers still don't seem to know about something so fundamental to their foundational cyber security - Effective Permissions.)


This incredibly important post is a bit long so for enhanced readability, it is comprised of the following 12 sections-
  1. This is Paramount
  2. A Simple $ Billion Example
  3. Active Directory Effective Permissions
  4. Their Importance
  1. The Effective Permissions Tab
  2. A Huge Challenge
  3. What Organizations Need
  4. The Solution
  1. The Answer
  2. A Note About Microsoft
  3. About Black Hat Conference
  4. Summary





This is Paramount

Let's begin by understanding why this is so relevant and paramount to the foundational cyber security of every organization.


Consider this. In an Active Directory deployment (the foundation of IT and cyber security at most organizations in the world,) do you know what is the only way to answer each & every one of the following 10 basic and elemental cyber security questions? -

  1. Exactly who has what level of privileged access where and how in Active Directory?

  2. Exactly who can create new user accounts, security groups, OUs, SCPs etc. in Active Directory?

  3. Exactly who can delete existing user accounts, security groups, OUs, SCPs, etc. in Active Directory?

  4. Exactly who can reset the password of which user accounts (including privileged users) in Active Directory?

  5. Exactly who can modify the membership of which groups (including all privileged groups) in Active Directory?

  6. Exactly who can modify the ACL of the AdminSDHolder object to control all privileged access in Active Directory?

  7. Exactly who can modify the contents of the Configuration and Schema partitions to gain control of Active Directory?

  8. Exactly who can manage all accounts, computers, groups, OUs, DCs, SCPs, Trust relationships etc. in Active Directory?

  9. Exactly who can compromise everyone's credentials by replicating secrets from Active Directory via Mimikatz DCSync?

  10. If any Active Directory integrated defense-in-depth measures such as these i.e. Smartcard authentication, MFA, Auditing, Random Password Manager, Password Vault etc. are in use, exactly who can disable them to render them useless?

The answer: Active Directory Effective Permissions.  (Not "Who has what permissions in Active Directory.") 


Organizations that do not have exact answers to these 10 simple questions cannot
be considered secure, so let's talk about Active Directory Effective Permissions.





A Simple $ Billion Example

This paramount cyber security concept is best understood via an illustrative example, so let's consider a real-world scenario -

Data Center

A fictional multi-billion dollar organization operates a high-security data-center, in which reside its high-value servers, including most of its file servers, web servers, app servers and Domain Controllers (DCs). Responsibility of managing all servers in the data-center is entrusted to the Data-Center Operations Team, an on-site team of highly trustworthy and proficient IT personnel.

To facilitate the privileged access this team needs, the organization created (and is using) an Active Directory security group called Data-Center Operations Team, and added it (via group policy) to the local Administrators group on all servers and DCs.

In effect, anyone who is a member of this highly privileged Active Directory (domain) security group Data-Center Operations Team has system-wide admin access and can thus control virtually everything in this multi-billion dollar organization's network.

Cognizant of this fact, the organization has worked really hard to minimize the number of individuals in this highly privileged Active Directory security group, and has been able to reduce its memberships to just 6 individuals -


Here are the members of this highly privileged Active Directory security group -

  1. David Parker, IT Manager
  2. Erica Lockhart, IT Administrator
  3. Larry Ellison, IT Administrator
  1. Michael Karp, IT Security Analyst
  2. Pamela Fitzgerald, IT Auditor
  3. Patrick Sullivan, Senior Operations Analyst
Speaking of which, for enhanced security, the organization also uses additional security measures to secure and defend all of its privileged user accounts (e.g. Enterprise Admins, Domain Admins etc.) which currently totals 15, including these 6 accounts.


Now, a Billion $ question begs itself - Although this highly privileged and mission-critical domain security group currently only has 6 members, "Exactly how many individuals can change the membership of the Data-Center Operations Team group?!"

This question is paramount because anyone who could change this group's membership could instantly take over everything.


The answer to this simple yet paramount question
lies in Active Directory Effective Permissions...





Active Directory Effective Permissions

First off, as you may know, to find out who can change the membership of the Data-Center Operations Team security group, you have to find out who all actually have sufficient access so as to be able to modify the group's Member property/attribute.

Next, some very quick theory. As you know, literally everything in Active Directory is an object, and each object is protected by an access control list (ACL) that is comprised of zero of more access control entries (ACEs), each one of which Allows or Denies one or more of a dozen types of security permissions to a specific security principal (user, group or well-known SID), and together i.e. collectively (, and not individually) these security permissions impact the resulting access on the object.

With that theory in mind, let's take a quick look at the ACL protecting the Data-Center Operations Team security group, with the intent of finding out who all actually have sufficient access so as to be able to modify the group's Member property -

The ACL protecting the Data-Center Operations Team domain security group in Active Directory

As you can see above, there are numerous ACEs in the object's ACL, each one of which either explicitly or via inheritance, Allows or Denies, one or more of a dozen types of security permissions to various security principals. In fact, observe that -
  1. There are numerous Allow and Deny permissions, some of which are explicitly specified on the object, whereas others are inherited down from the object's parent object, and their actual impact is determined by a precedence order.

  2. There are numerous types of Active Directory security permissions that are specified, such as Write - Member (Property), Write - Group Membership (Property-Set), Write All Properties, Modify Permissions, SpecialFull Control etc.

  3. There are numerous security principals for whom these security permissions are specified, including individual users('s accounts), security groups, and well-known security principals (e.g. Domain Users, Authenticated Users, Self, etc.)

  4. Of the numerous security groups for which access is specified, they could have other security groups nested in them (, and some could also possibly be circularly nested,) and thus could easily end up impacting access for many users.

  5. Of these various access control entries / security permissions that exist in an Active Directory object's ACL, not all of them may actually be applicable to the object, as they may exist solely to facilitate inheritance to downstream objects.

[ Note: For detailed observation, you can download the entire ACL protecting this object here. ]

Considering the above, how do we find out who all have sufficient access to be able to modify the group's Member property?

As observed above, there are numerous security permissions that are specified in various ways (Explicit/Inherited, Allow/Deny) for numerous users and groups (which could in turn contain other groups) in an Active Directory object's ACL, and (theoretically) each one of these permissions could overlap or conflict with each other, thus collectively impacting the actual resulting access.


To see this in action, let us attempt to evaluate the impact that just even two following randomly selected ACEs in this object's ACL can have on the resulting access of a randomly chosen user, Peter Thiel  -
ACE # 13:   Allow    IT America Admin Team             Write All Properties                                                   Inherited 
ACE #  9:    Deny    IT Operations Support Level 3    Write Property - Group Membership Property Set    Inherited

In case it helps, Peter Thiel's (domain user account's) domain security group memberships are displayed below -



As you can see, Peter Thiel happens to indirectly be a member of each of the domain security groups for which permissions are specified in these two ACES, so both these ACEs will end up impacting the actual access that Peter Thiel has on this group.

If you were to consider the first ACE shown above solely by itself, you may errantly conclude that Peter Thiel can modify the membership of this group, because Peter Thiel is a member of the IT Helpdesk Operators group, which is turn is a member of the IT American Admin Team group, which is allowed blanket Write All Properties, and that includes Write Property - Member.

However, if you were to also consider the second ACE shown above, then you will correctly conclude that Peter Thiel cannot in fact modify the membership of this group, because Peter Thiel is also a member of the IT Helpdesk Team group, which in turn is a member of the IT Operations Support Level 3 group, which is denied Write Property - Group Membership Property Set, and it so happens that the Member property is a member (pun unintended) of the Group Membership Property Set.

In essence, it turns out that even though Peter Thiel has Allow Write All Properties specified on the object indirectly, he also has Deny Write Group Membership Property Set specified on the object indirectly, and since the inherited Deny access will override the inherited Allow access, he will effectively have the ability to modify all properties except the Member property on the Data-Center Operations Team security group, and as a result, he will not actually be able to modify the membership of this group.

Now, it must also be mentioned that if there were to be even one other ACE that would explicitly end up allowing Peter Thiel Write-Property - Member whether directly or indirectly, that explicit Allow would override the inherited Deny, in which case, he would in fact be able to modify the group's membership. In such a case, it must further be mentioned that if there were to be even one other ACE that would explicitly end up denying Peter Thiel Write-Property - Member whether directly or indirectly, that explicit Deny would override the explicit Allow, in which case he would not in fact be able to modify the group's membership.

So you see, there could easily be well over a 100 ACEs in the object ACL, and each and every single one of these that specifies either of Write-Property - Member attribute, the Write Group Membership Property Set, Write All Properties or Full Control access, whether it be an Allow or a Deny and whether be explicitly specified or specified via inheritance, will likely directly or indirectly (i.e. via nested group memberships or well-known RIDs and SIDs ) impact whether or not Peter Thiel can change this group's membership, and they will also undoubtedly impact the complete list of users who will actually be able to change this group's membership. In other words, there could easily be over a 100 ACEs in the object's ACL and the permissions they specify collectively impact the resulting access on the object!

Thus, the only way to correctly (i.e. accurately) find out what access the ACEs in an ACL actually end up entitling on the object, and to whom, is to collectively take them into account and determine the resulting i.e. effective access they end up granting.

Consequently, the actual set of permissions / access that a user ends up being granted (i.e. allowed) on an Active Directory object, in light of having correctly considered the collective impact of the entirety of all security permissions specified in all of the ACEs in the object's ACL, are known as the user's effective permissions on that object.

As seen above, it is a user's effective permissions that determine what access a user actually has on an Active Directory object.





Their Importance

Active Directory Effective Permissions are extremely important because as illustrated above, it is "what effective permissions does a user have" and not "what permissions does a user/group have" that determines whether or not a specific user has a specific type of access granted on an Active Directory object.



Consequently, it is Active Directory Effective Permissions that gate every single LDAP operation that can be performed on Active Directory content.

Privileged Access in Active Directory

In other words, they control everything, including who can create, manage and delete all domain user accounts and security groups (including all privileged accounts and security groups), containers, OUs etc. in and across Active Directory.

In fact, in a Microsoft Windows Server based IT infrastructure, from user authentication to secure network-wide authorization to organizational IT assets, not a leaf moves without (access to) Active Directory being involved, and not a single access to Active Directory, whether it be read access or modify access, is possible without users having sufficient effective permissions to do so.

If users did not have sufficient effective permissions in Active Directory, the entire organization would come to a stand still. By the same token, if someone had sufficient effective permissions in Active Directory, he/she could control the entire network!






The Effective Permissions Tab

The importance of Active Directory Effective Permissions is perhaps best conveyed by the fact that in addition to the tabs for Permissions, Auditing and Owner(ship), the fourth tab in Microsoft's native security tooling is for Effective Permissions -

Effective Permissions Tab

In other words, for Microsoft to have dedicated an entire tab for Effective Permissions, they must be at least as important to cyber security (if not more so) as Permissions, Auditing and Owner(ship), which we all know are important for obvious reasons.

Unfortunately, as important as effective permissions are to organizational security today, Microsoft’s Effective Permissions Tab for Active Directory is not only not 100% accurate, it is substantially inadequate (; and has been so for a decade now.)

Here's why -
  1. It is not always 100% accurate, since it self-admittedly does not take all relevant factors into account

  2. Most importantly, it can only determine (an approximation of) effective permissions (granted to) ONE user at a time

  3. It cannot show which underlying permissions in the object’s ACL entitle a specific user to a specific effective permission

As to its accuracy, as shown in the snapshot above, in reference to the example considered in the previous sections above, for the user Peter Thiel, it is indicating that Peter Thiel has Write all properties effectively allowed. This is inaccurate because as illustrated in the example above, in reality, Peter Thiel has the ability to write (to) all properties except the Member property, and this fact is evidenced by the following snapshot -

Insufficient Access
As seen above, the Add and Remove Member buttons are disabled (grayed out) for Peter Thiel because he does not in fact have sufficient effective permissions to modify the Member property on the Data-Center Operations Team security group.


As to its limitation of only being able to determine an approximation of effective permissions for one user at a time, this single limitation renders this tab virtually useless, because due to this limitation, the only way for an organization to determine exactly who all have a specific type of effective permission on a specific Active Directory object, would be to have IT personnel manually enter the identities of every single one of thousands of domain accounts one by one, and make a note of each user's effective permissions, and that is neither practical nor realistically feasible.


As to its inability to be able to identify and pinpoint the underlying security permissions in the object's ACL that are entitling a specific effective permissions for a specific user, this ability is essential if organizations are to have any hope of being able to lockdown any excessive effective permissions/access that may have been identified on a specific Active Directory object. After all, if you don't know which ACE / security permission / security group membership you need to tweak to eliminate or lockdown an excessive effective permission, how are you going to mitigate the identified risk?


In short, in reality, the substantial deficiencies inherent in Microsoft's Effective Permissions Tab make it virtually unusable. The same is true of most other tools from Microsoft that claim to do effective permissions, including dsacls, acldiag, accesschk etc.

Further, whilst numerous vendors claim to offer solutions that can help find out "who can do what in Active Directory" or "who has what effective permissions", not a single one of them actually determines effective permissions, let alone being able to determine them accurately. They merely perform basic permissions analysis. Finally, this one tool that claims to be able to do effective permissions is not only dangerously inaccurate, it has the same deficiencies as Microsoft's Effective Permissions Tab.





Huge Challenge

(This section is for all amateurs who might say - "What's the big deal here? I imagine I could this with some PowerShell?")

As we saw above, merely evaluating the collective impact of just 2 ACEs alone can be complicated. In many real-world Active Directory deployments, there may be over a 100 ACEs in the ACL of each Active Directory object, and correctly collectively considering the entirety of all security permissions specified in each of these ACEs can be extremely difficult.


In fact, the accurate determination of effective permissions in Active Directory poses a HUGE challenge for the world.

Here's why -
  1. Active Directory's security model, albeit extremely powerful, is substantially more complex than the traditional Windows file and folder security model. For instance, while there are only a few generic permissions in the file and folder security model, there are almost a dozen generic permissions in Active Directory's security model, and in addition there are also almost five dozen special permissions known as Extended Rights, all of which substantially increases its complexity.

  2. The problem size is substantially larger, in that there are far more ACEs in an Active Directory object's ACL than there are in a file or a folder's ACL. In many Active Directory deployments, there may easily be over a 100 ACEs in each Active Directory ACL, considering that a substantial amount of access provisioning is done in Active Directory to facilitate administrative delegation and to configure access for various Active Directory integrated applications and services.

  3. The existence of and thus the need enumerate of a possibly large number of domain security group memberships, especially those that may be deeply nested as well as those that may be circularly nested, further increases the complexity of the process of performing accurate access evaluation and conflict resolution.

  4. The inclusion of numerous arcane details that are unique to Active Directory, such as including the impact of object ownership on effective access, dynamically evaluating relative well-known RIDs etc. further complicates the process.

Consider this - Imagine trying to determine effective permissions on an Active Directory organizational unit, in whose ACL there exist 150 ACEs, 100 of which specify varying levels of access for security groups, 75 of which (i.e. security groups) contain nested security groups, 50 of which contain deeply nested security groups, and 25 of which deny various forms of access and 10 of which are circularly nested, and you'll get a sense of just how difficult this process can be to perform, let alone automate.





What Organizations Need

In light of the fact that Active Directory Effective Permissions are vital and in fact paramount for organizational cyber security, today, organizations absolutely need the ability to be able to accurately and efficiently determine effective permissions in their Active Directory deployments.


After all, considering that the foundational Active Directory deployments of most organizations have been in operation for years now, in most deployments today there very likely exists rampant unauthorized / excessive effective permissions / access, so organizations need to identify and lockdown all such unauthorized / excessive effective permissions / access, especially that granted on mission-critical content, such as all high-value (privileged and executive) user accounts and security groups, the Domain Controllers OU, the domain root, AdminSDHolder, various parts of the Configuration and Schema partition etc.

Here are 3 simple needs that organizations have regarding determination of Active Directory effective permissions -
  1. Accuracy - First and foremost, the ability to be able to accurately determine effective permissions in Active Directory

  2. Efficiency - Secondly, the ability to be able to efficiently determine effective permissions in Active Directory i.e. ideally be able to determine the complete set of effective permissions granted on an object, as well as the identities of all users who have these effective permissions granted, without having to enter each user's identity one at a time.

  3. Source-Identification - Finally, the ability to be able to identify which underlying security permissions in the object's ACL are entitling a specific user to a specific effective permission on a specific Active Directory object.  

If these 3 simple needs could be fulfilled, organizations could swiftly attain and maintain least privileged access (LPA) in and across their foundational Active Directory deployments.





The Solution - An Adequate Active Directory Effective Permissions Calculator

Given just how important it is for all organizations to be able to adequately determine effective permissions in Active Directory, it was clear to me about a decade ago that if the world didn't have an adequate solution for this, in years to come we would all be facing a major cyber security challenge.

So, about a decade ago we decided to take on this huge challenge and started working to build an adequate solution to address it, because we had understood back then just how important and essential this was going to be for the world, in years to come.

(The intention was never to build a cyber security company per se, but rather a desire to take this huge challenge head-on, and to see if we could solve it, and further to see how well we could solve it i.e. just how easy could we make it for everyone. The company and its products are merely an outcome of the successful pursuit of this desire to address this challenge for the world.)

Today, it is my privilege to share with you the outcome of over half a decade of innovative, industrious and committed research and development, so allow me to share with you Gold Finger for Active Directory, the world's only accurate Active Directory Effective Permissions Calculator / Tool that also delivers on everything organizations need to address this huge challenge -

Gold Finger Active Directory Effective Permissions Tool / Audit Tool / Calculator

At the touch of a single button, Gold Finger can -
  1. First and foremost, accurately determine effective permissions on Active Directory objects

  2. Secondly, it can determine the complete set of effective permissions granted on an object, as well as the identities of all users who have these effective permissions granted, without having to enter each user's identity one at a time.

  3. Finally, it can also identify which underlying security permissions in the object's ACL are entitling a specific user to a specific effective permission on a specific Active Directory object, thus helping making remediation very simple. 
I suppose the only thing more remarkable that Gold Finger's abilities is its simplicity of use. All you need to do it launch Gold Finger, point it to an object in Active Directory, and click a button.

When you click that button, under the hood and completely transparent to you, over half a million lines of code go to work, and within minutes, if not seconds, determine the complete set of effective permissions entitled on an Active Directory object, the complete set of individuals to whom each of these effective permissions are entitled, and the underlying security permissions in the object's ACL that entitle every identified user to every entitled effective permission on the object.

On a humorous note, the only downside of its remarkable simplicity is that it makes the solving of such a difficult technical challenge look so simple that people often wonder what the big deal is! I mean you just click a button, and you're done ;-)


In order to appreciate just how difficult and complex this problem is to solve, perhaps its worth taking a look under the hood...


Under the hood, when you click that button, Gold Finger begins by locating Domain Controllers, identifying the object, retrieving its access control list, and then it initiates the computation of accurate effective permissions analysis on the object, which involves so many technical functions such as but not limited to discovering and analyzing the Schema, resolving SIDs, correctly expanding all relevant security group memberships many of which could be deeply nested, identifying and resolving circularly nested security group memberships, analyzing individual permissions in each ACE (of which there could technically be over a 100 in an ACL), evaluating the impact of each one of them in light of numerous factors such as and not limited to precedence orders, applicability, suitability, inclusion in property sets etc. as well dynamically evaluating any and all well-known RIDs (e.g. Domain Users) and SIDs (e.g. Everyone), mapping Self SIDs to the security principal if applicable, etc. and a whole lot more, and ultimately arriving at its output, and presenting it in a fashion that is as intuitive and user-friendly as it could possibly be.

In contrast, all that most of the currently available Active Directory Permissions Analysis/Audit solutions in the world do today is merely retrieve an Active Directory object's ACL, and report the identities of the security principals encountered in the ACL along with the security permissions specified for that security principal in the ACL. (Some of them may expand a few security group memberships.) In effect, they do about 1% of what needs to be done to do this correctly (because they don't know better), yet they have thousands of customers who too don't know better, and happily proceed to act on dangerously inaccurate data.


Now, consider this - Active Directory environments can be so diverse in nature (from a small 100 object single Active Directory domain/forest for a small business to a globally dispersed Active Directory forest with possibly dozens of domains and 100s of 1000s of objects) that it is extremely difficult to build a product / solution that can automate this process such that it can just work in any Active Directory environment!

One of our many customers worldwide, a prominent 3-letter acronym government agency has 250+ ACEs in the ACL of every object in their Active Directory, and Gold Finger accurately determines effective permissions on these objects within minutes.

There is only one other thing I'd like to mention - while this tool can automatically determine effective permissions and effective access on individual Active Directory objects, its big brother, the Privileged Access and Delegation Audit Tool (i.e. this one) can accomplish the monumental feat of automatically being able to do so on 1000s of objects i.e. an entire Active Directory domain!

Thus, as you can see not only is this paramount to global cyber security today, it is by no means an easy problem to solve, let alone automate. In fact it is almost impossible, and at Paramount Defenses, we go to great lengths to make what is considered impossible as easy as touching a button.






The Answer

This post would not be complete without providing the answer to the paramount cyber security question posed above, which was - "Exactly how many individuals can change the membership of the Data-Center Operations Team group?!"

The Answer: 27.

So, while this vital security group only has 6 members, today there are 27 individuals who can change/control its membership.

In fact, here is the complete set of effective permissions entitled on the Data-Center Operations Team security group.

Now, in case you're wondering how I figured it out, it was actually rather simple; I just clicked one button -

Gold Finger Active Directory Effective Permissions Tool / Audit Tool / Calculator

Specifically, I launched Gold Finger, pointed it to the Data-Center Operations Team domain security group in Active Directory, and clicked the Run button. That's it. A few moments later, as shown above, I had the results. (Here is the exported output.)

So, as you can see, without the ability to determine effective permissions in Active Directory, and of course, do so accurately, we would never know just how many individuals can control the membership of such a vital security group, and who they are.

Without this valuable insight, the organization would have continued to indefinitely operate under the false assumption that only 6 people could control the entirety of their high-business impact (HBI) servers in their highly secure data-center, whereas in fact in reality there are 27 individuals who can do so today!

(Oh, and we haven't yet evaluated and included the number and identities of individuals who have effective modify permissions on this group, and the number and identities of individuals who can reset the passwords of those 27 individuals and who have effective modify permissions on each one of those 27 accounts. Yet at the very least, we've been able to answer the question.)

That is what we mean when we say that most organizations today are operating in the dark. There are many many more individuals that possess all kinds of privileged access in Active Directory than those that they think they know about.





A Note About Microsoft

Folks, as former Microsoft Program Manager for Active Directory Security, I care deeply about Microsoft as well as the foundational cyber security of all organizations worldwide, so I wanted to share a few thoughts.



By now, you've hopefully comprehended just how important Active Directory Effective Permissions are to organizational cyber security. They are absolutely paramount to Active Directory Security, and Active Directory Security is absolutely paramount to the organizational security of thousands of organizations, and to the security of Microsoft's ecosystem.

If this is the case (and this is the case,) how could Microsoft have completely forgotten to educate its global customer base about such an important and mission-critical aspect of cyber security for an entire decade?! It is absolutely astounding!

Last year, when they finally provided some earnest guidance on the importance of defending Active Directory, while they spoke at length about security permissions in Active Directory, they again completely forgot to tell the world about the fact that to attain and maintain least privileged access in Active Directory, you need to determine effective permissions in Active Directory!

It is in light of the above that I asked this question - How Well Does Microsoft Really Understand Cyber Security?

I find it partly amusing and partly concerning that on one hand Microsoft may not even have educated its customers about such a vital aspect of cyber security for an entire decade (most likely because this paramount aspect of cyber security wasn't even on their radar), yet on the other hand, it is wooing and wants the world to entrust their cyber security in its recent Cloud offering!


One cannot emphasize enough just how paramount Active Directory Effective Permissions are to global security today. In most organizations worldwide, due to almost complete ignorance about the value and importance of effective permissions, we have a situation wherein most organizations are operating in the proverbial dark, and there in all likelihood exist thousands of excessive / unauthorized effective access grants, which pave thousands of privilege escalation paths in Active Directory, which can today be easily identified and exploited by any insider / intruder who knows how to determine effective permissions in Active Directory, even if with marginal accuracy.

Fortunately, since organizations worldwide can now accurately and efficiently determine Active Directory effective permissions, they can now finally secure and defend the very foundation of their security, their foundational Active Directory deployments.





A Note About the Black Hat Conference 2017

Folks, as some of you may know, the famed Black Hat Conference is on in Las Vegas, Nevada, USA.

Black Hat Conference

The Black Hat Conference is supposedly one of the top cyber security conferences in the world, and given how vital cyber security is today, thousands will be attending, and numerous cyber security experts will be presenting at Black Hat this year.

YET, not a single one of these top cyber security experts knows much about Active Directory Effective Permissions, or how to calculate them, or their paramount importance to Active Directory Security and thus to organizational security, or has a solution.

NOT one of them!

This, when in fact Active Directory Security is at the very foundation of cyber security of almost all organizations worldwide whose employees (from IT Security Analysts to CISOs) will be attending the Black Hat Conference in Las Vegas this year!


( Last year I learnt just how much (or should I say how little) the Black Hat Conference Review Board seems to know about Active Directory Security, when I had a chance to communicate with them about a presentation I wanted to do on Active Directory Security last year to help raise awareness, which they declined. They allowed a presentation titled "Active Directory Beyond the MCSE" by a respected MCM, but they declined a presentation titled "From Zero to Enterprise Admin Within Minutes" by former Microsoft Program Manager for Active Directory Security. In light of this, I will let you be the judge of how much they seem to know. The loss was solely theirs, and I will NOT be applying to present at the Black Hat Conference again.

In retrospect, I can't blame them, because as I have said and proven, over the years, Microsoft has provided ZERO guidance on this to the world, so how're Black Hat's experts supposed to know about this paramount aspect of cyber security? So hey Black Hat Conference Review Board, here's Active Directory Security 101 to get you guys ramped up - Active Directory Security. )


By the way, this year there will be a presentation titled "An ACE Up the Sleeve: Designing Active Directory ACL Backdoors."

Here's its description -
"Active Directory (AD) object discretionary access control lists (DACLs) are an untapped offensive landscape, often overlooked by attackers and defenders alike. The control relationships between AD objects align perfectly with the "attackers think in graphs" philosophy and expose an entire class of previously unseen control edges, dramatically expanding the number of paths to complete domain compromise.
While DACL misconfigurations can provide numerous paths that facilitate elevation of domain rights, they also present a unique chance to covertly deploy Active Directory persistence. It's often difficult to determine whether a specific AD DACL misconfiguration was set intentionally or implemented by accident. This makes Active Directory DACL backdoors an excellent persistence opportunity: minimal forensic footprint, and maximum plausible deniability.
This talk will cover Active Directory DACLs in depth, our "misconfiguration taxonomy," and enumeration/analysis with BloodHound's newly released feature set. We will cover the abuse of AD DACL misconfigurations for the purpose of domain rights elevation, including common misconfigurations encountered in the wild. We will then cover methods to design AD DACL backdoors, including ways to evade current detections, and will conclude with defensive mitigation/detection techniques for everything described."

Finally a talk at the Black Hat Conference focused on weaknesses in Active Directory DACLs !  Kudos, but/and I just have one question - What took you guys so long?!  I mean, are these "experts" just now realizing all this in 2017  i.e. 17 years after Active Directory was shipped!  We have been saying this for years now, and 've already solved this problem over half a decade ago !

The respectable "experts" giving this presentation on Active Directory Security are absolutely right that "Active Directory ACLs are an untapped offensive landscape, often overlooked by attackers and defenders alike, and that while ACL misconfigurations can provide numerous paths that facilitate elevation of domain rights, they also present a unique chance to covertly deploy Active Directory persistence." That said, what these respected experts (may or) may not yet know is that at the root, crux and heart of all this actually lie Active Directory Effective Permissions.

So, to help these experts, newbies, and the entire world, in a few days, on this blog, I'll share just how easily organizations can now find and eliminate each one of these backdoors, leaving NO room to hide, or as they persist. Interestingly, the solution to that too involves (surprise!) Active Directory Effective Permissions.  Speaking of which, I doubt there will be any mention of Active Directory Effective Permissions in the ACE Up the Sleeve presentation, again thanks to 0 guidance from Microsoft!

As for that BloodHound tool, although it has gained much popularity especially amongst pen testers, it is massively inaccurate because it makes the same classic mistake that people have been making for years now i.e. it tries to find out "who has what permissions in Active Directory" when in fact what it should be trying to do is find out "who has what effective permissions in Active Directory."  The fact that it can still find so many holes only shows and proves just how bad the situation is out there!

Technically, comparing Gold Finger to Bloodhound is like comparing a Lamborghini to a prototype of the world's 1st car.

The one other very important thing to note is that while Bloodhound primarily aids attackers in attacking Active Directory, Gold Finger primarily aids organizational IT personnel in defending Active Directory, and in fact today Gold Finger may be the only solution that can help organizations identify and eliminate any backdoors or paths that attackers could find using Bloodhound.


Alright, enough of this. Actually, the Black Hat Conference doesn't deserve much mention here, but since the one presentation on Active Directory is completely focused on Active Directory ACLs, and since so many organizations are tuned-in to Black Hat this week, I figured they ought to know about a matter of paramount importance to the very foundation of their cyber security.


While I'm at it, let me tell you that not a single one of the world's top cyber security companies, including Microsoft, Cisco, IBM, Google, Amazon, EMC, Dell, HP, CA, Centrify, Palo Alto Networks, Blue Coat, FireEye, CyberArk, Beyond Trust, Leiberman Software, Thycotic, Checkpoint Software, Palantir Technologies, Kasperky Labs, Tripwire, DarkTrace, Lockheed Martin, BAE Systems, Tanium, BAH, etc. etc., likely has a clue about this or a solution to help organizations determine Active Directory Effective Permissions (, when in fact likely at their very foundation too lies Active Directory.)  Not a single one of them!





In Summary

I've been sharing my thoughts and perspectives for years now, on the Cyber Security Blog, the Active Directory Security Blog, and recently on the Paramount Defenses Blog. Of all the posts I've penned thus far (, and I've penned well over a 100 by now), this is possibly the most important one yet.

It is so because what I shared today directly impacts the foundational cyber security of thousands of government and business organizations in the world, and AFAIK, nothing is more important than securing and defending the very foundation of security.


It is Paramount (; and thus the name, Paramount Defenses.)


Make no mistake about one fact - no Active Directory deployment can be secured without possessing the ability to determine effective permissions / effective access in Active Directory, and no organization (not matter how big or powerful it may be) whose foundational Active Directory is not secure, can be considered secure from a cyber perspective.

That's all for today, Day 10 of this.

Best wishes,
Sanjay


PS: If you liked this blog post, you may like reading (each one of) these + stuff here, thinking about this, and checking this out. If you only have time to read one of them, I would read this one or this - A Trillion $ Active Directory Privilege Escalation Example.