1. Best Practices for Dynamics NAV Administration and Security
9/10/2018 4:04 PM
Best Practices for Dynamics NAV Administration and Security
Per Mogensen

2. Meet Your Presenter
Per Mogensen
CEO
Mergetool.com
NAVUG ISV Member

3. Description
If you’re like most Dynamics NAV customers your security setup is never quite perfect. We’ll walk through best practices for proper administration, and security setup and maintenance, in and around Dynamics NAV. Be ready to share your challenges and draw on the collective experience as we share "what I would have done differently," and gain insight on the additional tools and resources available in the community.

4. Session Objectives Understand NAV Security model
Best Practices for NAV Security
Typical problems with Security

5. Session Agenda Why is security necessary?
Adding Access Controls to a User
Defining Permission Sets (Roles)
How to design your security
Tips and Tricks

6. Why is security necessary?
Hide data like payroll, recipes, G/L or sales data
Protect data from accidental changes
Ensure data integrity by protecting setup
Segregation of duties
External requirements (SOX)
Auditors

7. Adding Access Controls to a User

8. User Access Control Combines Permission Sets (Roles) with companies
Access to single company or all companies
Permissions always add
Users can have access directly assigned or as part of groups using Active Directory
Best suited for a single company setup with limited security complexity
High level access to NAV should be avoided
NAV 2013 or later always require users to be created in NAV
NAV 2016 and 2017 support groups in NAV
Still create data in the regular tables

9. Login with Windows group
Can be administered directly in Active Directory
Many Windows Groups required when more than a single company
Work fine for low level access, but is a security risk for SUPER or similar access

10. Demonstration Add new User Add Access Controls to the user
Testing on a single computer
Run as a different User
Create Windows Group

11. Defining new Permission Sets (Roles)

12. Permission Sets (Roles)
A set of permissions for data, objects and system functions
Not related to companies only to data and code
Access control under Users combine Permission Sets and Company
Data security possible with Security Filters
No Field Level control

13. What can be secured in NAV
Data (TableData)
Read, insert, modify and delete access
Direct or indirect
indirect access need proper permissions in code
Indirect read enough to calculate FlowFields (except in Queries)
Objects (Tables, Forms/Pages, Reports, Codeunits…)
Execute
Design different object types (only in NAV 2009 and older)
Read, insert, modify and delete
System (Execute)
Tools (Zoom, User administration), Design access (Importing fob, change report…)
NAV 2009 RTC, 2013 and later have limited functions that can be controlled. Only the Zoom is currently controlled

14. Indirect Permission to TableData
Allow users to perform tasks by using the right process
Post documents, apply entries
Permissions added in code
License permissions use Indirect to control editing posted data
Proper coding is required

15. Standard Permission Sets (Roles)
Access to login and more
“BASIC”, “FOUNDATION” and “ALL”
Functional permission sets
“S&R Q/O/I/C/B/R”, “P&P VENDOR, EDIT” and many more
System permission sets
“TOOLS, ZOOM”
High level access
“SUPER”, “SUPER (DATA)”

16. “SUPER” versus “SUPER (DATA)”
“SUPER” can administer users
“SUPER” can design and change objects (classic)
“SUPER (DATA)” and “BASIC”/”FOUNDATION” still have full access to the application
Consider creating other “SUPER” roles
“SUPER (DATA READ)” read-only access to the complete application
“SUPER (TOOLS)” allow access to all tools

17. Demonstration Correct Permission Errors by Caption
Edit Permissions based on existing Permission Sets
Record Permissions in NAV 2017
Create new Permission Sets
“TOOLS, ZOOM”, “SUPER (DATA READ)”

18. How to design your security

19. Different options for security
Traditional NAV security
Allow access to read and change on TableData with Permission Sets
Full Read Access only control change Access
Reduced numbers of TableData needed in Permission Sets
Use Objects and TableData
Many more records needed, but allow higher control

20. Best practices for designing Task based Permission Sets
Focus on a small task in NAV
Make assigning permissions and testing simple
Small chance of breaking all roles when upgrading or adding new customizations
Design Permission Sets based on NAV tasks not user processes
Combine tasks to user level access
Do NOT make a single role for each user
Hard to maintain
Very hard to know if everything is covered
Cannot remove permissions easily without a lot of testing

21. Role Center versus Permissions
Role Center give access to view and is improving usability
Permissions give access to perform tasks
BASIC role in NAV 2013 and later has many permissions to view data
Access to Login/Logout (OK)
Access to execute objects (OK)
Access to read all data for ORDER PROCESSOR (wrong)

22. Controlling the Department Menu
Department menu can be disabled by command line parameter
Not a practical approach in all cases
The Department Menu is part of the source for the search function
Access to TableData or Object allow access
NAV 2015 and later can remove MenuItems
Object Level security is great for control

23. License and User Permissions
User can never exceed the license permissions
Indirect license permissions are used to secure important posting data
Removed when buying 7300 Solution developer as a customer (be careful, security setup is much harder)
MenuSuite remove MenuItems based on license or user permissions
Classic: always removed from MenuSuite
RTC: optional based on setup, different by version, 2015 also include fields and actions removal on pages

24. NAV 2009 versus 2013+ security NAV 2009 NAV 2013 and later
User connect directly to SQL database
User needs access to data in SQL database
Complex setup to allow impersonation for RoleTailored client
NAV and SQL database verify user credentials
NAV 2013 and later
Service user connect to SQL Database
User need NO access to data in SQL database
No requirements to only use SQL database or windows login
NAV Service Tier verify user credentials
No Login/Logout required after security changes
NAV 2009 and 2013 and later
Design access (Classic Client) require access to SQL database
DBOwner for many design functions

25. Common confusion about security
TableData versus Table
Security data and companies
Objects and Read/Insert/Modify/Delete
TableData and Execute
AccessByPermissions
Partner NAV License cannot test Indirect

26. Summary

27. Online Resources Microsoft Developer Network

28. Thank you for attending this session!
Per Mogensen
Mergetool.com
Don’t forget:
Please complete the survey on your mobile conference app, or online at summitemea.com.
Download session materials from the app or on the event website.

29. 9/10/2018 4:04 PM

30. Preferred text layout (no bullets)
9/10/2018 4:04 PM
Preferred text layout (no bullets)
Main topic 1: size 40pt
Size 20pt for the subtopics
Main topic 2: size 40pt
Main topic 3: size 40pt