Users With Deploy Permissions

Products

• CA Release Automation - Release Operations Center (Nolio)
• CA Release Automation - DataManagement Server (Nolio)

Issue/Introduction

We have an audit requirement to list every user who can execute releases.

Is there a report that will show which users can execute releases? 

Environment

CA Release Automation v6.x

Resolution

No. There is a chrome plugin that works with version 6.3. That can be found here: https://chrome.google.com/webstore/detail/release-automation-permis/bojghbfgnapobcdoagkokikjhidjhemk

Note 1: 
Before installing the extension you can see what requirements it has for setting it up.

Note 2: 
In order for a user to be able to execute releases against an environment they one of the following must be true:

• The user must be a superuser
• A non-superuser must be given explicit permissions in the form of:
  
  • At the application level: Application Owner; or
  • At the application level: Execute Releases In All Environments with either "Environment Admin" or "Release Designer" privilege at the environment level; or
  • At the application level: Nothing (except Can view application) with either "Environment Admin" or "Release Designer" AND "Can Execute All Releases" at the environment level.

The chrome extension provides insight (per application) on the privileges each user has. 

Also, there is an SQL query that you could attempt to run. It is not anything officially certified but unofficially the following query should also provide the information you are looking for (limited testing done against v6.4):
select 
    asid.SID as USERNAME, 
    apps.APP_NAME as APP_NAME,
    ae.MASK as MASK,
    en.NAME as ENVIRONMENT_NAME,
    appNameForEnv.APP_NAME as APPLICATION_NAME_FOR_ENV,
   u.NOT_IMPORTED_LDAP,
   ug.name as LDAP_GROUP_NAME
FROM acl_sid asid 
    INNER JOIN acl_entry ae 
        on ae.sid=asid.id 
    LEFT OUTER JOIN acl_object_identity aod 
        on aod.ID=ae.ACL_OBJECT_IDENTITY 
    LEFT OUTER JOIN applications apps 
        on aod.OBJECT_ID_IDENTITY=apps.ID
    LEFT OUTER JOIN environments en
        on aod.object_id_identity=en.id
    LEFT JOIN applications appNameForEnv
        on en.APPLICATIONID=appNameForEnv.id
    LEFT OUTER JOIN users u
       on upper(asid.SID)=upper(u.USERNAME)
    LEFT OUTER JOIN user_groups ug
       on asid.SID='GROUP_'||ug.id
where asid.sid != 'superuser'
AND ae.mask='16' /*app owner privilege if app_name is populated. otherwise, environment admin if environment name is populated*/
or ae.mask='512'  /*execute all releases in all environments if app_name is populated. otherwise, execute all releases for a specific environment if the environment_name is populated*/
or ae.mask='1024' /*release designer at envirtonment level*/;

Note 1: 
The superuser username has an entry for each application/environment. That is why it is filtered via the query. 

Note 2: 
Users assigned the superuser role will not be returned in the output (maybe unless they specifically created an application). Users assigned the superuser role seem to be tracked via the AUTHORITIES table. This can be seen by running: select username from authorities where authority = 'ROLE_SUPERUSER'

Note 3: 
This query was tested against an Oracle database. It might not work as advertised against MSSQL. Specifically there might be problems with the way it looks for user<->user_group information. 

Note 4: 
The NOT_IMPORTED_LDAP and LDAP_GROUP_NAME fields are provided in case the user retrieved its permissions from an imported LDAP group. Value of 0 for NOT_IMPORTED_LDAP means that the user was not imported. For LDAP users that get their permissions from an a group that was imported from LDAP, it will only make this information available if the user has logged into CA Release Automation since CA Release Automation doesn't keep track of what ldap groups an ldap user is a part of. 

 

 

Still not officially supported/certified, this version of the query should work against MSSQL and version 6.7 of Nolio: 

select 

    asid.SID as USERNAME, 

    apps.APP_NAME as APP_NAME,

    ae.MASK as MASK,

    en.NAME as ENVIRONMENT_NAME,

    appNameForEnv.APP_NAME as APPLICATION_NAME_FOR_ENV,

   u.tbd67_not_imported_ldap as Imported_From_Ldap,

   ug.name as LDAP_GROUP_NAME

FROM acl_sid asid 

    INNER JOIN acl_entry ae 

        on ae.sid=asid.id 

    LEFT OUTER JOIN acl_object_identity aod 

        on aod.ID=ae.ACL_OBJECT_IDENTITY 

    LEFT OUTER JOIN applications apps 

        on aod.OBJECT_ID_IDENTITY=apps.ID

    LEFT OUTER JOIN environments en

        on aod.object_id_identity=en.id

    LEFT JOIN applications appNameForEnv

        on en.APPLICATIONID=appNameForEnv.id

    LEFT OUTER JOIN users u

       on upper(asid.SID)=upper(u.USERNAME)

    LEFT OUTER JOIN user_groups ug

       on asid.SID=CONCAT('GROUP_',ug.id)

where asid.sid != 'superuser'

AND ae.mask='16' /*app owner privilege if app_name is populated. otherwise, environment admin if environment name is populated*/

or ae.mask='512'  /*execute all releases in all environments if app_name is populated. otherwise, execute all releases for a specific environment if the environment_name is populated*/

or ae.mask='1024' /*release designer at envirtonment level*/

order by USERNAME;

Additional Information

This is also not official. But the following seems to be true

 

Permissions At Application Level	ACL_ENTRY.MASK Value
Can view Application	1
Application Owner	16
Application Publisher	256
Application Designer	128
Can View Design Component	2048
Execute Processes In All Environments	64
Can View Execution Components	4096
Execute Releases In All Environments	512
Approve Releases In All Environments	8192
Release Template Designer	32

 

Permissions At Environment Level	ACL_ENTRY.MASK Value
Environment Admin	16
Release Designer	1024
Can Execute All Processes	64
Can Execute All Releases	512
Can Approve All Releases	8192