BEST PRACTICES FOR DYNAMICS NAV ADMINISTRATION AND SECURITY Per Mogensen

#NAVUGCongress16 We will take a relaxed approach and walk through our experts' best practices for proper administration, and security setup and maintenance, in and around Dynamics NAV. 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. DESCRIPTION

#NAVUGCongress16 What is the difference between security and usability Adding Access Controls to a User Defining new Permission Sets (Roles) How to design your security AGENDA 3

#NAVUGCongress16 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 WHY IS SECURITY NECESSARY?

#NAVUGCongress16 A DDING A CCESS C ONTROLS TO A U SER 5

#NAVUGCongress16 Combines Roles/Permission Sets 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 High level access to NAV should be avoided NAV 2013 or later require users to be created in NAV NAV 2016 support groups in NAV Still create data in the regular tables USER ACCESS CONTROL

#NAVUGCongress16 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 LOGIN WITH WINDOWS GROUP

#NAVUGCongress16 Add new User Add Access Controls to the user Testing on a single computer Run as a different User Create Windows Group DEMONSTRATION 8

#NAVUGCongress16 D EFINING NEW P ERMISSION S ETS (R OLES ) 9

#NAVUGCongress16 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 PERMISSION SETS (ROLES)

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

#NAVUGCongress16 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 INDIRECT PERMISSION TO TABLEDATA 12

#NAVUGCongress16 Access to login and more ALL/BASIC/FOUNDATION Functional permission sets S&R Q/O/I/C/B/R System permission sets TOOLS, ZOOM High level access SUPER, SUPER (DATA) STANDARD PERMISSION SETS (ROLES)

#NAVUGCongress16 “SUPER” can administer users “SUPER” can design and change objects “SUPER” can run tables from the designer “SUPER (DATA)” and “BASIC” still have full access to the application Consider creating other “SUPER” roles “SUPER (READ)” read-only access to the complete application “SUPER (TOOLS)” allow access to all tools “SUPER” VERSUS “SUPER (DATA)”

#NAVUGCongress16 Correct Permission Errors Edit Permissions based on existing Permission Sets Record Permissions in NAV 2016 Create new Permission Sets TOOLS, ZOOM, SUPER READ DEMONSTRATION 15

#NAVUGCongress16 H OW TO DESIGN YOUR SECURITY 16

#NAVUGCongress16 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 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 BEST PRACTICES FOR DESIGNING ROLES

#NAVUGCongress16 Role Center give access to view and is improving usability Permissions give access to perform tasks BASIC role in NAV 2013 and later has too many permissions to view data Access to Login/Logout (OK) Access to execute objects (OK) Access to read all data for ORDER PROCESSOR (wrong) ROLE CENTER VERSUS PERMISSIONS

#NAVUGCongress16 NAV 2009 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 and security functions (2009 only) NAV 2009 VERSUS SECURITY

#NAVUGCongress16 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 LICENSE AND USER PERMISSIONS

#NAVUGCongress16 TableData versus Table Security data and companies Objects and Read/Insert/Modify/Delete TableData and Execute COMMON CONFUSION ABOUT SECURITY

#NAVUGCongress16 S UMMARY 22

#NAVUGCongress16 Permission Set (Role) spreadsheet S zip REFERENCES 23

#NAVUGCongress16 Reminders: Please download the session slides from the NAVUG Congress Community or through the Congress App Please visit our Dynamics NAV help desk Monday evening in the Expo Please complete your session survey in the Congress App 24 THANK YOU FOR ATTENDING