Data Security in Microsoft Dynamics NAV

Introduction

The Microsoft Dynamics NAV security system allows you to control which objects or tables a user can access within each database. You can specify the type of access that each user has to these objects and tables, whether they are able to read, modify, or enter data.

You can specify which records are stored in the tables that each user is allowed to access. This means that permissions can be allocated at both the table level and the record level.

The security system contains information about the permissions that have been granted to each user who can access a particular database.

This information includes the roles that the users have been assigned, as well as any permission that they have been granted to individual users.

There are four different levels of security:

• Database
• Company
• Object
• Record

Graphically, these can be represented as the layers, where the central layer is the records in the database.

Database-level Security

After you start Microsoft Dynamics NAV and attempt to open the database, your credentials are checked. If you have not been granted permission to open the database then the database is not listed in the Available Databases window.

Microsoft Dynamics NAV administrators should have db_owner database role for all relevant Microsoft Dynamics NAV databases.

To grant the db_owner role on a Microsoft Dynamics NAV database in SQL Server Management Studio, follow these steps:

1. Select the Microsoft Dynamics NAV database, then Security, then right-click Users and choose New User.
2. Choose the button at the right of the Login Name field to open the Select Login dialog box.
3. Choose the Browse button, select the check box for the relevant Login, and then choose the OK button.
4. Choose the OK button to exit the Select Login dialog box.
5. Enter a User name for the user. This can be the same as the login name.
6. In the Database User - New dialog box, under Select a Page, choose In the Database role membership.
7. Select the db_owner check box.
8. Choose the OK button to exit the Database User - New dialog box.

Company-level Security

After you have gained access to the database, you can open the company that you want to work with.

Use the Microsoft Dynamics NAV Windows client to open a company. The Select Company window lists all of the companies that have been created in the current database and that you have been given permission to access. If there are companies in the database that you have not been given permissions to access, you will not be able to see them in this window.

A Microsoft Dynamics NAV database can contain several companies. Each company can use its own tables and can also share tables with other companies.

When you assign a permission set to a user, you can specify a company to restrict the user’s access for that permission set to that specific company.

Menu Path: CRONUS India Ltd./Departments/Administration/IT Administration/General/Users

Object-level Security

Object-level security is the set of permissions on Microsoft Dynamics NAV objects that constitute a permission set. Permission sets determine the access that users have and the tasks that users can perform on objects in the database.

You can define permissions for all types of objects in a Microsoft Dynamics NAV database.

Object Type	Description
Table Data	The actual data that is stored in the tables.
Table	The tables themselves.
Pages	The pages that are used to view and enter data.
Report	The reports that are used to present the data.
Codeunit	The codeunits that are used in the database.
XMLport	The XMLports that are used to import and export data.
MenuSuite	The object that contains the menus that are displayed in the navigation pane.
Query	The object that you use to specify a dataset from the database.
System	The system tables in the database that allow the user to make backups, change license files, and so on.

The various permission sets that exist in Microsoft Dynamics NAV determine the actions that you can perform on these objects.

Permissions on Objects

Permission	Description
Read	You can read this object.
Insert	You can insert data into this object.
Modify	You can modify data in this object.
Delete	You can delete data from this object.
Execute	You can run this object.

If you have been granted permission to read a page, then you can open the page and view the data that it displays. If, however, you do not have write permission, you are not allowed to enter data into this page.

Sometimes, when you open a page it displays information from several tables. To access this page, you must have permission to view all the data displayed by the page. You might not have permission to read directly from all the tables that the page uses. In this case, you must have indirect permission to read from the tables in question. Having indirect permission to a table means that you cannot open the table and read from it but can only view the data it contains indirectly through another object, such as a page or report, that you have direct permission to access.

Microsoft Dynamics NAV has a number of standard predefined security permission sets. You can use these permission sets as defined or you can change a permission sets to suit your particular needs. You can also create your own permission sets and assign them the permissions that you want.

Record-level Security

Record-level security lets you limit the access that a user has to the data in a table.

You can implement record-level security in Microsoft Dynamics NAV by creating security filters on table data. A security filter describes a set of records in a table that a user has permission to access. You can specify, for example, that a user can only read the records that contain information about a particular customer. This means that the user cannot access the records that contain information about other customers.

To set a security filter In the Search box, enter Permission Sets, and then choose the related link. On the Permission Sets page, select the permission set to which you want to add a security filter, and then choose Permissions. On the Permissions page, on the row for the table data to which you want to add a security filter, in the Security Filter column, choose the AssistEdit button. The Table Filter page opens. In the Table Filter page, in the Field Number column, select the field on which you want to limit a user's access. For example, if you want to create a security filter so that a user can view only sales with a specific customer posting group, then choose the field number for the Customer Posting Group field. The Field Caption column in the Table Filter page is filled in automatically after you select the field number. In the Field Filter column, enter the value of field that you want to use to limit access. For example, to limit a user's access to only domestic customer’s sales, enter DOMESTIC, which is the customer posting group for domestic customers, in the Field Filter column. Similarly we have added security filter for Location Code. Finally, the particular user is restricted to access only the customers of Domestic (Customer Posting Group = DOMESTIC) and BLUE, YELLOW (Location Code = BLUE & YELLOW) locations. Customer List page of user shows only the customer related to him. When the user is creating sales order, even the Customer List window will show only the related customers since security filter has been applied at customer table itself. Similarly for Location list. If the user is running a report, security filters are applied in the report filter page and the user can’t see the records of restricted customer/location. Note

Record level security filters do not support wildcard characters. This means that you cannot use * and ? in the filters. You can use the other symbols, delimiters and, operators, such as, <, >, |, &, .., and =. If you do not enter an operator, then the default operator = is used.

Security filters support Unicode characters. The maximum length of a security filter is 504 characters, which includes all of the delimiters, symbols, and operators.

When multiple permission sets that refer to the same table data are assigned to a user, they are combined so that the least restrictive filter is used. You should not repeat a table in multiple permission sets if you plan to combine those permissions sets for one user.