Easy Security: Best Practices

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 permission sets delivered from Microsoft are a good base for a simple security setup. Even when the permission sets have errors and are missing your customizations and add-ons, most permission sets are working OK. By using the Recorder in Logins and Permissions, it is easy to fix the problems in the base permission sets or build new ones when needed for special processes. However, to create permission sets 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" permission set, the principle of separation of duties is not being followed. The Segregation of Duties Permission Sets delivered with NAV Easy Security and the associated spreadsheet show an approach for setting up precise security based on tasks inside NAV.

If Field Level and Data Security are going to be used, it is not a replacement for good security based on Permission Sets. This module adds additional functionality on top of the normal security system but can help accomplish many tasks not possible with the standard NAV security like hiding the cost on the sales documents for certain users, preventing users from changing the credit limit and simplifying the screens by hiding fields. The Data Security is also good at showing only some records and is not having an impact of the processing like the Security Filters in standard NAV.

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 to the NAV Easy Security application in that company. 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 by using the Login Setup to lock down the user.

A blank company without any data is the best to use for the data in Easy Security. By using a separate company the NAV Easy Security setup wizard can also be run at a later point if the initial data needs to be re-initialized.

Other companies can be setup for recording only. This is easily done with the setup wizard in Easy Security. Recordings done in one company with the SQL Profiler is only a list of required permissions and is imported in the NAV Easy Security company. The Launch Objects feature used for recording especially of Role Centers can also be used from any company. The data in the Easy Security company is used to calculate the needed information.

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, Permission Groups, Company Groups and features in the Permission Set Builder will not work the same way if reinstalled in a new company. All Data from the original company can be exported and imported to the new company. This is also the approach to move an Easy Security setup from a test to a production environment.

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 permission sets. This makes it easy to get an overview of the high level permissions for a user. Instead of 50 individual permission sets, maybe only a single or few permission groups are needed. By making groups like "CUSTOMERSERVICE", "SALES", "ACCOUNTING" and "WAREHOUSE" the groups refer to the job the people in the group performs. When later adding another customization or add-on that requires more permission sets for a user, only the permission group would be affected and not each individual user.

Certifying users with Sarbanes-Oxley is also easier when using the permission groups in comparison to maintaining many individual permission sets. For user with only a single permission group, an auditor can certify the permission group by using the summary permissions. Then it is not necessary for each user to be looked at. The summary permissions can also be calculated for the live data in NAV allowing an auditor to also verify the actual security for the logins.

Permission groups can also be nested by including permission groups inside a permission group. This can be used for building a setup with a user only having 1 permission group in each company or build the hierarchical structure of the company inside the permission groups.

The "SUPER" or "SUPER (DATA)" permission sets should normally not be included in Permission Groups, since these are really important and need to be visible directly under the Login. Other permission sets can of course also be added directly to the logins if a special permission is needed for a single login.

A couple of permissions sets should be included in all permission sets allowing the user to log in and execute objects as needed. Depending if the setup is using base NAV permission sets ("BASIC"), Quick Security ("ES_QS_LOGIN" and "ES_QS_OBJECTS") or Segregation of Duties ("E_TECH_LOGIN" and "ES_TECH_ALLOBJFREE") is different permission sets are needed.

If many users work in a similar permission set in a company and need the same permissions, the "Permissions as User ID" can 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. With the proper setup of permission groups each login would only need a single record for the login access controls, giving a better visibility than the Permission as User ID.

Company Groups can remove a lot of complexity by having multiple 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. In a production database with accounting people having access to multiple companies the company group is used for a single record under the login. This still allow the adding of future companies and not allowing access to companies like the Easy Security Company.

Maintaining Permission Sets

Permission sets should be maintained as small tasks to allow for easy testing, modifying and adding permissions when new customizations or add-ons are added to the database. Using a new recording for a change in process or permissions needed, a small permission set can easily be updated.

The 0 permissions for objects should not be used in many different permission sets. This permission is so powerful that trying to control object level permissions when this is scattered in many different permission sets is very difficult. The Quick Security and Segregation of Duties permission sets also control access to objects. All object types except Table and MenuSuites are controlled with the object level security. Standard NAV permission sets do not use the object level security. The "BASIC" permission includes all the object types.

Recording permissions for everything a user does in a single recording is a very bad idea. This is hard to maintain and always create problems for most users when adding customizations. Instead a permission group should be created and then assigned to the user. Future code changes only affect a few smaller permission sets and correcting this makes it work for all users. If a single recording is done it is not possible to take a single process away from the login in the future. The complete recording needs to be redone.

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 multiple permission sets 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 NAV 2013 and later, you must clear data and object cache before starting a recording to ensure that all needed permissions are captured. This requires restarting the NAV server service. Using the same service tier as production users would be impractical. Also when multiple users are connected to a service tier the permissions needed for all users are captured. In order to avoid disruptions, we recommend setting up a separate NAV Server instance with a separate service account that allows for simple filtering on the transactions. With a separate service tier the server connection information can be shared with a user that does a unique process in NAV and still be recorded with the SQL Profiler.

Publishing Permissions

All changes to data inside the Easy Security company are offline from the Live security data controlling access in NAV. When a Publish of permissions is done the Live data controlling security is changed, but a Restore Point ensures that changes can easily be reverted. A Restore Point is also created during the setup to ensure future changes can be compared or reverted to the original security. One or more logins or permission sets can also be published. This allows for testing a single login before a larger change or to correct a single permission set when working on a larger change. The publishing of a single login or permission set is not intended to be used as the normal process. The complete publish ensures that all changes including grouping is deployed correctly.

A process exists for the Field Level and Data Security to copy data between companies. This process can be used to copy the initial READONLY codes, but also maintain a similar Field Level Security Codes and Data Security Codes between companies. This can reduce the data manually maintained when many companies need similar setups. Functions exist to copy data from a production company back to the Easy Security company. This allows for developing new security codes where the data exists and when done deploying them to multiple companies.

Implementing NAV Easy Security

When implementing enhanced security to the level of Segregation of Duties in a larger NAV installation, either during implementation/upgrade or in a stable production system, below is the suggested approach/procedure.

During Go-Live the Quick Security can ensure that changes to code and processes do not interfere with the users work. It allows good security in the setup data by only allowing read for most users, but allows users to do different processing if needed with no additional permissions if code changes are needed. By making some tables or objects "No Access" Payroll, Credit Card Processing, Chart of Accounts and similar tasks can be controlled in a simple way. Quick Security can also be used to remove a few important tables (maybe the ones the auditors require for Segregation of Duties). When those tables are removed with No Access the permission sets provided by Mergetool.com are enough to control security without a manual recording or correction of permissions. This is important for the Go-Live when many ISV solutions could make recording of custom processes necessary using the complete security approach.
Field Level and Data Security are also simple to implement and maintain during a Go-Live. The setup is not impacted when code is changed or processes corrected. This ensures a good security for certain processes or data with minimal work to maintain and correct during a Go-Live.

1. Initial install and training in NAV Easy Security in a test environment. Get familiar with the application and the features available to control security.

2. Implement Quick Security (apply to 90% or more of the users) and Field Level and Data Security for most important tables in production. The Quick Security can be used to remove specific objects like Chart of Accounts or access to tables like Payroll quickly with minimal chance of breaking the security when changing code or doing upgrades. When implementing Field Level and Data Security use as many defaults (blank User ID) as possible that allow a minimum of data to be created and controlled. Data Security can quickly separate records between different department and remove access to important entries in the system like payroll postings and similar.

3. Identify important objects that users should not have access to by default (Object Level Security). Build Permission Groups that matches job descriptions like Customer Service, Warehouse Worker, AP Clerk or similar. Follow the guidelines in the spreadsheet delivered with the NAV Easy Security install folder when breaking down the individual tasks to Permission Sets.

4. Work on specific Permission Sets for the people with least access to the system (fewest tasks). Use the Permission Sets provided by Mergetool.com as a basis and record additional Permission Sets as needed. The Permission Sets provided by Microsoft can be used as a base for Manufacturing or WMS, but do not use Sales, Purchase, Finance and Inventory Permission Sets. They are too broad and do not adhere to Segregation of Duties concepts.

5. Implement a single person with the new security in production by assigning a single Permission Group with multiple Permission Sets. By only applying to a single person the impact on productivity is limited. Selecting a person that is good to work with is important.

6. When security is tested with a single person, the roll-out of the security to the other people with similar tasks has minimal impact on productivity since the Permission Sets have already been tested.

7. Work on creating Permission Sets for the people with a few more tasks and repeat from step 5 when deploying. When only a few more tasks are needed it is easy to test the few extra Permission Sets. When deploying in production the chance of a problem is a lot smaller since a lot is in use already.

8. Continue this approach building permission sets for 60% to 90% of the employees step by step by adding to the Permission Sets already created for other users.

9. When a large portion of the users is using Segregation of Duties level security it is time to look more detailed into Field Level and Data Security. Add more tables and ensure people only have access to the functions and data as needed.

10. Quick Security can still be used for the last portion of the users on a high level of access. Most of the setup tables should still be stable and not require daily changes. Even Controllers and similar users do not need SUPER access. Access to all TableData should be enough for those users.
Following this approach ensures minimal interruption caused by security related issues and still allows a good level of security during Go-Live. Below is a list of estimated times based on our experience.

Training and initial install 8-10 hours.
Implement NAV Easy Security and Quick Security in production database 3-4 hours.
Implement Field Level and Data Security in production 2-3 hours.
Record and test 10 specific task-based Permission Sets 3-4 hours.
Implement and test task-based Permission Sets for one user in Production 2 hours.

The typical process that we see causing delays with implementing security in NAV is not the technical processes in NAV Easy Security but the definition of who needs to do what and what are people allowed to do in NAV. This definition is not related to the technical tool but processes inside the company using NAV that needs to be defined.

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 Permission set. This makes it very hard to use for tables like G/L Entries or similar, where permissions are given from many permission sets.

A Security Filter is normally also user specific, but the setup within a Permission set makes it unavailable by user. This will cause a lot of very similar permission sets to be created based on different Security Filters needed.

Field Level and Data Security supports this in a much better way than what Security Filters can be used for.

Don't Like

Related resources

Download software from Mergetool.com