Auditing Permission Sets

While permission sets makes assigning permissions a breeze, it can be a bit of a bear to audit all 150 of them. By audit, i mean see which ones give you [some permission] on [some object]

So this blog post will cover a number of ways to audit permission sets, and specifically will go into details on how to audit record type access using the metadata api, as that is the only way that I could find. Note that this would work for profiles or permission sets.

Now the first place to go is to use the list view itself. You can display and edit CRED permissions for any object on a permission set list view, just like you can with profiles. And that means you can edit them all at once (up to 200 at a time).

So, if you want to see which permission sets give Delete access on accounts, that is the first place to go. Just note that the search functionality for setting the ‘filter criteria’ is kinda wonky - you have to put the exact value in correctly or it probably will give you an error. Its easier to use the search on ‘select columns to display’ and sort, unless you have a ton of perm sets.

list_view.png

List views will only let you view and edit the following types of settings
User Permissions (run reports, modify all data)
Object Permissions (CRED)
Permission Set Details (Name, Created Date)

So there are a few other places to turn that can work with some other pieces of data

The perm-comparator app lets you compare and contrast up to 4 permission sets, and includes ‘Setup Entity’ permissions like apps, apex classes, etc.

perm_comparator.png

And for another awesome option to understand a specific user’s access at a granular level, check out this awesome post from 2013 on Adam Torman’s blog that has a link to an app you can install that looks excellent (full disclosure, have not tried it myself yet…)

But none of these tools give you access to audit record type access by permission set (or profile). And that is what I needed to do, so I figured out a way to do so using the metadata api and workbench.

The process has two steps

  1. retrieve the record type settings for a specific record type for all permission sets
  2. search across the resulting files to find any where visible = true

First, create a text file called package.xml with the following code

<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
<types>
    <members>**INSERT YOUR RECORD TYPE NAME HERE**</members>
    <name>RecordType</name>
</types>
<types>
    <members>*</members>
    <name>PermissionSet</name>
</types>
    <version>35.0</version>
</Package>

You need to replace ‘INSERT YOUR RECORD TYPE NAME HERE above with your record type name as follows: ObjectName.RecordTypeName

Note that while you can do this for multiple record types at once, for reasons that will become clear later, my technique will only work if you do one at a time.

So to audit access to a record type on accounts named 'Bank’, you would insert Account.Bank

Save the file, and login to workbench.developerforce.com

Select migration - retrieve from the drop-down menus at the top of the screen.

Next to ‘unpackaged manifest’ click choose file and and select your file.

Click next

Click retrieve

Wait for the operation to complete

Click download zip file

The resulting zip file will contain a few folders.

directory_tree.png

Go to unpackaged - permission sets and you will see an xml file for each of your permission sets.

Open one, and you will see something like

<?xml version="1.0" encoding="UTF-8"?>
<PermissionSet xmlns="http://soap.sforce.com/2006/04/metadata">
    <description>access to create bank record type.  </description>
    <label>Account - Bank Record Type Acccess</label>
    <recordTypeVisibilities>
        <recordType>Account.Bank</recordType>
        <visible>true</visible>
    </recordTypeVisibilities>
</PermissionSet>

The true means that this permission set is granting access to that record type.

Now, the trick - how to search across all the files. In Linux, there is the GREP command, which can do this. The trick is that it searches line by line - there is no way that I know of to use GREP across multiple lines. There are other commands that can do this but it was much more complex.

Open up the folder in terminal, and run the following command to output a list of files where the text ‘true’ is present.

grep -rlw "./" -e "<visible>true"

This will get you a list of the permission sets that grant access to the record type. Note that this would work for profiles or permission sets. The screenshot below is actually for profiles, as none of the perm sets were granting access to the record type i was interested in.

Also note that this works best one record type at a time. You would need to work out a way for multi-line matching to do multiple record types.

perm_sets.png

Thats all i have. If you have a better way of doing this - let me know!

 
2
Kudos
 
2
Kudos

Now read this

Fixing the ‘fix’ - the return of the ‘add to campaign’ button

The Spring 16 release contains a ‘fix’ for a problem that IMHO does not exist. update: the link to help and training above now pulls up a blank article. google’s cache shows the article describing the ‘fix’. Perhaps a change is in the... Continue →