With our most recent SentinelOne release we have completely revamped our Active Directory (AD) Integration. This is one of the many compelling enhancements to this monumental release. This post will primarily focus on AD Integration with cloud based Sentinelone management, but some of the concepts can also apply to on-premise SentinelOne management deployments.
Over the years I have dealt with many SaaS/Cloud based solutions across multiple vendors. One thing that always seems tricky is how to securely and easily publish the AD environment to the cloud. In my humble opinion, I feel that most vendors get it wrong. Below details the two most common approaches that I have seen.
Approach #1 – LDAP/S query from the Cloud
This is most common approach that I have come across, likely because of its simplicity. Basically, solutions that utilize this approach recommend that their customers allow a LDAP/S query from their data center/s to the customer’s AD. Although this is a very straightforward configuration, the problem is that the customer must open a hole in their firewall to talk to their AD environment. In other words, they allow outside access to talk internally to their AD. Yikes! Allowing outside access to talk to one of your most sensitive & critical IT infrastructure components is a security risk most customers do not want to accept (even if it is restricted by IP). And to be frank, neither would I.
Approach #2 – Internal Software that pushes AD details to the Cloud
Although not nearly as common as Approach #1, some vendors provide software that is installed internally within the environment. This software then will query the AD infrastructure and push those details to the cloud. Although much more secure than Approach #1, the downside is that this requires another component, typically a dedicated server, that needs to be managed just to receive AD integration. With today’s problem of not having enough IT resources, who wants to manage yet another server or application? So again, in my opinion, not a desirable option.
AD Integration Done Right!
So how did SentinelOne get AD integration right? By installing our agent locally at the endpoint, we are able to avoid both of the approaches mentioned above. Installation within the kernel of the operating system gives us deep visibility into the endpoint, such as AD membership for that endpoint. With this new integration, we simply query the local endpoint for its AD membership and send those details to the cloud over SSL. These details include both computer and user group membership/attributes, which are critical for VDI environments.
This is more secure than Approach #1, as there is no need to open a hole within the perimeter/firewall. And much simpler than Approach #2, as the customer doesn’t need to deploy any additional software to receive AD integration. In our opinion, this is how AD integrations should be done and this is just one of the many exciting enhancements to our Central Park release.
The image below provides a sample of the details of an endpoint and its AD integration.
In our next post, we will show you how to use this information to dynamically filter/group systems by the Distinguished Name or Group Membership of the device or the user.
