NAV Security and Security Filters – Practical Observations
Over the years I have implemented security for Microsoft Dynamics NAV at a number of clients. That has given me the opportunity to see the battle between security needs and wants play out in various ways. Here are a few observations.
Security Groups:
I find that using Windows Security Groups saves a lot of time. Assign your users to Active Directory Security Groups with names such as “NAV-Sales”, then create a NAV user associated with that name. Set the “License Type” field on the User Card to - “Windows Group” and now you have a single place to set up security for the Sales group. In this way you are not assigning long lists of specific permission sets to individuals.
The fewer groups that you divide your users into, the better chance you have of maintaining security a year after implementation. The effort required to maintain security increases faster than the level of complexity of a NAV security setup. Take every opportunity to simplify even if it means giving people permissions to parts of the system that they may not use, but that do not constitute a threat to your data. The best time to do all of this is during implementation, in that way you are irritating people who are already irritated by a new system.
Changes:
When adding new permissions or making existing ones more generous in a stock permission set a simple way to document your additions is to create new permission sets for extra permissions e.g. “G/L-ACCOUNT-XTRA”. By adding a permissions set to a windows group’s permissions it is clear what extra security has been granted and it will still be clear next year.
Users:
Accentuate the positive - it helps to remind users that you are not targeting them (the typical trusted employee) out of functionality; you are locking out next year’s mistaken new hire that none of us know yet.
Field Level Security on the cheap: (hide some vendors from me)
The more granular that security becomes, the more difficult it is to maintain and the more likely that it will fail miserably. In spite of this, NAV offers Security Filters that can provide some powerful functionality. Be warned that Security filters are the first step on the road to unmanageable security, but sometimes they really are worthwhile.
Example: purchasing is performed in NAV, employees are also listed as NAV vendors. Most users should not have access to the employee type vendor records or their associated documents.
How to:
Typically a permission record gives a level of access to an object that is the same for every record. By populating the Security filter field, it is possible to make the permission only valid for a subset of records.
We are going to look at Permission Sets and the Permissions under them. The Security Filter will be set on an individual object permission.
1) Search for “Permission Sets” and Click the “Permissions” Action for any Permission Set.
2) Select Advanced Filter and just filter on Object ID – in this example the Vendor Table (23)
Now we see all the occurrences of the Vendor Table. There is a choice between deleting these particular entries and providing Vendor security with our own permission sets, or adding Security Filters to them. If the only users that are going to see the FOREIGN vendors are super users, then we can add Security filters to these permissions. Let’s make that our example.
3) Click on the AssistEdit Button of the Security Filter field.
Now you may enter a Security filter. Note that no wild cards are allowed here. In this case “Vendor Posting Group<>FOREIGN” will prevent the user from having any privileges from a permission record for vendors with the Posting Group “FOREIGN”. Be careful not to exclude permissions for blank Vendor Posting Groups, or a user will not be able to open a new Vendor Record. Vendor Lists that the user is shown, should be filtered to exclude these FOREIGN vendors, or errors will occur. Obviously, Vendor Ledger Entries become a candidate for this treatment depending on the specific security result desired. There are code changes that can be made such as the use of SETPERMISSIONFILTER. This can filter the records an object (typically a page) can see and avoid permissions errors.
Summary:
Keep It Simple - there is no better advice. Security systems should be designed for the future to protect your environment from threats that are as yet unknown. Unnecessary complexity should be avoided wherever possible to avoid unintentional security gaps being created.
A typical administrator will be tempted to add a permission every time a user gets an error. At the very least by adding that permission into an “Extras” permission set these changes may be reviewed later.
Under the terms of this license, you are authorized to share and redistribute the content across various mediums, subject to adherence to the specified conditions: you must provide proper attribution to Stoneridge as the original creator in a manner that does not imply their endorsement of your use, the material is to be utilized solely for non-commercial purposes, and alterations, modifications, or derivative works based on the original material are strictly prohibited.
Responsibility rests with the licensee to ensure that their use of the material does not violate any other rights.