The Zurich release has arrived! Interested in new features and functionalities? Click here for more

ACL deny read on single record

Julian12
Mega Guru

I'm trying to simply deny read access to a record on the cmdb_ci. But not even puting answer = false; on the script area is restricting access to users...

Any ideas on what I'm doing wrong
This is the ACL

Julian12_0-1675201941529.png

But any ITIL user is having access to the record:

Julian12_1-1675201979005.png

 

 

1 ACCEPTED SOLUTION

Julian12
Mega Guru

Resolved by myself:

There was another ACL grating access to the entire cmdb_ci table, had to add a filter to bypass the actual CI record using sysID and created another ACL with a condition on the same CI and the script:

 

var answer = true
var grDeniedGroup = new GlideRecord("sys_user_group");
grDeniedGroup.addEncodedQuery("query with groups if user is member of then wont have access");
grDeniedGroup.query();

while (grDeniedGroup.next()) {
    if (gs.getUser().isMemberOf(grDeniedGroup.name)) {
        answer = false;
break;
    }
    else {
        answer = true;
        }
}

View solution in original post

4 REPLIES 4

Tony Chatfield1
Kilo Patron

Hi, have you enabled security debugging, reproduced the issue and reviewed your security logs?
ACL debugging tools (servicenow.com)

I would expect that there are existing OOB ACL's that are allowing access to this record, and these ACL's would also need to be updated as access is allowed as long as 1 ACL has conditions that are met.

Hi There Tony! Thanks for your help!

I'm trying to debug although without succes since the debugger shows 3 ACLS granting access to the field although I can not find them in the ACL table... I'm pretty sure I'm doing something wrong since this is my first time debugging ACLS,,, see picture below...

Showing 3 ACLS...

Julian12_0-1675252987461.png


No acl .configuration_item in ACL table:

Julian12_1-1675253022510.png

 

Hi @Julian12 , This ACL mostly likely is dynamically evaluated at runtime so might not be an static entry in ACL table. The evaluation might depend on current context such as your role, system state or other variables.

Please Mark My Response as Correct/Helpful if it helped.
Regards,
Badal Khojare
Community Rising Star 2023

Julian12
Mega Guru

Resolved by myself:

There was another ACL grating access to the entire cmdb_ci table, had to add a filter to bypass the actual CI record using sysID and created another ACL with a condition on the same CI and the script:

 

var answer = true
var grDeniedGroup = new GlideRecord("sys_user_group");
grDeniedGroup.addEncodedQuery("query with groups if user is member of then wont have access");
grDeniedGroup.query();

while (grDeniedGroup.next()) {
    if (gs.getUser().isMemberOf(grDeniedGroup.name)) {
        answer = false;
break;
    }
    else {
        answer = true;
        }
}