Best Practices for NAV Easy Security setup
When doing setup of permissions in NAV, there are many different ways to approach the task. This document will try to give some guidelines for the best way to maintain and create permissions.
When starting a new installation, the roles delivered from Microsoft are a good base for a simple security setup. Even when the roles have errors and are missing your customizations and add-ons, most roles are working OK. By using the Recorder in Easy Security, it is easy to fix the problems in the base roles or build new ones when needed for special processes. However, to create roles that adhere to Sarbanes-Oxley Segregation of Duties or similar principles, the concept is flawed. By giving a complete functional area, like the "S&R Q/O/I/C/R" role, the principle of separation of duties is not being followed. The Role Demo Data and the associated spreadsheet show an approach for setting up precise security based on tasks inside NAV.
If Field Level, Actions and Data Security is going to be used, it is not a replacement for good security based on Roles and Logins. This module only adds additional functionality on top of the normal security system.
What Company to use for Easy Security data
Data in Easy Security should be maintained in a company that can be controlled with specific permissions, meaning a company that is not used for other purposes than security setup. This can allow a person in the IT department working on security to have full permissions in that company, since no data is confidential. By using a NAS (NAV Application Server), it is possible to have a person without SUPER rights maintain and publish permissions; they cannot even change their own permissions.
A blank company without any data is the best to use for the data in Easy Security. If the company will be used for recordings, the data in the company can contain setup for add-ons and customizations. The best way is typically to use a CRONUS demonstration company that has been renamed without CRONUS as the first part of the Company Name. With the data in the demo company, it is often possible to record all scenarios without using actual data.
Other companies can be setup for recording only. This is easily done with the setup wizard in Easy Security. Recordings done in one company can be copied with the functions on the Recording window or exported to a file to be imported in a different database.
Although Restore Points and Recordings can be exported and imported,a lot of other data is being used when publishing permissions. Without maintaining all the data in the company, Object Level Security, Role Groups, Company Groups and features in the Role Builder will not work the same way if reinstalled in a new company.
A CRONUS company should not be used for maintaining security. Based on the special permissions in a company starting with the word "CRONUS", recordings may not always be correct. The message from Easy Security will also warn the user about this when running processes in Easy Security.
Maintaining Logins
Logins are best maintained by using groups of roles. This makes it easy to get an overview of the high level permissions for a user. Instead of 50 individual roles, maybe only a few Role Groups are needed. By making groups like "BASE", "SALES", "ACCOUNTING" and "WAREHOUSE" the groups refer to functional areas. When later adding another customization or add-on requiring more roles for a user, only the Role Group would be affected and not each individual user. Certifying users with Sarbanes-Oxley is also easier when using the Role Groups in comparison to maintaining many individual roles.
Role Groups can also be nested by including Role Groups inside a Role Group. This can be used for building a setup with a user only having 1 Role Group in each Company.
The "SUPER" or "SUPER (DATA)" roles should normally not be included in Role Groups, since these are really important and need to be visible directly under the Login.
A Role Group "BASE" is very useful to add permissions that all users need. The Role "ALL" and "BASIC" can be included in the Role Group. Roles required by add-ons to be added to every user can also be added to the Role Group.
If many users work in a similar role in a company and need the same permissions, the "Permissions as User ID" should be used. This allows for only maintaining permissions for one user and is convenient for cases when all employees in a department should be the same, for example.
Company Groups can save a lot of complexity by having multiple test companies in a single Company Group. New test companies are typically created on a regular basis, and adding the permissions to users would require only adding the Company in the Company Group and then publishing permissions. By using Company Groups, it is also easy to handle renaming of companies between a test and live database.
Maintaining Roles
Roles should be maintained as small tasks to allow for easily modifying and adding permissions when new customizations or add-ons are added to the database. Using a recording for a change in process, a small Role can easily be updated.
The 0 permissions for objects should not be used in many different roles. This permission is so powerful that trying to control object level permissions when this is scattered in many different roles is very difficult.
If a role is created to be a complete set of permissions that a user needs for doing all the work in a day, several roles will be created for each type of user in a company. This will turn into a nightmare for maintenance, because hundreds or even thousands of permissions are repeated again and again in each role. The Role Groups should be used instead to maintain this by building a Role Group with multiple smaller Roles.
If a new customization or add-on is added, a small recording can be created with the changes. This recording can then be added to the Roles affected by the changes. In this way it is easy to track changes and even reverse permissions added if a mistake happens.
Recordings
A separate NAV Server instance should be created to be used only for recordings. When recording from RTC, you must clear object cache before starting a recording to ensure that all object permissions are captured. This requires either restarting the NAV server service or setting object cache to zero. In both cases, production users would be impacted. In order to avoid disruptions or performance lag (in the case of cache set to zero), we recommend setting up a separate NAV Server instance.
See Installing additional NAV Service Tier for recording of permissions
Also How to set Object Cache to zero for recording
Security Filters
Using Security Filters with Easy Security is no different than in base NAV. There are some limitations of the implementation in NAV. Permissions are always added, which will cause a Security Filter to be removed if permissions to the same table are given from another role. This makes it very hard to use for tables like G/L Entries or similar, where permissions are given from many roles.
A Security Filter is normally also user specific, but the setup within a Role makes it unavailable by user. This will cause a lot of very similar roles to be created based on different Security Filters needed.
Field Level, Actions and Data Security supports this in a much better way than what Security Filters can be used for.
Refer to the Documentation for the processes in Easy Security
Like


© 2015 Mergetool.com. All rights reserved.
