Resolve Security Problems

Last updated
Save as PDF

Overview

Explains how resolve common security issues.

Solutions to common security problems appear in the following sections.

LDAP Incorrectly Authenticates User IDs That Do Not Match Letter Case

Some LDAP implementations are case-insensitive, most notably Microsoft Active Directory. When using one of these LDAP distributions as a BA Server authentication back end, you might run into an issue where a valid user name with invalid letter cases will improperly validate. For instance, if Bill is the valid user ID, and someone types in bILL at the User Console login screen, that name will authenticate, but it might have improper access to parts of the BA Server.

The fix for this is documented: LDAP Authenticates User IDs That Do Not Match Case.

LDAP Authenticates User IDs That Do Not Match Case

Some LDAP implementations are case-insensitive for user names, most notably Microsoft Active Directory. You might run into an issue where a user name typed into the login screen does not exactly match the letter case of that user's ID in the directory, but the server will authenticate it anyway and may give the user improper access to parts of the BA Server. For example, if Bill is the valid user ID, and someone types in bILL at the User Console login screen, the incorrectly typed one will authenticate, but it may have improper access to parts of the BA Server.

Follow these instructions to force case-sensitivity and fix this potential security risk.

Stop the BA Server.
Edit the /pentaho/server/biserver-ee/pentaho-solutions/system/applicationContext-spring-security-ldap.xml file.
Find the daoAuthenticationProvider bean, and below the last </constructor-arg> therein, and add the <property> definition shown in the example:
```
<property name="userDetailsContextMapper">
    <ref local="ldapContextMapper" />
</property>
```

After the </bean> tag for daoAuthenticationProvider, add the following bean definition, changing the ldapUsernameAttribute from samAccountName to the value that matches your environment:

<bean id="ldapContextMapper" class="org.pentaho.platform.engine.security.UseridAttributeLdapContextMapper">
    <property name="ldapUsernameAttribute" value="samAccountName" />
</bean>

Start the BA Server.

The BA Server will now force case sensitivity in LDAP user names.

LDAP Roles Are Not "Admin" and "Authenticated"

You must not use Admin and Authenticated roles in your LDAP. Instead you must configure your system to use pentahoAdmins and pentahoUsers or other easily identifiable role names. Edit /pentaho-solutions/system/applicationContext-spring-security.xml. At the bottom of this file, you will find a number of lines that look like: A/docs/.*Z=Anonymous,Authenticated.

These are entries for URL Security. They are regular expressions to match a path on the browser’s URL that require the user to be a member of the defined role to gain access. In the example above, both Anonymous and Authenticated get access. In the example above, use pentahoUsers in the place of Authenticated. by entering A/docs/.*Z=Anonymous,pentahoUsers. For all entries that show Authenticated, replace it with pentahoUsers or your chosen name. Replace Admin with pentahoAdmins or your chosen name. For the change from Authenticated to pentahoUsers replace all occurrences. For Admin to pentahoAdmins you need to be a little more careful because there are some entries that look like this: A/admin.*Z=pentahoAdmins.

Edit the /pentaho-solutions/system/repository.spring.xml file and change:

<bean id="singleTenantAuthenticatedAuthorityName" class="java.lang.String">
    <constructor-arg value="Authenticated" />
   </bean>

to:

<bean id="singleTenantAuthenticatedAuthorityName" class="java.lang.String">
    <constructor-arg value="pentahoUsers" />
   </bean>

and:

<bean id="singleTenantAdminAuthorityName" class="java.lang.String">
    <constructor-arg value="Admin" />
   </bean>

to:

<bean id="singleTenantAdminAuthorityName" class="java.lang.String">
    <constructor-arg value="pentahoAdmins" />
   </bean>

With LDAP Authentication, the PDI Repository Explorer is Empty

If you log into a solution repository from Spoon before you switch the authentication to LDAP, then the repository IDs and security structures will be broken. You won't see an error message, but the solution repository explorer will be empty and you won't be able to create new folders or save PDI content to it. To fix the problem, you will have to delete the security settings established with the previously used authentication method, which will force the DI Server to regenerate them for LDAP.

CAUTION:

Following this procedure will destroy any previously defined DI repository users, roles, and access controls. You should back up the files that you delete in these instructions.

Stop the DI Server
Delete the security and default directories from the following directory: /pentaho-solutions/system/jackrabbit/repository/workspaces/
Start the DI Server

You should now have a proper LDAP-based DI Repository that can store content and create new directories.

Cannot Access Kerberos Nodes

If a step or entry cannot access a Kerberos authenticated cluster, review the steps in Use Impersonation to Access a MapR Cluster.

If you are still having problems, make sure the username, password, UID, and GID for each impersonated or spoofed user is the same on each node. Sometimes they are not the same if a user was deleted, then recreated with different UIDs and GIDs.

Cannot Access a Hive Cluster

If you cannot use Kerberos impersonation to authenticate and access a Hive cluster, review the steps in Use Impersonation to Access a MapR Cluster.

If problems persist, copy the hive-site.xml file on the Hive server to the MapR distribution in these directories:

DI Server: data-integration-server/pentaho-solutions/system/kettle/plugins/ pentaho-big-data-plugin/hadoop-configurations/[mapr distribution]
Spoon: data-integration/plugins/pentaho-big-data-plugin/hadoop-configurations/[mapr distribution]

If this still does not work, disable pooled connections for Hive.

Cannot use Keytab File to Authenticate Access to PMR Cluster

If you cannot authenticate and gain access to the PMR cluster, copy the keytab file to each task tracker node on the PMR cluster.

HBase Get Master Failed Error

If this error occurs “HBase cannot negation the authenticated portion of the connection” copy the hbase-site.xml file from the HBase server to the MapR distribution in these directories:

DI Server: data-integration-server/pentaho-solutions/system/kettle/plugins/ pentaho-big-data-plugin/hadoop-configurations/[mapr distribution]
Spoon: data-integration/plugins/pentaho-big-data-plugin/hadoop-configurations/[mapr distribution]