Unable to expand nested groups for Active Directory authentication

[eroji]

Issue type: Bug report/Enhancement Request

My Rundeck detail

• Rundeck version: 2.9.2-1.36.GA
• install type: rpm
• OS Name/version: CentOS 6.11
• DB Type/version:

Expected Behavior
I have an admins and a users group configured for Rundeck in AD to authenticate against. It is able to see at base DN level of users that belong to each group and allow login with respect to the security role and ACL configuration. I want to nest groups (ie. Domain Admins into Rundeck Admins) into these Rundeck groups so that users belonging to a nested group that is a member of the Rundeck group is allowed to complete the login successfully.

The groups are:
Rundeck Admins
Rundeck Users

web.xml Security Roles

        <security-role>
                <role-name>Rundeck Users</role-name>
        </security-role>
        <security-role>
                <role-name>Rundeck Admins</role-name>
        </security-role>

My sanitized AD configuration

activedirectory {
  com.dtolabs.rundeck.jetty.jaas.JettyCachingLdapLoginModule required
    debug="true"
    contextFactory="com.sun.jndi.ldap.LdapCtxFactory"
    providerUrl="ldaps://dc1.domain.com:636"
    bindDn="ldap@domain.com"
    bindPassword="Password123"
    authenticationMethod="simple"
    forceBindingLogin="true"
    userBaseDn="ou=Employees,dc=domain,dc=com"
    userRdnAttribute="sAMAccountName"
    userIdAttribute="sAMAccountName"
    userPasswordAttribute="unicodePwd"
    userObjectClass="user"
    roleBaseDn="ou=Misc Groups,ou=Custom Groups,dc=domain,dc=com"
    roleNameAttribute="cn"
    roleMemberAttribute="member"
    roleObjectClass="group"
    cacheDurationMillis="300000"
    reportStatistics="true";
};

Actual Behavior
After nesting a group that the users I want to give access, if they try to login, the !role error page is shown. And the current documentation on the website does not mention anything about nested group configuration for AD.

How to reproduce Behavior
Per description above.

[eroji]

I converted the configuration to use LDAP since it has a statement specifically to enable nestedGroups but it still yields the same result.

ldap {
  com.dtolabs.rundeck.jetty.jaas.JettyCachingLdapLoginModule sufficient
  debug="true"
  contextFactory="com.sun.jndi.ldap.LdapCtxFactory"
  providerUrl="ldaps://dc1.domain.com:636"
  authenticationMethod="simple"
  forceBindingLogin="true"
  bindDn="ldap@domain.com"
  bindPassword="Password123"
  userBaseDn="ou=Employees,dc=domain,dc=com"
  userRdnAttribute="sAMAccountName"
  userIdAttribute="sAMAccountName"
  userPasswordAttribute="unicodePwd"
  userObjectClass="user"
  roleBaseDn="ou=Misc Groups,ou=Custom Groups,dc=domain,dc=com"
  roleNameAttribute="cn"
  roleMemberAttribute="member"
  roleObjectClass="group"
  supplementalRoles="user"
  cacheDurationMillis="300000"
  reportStatistics="true"
  nestedGroups="true";
};

[BenPhegan]

We had a similar problem, one of our guys found that replacing:

roleMemberAttribute="member"

with

roleMemberAttribute="member:1.2.840.113556.1.4.1941:"

did the trick. Some details as to why: https://msdn.microsoft.com/en-us/library/aa746475(v=vs.85).aspx

[djorem]

@BenPhegan
Thanks. For me it worked

[wouteroostervld]

Confirmed! This should be in the documentation.

[wouteroostervld]

This solution even works with nestedGroups="false". So the nestedgroups lookup in rundeck self still broken/misconfigured.

[gschueler]

nestedGrops="true" seems to invoke this behavior:

• query the directory for roleBaseDn, subtree scope, member=* filter
• for each result,
  • look for "roleNameAttribute" as the role name
  • read each "roleMemberAttribute" as the members list
    • if the the role member value doesn't match ^cn=([^,]+), skip it
    • otherwise record the cn of the "member" as being a sub role of the "roleName"

Then when determining user roles, query the user roles normally, and recursively add recorded "sub roles" from the previously created map.

I do not know if that is the correct way to do it in Active Directory, (not my code), but if maybe someone else understands a better way..?

[ThorbenJ]

roleMemberAttribute="member:1.2.840.113556.1.4.1941:" worked a treat and is the normal way to flatten nested groups:

• https://ldapwiki.com/wiki/Active%20Directory%20Group%20Related%20Searches
• https://ldapwiki.com/wiki/1.2.840.113556.1.4.1941

We use it a lot for other LDAP connected applications, just I never thought I could twiddle roleMemberAttribute to use this LDAP matching rule.

Rundeck should prefer this for LDAP servers that support (AD does) over local application logic.

[mergeable]

There haven't been much activity here. This is stale. Is it still relevant? This is a friendly reminder to please resolve it. :-)

[stale]

In an effort to focus on bugs and issues that impact currently supported versions of Rundeck, we have elected to notify GitHub issue creators if their issue is classified as stale and close the issue. An issue is identified as stale when there have been no new comments, responses or other activity within the last 12 months. If a closed issue is still present please feel free to open a new Issue against the current version and we will review it. If you are an enterprise customer, please contact your Rundeck Support to assist in your request.
Thank you, The Rundeck Team