USER MANAGEMENT IN APPSYNC

Transcription

1 USER MANAGEMENT IN APPSYNC ABSTRACT This white paper discusses and provides guidelines to understand how to manage different user roles, and the configuration of how AppSync behaves with access control capabilities (ACLs); for the different applications supported by AppSync. User access roles and ACLs are explained in detail. February 2018 WHITE PAPER

2 The information in this publication is provided as is. Dell Inc. makes no representations or warranties of any kind with respect to the information in this publication, and specifically disclaims implied warranties of merchantability or fitness for a particular purpose. Use, copying, and distribution of any software described in this publication requires an applicable software license. Copyright 2016 Dell Inc. or its subsidiaries. All Rights Reserved. Dell, EMC, and other trademarks are trademarks of Dell Inc. or its subsidiaries. Other trademarks may be the property of their respective owners. Published in the USA 02/2018, White Paper, H16946 Dell EMC believes the information in this document is accurate as of its publication date. The information is subject to change without notice. 2

3 TABLE OF CONTENTS EXECUTIVE SUMMARY...5 Audience... 5 Introduction... 5 Using the Guidelines... 5 Terms and Definitions... 6 ARCHITECTURE AND REQUIREMENTS...6 AppSync Architecture... 6 AppSync Prerequisites... 6 USER MANAGEMENT...7 Two Types of Users... 7 Roles and Permissions... 7 How to register an LDAP server within AppSync... 9 ADDING AN LDAP USER IN APPSYNC Troubleshooting INTRODUCTION TO APPSYNC ACCESS CONTROL Access Control Overview Access Control User Roles and Permissions CONSOLE VIEW CHANGES WHEN ACLS ARE ENABLED Dashboard Views Service Plan Views Repurposing Views Copy Management Views ACL BEHAVIOR WITH APPLICATIONS AND DATABASES ACL Behavior with SQL Server Databases ACL behavior with Exchange ACL Behavior with Oracle Databases ACL Behavior with VMware Datastores APPLY AN ACCESS CONTROL LIST (ACL) TO AN APPLICATION OBJECT Procedure Results

4 CONCLUSION REFERENCES

5 EXECUTIVE SUMMARY This document provides insight into user management, their roles, and the access controls (ACLs) available for each application that is supported by AppSync. This document also provides technical information about how to integrated with Windows Active Directory, including the configuration and environmental caveats which should be taken into consideration when using Active Directory with AppSync. AUDIENCE This white paper is intended for application and/or storage administrators who are currently administering AppSync in their environment, Dell EMC internal field personnel, as well as partners who assist customers with deploying AppSync. INTRODUCTION Dell EMC AppSync is software that enables Integrated Copy Data Management (icdm) with Dell EMC's primary storage systems. AppSync simplifies and automates the process of generating and consuming copies of production data. By abstracting the underlying storage and replication technologies, and through deep application integration, AppSync empowers application owners to satisfy copy demand for operational recovery and data repurposing. In turn, storage administrators need only be concerned with initial setup and policy management, resulting in an agile, frictionless environment. AppSync automatically discovers supported applications, learns their layout structure, and maps them through the virtualization layer to the underlying storage devices. AppSync then orchestrates all the activities required from copy creation and validation, through mounting at the target host, and recovering the application. Supported workflows also include refresh, expire, and restore operations. USING THE GUIDELINES The information and guidelines described in this document have been provided by the AppSync Engineering group. This information is supplemental, and should be used in conjunction with other AppSync documentation, including the AppSync User and Administration Guide, the AppSync Installation and Configuration Guide, and the version specific AppSync Release Notes. AppSync s terms which are seen directly within the user interface (UI) are bolded in blue. This provides a direct link to what is seen within the user console, offering clearer readability. For example, within the user interface, there is a menu called Settings where you can click Storage Infrastructure which provides a wizard to add storage arrays, as seen in Figure 1 - AppSync Console UI. The words in blue are seen verbatim. Figure 1 - AppSync Console UI 5

6 TERMS AND DEFINITIONS AppSync uses terms that may also be used commonly in the industry, which may have a slightly different meaning, or perhaps a very specific, versus general meaning. The following terms which are defined below, should help provide guidance. Local User - Local system users LDAP Lightweight Directory Access Protocol LDAPS - Lightweight Directory Access Protocol over SSL (Secured) Active Directory Windows proprietary software for directory and domain services ARCHITECTURE AND REQUIREMENTS APPSYNC ARCHITECTURE A typical AppSync architecture has three major components including the AppSync server, the host plug-in software, and the AppSync console. The AppSync server software Residing on a Windows virtual or physical system, and controls workflow activities, user management, manages alerting, monitoring, and stores the information within an internal PostgreSQL database. You can set up AppSync to have multiple users. Each user can be assigned one or more roles that correspond to their responsibilities and requirements. You can create users that are local to AppSync, and optionally add Active Directory users. The host plug-in A light-weight software installed on all source, and any mount host, providing AppSync with the ability to integrate with the operating system and optional applications, such as Microsoft Exchange and SQL, Oracle, or operating system file systems. In the case of VMware datastore replication, there is no host plug-in, as AppSync communicates directly with the vcenter server. The AppSync console A web-based interface used to manage AppSync. The console is generally used directly on the end user s laptop, or on another server, requiring only a supported browser environment. Users login to the AppSync console to manage and use various functionalities of AppSync. Alternatively, VSI, REST API, and CLI can be used to manage the environment. NOTE: THE APPSYNC CONSOLE IS COMPATIBLE WITH GOOGLE CHROME, INTERNET EXPLORER, AND MOZILLA FIREFOX. ADOBE FLASH PLAYER VERSION 10.2 OR HIGHER IS REQUIRED TO RUN THE APPSYNC CONSOLE. NOTE: FOR MORE INFORMATION ABOUT EACH COMPONENT, REFER TO THE APPSYNC INSTALLATION AND CONFIGURATION GUIDE, THE APPSYNC USER AND ADMINISTRATION GUIDE, AND TO VALIDATE SUPPORTED VERSIONS, PLEASE REFER TO THE LATEST APPSYNC SUPPORT MATRIX. APPSYNC PREREQUISITES The AppSync server software is assumed to be installed according to the AppSync Installation and Configuration Guide. Microsoft Windows Active Directory server host s credentials are required to configure LDAP or LDAPS with AppSync. 6

7 If using OpenLDAP, rather than Microsoft s Active Directory LDAP, which is an open source implementation of the Lightweight Directory Access Protocol, the same procedure applies. Please ensure the correct pre-requisite steps are followed for setting up OpenLDAP. These steps are not discussed in this white paper, and can be found available on the general internet. A user is created who can manage AppSync with appropriate access rights and credentials to configure/add Active Directory user in the AppSync. This user is typically the admin user who was initially configured during the installation process, who has the Security Administrator role. If configuring LDAPS, then a valid certificate issued by an AD certificate Authority is required. USER MANAGEMENT TWO TYPES OF USERS 1. Local Users - These are local users created by anyone with the Security Administrator role. 2. LDAP Users - These are the users created from an Active Directory catalog which communicates using the LDAP or LDAPS protocol. AppSync uses Common Security Toolkit (CST) for user authentication and management. CST is designed to provide a common set of security-related services including authentication, role management, accountability, cryptography, key management and secret protection. When you register a local user with AppSync, its user name and password get stored with the CST component. This component is bundled with the AppSync installation, which provides the authentication. The passwords are stored in a one way, irreversible, hashed format. When you register an Active Directory user, only the user name is stored with the CST component, while the password is validated against the LDAP server for each login attempt. Each of the local and/or LDAP users can be associated with multiple Roles as defined by AppSync, to manage various AppSync operations. These roles are accumulative. ROLES AND PERMISSIONS Role Security Administrator Permissions Manages user s access to AppSync 1. Configure LDAP servers 2. Add users 3. Modify users, including changing other users' passwords 4. Remove users 5. Add roles to users 6. Remove roles from users 7. Assign an ACL (Access Control List) Manager role to a Data Administrator 7

8 Resource Administrator Manages hosts, storage systems, servers 1. Add, modify or remove any type of storage array 2. Add, modify or remove a RecoverPoint site 3. Add a host; requires host credentials 4. Modify or delete a host 5. Add a vcenter Server 6. Modify or delete a vcenter Server 7. Obtain and upload licenses 8. Modify server settings Service Plan Administrator Customizes and runs service plans used for data protection 1. Add service plan 2. Modify service plan (except overrides and selection of DAG member server and DAG copy to be protected) 3. Delete a service plan 4. Run a service plan Data Administrator Manages the protection and recovery of data. 1. Configure applications on a host 2. Discover application databases on a host 3. Discover VMware datastores 4. Subscribe data to a service plan 5. Remove applications from a service plan subscription 6. Specify override settings applications subscribed to a service plan 7. Select DAG member server and copy for protection 8. Repurpose a copy 9. Create a copy on demand 10. Run a service plan on demand 11. Mount a copy on demand 12. Restore a copy on demand ACL (Access Control List) Manager 1. Assign an application to an ACL 2. Grant and revoke users from an ACL 3. Add new users to the ACL of a child. 4. View applications under the ACL 5. View report data for applications under the ACL 6. Security Administrator enables the ACL Manager role to a Data Administrator 8

9 HOW TO REGISTER AN LDAP SERVER WITHIN APPSYNC In the AppSync console, go to Settings -> User Administration. Choose the LDAP Settings tab, as seen in Figure 2 - LDAP Settings, and fill in all the details required. The below table describes the details of each field. Table 1. SETTINGS Authority Name LDAP Server Port Use LDAPS Protocol Distinguished Name Password Certificate File User ID Attribute User Object Class User Search Path Figure 2 - LDAP Settings Specific settings are required to set up access to LDAP. DESCRIPTION Fully-qualified domain name that represents the root of the LDAP directory tree. Use a periodseparated format similar to that used in DNS. This is translated to X.509 format. For example, ldap.emc.com is translated to the X.509 format dc=ldap,dc=emc,dc=com. IP address, hostname, or FQDN of the primary directory server to use for authentication. The value you specify depends on the format of the subject field entry in the directory server's certificate; typically this requires a hostname. One value only. The AppSync server should be able to ping the LDAP server Port number used by the directory server for LDAP communications. By default, LDAP uses port 389 and LDAPS uses port 636. Select this option to use LDAPS for securing communication provided LDAPS on LDAP Sever is configured. Indicates the administrator user who has privileges to connect to LDAP for authentication. The DN can be expressed in Down-Level Logon Name, User Principle Name, or RDN format. For example, if the fully qualified domain name is mycompany.com, the DN can be expressed as, mycompany\administrator, administrator@mycompany.com or cn=administrator,cn=users,dc=mycompany,dc=com. Specify the account's password (the bind credential used to authenticate the account). The absolute path of the file containing the SSL certificate issued to the AD server from Certificate Authority, required to enable SSL communications to the AD server The certificate has to be copied by the user to the AppSync server. The subject filed entry in the certificate should match the LDAP server name. Name of the LDAP attribute whose value indicates the user ID (for example, samaccountname). LDAP object class for users (for example, user in Active Directory). Path to search for users on the directory server, for example, cn=users, dc=mycompany, dc=com 9

10 AppSync can communicate with the LDAP server using either secured or unsecured ports. As mentioned in the above table, TCP port 389 is an unsecured LDAP communication port, whereas port 636 is a secured LDAPS port which communicates over SSL. The certificate file must reference a PEM formatted file, which includes the following: End-entity or leaf certificate for the LDAP server All intermediate and root CA certificates required to build a full chain for the LDAP server, if they are not sent from the server during the SSL/TLS handshake. NOTE: TYPICALLY, SERVERS REPLY WITH THE END-ENTITY AND ALL INTERMEDIATE CA CERTIFICATES, BUT MIGHT NOT SEND THE ROOT CA CERTIFICATE. POPULATE THE PEM FILE WITH THE ENTIRE CERTIFICATE CHAIN, INCLUDING THE CA CERTIFICATE. AppSync Integration with LDAP AppSync internally uses Dell EMC s RSA Common Security Tool (CST) kit to communicate with Active Directory. When the AppSync server is installed, a folder named cst is also created under: <Install Directory>:\EMC\AppSync\. This folder contains the required binaries which will communicate with Active Directory. AppSync uses Java Native Interface (JNI) to communicate with the CST. When an Active Directory server is registered within AppSync, it sends requests to Active Directory via CST and stores the user entered details, except for passwords, in a config.xml file which is stored in: <Install Dir>:\EMC\AppSync\cst\xml\Config.xml. The password is stored in an irreversible hashed format. If the authentication is successful, then AD is registered successfully with AppSync. NOTE: ONCE THE CONFIGURATION IS COMPLETE, EXPORT THE CERTIFICATE AND THEN CONVERT IT INTO PEM FORMAT (THIS IS THE FORMAT WHICH THE CST KIT RECOGNIZES, AND USES, TO ESTABLISH A SECURED CONNECTION WITH ACTIVE DIRECTORY). How to export a Windows Active Directory certificate: Once the certificate is obtained from the CA, export the certificate with PKCS7 format from Windows Active Directory, which will include all of the certificates in the chain, and convert it into pem format. In the case of Windows, choose to export the certificate. Figure 3 - Certificate Export Wizard Once the certificate is exported, use the following openssl command to convert the certificate to pem format. Openssl has to be installed by the customer in a Windows environment. 10

11 openssl pkcs7 -print_certs -inform der -in <certificate name>.p7b -out <certificate name>.pem ADDING AN LDAP USER IN APPSYNC A user with the Security Administrator role, is required to enter an Active Directory LDAP user name, and then choose which AppSync roles to assign to the new user. The description of each role is described later in this white paper. AppSync stores the LDAP username, and not the password. AppSync provides the option to look up the user in Active Directory, before adding them to AppSync, confirming the user exists. When clicking on Look Up, AppSync, via CST, verifies the user exists in LDAP with the privileges entered in the distinguished name LDAP setting page. If the user is not found, check if the user search path entered is correct. Also check the privileges of the user entered in the LDAP settings page. Figure 4 - Using the LDAP Look Up Feature Figure 5 - LDAP User Added TROUBLESHOOTING 1. Verify the subject in the certificate and LDAP server name is the same. 2. Verify the right user name, and not user ID or other attributes along with the user name, are entered. 3. Verify the LDAP server is reachable with the same name from the AppSync server. 4. Verify if the user entered in LDAP settings page, has sufficient privileges. 5. If there are any LDAP management failure within AppSync, then the CST logs are required for debugging the issue. Follow the below steps to get the CST logs. 11

12 5.1 Set CST_TRACE system environmental to point to a text file, and then reproduce the issue to collect the logs. Example: Set environment variable CST_TRACE=C:\log.txt NOTE: THE APPSYNC SERVER SERVICE AND APPSYNC SECURITY SERVICE SHOULD BE RESTARTED AFTER MAKING THIS CHANGE. Figure 6 - Setting CST_TRACE Environment Variable INTRODUCTION TO APPSYNC ACCESS CONTROL This section provides an overview of the settings available to ensure secure operation of the product, security settings are split into the following categories: Access control setting describes settings available to limit access by end-user or by external product components. Communication security settings describe settings related to security for the product network communications. Data security settings describe settings available to ensure protection of the data handled by the product. Log settings describe settings related to the logging of events. Security alert system settings describe settings related to sending security alerts and notifications for the security-related events. Other security considerations describe security settings that may not fall in one of the previous sections. ACCESS CONTROL OVERVIEW This section demonstrates how to use Access Controls to manage user access with all applications in AppSync, by understanding how to use an Access Control list (ACL) to restrict user-access to specific application objects. When creating an ACL for an application, and then assigning users to the access list, those users gain access to the application in AppSync, at the same time, other users are restricted. A user then can subscribe the application to a service plan and perform various operations, such as view, generate, mount, unmount, and restore copies. 12

13 Some applications have a parent/child relationship. For example, an SQL Server Instance (parent) and SQL Server databases (children). Child application objects inherit any ACL applied to the parent. ACCESS CONTROL USER ROLES AND PERMISSIONS This section will review ACL user roles and permissions, including enabling users, restrictions of roles, and parent/child ACL user rules. Except for the Service Plan Administrators and Data Administrator roles who have an ACL Manager Role assigned by a Security Administrator, only users who are listed on the ACL can access or view the application in the AppSync console. Users with ACL access do not receive references to the application, such as events and alerts. The following list describes the roles and permissions for ACLs in AppSync: A Security Administrator enables the ACL Manager role to a Data Administrator Data Administrators that are designated as ACL Managers can grant and revoke users from an ACL, and assigns ACLs on application objects. Resource Administrators and Security Administrators cannot access applications under ACL control. They can, however, view report data generated from applications that they can access. ACLs do not affect Service Plan Administrators, who can perform all operations allowed by this role. Child application objects inherit any ACL applied to the parent. Review the following behavior of the parent/child ACL model: o o o When children objects are discovered, they inherit the parent ACL. Users can be added to the ACL of a specific child A child user can see the parent even if that user is not on the parent ACL. The child user cannot perform any operations on the parent other than navigate (read-only access). Only Data Administrators who have the ACL Manager role have authority to grant or revoke ACLs. Data Administrators without ACL Manager privileges can only view a service plan for which applications that they can access Roles are cumulative gaining all entitlements for each role to which the user belongs. CONSOLE VIEW CHANGES WHEN ACLS ARE ENABLED This section demonstrates how the view of the AppSync console changes when ACL lists are added to an application. After a Data Administrator with ACL Manager privileges applies an ACL to an application, the Copy Management page of the console displays an ACL Settings button. Only Data Administrators with ACL Management permissions can see this button. They are the only users who can create and manage the ACL. After an ACL is created for an application, access to the application on the console moves from all users to the users designated in the ACL. Users who could view the application beforehand, can no longer view it in their console, unless explicitly granted permissions. DASHBOARD VIEWS The console Dashboard is the landing page for protected applications. It reflects data generated from service plan runs against these applications. Consequently, the information displayed on the dashboard derives only from applications to which a user has access. The following table lists content that can be viewed on the Dashboard, depending on the role. 13

14 Table 2. Role Dashboard View after ACLs are Applied Dashboard view Security Administrator Resource Administrator Service Plan Administrator Data Administrator plus ACL Manager role Data Administrator No report data or alerts for any application under ACL control. Same view as the Security Administrator. View all report data and all alerts. ACLs do not affect the role. Same view as the Service Plan Administrator role. The accessible applications display only report calculations, alerts, and alert events. SERVICE PLAN VIEWS Data Administrators can view the service plan console and navigate its tabs. If a user is only a Data Administrator, the system does not display the Events tab, however, Data Administrators with ACL Manager capability can see the events tab. Table 3. Tab User Views from the Service Plan Console Affect Subscriptions Copies The user only sees the applications they are authorized for. The users only sees those copies for applications which they are authorized for. REPURPOSING VIEWS Users can view applications being repurposed only if they have access to those applications. COPY MANAGEMENT VIEWS The following table lists possible operations that a Data Administrator can perform from the Copy Management tab of the console. Table 4. Data Admin Copy Management operations Operation Abbreviation Description Run/Subscribe/Unsubscribe SUB Perform these copy operations Mount MNT Mount copy Unmount UMNT Unmount copy: Occasionally, A user cannot execute unmount operations when a previously run service plan protects applications to which the user does not have access. This scenario triggers a 403 unauthorized exception. Expire EXP Expire copy: removes it from the console Restore RST Restore copy: Restore operations can also result in a 403 unauthorized exception when users run a restore operation that 14

15 affects other applications that user cannot access. Repurpose RPP Repurpose the copy Discover DSC Discover storage Set Alerts ALTS Set reporting alerts View/Navigate VIEW View and navigate in the console ACL BEHAVIOR WITH APPLICATIONS AND DATABASES ACL behaviors can vary depending on the application database, file system or datastore. ACL behavior with the following applications are discussed: SQL Server Databases Exchange Oracle Databases VMware Datastores File Systems ACL BEHAVIOR WITH SQL SERVER DATABASES Learn the ACL behavior when used with SQL Server databases, including parent/child access and allowed operations. SQL Server has a unique user database node that allows ACLs. This affects the user only if that user has access to a contained database that is also covered by a subscription to the user database. Although the user can view a database and its subscription, the user may not be able to run the plan if the database subscription was made at the user database level. This occurs because a service plan subscription at that level behaves differently. For example, the run discovers and protects new databases, and since those databases inherit the parent ACLs, users that can run the parent service plan must also be included in the SQL Server instance ACL. Table 5. ACL Behavior with SQL Server Databases Application Parent Access Child Access Allowed Operations SQL Server Instance Yes Yes SUB, ALTS, DSC SQL Server Instance No Yes VIEW SQL Server Instance No No NONE SQL Server Database Yes Yes SUB, MNT, UMNT, EXP, RST, DSC SQL Server Database No Yes SUB, MNT, UMNT, EXP, RST NOTE: USERS MAYNOT BE ABLE TO RUN THE SERVICE PLAN WHEN SUBSCRIBED AT THE DATABASE LEVEL. EXAMPLE: IF THE ACL IS SET AT THE DATABASE (CHILD) LEVEL, RATHER THAN AT THE USER DATABASE FOLDER (PARENT) LEVEL, MEANING, THE ACL IS SET PER DATABASE, SUCH AS DB1 AND DB2, AND THEN IF ANOTHER DATABASE GETS ADDED, SUCH AS DB3, THEN IT WILL INHERIT THE PARENT ACLS, WHICH THERE ARE NONE, SINCE THE ACLS HAVE BEEN APPLIED TO THE INDIVIDUAL DATABASES. THEN, IF THE SERVICE PLAN IS SUBSCRIBED AT THE USER DATABASE FOLDER LEVEL, THAN UPON ADDING THAT THIRD DATABASE, THE SERVICE PLAN WILL FAIL TO RUN THAT PARTICULAR FUNCTION, SINCE THE SERVICE PLAN IS ACTIVING ON ALL DATABASES UNDER THE USER DATABASE FOLDER, AND THE USER RUNNING THE PLAN DOES NOT HAVE SPECIFIC PERMISSIONS FOR THE NEWLY CREATED DATABASE. IN ORDER TO ALEVIATE THIS TYPE OF ISSUE, PLEASE EITHER SET THE ACL ON THE USER DATBASE FOLDER, OR ENSRUE THE NEWLY ADDED DATABASE HAS THE CORRECT ACL PERMISSIONS. 15

16 ACL BEHAVIOR WITH EXCHANGE The following table summarizes parent/child access and allowed operations when using an ACL with Exchange. Table 6. ACL Behavior with Exchange Application Parent Access Child Access Allowed Operations Exchange Server Yes Yes ALTS, DSC Exchange Server No Yes View Exchange Server No No None Exchange Database Yes Yes SUB, MNT, UMNT, EXP, RST, DSC Exchange Database No Yes SUB, MNT, UMNT, EXP, RST ACL BEHAVIOR WITH ORACLE DATABASES Review this table to learn about ACL behavior with Oracle databases including user access and allowed operations. Table 7. ACL Rules for Oracle Application User Access Allowed Operations Oracle Database ACL user Yes SUB, MNT, UMNT, EXP, RST, RPP, DSC Oracle Database without user on ACL No None ACL BEHAVIOR WITH VMWARE DATASTORES Learn about ACL behavior with VMware datastores including parent/child access and allowed operations. The Protected Virtual Machines tab for datastores shows a protected VM only if the user can access at least one datastore associated with the VM. Because VM images have a one-to-many relationship to datastores, users need access to only one of the image's datastores to access the image. Otherwise, the user cannot view the image. Table 8. ACL Rules for VMWare Datastores Application User Access Allowed Operations VM Datastores Yes SUB, MNT, UMNT, EXP, RST,DSC VM Datastores No None ACL Behavior with File Systems Learn about ACL behavior with file systems including host level access, parent/child access, and allowed operations. With file systems, parent/child relationships behave differently than with Exchange and SQL Servers. File system parent ACLs (host level) refers only to the collection of file systems on a host. The ACL is not applied to the host, and therefore does not prohibit operations a user can perform on a host. Usage of parent /child refers to a file system ACL as a group without having to select individual file systems. Since ACLs are not applied to the host, Data Administrators can always view them, even if the Data Administrator navigates to an empty page. Table 9. ACL Behavior with File Systems Application Host Level Access Child Access Allowed Operations Host Level yes yes DSC Host Level No yes VIEW, DSC, ALRT Host Level No No VIEW File system yes yes SUB, MNT, UMNT, EXP, RST, DSC File system No yes SUB, MNT, UMNT, EXP, RST, DSC 16

17 Add a User for Access Control Manager (ACL Manager) Privileges Learn how to assign a user and yourself as an ACL Manager. Before you begin, AppSync requires the Security Administrator privilege to assign a user as an ACL Manager. Procedure 1. Select Settings > User Administration and under the Users tab, click Add 2. In the User Authentication radio button, select Local, and then enter the user name, password, and password confirmation. 3. To add an ACL Manger role to a user, select Data Administrator, and then click Enable ACL Manager as seen in Figure 7 - Setting Enable ACL Management NOTE: ACL MANAGERS MUST ALSO BE ASSIGNED THE DATA ADMINISTRATOR ROLE Figure 7 - Setting Enable ACL Management 4. To assign an existing user as an ACL Manager, complete the following steps: 4.1 Select Settings > User Administration and again under the Users tab 4.2 Select the user 4.3 Click Change Role 4.4 Click Enable ACL Manager. 17

18 APPLY AN ACCESS CONTROL LIST (ACL) TO AN APPLICATION OBJECT Learn about privileges required, restrictions and steps to add users to an access control list for an application object. Please note the following: Each object must be individually configured with ACLs, by selecting Enable ACL support, see Figure 9 - Enable ACL on an Object. You cannot multi-click objects. The default setting for each object is unrestricted (all users will have access). Setting an ACL on a parent object, such as a SQL instance, or the User Database folder, will cause the child objects to inherit those settings, but those child objects can uniquely be configured as well. Any new object added to an environment, where the parent object is not configured with ACLs, should be configured with ACL Management, otherwise, by default, new objects will be unrestricted. File systems are objects which must also be configured with ACLs. This means that if a database utilizes a file system, the ACLs should not only be applied to the database, but to the underlying file systems as well, to ensure the objects are restricted. Before beginning, the user running the following actions must have the Data Administrator privilege with ACL Manager enabled to add users to an application ACL, and set the ACL on the object. PROCEDURE 1. Navigate to Copy Management, where lists of available applications appear.. 2. Click an appropriate application, such as Microsoft SQL Server 3. Depending on the type of application, select the instance, database, host, file system, or datastore by highlighting the line item 4. Click ACL Settings to launch the ACL Settings dialog box, where users can be specified to the desired application object. The ACL Settings dialog box lists eligible users, and users already assigned to an ACL as seen in Figure 8 - ACL Settings Button. Figure 8 - ACL Settings Button 5. Once the ACL Settings dialog box appears, click Enable ACL Support to enable ACL management on that object, and then select the desired users whom do not have a check mark beside them, and then click Apply, as seen in Figure 9 - Enable ACL on an Object. 18

19 RESULTS Figure 9 - Enable ACL on an Object The ACL is applied to the desired object. If the ACL were applied to, for example, an SQL Server database instance, that ACL will be propagated to the SQL Server database's child databases. If you open the dialog box on the child database, it displays the inherited users applied to the parent SQL Server instance. You cannot remove inherited users from a child ACL. However, you can add new users to a child ACL. CONCLUSION In conclusion, this whitepaper explains key information and concepts of integrating an Active Directory LDAP server support adding LDAP users for role-based access management, including troubleshooting tips. REFERENCES AppSync Installation and Configuration Guide AppSync Security and Configuration Guide AppSync User and Administration Guide Dell EMC Common Security Toolkit Developers Guide NOTE: ALL DOCUMENTS CAN BE FOUND ON THE FOLLOWING APPSYNC PRODUCT DOCUMENTATION PAGE