Re: [rundeck] make ldap user an admin

[Greg Schueler]

Hi Adrian,

It sounds like you simply haven't updated your aclpolicy to recognize the ldap groups that your account is a member of.

If you click on the user profile link in the header, you should see a page which lists the groups/roles that Rundeck recognizes for the account.

Modify your etc/admin.aclpolicy to apply to the role that you want to grant admin rights to.  Change the "by" clause:

by:

  group: 'my_admin_group'

On Wed, Sep 19, 2012 at 6:01 AM, Adrian Nye <adri...@gmail.com> wrote:

I configured rundeck to use ldap, and can log in, but when I log in I get:

No authorized access to projects. Contact your administrator.

How do I define myself as the administrator?

I see the doc for how to do this using the realm file but when using ldap the realm file is no longer used, right?
I need to assign my username to the admin group somehow, but the doc does not seem to address this.

By the way, I cannot create a user called "admin" since this is a large corporate environment and I can't add a user for such a purpose.

Thanks

[Adrian Nye]

Thanks for the response, but as far as I know, no user account is in any rundeck group yet.   That is my question - how do I put a user in a group when using ldap?
Putting the question another way based on your config below, where do I define my_admin_group and who is in it?

According to the doc, two groups are defined by the installation only if you use the non-ldap config, user and admin, and there is a user named admin.   But if you use the ldap config, the file that defines user and admin is not read and there appear to be no groups at all defined, and there is no user called admin.

If I click on my name in the header (top right), I also see No authorized access to projects. Contact your administrator.

[Greg Schueler]

When using LDAP, the groups are defined by your LDAP directory.  You define the specifics of how to query LDAP for the group/role membership in the config for the login module: http://rundeck.org/docs/administration/authentication.html#login-module-configuration

So you would need to decide on one of the LDAP groups that your account is a member of as representing the "administrative role", and then define that group name in your aclpolicy files.  

You could also modify the admin.aclpolicy to grant it to your specific username if the group/role is not being recognized.  You would use "by: username"

by:

  username: 'bob'

Make sure you change both of the "contexts" in the aclpolicy file

[Adrian Nye]

Thanks.  It's pretty unclear from the doc that roleBaseDN etc are what defines this.   Would be best to either use role or group as the term to avoid confusion of using two terms for the same thing.

Also it would be very useful to have an example of how to use the five fields:

roleNameAttribute

roleMemberAttribute

roleUsernameMemberAttribute

roleObjectClass

rolePrefix

[Dimitar]

I have a similar issue and I agree with Adrian, an example would be really helpful.

If I am not mistaken RunDeck will search all groups under roleBaseDn and try to match them against one of the acl policy files.

What if the group/role name has white characters in the name like "Long Admin Group Name"

Should I use in the acl file something like

by:

  group "Long Admin Group Name"

to match the group?

Thanks

Dimitar

[Dimitar]

I was able to resolve the issues with the authorization of groups. 

the following are the role settings in the jaas conf file

    roleBaseDn="OU=Groups,DC=example,DC=com"

    roleNameAttribute="cn"

    roleMemberAttribute="member"

Create the appropriate aclproperty file and assign the desired privileges to the selected group:

  by:

      group: groupname

It is a good idea to query the LDAP server first with a tool like ldapsearch to ensure that the groupname exist on the server.

Diimitar

[Marco Boschetti]

Hi all,

since I also would have appreciated a more helpful example in rundeck docs, I give my contribution to this topic in the hope that it could save a bit of time to someone else in the same situation

In my company we use MS Active Directory as LDAP server, and normally we don't base authorization features on LDAP groups.

In fact other OSS tools in our chain (such as Jenkins and Artifactory) use LDAP just for authentication purpose. Authorization is normally fully delegated to the tool itself. Not in the case of Rundeck though...

Said that, I finally solved the problem as follows.

In my rundeck RPM installation I created a /etc/rundeck/jaas-multiauth-loginmodule.conf file like this:

multiauth {

      com.dtolabs.rundeck.jetty.jaas.JettyCachingLdapLoginModule sufficient

      debug="true"

      contextFactory="com.sun.jndi.ldap.LdapCtxFactory"

      providerUrl="ldap://myadserver.domain.it:389"

      bindDn="mybin...@myadserver.domain.it"

      bindPassword="mybinduserpassword"

      authenticationMethod="simple"

      forceBindingLogin="true"

      userBaseDn="dc=myadserver,dc=domain,dc=it"

      userRdnAttribute="displayName"

      userIdAttribute="sAMAccountName"

      userPasswordAttribute="pwdLastSet"

      userObjectClass="Person"

      roleBaseDn="dc=myadserver,dc=domain,dc=it"

      roleNameAttribute="cn"

      roleMemberAttribute="member"

      roleObjectClass="group"

      cacheDurationMillis="300000"

      reportStatistics="true";

      org.mortbay.jetty.plus.jaas.spi.PropertyFileLoginModule required

      debug="true"

      file="/etc/rundeck/realm.properties";

};

I updated the RDECK_JVM setting in /etc/rundeck/profile file accordingly:

export RDECK_JVM="-Djava.security.auth.login.config=/etc/rundeck/jaas-multiauth-loginmodule.conf \

        -Dloginmodule.name=multiauth \

        -Drdeck.config=/etc/rundeck \

        -Drdeck.base=/var/lib/rundeck \

        -Drundeck.server.configDir=/etc/rundeck \

        -Dserver.datastore.path=/var/lib/rundeck/data \

        -Drundeck.server.serverDir=/var/lib/rundeck \

        -Drdeck.projects=/var/rundeck/projects \

        -Drdeck.runlogs=/var/lib/rundeck/logs \

        -Drundeck.config.location=/etc/rundeck/rundeck-config.properties \

        -Djava.io.tmpdir=$RUNDECK_TEMPDIR"

and I modified the /etc/rundeck/admin.aclpolicy file adding an LDAP group (named 'MyLDAPGroup') my LDAP user is member of, like this

description: Admin, all access.

context:

  project: '.*' # all projects

for:

  resource:

    - allow: '*' # allow read/create all kinds

  adhoc:

    - allow: '*' # allow read/running/killing adhoc jobs

  job:

    - allow: '*' # allow read/write/delete/run/kill of all jobs

  node:

    - allow: '*' # allow read/run for all nodes

by:

  group: [admin,MyLDAPGroup]

---

description: Admin, all access.

context:

  application: 'rundeck'

for:

  resource:

    - allow: '*' # allow create of projects

  project:

    - allow: '*' # allow view/admin of all projects

by:

   group: [admin, MyLDAPGroup]

Hope this can help

Bye

Marco

[Ravi Sagar]

Thanks for the solution. I spent an entire day trying to resolve this. No where in the rundeck documentation (or I missed) it says to add the group name in  /etc/rundeck/admin.aclpolicy. 

[Craig White]

open source project - if you feel the documentation is inadequate, feel free to contribute changes to the documentation.