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.