Using the LDAP Protocol with Neo4j Enterprise Edition [Security Series, Part 3]


Neo4j 3.1 supports the LDAP protocol, so you can integrate Neo4j with Active Directory, OpenLDAP or other LDAP-compatible authentication services.

Unlike with native users, management of federated users is performed through the external LDAP service. The only aspect of user and role administration still performed in Neo4j is mapping LDAP groups to Neo4j-defined roles.

In this series on database security and access control, we’ll explore all of the different facets and features available in Neo4j Enterprise Edition to keep your data secure. In past weeks, we’ve looked at role-based access control in Neo4j and administering native user security and authorization.

This week, we’ll take a closer look at connecting Neo4j Enterprise Edition to the LDAP protocol.

Administering Federated Users via the LDAP Protocol Connector


Before starting, you should have LDAP service up and running. Let’s verify that with the ldapsearch command:

 
ldapsearch -x -h myactivedirectory.example.com -p 389 -b dc=example,dc=com
-D “cn=admin,cn=Users,dc=example,dc=org” -w admin

All LDAP connector settings must be defined at server startup time. The example below shows a typical LDAP section in the neo4j.conf configuration file:

Learn more about the LDAP protocol connector for federated users with Neo4j Enterprise Edition


To illustrate the ease of integrating with an LDAP directory service, let’s start from the top. First, you need to choose the LDAP protocol connector as the authentication and authorization provider.

dbms.security.auth_provider=ldap

Then, you define the endpoint for LDAP service in our network.

dbms.security.ldap.host=ldap://myactivedirectory.example.com:389

Alternatively, to configure encrypted LDAPS, use one of the following. Not specifying the port will will lead to using LDAPS over the default port 636.

dbms.security.ldap.host=ldaps://myactivedirectory.example.com:636
dbms.security.ldap.host=ldaps://myactivedirectory.example.com

If defined LDAP users are not allowed to search directory information for themselves, you can specify credentials for a special LDAP system account with read access to all users and groups:

dbms.security.ldap.authorization.use_system_account=true
dbms.security.ldap.system_username=cn=admin,dc=example,dc=org
dbms.security.ldap.system_password=admin

Most importantly, you need to provide details on your user graph structure (this is a graph as well!). These settings are crucial to the proper configuration of the LDAP connector:

Setting Effect
user_dn_template Enables log in without specifying fully distinguished name
user_search_filter Sets LDAP search filter to search for a user principal
user_search_base Sets base object or named context to search for user objects
group_membership_attributes Lists attribute names on a user object that contains groups to be used for mapping to roles
group_to_role_mapping Lists an authorization mapping from groups to pre-defined roles (admin, architect, publisher, reader) or other custom-defined roles

Conclusion


This has been a brief look at how to integrate Neo4j Enterprise Edition with the LDAP protocol and administer federated LDAP users. With the right settings you can manage your existing directory of users outside of Neo4j while mapping them to pre-defined (or custom) roles for access to the graph database.

In the coming weeks, we’ll take a closer look at admin query management, security event logs, custom plugins, user-defined procedures and more. In the meantime, download the enterprise security white paper below to dive into more details.


Discover how to protect your graph data with enterprise-ready security and access control: Download this white paper, Why Intelligent Applications Need a Graph Database with Granular Security, and get started on securing your graph database today.

Read the White Paper


Catch up with the rest of the Neo4j graph database security series: