Rundeck Upgrade from 5.1.0 to 5.12.0

[eric....@gmail.com]

Hi!  After upgrading RunDeck from 5.1.0 to 5.12.0 and upgrading the java version from java11 to java17, my user no longer has access to my only project on the server.  I still have access through my admin user.  How do I fix my, as well as all of our users, access to the project?  Thanks!  Eric

[eric....@gmail.com]

Here's the ACL policy for my user (in AD group associated with my user):

description: Admin project level access control
context:
  project: '.*' # all projects
for:
  resource:
    - equals:
        kind: job
      allow: [create] # allow create jobs
    - equals:
        kind: node
      allow: [read,create,update,refresh] # allow refresh node sources
    - equals:
        kind: event
      allow: [read,create] # allow read/create events
  adhoc:
    - allow: [read,run,runAs,kill,killAs] # allow running/killing adhoc jobs
  job:
    - allow: [create,read,update,delete,run,runAs,kill,killAs] # allow create/read/write/delete/run/kill of all jobs
  node:
    - allow: [read,run] # allow read/run for nodes
by:
  group: my-group

---

description:  All jobs access control
context:
  application: 'rundeck'
for:
  resource:
    - equals:
        kind: project
      allow: [create] # allow create of projects
    - equals:
        kind: system
      allow: [read,enable_executions,disable_executions,admin] # allow read of system info, enable/disable all executions
    - equals:
        kind: system_acl
      allow: [read,create,update,delete,admin] # allow modifying system ACL files
    - equals:
        kind: user
      allow: [admin] # allow modify user profiles
  project:
    - match:
        name: '.*'
      allow: [read,import,export,configure,delete,promote,admin] # allow full access of all projects or use 'admin'
  project_acl:
    - match:
        name: '.*'
      allow: [read,create,update,delete,admin] # allow modifying project-specific ACL files
  storage:
    - allow: [read,create,update,delete] # allow access for /ssh-key/* storage content

by:
  group: my-group

[eric....@gmail.com]

Note that when I log on as my user I get:

You have no authorized access to projects.

The only thing I noticed when looking at ACL's is that the group names had incorrect case in them so I fixed that.  Didn't fix the problem however...

On Tuesday, May 27, 2025 at 11:29:01 AM UTC-6 eric....@gmail.com wrote:

[eric....@gmail.com]

ACL Policy seems to work fine for the admin user.  So I copied that policy to a new policy (both are on the file system in /etc/rundeck) and changed the admin username to my Active Directory group.  This new group didn't work.  I even changed the group to my username instead.  This also didn't work.  I'm still able to login (AD User) but it says that I don't have authorized access to any projects.  At this point the only option I have is to give the admin user to all my users because they have no accesses.  Can anyone help please?  I feel like I've tried everything...  Thanks - Eric

[rac...@rundeck.com]

Hi Eric,

I've tested your ACL successfully on my end, focusing on a non-admin user group; I can see the projects. Can you double-check if you have another ACL that blocks your user? Also, try adding the ACL definition to the "Stored ACL Policies" instead of using ACL policy files in the /etc/rundeck path.

Regards.

[eric....@gmail.com]

I've moved both ACL's over to "Stored ACL Policies" with the same results.  The only other ACL I have, other than the admin one (which I left in /etc/rundeck so that I don't potentially screw this one up), also worked before.  Here it is:

description: Admin project level access control
context:
  project: '.*' # all projects
for:
  resource:
    - equals:
        kind: job
      allow: [create] # allow create jobs
    - equals:
        kind: node
      allow: [read,create,update,refresh] # allow refresh node sources
    - equals:
        kind: event
      allow: [read,create] # allow read/create events
  adhoc:
    - allow: [read,run,runAs,kill,killAs] # allow running/killing adhoc jobs
  job:
    - allow: [create,read,update,delete,run,runAs,kill,killAs] # allow create/read/write/delete/run/kill of all jobs
  node:
    - allow: [read,run] # allow read/run for nodes
by:

  group: my-other-group

  group: my-other-group

The only other guess I had was if the AD Integration wasn't working, but obviously it was as it allows me to login, just doesn't give me access to any projects.  Thanks for your response!  Anything else you can think of?

[eric....@gmail.com]

Note that I checked and there are no Project Level ACL Policies...

[rac...@rundeck.com]

Can you check the service.log output? Probably it is a problem related to your AD/LDAP. Try with another user/group and test with local users/groups (not AD) to isolate the root cause.

Regards.

[eric....@gmail.com]

service.log output:

[2025-05-28T14:09:56,207] INFO  jaas.JettyCachingLdapLoginModule - Login attempts: 35, Hits: 0, Ratio: 0%.
[2025-05-28T14:09:56,207] DEBUG jaas.JettyCachingLdapLoginModule - Cache Miss for efetzer.
[2025-05-28T14:09:56,207] DEBUG jaas.JettyCachingLdapLoginModule - Searching for users with filter: '(&(objectClass={0})({1}={2}))' from base dn: myDN
[2025-05-28T14:09:56,209] DEBUG jaas.JettyCachingLdapLoginModule - Found user?: true
[2025-05-28T14:09:56,209] INFO  jaas.JettyCachingLdapLoginModule - Attempting authentication: CN=Eric Fetzer,OU=myOU
[2025-05-28T14:09:56,213] DEBUG jaas.JettyCachingLdapLoginModule - Adding efetzer set to expire: 1748459396213300000
[2025-05-28T14:09:56,240] DEBUG authentication.GrailsUsernamePasswordAuthenticationFilter - Set SecurityContextHolder to JaasAuthenticationToken [Principal=efetzer, Credentials=[PROTECTED], Authenticated=true, Details=WebAuthenticationDetails [RemoteIpAddress=10.2.40.127, SessionId=node03dxq9gwfiaiohq57gupa38b11382], Granted Authorities=[]

All of our users are AD users unfortunately.

[eric....@gmail.com]

And wait, if the AD integration wasn't working, I wouldn't be able to login with my AD user.

[eric....@gmail.com]

Hmmm, maybe it's just not seeing my groups.  How do I change my ACL to access via my user instead of group?

[eric....@gmail.com]

Found out how and that works to use my username.  Guess I have to set up the other ACL to use multiple users.  I really don't like this solution but I guess it is what it is.  Do you have a way to test to see if this is a bug in the new version of Rundeck?

[rac...@rundeck.com]

Hi Eric, 

To determine it,  more context is needed. Check the different behavior between 5.1 and 5.12. If the behavior is different with the same config/ACLs, please open a new ticket here and provide detailed steps to reproduce it. Don't forget to share the LDAP config file (jaas-ldap.conf or jaas-ad.conf).

Thanks!