Loading...

Elasticsearch and Active Directory

Used:   ldapsearch v2.4.44  elasticsearch v7.11.0  gpresult v2.0 

In my professional career I have integrated over 10 times already Active Directory as authentication backend into Elasticsearch.

Sadly most companies use Active Directory over the OpenLDAP alternative.

I always end up looking up or googling the same stuff 🙈, cause you tend to do it not very often and it takes you only half a day to get everthing running.

Since my last client and my current architecture review I found my old notes and there are still valid to this point.

Security infrastructure tends not to change that often as development :joy:.

To use Active Directory authentication with Elasticsearch requires a Elatic subscription or a trial run.

AD Integration

To integrate with Active Directory, you configure an active_directory realm and map Active Directory users and groups to roles in the role mapping file.

Realm Definition

In the Elasticsearch configuration (elasticsearch.yml), add your active directory realm to the existing realms.

xpack:  
  security:
    authc:
      realms:
        file.file1:
          order: 0
        native.native1:
          order: 1
        active_directory.ad1:
          order: 2
          domain_name: ldap.dom # your ldap hostname - fqdn preferred
          url: ldaps://ldap.dom:636
          unmapped_groups_as_roles: false
          group_search.base_dn: "DC=security,DC=logservice"
          files.role_mapping: ${ES_PATH_CONF}/x-pack/role_mapping.yml
          ssl.certificate_authorities: certs/ad-server.pem

I recommend to keep existing realms, so you have a fallback system in place, when your ldap server or active directory is unavailble.

It might be unlikely, but so far I have experienced 6 outages or service degradations of major backends.

Especially if you need logging and monitoring data and can not access it :wink:, it makes your Elastisearch usage very useful. 🙈 :joy:

If you comment and uncomment the realms out in case of emergency, you have to restart your whole cluster.

Do yourself a favor and don’t rely solely on one authentication backend.

Role Mapping

Before you start, you should have at least some role concept in place. Role concepts are agnostic. Agnostic, in an information technology (IT) context, refers to something that is generalized so that it is interoperable among various systems.

This example has following roles

  • guest = read-only users for exploring uncritical data
  • devops = development and operations role
  • admin = superuser role for Platfrom and Service Reliability Engineers

You can map Elasticsearch roles to LDAP users or groups with the respective bind distinguished name (dn).

Example:

## Role Mapping

# Role mapping configuration file which has elasticsearch roles as keys
# that map to one or more user or group distinguished names
#roleA:   this is an elasticsearch role
#  - groupA-DN  this is a group distinguished name
#  - groupB-DN
#  - user1-DN   this is the full user distinguished name
admin:
  - "CN=Nguyen Vinh (cinhtau),OU=Users,OU=ApplicationEngineering,OU=analytics,DC=it,DC=swiss"
devops:
  - "CN=kibana-user,OU=Kibana,OU=Security,OU=Control Groups,DC=it,DC=swiss"
guest:
  - "CN=kibana-readonly,OU=Kibana,OU=Security,OU=Control Groups,DC=it,DC=swiss"

Retrieve AD DNs

In the beginning of a project or work, you have to identify groups and user bind dn for Windows users.

Use gpresult to display the Resultant Set of Policy (RSoP) information for a remote user and computer.

Write output to ldap.txt file.

C:\Users\cinhtau>gpresult /V > ldap.txt

The file ldap.txt should contain the unique CN (Common Name) for each user, that you can use for the role mapping for the user.

If you want to use a group dn to map to a role, find a common group of your target group. Select a group representative and do above command. You will find below all the group memberships for the user. Select one group and retrieve the group dn with an ldap query tool.

Truncated example output:

Microsoft (R) Windows (R) Operating System Group Policy Result tool v2.0
¸ 2019 Microsoft Corporation. All rights reserved.

Created on ?11.?05.?2022 at 15:36:06

RSOP data for DESK\cinhtau on HP-SCHROTT : Logging Mode
----------------------------------------------------------

OS Configuration:            Member Workstation
OS Version:                  10.0.18363
Site Name:                   N/A
Roaming Profile:             N/A
Local Profile:               C:\Users\cinhtau
Connected over a slow link?: No


USER SETTINGS
--------------
    CN=NGUYEN Vinh (cinhtau),OU=...,OU=Users,OU=...,DC=...,DC=cinhtau,DC=net
    Last time Group Policy was applied: 11.05.2022 at 14:43:53
    Group Policy was applied from:      server.ad.cinhtau.net
    Group Policy slow link threshold:   500 kbps
    Domain Name:                        DESK
    Domain Type:                        Windows 2008 or later
    
    Applied Group Policy Objects
    -----------------------------
        ...
    The following GPOs were not applied because they were filtered out
    -------------------------------------------------------------------
        ...
    The user is a part of the following security groups
    ---------------------------------------------------
        Domain Users
        ...                
    The user has the following security privileges
    ----------------------------------------------
    Resultant Set Of Policies for User
    -----------------------------------
        Software Installations
        ----------------------
        Logon Scripts
        -------------
        Logoff Scripts
        --------------
        Public Key Policies
        -------------------
        Administrative Templates
        ------------------------
        Folder Redirection
        ------------------                                   
        Internet Explorer Browser User Interface
        ----------------------------------------
        Internet Explorer Connection
        ----------------------------
        Internet Explorer URLs
        ----------------------
        Internet Explorer Security
        --------------------------
        Internet Explorer Programs
        --------------------------

Test AD Integration

Once properly configured, you can test with the Elasticsearch Security API, the role resolvement.

GET /_security/_authenticate
# alternative as curl command
# curl -XGET "https://elasticsearch:9200/_security/_authenticate" -u cinhtau:mypasswd

Elasticsearch returns:

{
  "username" : "cinhtau",
  "roles" : [
    "devops",
    "reporting_user",
    "superuser"
  ],
  "full_name" : null,
  "email" : null,
  "metadata" : {
    "ldap_dn" : "CN=Nguyen Vinh (cinhtau),OU=Users,OU=ApplicationEngineering,OU=analytics,DC=it,DC=swiss",
    "ldap_groups" : [
      // many fancy groups here
    ]
  },
  "enabled" : true,
  "authentication_realm" : {
    "name" : "ad1",
    "type" : "active_directory"
  },
  "lookup_realm" : {
    "name" : "ad1",
    "type" : "active_directory"
  },
  "authentication_type" : "realm"
}

Check in the roles array, if the role was properly mapped to your role_mapping.yml.

Summary

Integrating Elasticsearch with Active Directory is straight forward.

Retrieving the bind dn can be time intensive, since most engineers don’t deal with Active Directory on a daily basis.

Everything of course is not needed, if you happen to have the AD expert at hand, which in most project setups, is rarely the case :rofl:.

Links

Please remember the terms for blog comments.