How to Audit Who Can Change/Control/Delete a Service Connection Point in Active Directory?

Dear Microsoft,

Today is Day-18 of our Active Directory Security School for you. Today, I'll answer the question I had asked you on Day-17, and in doing so, along with you, we will also help thousands of organizations worldwide find out how to correctly audit who can change, control or delete Service Connection Points in their Active Directory deployments.

First, A Quick Recap

If you have yet to read the previous post, which can be found here, you may want to do so to get sufficient context for this post.

In the previous post, we had talked about what a Service Connection Point is, and how numerous Active Directory-integrated applications, both those developed in-house as well as 3rd-party applications, use and rely on them to deliver their functionality.

A Service Connection Point in Active Directory

In short, we had seen how various mission-critical applications that provide everything from email to two-factor authentication and from Linux/UNIX integration with Active Directory to auditing and privileged user account management, use and rely on Service Connection Points in Active Directory for their proper functioning. (A list of a few such apps is provided below.)


We had also covered the impact of someone being able to make an unauthorized modification to one or more attributes of the Service Connection Points of these mission-critical cyber security enabling Active Directory integrated-applications.

An Intruder Changing the Keywords Attribute on a Service Connection Point in Active Directory

To be precise, we had concluded that in the event that an intruder or a malicious insider could do so, he/she could potentially disrupt these applications from delivering their functionality, the impact of which could range from an instant denial-of-service attack on these critical Active Directory-integrated applications to leaving millions of IT resources vulnerable to compromise.




Next, A Few Such Apps

To appreciate the real-world security implications of an unauthorized change made to the Service Connection Points of such applications, perhaps it may help to identify even just a few prominent such 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 likely agree, many of these applications play a vital role in ensuring cyber security at many organizations worldwide.

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.

The Question

In light of the above, I had posed the following few most simple and elemental questions, and asked you how organizations worldwide could answer these questions  -

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.

Finally, The Answer

It is imperative that every organization that has any application that relies on the use of Service Connection Points in Active Directory know the exact answers to these questions at all times, and now let me show you how to correctly answer them.


First, lets rule out the incorrect answer, which is how most organizations worldwide may be trying to answer these questions today, and that incorrect answer is - "Find out who has what permissions on a Service Connection Point in Active Directory."

acldiag

Even though this is the incorrect answer, most organizations may not know this, so they continue to use tools like dsacls, acldiag, PowerShell scripts etc. or any one of numerous 3rd-party Active Directory Permissions Audit Tools to do so.


Now, the correct answer, which is how every organization worldwide should be attempting to answer these questions today, and that correct answer is - "Find out who has what effective permissions on a Service Connection Point in Active Directory."

The Effective Permissions Tab is Inaccurate

As we can all see above, effective permissions are so important that Microsoft's native tooling has an entire tab for them!

Now, before you assume that the Effective Permissions Tab is sufficient/adequate to answer these questions and stop reading this further, let me share with the three (3) reasons as to why it is substantially inadequate and thus almost useless -

1. First and foremost, it is not 100% accurate because it does not take all the factors that influence the accurate determination of effective permissions in Active Directory into account.


2. Secondly, it can at best determine (an approximation of, and thus inaccurate) effective permissions one user at a time. So if you have 10,000 users in your organization, you will have to manually enter each user's name individually i.e. one by one, one at a time; now I don't know about you, but if I had to do this, I would probably find another job. 


3. Finally, even though it can at best determine (an approximation of, and thus inaccurate) effective permissions one user at a time, it (also) CANNOT show you exactly which permission in the object's ACL is granting a specific effective permission, so if you're trying to find out HOW a user has a specific effective permission, you can't do so using this tool.  

Unfortunately, the same is true of dsacls, acldiag, LDP, PowerShell scripts and virtually every other 3rd-party Active Directory ACL/Permissions Analysis/Audit Tool out there, so there's really no easy way to answer these simple questions. Oh, and this free tool is so dangerously inaccurate that if it were an X-ray machine at an airport, I'd advise you to stay away from the airport.

Before we continue further, let me say this again. I cannot stress this enough - if you don't know what effective permissions in Active Directory are and why they're paramount to your security, you'll want to read this - Active Directory Effective Permissions.



So, now that we know that theoretically the correct answer is - "Find out who has what effective permissions on a Service Connection Point in Active Directory", is there an easy way to determine effective permissions on Active Directory objects?

Yes, (thankfully) there is one way...



Here's how so many of the world's top business and government organizations easily and accurately answer these questions -

The Gold Finger Active Directory Effective Permissions Audit Tool

The snapshot above is of the Gold Finger Active Directory Effective Permissions Audit Tool.

This tool quite simply is the world's only accurate and adequate effective permissions calculator for Active Directory.

Not only can this tool accurately determine effective permissions on any object in Active Directory, to use this tool, all you have to do is point the tool at whatever object you want to determine effective permissions on, and then click ONE button. That's it!

As seen in the snapshot above, we used this tool to perform an effective permissions audit on a service connection point called RMS Service in Active Directory, and the audit results show us every single security permission-combination that is effectively allowed on this service connection point object, as well as exactly who each effective permission is granted to, and how so.

So, for example, to find out who can change a Service Connection Point's keywords, all you have to do is use the What drop-down to select Write-Property - Keywords effective permissions and the tool will display the complete list of all individuals who can do so. Similarly you can find out exactly who can change each attribute/property, as well as its ownership and permissions.


Now, wouldn't it be nice if someone could make it even simpler such that all these technical details (i.e. effective permissions, attributes, mappings etc.) could be abstracted enough that we could just find all this out in English. Well, guess what? Done! -

The Gold Finger Active Directory Effective Access Audit Tool

The snapshot above is of the Gold Finger Active Directory Effective Access Audit Tool, which is the world's only tool that can accurately and adequately determine effective access in Active Directory environments.

As seen in the snapshot above, we used this tool to perform an effective access audit on a service connection point called RMS Service in Active Directory, and the audit results show us every single administrative task that can be enacted on this object by virtue of the effective permissions allowed on this service connection point object, as well as exactly who can enact each one of these administrative tasks, and of course, how so. In other words, you can now find out exactly who can do what, in English!

(Finally, if you have numerous Service Connection Points in Active Directory, this tool can audit all of them at a button's touch.)

In this manner, every organization worldwide that needs to know exactly who can change, control or delete Service Connection Points in their Active Directory can now accurately and instantly find out so 365-24-7, in seconds, and at the touch of a button.


So, Microsoft, you see, today this is how organizations worldwide can answer these simple yet vital cyber security questions.

In contrast, let alone providing your customers i.e. organizations worldwide, a solution, in 17 years, you haven't even told them that what they actually need to do is not to audit "who has what permissions" but to audit "who has what effective permissions"!

Need one say more?

Best,
Sanjay


PS: It took half a decade of laser-focused execution to make something this difficult, this easy for the world. You're welcome.

How to Correctly Audit Who can Create User Accounts in Active Directory

Folks,

Earlier this week, I had posed a most simple question to the respectable $ 550 Billion Microsoft Corporation regarding possibly the most elemental and fundamental aspect of cyber security and identity management, and that question was -

Exactly how do/should organizations find out exactly who can create domain user accounts in their Active Directory? (and ideally also, where they can do so & how)

Now, of course, Microsoft's likely not going to respond (for obvious reasons), and because this is so important to organizational cyber security, I'll provide the answer today. Ideally Microsoft should have educated organizations about this 10 years ago!

I'll not only answer the question, I'll show you how to easily answer this question.




First, A Scenario to Visualize

To help visualize this problem, let us begin by considering a single Active Directory domain of a fictional organization. As is the case with most organizations, and as displayed above, this fictional organization has a fairly elaborate organizational unit (OU) tree hierarchy/structure, the design of which was dictated by a combination of their group policy and permissions inheritance requirements. In essence, assume that it is more than 6 levels deep, and includes 60+ organizational units (OUs).






Next, Just Enough Technical Background

Like everything else in Active Directory, even (domain) user accounts are objects, and thus the administrative task of creating a user account in Active Directory corresponds to an LDAP operation targeted at the parent object and involving the creation of an object of class User, and this LDAP operation is gated by a specific Active Directory security permission: Create Child - User.

In practice, the presence of either one of the following permission combinations on a candidate parent object in Active Directory would influence a user's ability to create user objects in Active Directory, the premise being that Create All Child Objects obviously includes Create Child - User and similarly that Full Control obviously includes Create All Child Objects -

1. Create Child - User

2. Create All Child Objects

3. Full Control

Oh, and speaking of candidate parent objects in Active Directory, while most people likely just assume that you can create user objects under organizational units, strictly and technically speaking, it is the Active Directory Schema that defines and governs (via an attribute in Schema Class definitions) the specific types of objects that may be created under specific types of objects.






Oh, and Debunking a Myth - Finding out Who has What Permissions in Active Directory is NOT the Answer

Most IT personnel and vendors in the Active Directory space are familiar with the above technical background, and if you ask them this simple question "How to find out who can create domain user accounts in Active Directory?", you'll likely get one of the 2 most common answers, depending on whom you ask -

1. If you ask the vendors, their answer will likely be - "Sure, this is simple. All you have to do is perform a permissions audit in your Active Directory to find out who has the above specified permissions in your Active Directory, and that's it, you're done! Oh, and our amazing "Active Directory Permissions Audit Tools" can help you get the job done in no time!"


2. If you ask most IT personnel, their answer will likely be - "Sure, this is simple. All we need to do is perform an Active Directory permissions audit to find out who has the above specified permissions in our Active Directory, and that's it, we're done! Oh, and tools like PowerShell Get-Acl, AclScanner, dsacls, acldiag, Bloodhound, etc. let us do this easily!" 

Guess what?! Unfortunately, both these answers are wrong.

In fact, they're not just wrong, they're dangerously wrong. Simply finding out "Who has what permissions in Active Directory" aka performing an "Active Directory permissions Audit", is not the answer and it is NOT going to give you accurate results, and the last time I checked, when it comes to cyber security, accuracy is paramount. Of course, if you don't care about accuracy, ... .

By the way, if you want to know why these answers are so wrong, you will absolutely want to read this.

To accurately answer this and all such questions related to "Who can do what in Active Directory", what organizations need to do is find out "Who has what effective permissions in Active Directory," / "Who has what effective access in Active Directory."





Active Directory Effective Permissions

One of the most important measures organizations worldwide can take today is understand the one paramount aspect of cyber security that impacts the security of just about everything in their IT infrastructures - Active Directory Effective Permissions.

I am not going to explain what Active Directory Effective Permissions are in this post, as I have already explained it thoroughly in that post pointed to by the link above, but you will definitely want to read that before proceeding any further in this blog post.

In order to find out who can create domain user accounts under a specific Active Directory object, such as an Organizational Unit (OU), all that we need to do is find out "who has sufficient effective Create Child - User permissions" granted on that OU.





Now, The Answer to This Trillion Dollar Question

With the above background and concepts in mind, we are now in a position to answer this simple cyber security question.

Theoretically, here is what it takes to answer this question -

1. The first step is to identify all objects in Active Directory under which the Schema permits the creation of objects of class User. This step is needed because as noted above, we need to determine "who has what effective permissions" on all objects under which objects of class User can be created, so in order to be able to do so, we will first need to identify each one of these objects. It is these objects on which we will need to determine effective permissions.


2. The next step would be to accurately determine effective permissions on each one of the Active Directory objects identified in step 1 above, to identify all users who have sufficient effective Create Child - User permissions on them.


3. The final step, which is the simplest one, merely involves aggregating the individual results of step 2, as performed on each one of the objects identified in step 1, to ultimately arrive at the complete list of all individuals who can create domain user accounts in an Active Directory domain.  

So you see, there is a WORLD of a difference between what the world thinks the answer is, and what the answer actually is!

Keep reading...




A Herculean Challenge

Now, while the answer to this simple question seems simple, in reality, it represents a herculean challenge for the world today.

Here's why -

1. To begin with, the actual technical process involved in accurately determining effective permissions in Active Directory is very complicated, expertise-reliant, time-consuming and error-prone. In fact, even just the expertise required to know how to correctly do this alone is extremely rare, and hardly anyone in the world could engage in this process repeatedly without making mistakes, and unfortunately, in cyber security, there is no room for mistakes. Thus, even if organizations were to attempt to try and do this manually, most organizations likely won't even have the expertise to do this correctly.


2. Secondly, the capability (i.e. tooling) required to be able to accurately determine effective permissions in Active Directory is virtually non-existent (barring one tool.) In fact, not a single vendor in the Active Directory space or any cyber security company (barring one) in the world has ever built a tool that could accurately determine effective permissions in Active Directory. The only tooling available in the world is Microsoft's Effective Permissions Tab, which unfortunately is not only inaccurate, it is substantially inadequate, and here's why. Oh, and this little excuse of a tool is dangerously inaccurate.


3. Finally, there could easily be hundreds if not thousands of objects in an organization's Active Directory domain under which the Schema permits the creation of objects of class User. Consequently, at many organizations, to answer this question, they would have to accurately determine effective permissions on hundreds, if not (on) thousands of objects, and to do that manually could take months, if not years, let alone the fact that the data would be obsolete within days anyway, considering that the state of permissions in Active Directory do change every so often.

In light of the above, how are organizations supposed to be able to answer what is such an elemental cyber security question?!

Where is Microsoft ?

In light of the above, if you agree that this is an important question for organizations to be able to answer today (and if not, I could share with you many more such questions, all of which involve a similar process to answer), then in light of everything I have shared above, is it not worth asking how, if in any way, Microsoft may be helping organizations answer this question?

Unfortunately, let alone helping organizations answer this question, for more than a decade now, Microsoft has not even shed light on what it takes to answer this question. Most recently, and in all likelihood, in response to this, when it finally provided some guidance on the subject, again it completely missed out on educating the world on how to correctly answer this question!

That's how much Microsoft seems to care about cyber security. Yet, it would love for the world to embrace its Cloud offering!






What is the World To Do?

I'm told last year almost $ 80 Billion was spent worldwide on Cyber Security. As you all know, over 85% of all organizations worldwide are operating on Active Directory, and yet, not a single one of these organizations likely has an accurate answer for such a simple, elemental and fundamental cyber security question!

What is the world supposed to do? How are thousands of organizations worldwide supposed to be able to answer this most basic, elemental and fundamental of all cyber security questions, and what's the point when, even after spending millions of dollars on cyber security, an organization can't even accurately answer "Who can create user accounts in Active Directory?"

A while back, we had a prominent 3-letter acronym government agency reach out to us. They had well over 10,000 OUs in their Active Directory domain, and (perhaps because someone had been able to create and misuse a domain user account,) they wanted to know if we could help them identify exactly who can create domain user accounts in their Active Directory.






We are Paramount Defenses

Please allow me to show you how thousands of organizations worldwide can instantly and accurately find out exactly who can create domain user accounts in their Active Directory, where, and how, at the touch of ONE button -

Gold Finger Administrative Access And Delegation Audit Tool

The Administrative/Privileged Access and Delegation Audit Tool, a part of our Gold Finger Active Directory Audit Tool Suite can instantly and accurately determine effective permissions/access across an entire Active Directory domain, whether it has a 100 objects or a 100,000+ objects, and reveal in plain English exactly who can create domain user accounts in Active Directory.

In fact, not only can it audit (identify and reveal) exactly who create domain user accounts in Active Directory, it can accurately and automatically audit exactly who can enact over 100 administrative tasks in an Active Directory domain, no matter its size.

With Gold Finger, here's what it takes to answer this simple, elemental and fundamental cyber security question -

1. Launch Gold Finger
2. Select Report #1 - "Who can create Domain User Accounts"
3. Set the Scope to be the entire domain. (By default, it is already pre-set for you.)
4. Press the Gold Finger button. 

That's it!

Within minutes, Gold Finger will automatically identify all such objects under which domain user account creations are permitted (by your unique Schema), then perform the herculean task of accurately determining effective permissions/access on each one of them, whether it be on 10 OUs or on 10,000+ OUs and containers, to correctly figure out and reveal the identities of everyone who can actually create domain user accounts in your Active Directory, as well as where (i.e. under which OUs) they can do so, and how they can do so (i.e. which permissions in the underlying ACLs entitle them to do.)   [Sample output - CSV, PDF.]

(The BIG advantage of knowing the HOW is that if there are users who can create domain user accounts but who should NOT ideally be authorized to do so, organizations can at once tweak the appropriate permissions/groups to revoke their access.)

So you see, all that IT admins need to do is click a button and sip their favorite beverage while it almost magically does it ALL.

A Note To My Friends at Microsoft: Gentlemen, I want you to think about this for a moment - imagine being able to automatically and accurately determine effective permissions on hundreds of thousands of objects in Active Directory in a single shot, and not just that, also figure out what administrative tasks they end up entitling and then present the results in terms of administrative tasks, so that IT personnel worldwide can easily comprehend them and act upon them. Imagine that!

In light of this, travel as far as needed, from Silicon Valley (the hot-bed of venture capital funded companies) to Israel (the hot-bed of cyber security companies these days) and across the whole world, and if you can find me even ONE company that can do anything even remotely close to this, let me know.

This tool is our flagship tool. It embodies our unique, patented effective-access assessment technology, and is the culmination of over half a decade of innovative, focused and disciplined research and development. Simply put, it is simultaneously both, the Rolls Royce and the Lamborghini of Active Directory Audit Tools.




Summary

Microsoft Active Directory is the very foundation of cyber security at over 85% of all organizations worldwide today. At these organizations, the need to know exactly who can do what, where and how, in Active Directory domains is paramount to cyber security, because the entirety of all building blocks of cyber security, from domain user accounts to domain computer accounts and from domain security groups to group policies are all stored, managed and protected in Active Directory.

There is only one correct way to find out who can actually do what in Active Directory, and that involves accurately determining effective permissions in Active Directory. In other words, it is not "who has what permissions in Active Directory" that matters, but in fact "who has what effective permissions in Active Directory that matters."

Unfortunately, the process involved in accurately determining effective permissions in Active Directory is extremely complicated.

Yet, to be able to answer so many vital cyber security questions, such as "Who can create domain user accounts in Active Directory", not only do organizations absolutely need to be able to determine effective permissions in Active Directory, but in fact, depending on the size of their Active Directory domains, may also need to determine effective permissions on possibly hundreds if not thousands of Active Directory objects, and do so often since Active Directory permissions do often change.

Sadly, Microsoft does not seem to have done much to help the world in this vital regard. In fact, they apparently even forgot to educate the thousands of organizations that operate on Active Directory regarding the importance of Active Directory effective permissions. Further, while there are almost a thousand cyber security companies in the world today, not a single one of them has a solution that can help organizations accurately find out the answer to even such basic and elemental cyber security questions as "Who can create domain user accounts in Active Directory?"

Fortunately, organizations worldwide that DO care about knowing the answer to not just this vital question, but also many other similar, equally important questions that impact their foundational cyber security, now do have an option and can now do so.


That'll do it for today, Day-12.

Best wishes,
Sanjay


PS: To anyone who wishes to see just how inaccurate virtually all Active Directory permissions audit tools out there including PowerShell Get-Acl, AclScanner, dsacls, acldiag, Bloodhound, etc.. are, all you need to do is compare its results to those of Gold Finger. The simple fact is that none of those tools can accurately determine effective permissions, which is all that matters.

PS2: In case you're wondering why this was a Trillion $ question, please read this.

Lack of Gravitas at Organizations + Risks of Amateur Tooling (Day 7)

Folks,

If you review what I've shared thus far on Active Directory Security, you may likely see why I believe that Microsoft may have completely missed out, for over a decade, on educating the world about what clearly is such a vital aspect of cyber security.

However, in Microsoft's slight defense, I'd also like to add that organizations and amateur vendors are partly responsible too.



In Ever So Slight Defense of Microsoft

First and foremost, I would like everyone to know that I love and care deeply for Microsoft, (and have many friends at Microsoft,) which is the only reason that I am spending so much effort on helping Microsoft and the world understand all this important stuff.

As I indicated on Day-0, the sole objective of conducting this school for Microsoft is because they completely missed out on educating their customers about the importance of "Effective Permissions" to Active Directory security for an entire decade.

In support, I provided irrefutable proof: Top-3 official/primary sources of guidance from Microsoft on Active Directory security -

1. Microsoft's original 100+ page official Best Practice Guide for Securing Active Directory (Part I) and Part II

2. Microsoft's latest official Best Practices for Securing Active Directory guidance, introduced by Microsoft's CISO

3. Microsoft's latest 5+ hour series of 12+ videos on Defending Active Directory Against Cyber Attacks

As of Jan 26, 2017 (and likely even today), if you did even a simple keyword search for the term "effective permissions" across these 3 official authoritative sources of guidance from Microsoft, you'll find 0 instances of the term "effective permissions."

Zero!      нуль, nul, صفر , 零,Null, μηδέν, ʻole, אֶפֶס , शून्य, ゼロ,제로, nihil, sero !

In all likelihood, if you were to additionally review 10+ years worth of Microsoft TechEd presentations, i.e. a 1000+ of them, presented by Microsoft and other industry experts, again you may likely find virtually zero mention of "effective permissions."

In light of these facts, as hard as I try, it is very difficult for me to defend Microsoft's complete ignorance on the subject.


That said, if I had to try, I would probably have said the following -

If I were still at Microsoft, in its defense I would probably have said - "generally speaking, at Microsoft our primary charter is to make BIG, lasting changes, such as embracing the Cloud, and of course helping safeguard our customers from serious risks to their security (e.g. combating credential-theft attacks.) It does appear though that, for whatever reason, one such serious risk (illustrated here) may not have been on our radar all this while, and we will begin by looking into how and why we may have systemically and completely forgotten to educate our customers about it, for an entire decade.

(Most of my friends at Microsoft would agree that at the very least Microsoft should have adequately educated its customers.)

After all, for Microsoft to have completely missed providing any guidance on such a vital security topic for more than a decade, more than a few folks would've had to have missed this / not gotten it (at all) - several folks on the Product Development Team, Security Business Unit, Microsoft Research, Trustworthy Computing Group, MCS, PSS, MS IT and others, but we'll let it go and focus on helping them get it.

Moving on to...




Lack of Gravitas at Organizations

Microsoft may not be entirely responsible for a global lack of understanding on such a fundamental aspect of cyber security.

Over the last decade, at Paramount Defenses, we've had an opportunity to learn a lot about several thousand organizations, all of whom knocked at our doors unsolicited, and if there is one commonality we've found, it is that most organizations seem to lack gravitas and the depth of knowledge required to adequately protect their foundational Active Directory deployments.

IT Personnel at Organizations

We could share stories many almost unbelievable stories with you, and we're talking about so many of the biggest organizations in the world, but we will never do that because we're professionals. I will just leave it at saying that at the end of the day, based on what we have seen thus far, there are 3 aspects that organizations seem to lack (to varying degrees) -

1. First and foremost, the understanding that if their Active Directory is compromised, the very foundation of their cyber security is compromised and thus that the very fabric of trust across their network would have been pierced.


2. Secondly and as a consequence, (the fact that) adequate protection of foundational Active Directory deployments may not even be on their radar, let alone it being one of the top (and adequately funded) cyber security priorities today.


3. Lastly, at many organizations, IT groups/departments seem to lack the depth of knowledge as well as the expertise required to adequately protect their foundational Active Directory deployments.

Given that Microsoft's documentation at least unequivocally states the value and importance of adequately protecting Active Directory, in light of the above 3 points, it appears that perhaps organizations may likely also be partly responsible -

Quoting Bret Arsenault, Microsoft’s CISO from the Foreward of Microsoft's official whitepaper on Active Directory Security – “Active Directory plays a critical role in the IT infrastructure, and ensures the harmony and security of different network resources in a global, interconnected environment.”

How much clearer could Microsoft have been than the CISO of Microsoft Corporation stating the above?

Sadly, the reality on the ground today is that so many organizations worldwide do not yet seem to be taking the security of their foundational Active Directory deployments as seriously as they should, and thus may not even know what the attack surface is, what the top Active Directory security risks are, what the easiest avenues to compromise may be, how colossal the impact of an Active Directory security breach could be, what risk mitigation measures they should be enacting to protect Active Directory etc.

Here's super simple evidence - Each week we get to speak to Domain Admin equivalent IT personnel from many organizations across the world, and in many cases, they just do not seem to know what effective permissions in Active Directory are.

I must ask this with complete respect - "Realistically speaking, if Domain Admins at such prominent business and government organizations do not even seem to what effective permissions are, how can these organizations protect their foundational Active Directory deployments?" (No, we're not talking about Mom and Pop Stores, we are talking about multi-billion $ organizations.)





Lastly, Risks of Amateur Tooling (From Amateur Vendors)

The one other thing I will add is that the presence of amateur vendors in the Active Directory security space worries us, because they may be worsening the situation. I say that because not only may their solutions actually be exposing organizations to far greater security risks, their misleading marketing may be giving customers a false sense of security, and that's dangerous.

Sales Associate at Amateur Vendor

Allow me to explain. We know of several vendors in the Active Directory Security space that offer very basic Active Directory reporting/management solutions. If you look into whose behind them, you'll find that many of them are built by puny companies in developing countries by mostly amateur developers, which makes you wonder how reliable and secure their solutions might be. Some of them are outright inaccurate and many of them are not even digitally signed, and they are being sold to and being used by Domain Admin equivalent IT personnel at multi-billion dollar business and government organizations across the world.

Further, more concerning is that fact that many of them are required to be run either as System on Domain Controllers or in highly elevated security contexts such as Domain Admin! Specifically, many of them require organizations to add the service account being used by that solution to the membership of the Domain Admins group.

Code

That, in our professional opinion, is a serious risk, because in essence you have potentially untrustworthy code that isn't even digitally signed, written by amateur developers, with its codebase residing who knows where, running as System on DCs or as Domain Admin at thousands of prominent business and government organizations in the United States, Europe and far beyond!

Think about it. If a nefarious entity or an APT were to be able to compromise even one of these vendors and acquire the ability to tamper with their code-base, it could very quickly completely compromise hundreds, if not thousands of organizations!

This also raises the question as to who at these organizations is authorizing the deployment of a solution to be run as System on DCs or as an Domain/Enterprise Admin, when it is not even digitally signed, i.e. that's trustworthiness evaluation 101.


Finally, there is the part about misleading marketing giving customers a false sense of security, elaborated below.

There are several vendors that offer very basic Active Directory Permissions Audit solutions (i.e. basically well-presented Active Directory ACL dumps) that are substantially inadequate if what you're trying to do is audit privileged access in Active Directory.

Yet, their marketing verbiage (both on-site and in advertisements displayed on Google, Bing etc.) misleads organizations into believing that their products are sufficiently capable of getting the job done, and because these customers don't know better (because Microsoft has never talked about Effective Permissions), they end up acquiring these solution to perform basic Active Directory permissions audits, which obviously provide them with a substantially misleading picture, as a result of which they end up making highly sensitive access-control decisions based on inaccurate data, and in doing so, from that point on, they end up operating on a false sense of security.

Should you like to see what I'm talking about for yourself, simply click here, or Google Active Directory Permissions Audit.

In contrast, technically speaking there is only one correct way to audit privileged access in Active Directory - this.

In fact, one of these solutions is so inaccurate that (to paint you a picture) if it were a security scanner being used at an airport, let alone boarding the flight, we would get out of the airport immediately. The shocking part is that not only does its vendor not know that its not accurate, they've actually spent some marketing dollars to get coverage in a few publications, and of course the publications ran with it, so now you have a vendor that has an inaccurate solution that is also vouched for by small-time publications, and how many IT personnel do you think actually have the expertise to evaluate its accuracy? They'll just see the endorsement from a publication, give it a second's thought, and run with it, and in doing so will have jeopardized their security.

In short, the availability of misleading and potentially low-assurance solutions from many puny vendors does not help security.




Wrapping It Up

Alright, I've said enough today. The point is that Microsoft alone may not be entirely to call out for the fact that 99% of the world has no clue that there's likely a security hole the size of the Pacific Ocean in their foundational Active Directory deployments.

Organizations too likely bear some responsibility for being deep in the dark, especially given that so many of them have been operating on Active Directory for years. Lastly, vendors with misleading marketing and products don't help the situation either.

Next post onwards, we'll get objective and technical and dive into some serious Active Directory security internals.

Best,
Sanjay


PS: The objective of this is to help Microsoft get the importance of effective permissions/access to Active Directory security, so that they in turn can help their global customer base understand the sheer vitality of this essential cyber security capability.