Community Articles

Find and share helpful community-sourced technical articles.
Celebrating as our community reaches 100,000 members! Thank you!
Labels (1)

In HDP 2.5, Zeppelin Notebook supports the ability to impersonate a user's security context when accessing a data set. This is critical to allow multi-tenant, fine-grained access using Ranger authorization policies. In order to support this, the user will first need to authenticate to the Zeppelin UI.

(In Part 2, we harden this configuration to use LDAPS).

Zeppelin provides a few different authentication mechanisms (based on what the underlying Apache Shiro project supports); we'll use OpenLDAP in this walkthrough.

In this article, we'll assume you already have an OpenLDAP server installed in your environment, which contains the users to which you want to provide access to the Zeppelin UI (I plan to create a supporting article regarding OpenLDAP installation). We'll further assume that these users exist as local OS users (this is outside the scope of this article, but we can use a solution like SSSD for this).

Our organizational structure is as follows:


With this structure, our search base will be restricted to dc=field,dc=hortonworks,dc=com and our user DN template will be cn={0},ou=People,dc=field,dc=hortonworks,dc=com as the People OU contains the users.

The Zeppelin configuration in question can be found in the shiro_ini_content sub-section of the Advanced zeppelin-env section on the Config tab in Ambari. The configuration should like the below, with the search base, user DN template, and URL specific to your environment (my OpenLDAP server lives at

ldapRealm = org.apache.zeppelin.server.LdapGroupRealm
ldapRealm.contextFactory.environment[ldap.searchBase] = dc=field,dc=hortonworks,dc=com
ldapRealm.userDnTemplate = cn={0},ou=People,dc=field,dc=hortonworks,dc=com
ldapRealm.contextFactory.url = ldap://
ldapRealm.contextFactory.authenticationMechanism = SIMPLE
sessionManager = org.apache.shiro.web.session.mgt.DefaultWebSessionManager
securityManager.sessionManager = $sessionManager
securityManager.sessionManager.globalSessionTimeout = 86400000
shiro.loginUrl = /api/login
securityManager.realm = $ldapRealm
admin = *
/** = authc

Make sure you specify securityManager.realm = $ldapRealm as in the last line as this isn't part of the sample shiro.ini included with Zeppelin.

After these changes are saved, make sure to restart Zeppelin. Now, navigate to the Zeppelin UI. With authentication enabled, you should not see any notebooks accessible until a user logs in.


I'll now login using user1 (full DN is cn=user1,ou=People,dc=field,dc=hortonworks,dc=com, based on the userDnTemplate value above) and the password stored in OpenLDAP.

After authenticating, I can navigate to the notebooks to which user1 has access:


In the next article in this series, we'll show how to use this authenticated subject to support impersonated access to data assets.


Dears, I'm trying to configure shiro to authenticate users from AD and to limit access to login to webui for specific group.

Here's my shiro.ini config:

activeDirectoryRealm = org.apache.zeppelin.server.ActiveDirectoryGroupRealm
activeDirectoryRealm.systemUsername = user
activeDirectoryRealm.systemPassword = password
activeDirectoryRealm.searchBase = "OU=x,OU=x,OU=x,DC=x,DC=x,DC=x"
activeDirectoryRealm.url = ldaps://
activeDirectoryRealm.groupRolesMap = "CN=HADOOP_GROUP,OU=x,OU=x,OU=
activeDirectoryRealm.authorizationCachingEnabled = false

role1 = *

/api/version = anon
/** = authc

Currently, authentication works for every user who is in search base, so everyone from search base can login.

To limit access, I would like to have authorization based on specified group, so only users from HADOOP_GROUP can log in, like above in groupRolesMap, but it's not working as I expected. What am I missing? I'll appreciate your help. Kind regards, Michał


Hi @Michał Kabocik, please post this as a separate question. Group Roles Map is used to map AD groups to Zeppelin roles. The Search Base can be used to restrict which users can authenticate.

Cloudera Employee


Hi all, Even I'm too facing an issue. I specifically want user_role not to access /api/configuration/**

I tried various ways, but in vain. Can someone help ?