Connect Rundeck to Active Directory

The Rundeck authentication documentation contains some errors and is not very explicit. That's why this information could help you connect your rundeck installation to Active Directory.

Reconfigure Rundeck

Firstly, tell Rundeck to have a look at a different file for authentication information:
Here is a part of /etc/rundeck/profile:

export RDECK_JVM="-Djava.security.auth.login.config=/etc/rundeck/jaas-activedirectory.conf \
        -Dloginmodule.name=activedirectory \

As you can see "loginmodule.name" refers to "activedirectory". So, create a file /etc/rundeck/jaas-activedirectory.conf:

activedirectory {
com.dtolabs.rundeck.jetty.jaas.JettyCachingLdapLoginModule required
debug="true"
contextFactory="com.sun.jndi.ldap.LdapCtxFactory"
providerUrl="ldaps://ldap.eu.company.com:636"
bindDn="CN=Some User,CN=Users,DC=eu,DC=company,DC=com"
bindPassword="MyPaSsWoRd"
authenticationMethod="simple"
forceBindingLogin="true"
userBaseDn="dc=eu,dc=company,dc=com"
userRdnAttribute="sAMAccountName"
userIdAttribute="sAMAccountName"
userPasswordAttribute="unicodePwd"
userObjectClass="user"
roleBaseDn="dc=eu,dc=company,dc=com"
roleNameAttribute="cn"
roleMemberAttribute="member"
roleObjectClass="group"
cacheDurationMillis="300000"
reportStatistics="true";
};

Import Active Directories Certificate Authority certificates

Obtain (all) the certificates:

$ openssl s_client -showcerts -connect ldap.eu.company.com:636

In my case I got a chain of 3 certificates and had to import them all. I did this by saving each certificate in a file and running:
keytool -import -alias company1 -file company1 -keystore /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/security/cacerts -storepass changeit

Authorization

After connecting to Active Directory, I could authenticate, but miss authorizations, so edit /etc/rundeck/admin.aclpolicy:

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

description: Full 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: [MyWindowsGroupName]

---

description: Admin, all access.
context:
  application: 'rundeck'
for:
  resource:
    - allow: '*' # allow create of projects
  project:
    - allow: '*' # allow view/admin of all projects
by:
  group: [MyWindowsGroupName]

There is an open bug, now you have to edit web.xml to point to a group that any user that need to login to RunDeck has.

...
        <security-role>
                <role-name>Some-AD-Group</role-name>
        </security-role>
...

Comments

Although I love to code but

Although I love to code but unfortunately I could not find time to learn it so I did not understand how to reconfigure Rundeck. I am running top еssay servіce for all college students.

I am still struggleing to

I am still struggleing to make rundeck to recognize the AD group memberships and I ended up raising a detailed bug at https://github.com/rundeck/rundeck/issues/1397

There is something that I do not really understand on your configuration, as you say that the group name would use the group CN attribute but this is a very ugly/techincal way to describe a group. Usually people would want to use the sAMAccountName attribute as the group name.

We do both know that the member attribute would contain a CN and not a sAMAccountName, so how are we supposed to make rundeck use the group with a proper name?

Thanks for the great article.

Thanks for the great article. Looks like the bug is fixed, instead of editing web.xml you can now add "supplementalRole" to your jaas config. Same thing still applies though .. you need to have one of those roles listed in the web.xml, so for me I'm including "user". Specifically, I'm using:

supplementalRoles="admin,user"

since (a) it's fine for this group of AD users to be admins, (b) I've not yet got any other ACL policies defined.

Great article, I wish I had

Great article, I wish I had found it earlier! I spent ages getting it working and also wrote a blog post about it

http://ftclausen.github.io/general/rundeck_-_authentication_and_authorisation_notes/

for the context where we have an "admin" group and a less privileged "ops" group.

About Consultancy Articles Contact




References Red Hat Certified Architect By Robert de Bock Robert de Bock
Curriculum Vitae By Fred Clausen +31 6 14 39 58 72
By Nelson Manning [email protected]