Security

The admin.cfg file contains the users and groups registered for the internal server security (PTH). To encrypt this file, do the following.

1. Connect to the Web Console as a Server Administrator.
2. On the Access Control page ribbon, click Settings and select Encryption Settings.
3. Select y from the encrypt_admincfg drop-down list.
4. Click Apply and Restart Server.

When the server restarts, admin.cfg will be encrypted.

The user interface for configuring an LDAP security provider has been redesigned. The configuration parameters have been grouped into categories, and there are new buttons for retrieving sample lists of users and groups.

1. To configure a new LDAP provider, on the Access Control page, right-click LDAP under Security Providers and select New from the shortcut menu.

   The following LDAP Security Provider Configuration page opens on which you configure the provider name and connection parameters.

   

2. Configure the following connection parameters.

   LDAP_PROVIDER

   Specifies a name for this provider.

   ldap_host

   Is a host identifier consisting of a host name or an IPv4 dotted string representing the IP address of a host running the LDAP server to connect to.

   Alternatively, it may contain a list of space-delimited host identifiers. Each host identifier may include a trailing colon and port number. In the case where more than one host identifier is specified, each host identifier in turn will be contacted until a connection can be established. For example:

   directory.example.com 
   192.0.2.0 
   directory.example.com:1050 people.catalog.com 192.0.2.0

   ldap_secure_connection

   Specifies whether the server uses a Secure Socket Layer (SSL) session with the LDAP server. Select No or Yes. The server default is No.

   An LDAP (Lightweight Directory Access Protocol) security provider supports Secure Sockets Layer (SSL) API calls to establish an SSL/TLS connection. Using server authentication only, the Reporting Server initiates API calls to verify that the LDAP server being connected to is the same server that provided certification.

   You can set the LDAP secure connection from the Web Console:

   • Select No, the default value, if you do not wish to enable SSL.
   • Select Yes to enable an encrypted Secure Sockets Layer (SSL) session with the LDAP server.

   If you have selected IBM, Sun, or Novell as the your ldap_lib_vendor, when you select Yes in the ldap_secure_conection field, additional options are added to the Connection tab:

   • For Sun and IBM, ldap_ssl_certificate is added.
   • For Novell, ldap_ssl_certificate and ldap_ssl_certification_encoding are added.

   ldap_ssl_certificate. Enter the name of the LDAP attribute used by the API to establish the SSL/TLS connection. The server employs server authentication only, checking through API calls that the LDAP server you are connecting to is the one that provided the certificate. Values depend on the LDAP vendor, as follows:

   • Novell API specifies the file name, including path, of the Trusted Root Certificate that the LDAP server provided for authentication.
   • Sun/Netscape API specifies the path to cert7.db, Netscape certificate database, excluding the file name, that the LDAP server provided for authentication.
   • IBM API specifies the file name, including the path, for ldapkey.kdb (IBM key database file that the LDAP server provided for authentication). The ldapkey.sth password stash file should be in the same directory. Note that in addition to IBM LDAP client libraries, Global Security Kit libraries are needed to make SSL work. On Windows machines, GSK must be installed.
   • Microsoft API ignores the ldap_ssl_certificate configuration parameter since it is not used in an Active Directory. The server certificate should be installed in a certificate store.

   ldap_ssl_certificate_encoding. For Novell, select the standard used to encode the certificate from the drop-down list. Encryption and file format depend on API vendor specifications. The options are B64 and DER.

   ldap_port

   Is a positive integer that defines the TCP port number used to connect to the LDAP server. Note that ldap_port is ignored for any host identifier which includes a colon and port number. The server default port is 389 or 636 (for SSL connection).

   security

   Determines the type of bind used. Can be one of the following.

   Anonymous

   The bind is performed using no credentials. This is the internal default value.

   Windows security (NEGOTIATE)

   The reporting server authentication is performed against Active Directory utilizing a Windows-specific API.

   The bind is done under the Windows account that started the server.

   The windows machine that hosts the reporting server should be in the same domain as Active Directory.

   Explicit

   The bind is performed under the account that is defined by configuration parameters ldap_principal and ldap_credentials.

   Note: When connecting to Active Directory using Explicit or NEGOTIATE, ldap_user_attribute should have the value sAMAccountName or userPrincipalName.

   ldap_search_timeout

   Specifies the timeout in seconds for ldap_search. The server default value is 60 seconds.

3. Click Next.

   The User Search category of parameters opens, as shown in the following image. The common parameters for User Search and Group Search are automatically populated.

   

4. Configure the following user search and group search parameters.

   User properties

   ldap_user_base

   Specifies the DN of the entry that serves as the starting point for the search. Consists of attribute=value pairs, separated by commas. The server default is dc=ibi,dc=com.

   ldap_user_scope

   Specifies the scope with which the LDAP realm should search for users. Select Subtree, Onelevel, or Base:

   Subtree scope indicates that the LDAP realm should search everything under the base DN.

   Onelevel scope tells the LDAP server to only search entries one level down from the base DN.

   Base indicates that the search should be done at the search base only.

   The server default is Subtree.

   ldap_user_class

   Specifies the object class used when searching for user entries. The server default is person.

   ldap_user_attribute

   Specifies the LDAP attribute used when searching for user entries. uid is the default value for LDAP and sAMAccountName is the suggested value for Active Directory. One possible reason to change the default value would be to allow users to logon with an email address instead of a user ID. In this case, you might change the value to mail or userPrincipalName (if this corresponds with the name of the appropriate attribute in your directory).

   ldap_user_group_attribute

   Specifies the LDAP attribute used to identify a group in a user object.

   The Active Directory standard is Memberof.

   ldap_user_description

   Optional. Specifies the name of the attribute whose value contains description of an object (user, group). The server default is description.

   ldap_user_email

   Optional. Specifies the name of the attribute whose value contains the user email address. The server default is mail.

   Note: ldap_user_class, ldap_user_attribute, ldap_group_class, ldap_group_attribute are parameters that form a search filter.

   The search filter standard syntax conforms to the following structure:

   (&(Property_Name=Property_Value)(Property_Name=Property_Value))

   If you change value of the ldap_user_class and ldap_group_class parameters to an asterisk (*), the search filter syntax can be reduced to the following simplified form (although group support will not work properly):

   (Property_Name=Property_Value)

   By specifying an asterisk for these parameters, you achieve simplified search filter syntax, but in effect, disable group support.

   Group properties

   ldap_group_base

   Specifies the DN of the entry that serves as the starting point for the search. The server default is the ldap_user_base value.

   ldap_group_scope

   Specifies the scope with which the LDAP realm should search for groups. Select Subtree, Onelevel, or Base:

   Subtree scope indicates that the LDAP realm should search everything under the base DN.

   Onelevel scope tells the LDAP server to only search entries one level down from the base DN.

   Base indicates that the search should be done at the search base only.

   The server default is Subtree.

   ldap_group_class

   Specifies the object class used when searching for group entries. The server default is groupofuniquenames. The Active Directory standard is group.

   ldap_group_attribute

   Specifies the LDAP attribute used to identify the name of the group. The server default is cn.

   ldap_member_attribute

   Specifies the LDAP attribute used to identify users in a group. The server default is uniqueMember. The Active Directory standard is Member.

   ldap_nested_groups

   Disables or enables LDAP nested groups support. Select No or Yes. The server default is No, which disables nested group support.

   ldap_group_description

   Optional. Specifies the name of the attribute whose value contains description of an object (user, group). The server default is description.

5. Specify whether the server should accept trusted connections.

   trust_ext

   Specifies whether the server should accept trusted client connections. If there are multiple security providers, some may allow trusted connections and some may not. In these cases, if the trusted connection is made using a provider without the ability to accept trusted connections, the user will get an authentication error. The server default is n.

6. To test the configuration, click Test User Authentication.

   A Testing LDAP Security sign-in window opens.

   Enter a valid user ID and password for this LDAP security provider and click Continue.

   If your configuration and credentials are valid, a window opens telling you that you were successfully authenticated.

   If they are not valid, you will get a corresponding message.

7. To generate a sample user list, click Sample User List.

   A partial list of users with their descriptions and group memberships opens.

8. To generate a sample group list, click Sample Group List.

   A partial list of groups with their descriptions and a partial list of members opens.

9. To save this configuration, click Save. To go back to the first configuration page, click Back.

The following parameters are now supported in the edaserve.cfg configuration file to support OpenSSL ciphers and Diffie-Hellman (DH) and Elliptic Curve Diffie-Hellman (ECDH) key exchange.

ssl_ciphers

Configures the list of supported cipher strings. For example, the following is the default.

ALL:!ADH:!LOW:!EXP:@STRENGTH

ssl_dhparams_file

Specifies the full path to the Diffie-Hellman (DH) parameters file. To create a DH key exchange with key size 1024 bits, issue the following command.

'openssl dhparam -outform PEM -out dHParam.pem 1024'

ssl_ecdhcurve

Specifies a curve name for a specific Elliptic Curve Diffie-Hellman key exchange. To list all available curves, issue the following command.

'openssl ecparam -list_curves'

Connections to a Hive server with Kerberos enabled can be run in one of two ways:

• Server wide. The same Kerberos credential is used for all connections. You must obtain a Kerberos ticket before starting the server.
• Per user. Each user connecting to the server connects to Hive using their own credentials from the Hive Adapter connection in the user profile.

To setup connections to a Kerberos enabled Hive instance:

1. The Reporting Server has to be secured. The server can be configured with security providers PTH, LDAP, DBMS, OPSYS, or Custom, as well as multiple security providers environment,
2. The following jar files have to be added to the server CLASSPATH or IBI_CLASSPATH variable. These are default locations and vary by distribution and release:

   /hive_home/lib/hive-jdbc-standalone.jar
   /hadoop_home/hadoop-common.jar
   /hadoop_home/client/hadoop-auth.jar

A server started with security provider OPSYS can be configured for Kerberos connections.

To implement the single sign on Kerberos security:

1. On the Access Control page, right-click the OPSYS provider, and select Properties from the shortcut menu.

   The OPSYS Security Configuration page opens.

2. In the krb5_srv_principal * field, enter your server principal used for Kerberos security.
3. Click Save.

   The edaserve.cfg file is updated with this attribute.

4. On the Workspace page, expand the Special Services and Listeners folder, right-click TCP/HTTP, and select Properties of TCP.
5. Check SECURITY=KERBEROS.
6. Click Save and Restart Listener.

   The odin.cfg file is updated with this attribute.

When the server is started, a user can connect to the Web Console from Internet Explorer without a prompt for user ID and password. The Login Info shows connection type Kerberos. The connection is done using the Kerberos ticket from the browser. The connected user ID is derived from this ticket.

Connection to the server requires that there is a local OPSYS user ID with the same name as the Kerberos user ID on the operating system running the server. This user ID is used for tscom3 process impersonation.

If a user signs off from the Kerberos connection, the user can make explicit connections with the local Unix user ID and password. Connection with another Kerberos user ID as an explicit connection will not work.

You can configure uploads to operate on a specific list of file extensions.

1. On the Applications tab, click the Application Settings button on the ribbon, or right-click the Application Directories tree and select Application Settings from the shortcut menu.

   By default, the upload_allowed entry field contains a comma-separated list of all file extensions that the server can upload.

2. Edit the list to contain only the file extensions that should be allowed.
3. Click Save and Restart Server.

   After the server has restarted, the Upload Wizard will not show files with unsupported extensions if you click Select Upload File. If you try to drag a file with an unsupported file extension to the Upload Wizard, a message will be displayed that it is an invalid type of file.

You can configure Custom Provider authentication to encode passwords so that they cannot be viewed when they are passed as parameters to the authentication procedure.

1. On the Access Control tab, right-click a Custom Security Provider and select Properties from the shortcut menu, or right-click the CUSTOM folder and select New from the shortcut menu.

   The CUSTOM Security Provider Configuration page opens.

2. Select y from the cust_hashpasswd drop-down list.
3. Click Save.

When a user is authenticated, the server will send SHA-256 hashed passwords to the authentication procedure. This means that the passwords will be transformed into values that will be unusable for signing in to the Web Console and server. The hashed values have to be stored as passwords in the SQL database being used for authentication. As an alternative, you can create a utility called from the CUSTOM provider authentication procedure that decodes hashed passwords before sending a request to the SQL database for authentication.

The server administrator can choose whether to register users and groups for the primary security provider with one-part or two-part names. With two-part names, the user ID or group name is prepended with the provider name and a backslash. For example:

OPSYS\user1

or

LDAP01\user2

By default, all users and groups are registered using two-part names. To configure one-part registrations:

1. On the Access Control tab, click Settings and then Access Control Settings on the ribbon, or right-click the Access Control tree and select Settings and then Access Control Settings from the shortcut menu.
2. Select n from the prepend_provider_name drop-down list in the General section of the page, as shown in the following image.
   
3. Click Apply and Restart Server.

The prepend_provider_name=n attribute is added to the edaserve.cfg file.

The server administrator can now access Directory/File Privileges as a right-click menu option from any security subject (role, user, or group) on the Access Control tree.

The new Directory/File Privileges page enables the server administrator to configure privileges for all directories and files in those directories from a single page.

The new page has individual check boxes for Read, Write, and Execute privileges that can be changed on this page. The page is refreshed to update privileges for all inherited locations.

Each directory on the page has a right-click option to Show All Directories/Files. If this option is chosen, all nested folders and files are listed with their privileges.

The new Directory/File Privileges page is shown in the following image.

From the Access Control page, the server administrator can now register users and groups in server roles for a security provider that is not currently activated. These registrations will be available when the server is started with security ON and with that provider activated.

In addition, a server running with security OFF now has an Access Control page that a server administrator can use to register users and groups and to activate and deactivate providers.

One use for this feature is to register a Server Administrator for a Provider that will be active after the next server restart.