Presentation is loading. Please wait.

Presentation is loading. Please wait.

Best Practices for Dynamics NAV Administration and Security

Similar presentations


Presentation on theme: "Best Practices for Dynamics NAV Administration and Security"— Presentation transcript:

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


Download ppt "Best Practices for Dynamics NAV Administration and Security"

Similar presentations


Ads by Google