TechKnowledge Content
Issue
Navision security tips and tricks.
Resolution
Security setup in Navision Financials and Attainis commonly an area of confusion. In addition, the security in its default status from the Demonstration database on the CD needs to be analyzed and discussed to fully prepare for implementing security at a Company site. This document is meant to cover some basic information related to security and provide additional information for some of the common issues that have been reported.
Basics of Navision Attain or Navision FinancialsSecurity
1. Security consists of two main granules: 'User IDs and Passwords' and 'Permissions'. This document will focus primarily on the Permissions granule. For a detailed discussion of the User ID and Password granule, particularly as it relates to the Version 2.60B and later Windows Authentication and Database Authentication issues, see the Additional Resources linked to this Knowledge Base Article.
2. The Permissions granule consists of the Roles (Version 2.60 and later) or Groups (pre-Version 2.60) in the Demonstration database. (Going forward, the termRoles will be used synonymously with Roles or Groups).
The Roles are made up of a pre-established list of Object Types, Numbers, and Level of Access (Read, Insert, Modify, Delete, Execute). Each Level of Access can be set to 'Yes', 'Indirect', or 'No'.If 'Yes' is selected, the user has that level of access directly. For instance, if 'Yes' is entered in the Read field for the object, you can always directly access and Read the information directly. If 'Indirect' is selected, the permission is valid only when used with another object that you have permission for. For example, you cannot create G/L entries directly, but only 'indirectly', using the posting function. If the field is blank, you do not have this permission.
3. BasePermission Roles are based on Object Level Permissions. There are seven Object Typesthat make up thePermissions: Tables, Forms, Reports, Dataports, Codeunits, System, and Tabledata. The first five - Tables, Forms, Reports, Dataports, and Codeunits - are the basic Objects that make up a Navision database. The inclusion of these Object Typesin Permissions is fairly obvious. However, the other two Security Object Typesare less obvious and will be discussed in more detail in the next two sections.
4. The System Object Typeincludes the Menu Option Access in Navision Attain or Financials, such as access to the File | Database options and the Tools drop down options. The System Permissions will control access to the Development areas under Tools, assuming the Customer license provides access to the development area.
Note If the Customer doesn’t have a license for a granule, they will not have access to that area of the system. The license becomes the highest level of control of access to particular areas of Attain or Financials.
In addition, access to Navision Security is controlled through the System permissions. The Edit Drop Down Menu, which includes access to filtering and data entry,is also controlled through System Permissions.
5. The Tabledata Object Typeis controlling access to theinformation and datathat has been entered by the users. The Table Object provides the structure for storing data. The Tabledata is the actual information placed into this storage area. In order to see the data, the user must have access to the Table and the Tabledata.
In conjunction with the Table and Tabledata, a user must also have access to either a Form or a Report to view the data. With the control overaccess to data, you also have control over which Companies can be accessed. This is controlled on the Permissions of the User ID under Roles.
6. Before getting too deep into Permissions, a basic premise must be understood. In order for a User to see information, the User must either have a Form or Report to view information. Forms are the screens and menus to view information on-line (such as a Customer Card or a Setup Menu), while Reports are printed documents. In addition to the actualObjects used to view data(i.e. either the Form or Report), a User must also have access to Execute the Table object and some level of Read access to the Tabledata. If any one of these Object Type combinations is missing (i.e. either Form/Table/TableData or Report/Table/TableData), then a user will not have access to the desired information.
7. In each of the versions of Attain or Financials, the first Role that must be established is 'SUPER'. At least one User IDmust be assigned this Role and the first User set up will have to be assigned SUPER. Upon review of the SUPER Role permissions, you will see that all seven Object Types listed above are assigned. Each Object Type is given an Object ID '0' and Level of Access set to Yes for allof the Object Types. The '0' in the ObjectID fieldrepresents that all objects within that Object Type are assigned. The 'Yes' in the level of access means that the SUPERUSER can Read, Insert, Modify, Delete, and Execute on all Objects. Therefore, as long as the Object is included in the license, the user will be able to fully access that area.
In addition to the minimum of one SUPER User at the client site, itmay be desirablethat the NSC set up their Company established SUPER User. This insures that the NSC can access everything in the database just in case the SUPER User at the Customer site leaves and fails to inform others of this information. Otherwise, override procedures would need to be followed to access the database. TheNavision Break inAuthorizationform is included in all of our manualsor youmay contact Navision Support for the form. Of course, please make sure that you discuss setting up the Solution Center IDand Password with the Customer to make sure that they give approval to this.
8. For any user that is not assigned the SUPER Role, the Role called ALL should be assigned. The ALLRole has basic object access that every user must possess. Some level of Read access to the Setup Tables and Tabledata and other System areas are required for every Navision user, so the ALLRole is meant to provide this basic access. However, there will be some changes that may need to be made to the ALLRole before fully applying that Role to everyone. In particular, the ALLRole has a line established for 'Form 0' with Execute rights set to Yes.
The issue is that, in combination with the other Roles that give rights to POST transactions, such as 'R-Q/O/I/C, POST' and 'P-Q/O/I/C, POST', a significantissue in security for some Customerswill exist. Particularly, out of the box, these 'POST' Roles require a line for TableData Object ID 17, which is the G/L entry Table, and Read access set to 'YES'. This permission access, in combination with the ALL Role line of Form 0 and Table 0, gives this user full access to review the G/L Entry Table and see General Ledger transactions on screen, particularly detailed Income and Expense transactions. This may be undesirable for some Customers and will need to be addressed through some workarounds provided below.
To deal with the issue of G/L entry access, you can do one of two things. First, you may need to create a new 'ALL' Role called 'ALL-NOFORMS'. You will then use the Windows copy function and copy the Permissions lines from the 'ALL'Role and paste them into the 'ALL-NOFORMS' Role. You will then delete the line for Form 0 - Execute 'Yes' from the ALL-NOFORMS. You will then create new Roles for every Functional Area giving the necessary permissions to the individual Forms required for that Functional Area.
The second change that the user may want to consider is to modify Codeunit 12 Permissions related to reading the G/L Entry Table. To do this, you will:
A.Access Tools |Object Designer.
B.Select Codeunit 12.
C. Select the Design button.
D. Select the Properties icon.
E. Click in the Value field of the Permissions line.
F. Select the ellipse button (...).
G. On the line for Object ID 17, check the 'Read Permission' box.
Once this is completed, a user can select any of the 'POST' Roles listed above and change the 'Yes' option in Read Permission for Table 17 – G/L Entry Table data – to 'Indirect'. By completing this change, a user will be allowed to Post an Invoice and have the posting process create the new entry in the General Ledger Entry Table. However, by changing the Read Permission to Indirect, the user will not have access to the General Ledger Entry Table from a drill down in the Chart of Accounts Net Change field. Note that the second change will work only on the Native option and not on the SQL Server option.
Additional resources
1. Refer to Supplemental Information for Help Document #12462 - Navision Security Tips and Tricks. To download this document, visit the following Microsoft Web site:
https://mbs.microsoft.com/downloads/customer/tk28331.doc2. See Knowledge Base article 858242- NF 2.60 and Windows Authentication on the SQL Server Option.
3. See Knowledge Base article 874362 - How to set up Payroll security
4. See Knowledge Base article
858244- Difference between the User ID and Passwords granule and the User Permissions granule in Microsoft Dynamics NAV
5. See Knowledge Base article 858921- Windows Logins with Financials 2.60.
This article was TechKnowledge Document ID:28331
