Skip to main content

Pentaho+ documentation has moved!

The new product documentation portal is here. Check it out now at docs.hitachivantara.com

 

Hitachi Vantara Lumada and Pentaho Documentation

Security Issues

Parent article

The following tips provide help with adjusting log file output, examining logs for signs of configuration errors, and possible issues and related solutions during LDAP configuration:

  • Increase security log levels in the Pentaho Server
  • Log output security analysis
  • LDAP roles issues with admin and authenticated
  • With LDAP authentication, the PDI Repository Explorer is empty
  • LDAP incorrectly authenticates user IDs that do not match letter case
  • Connection timeout issues when using CAS

See Pentaho Troubleshooting articles for additional topics.

Increase security log levels in the Pentaho Server

The security logging facilities of the Pentaho Server are set to ERROR by default, which may not supply enough details for troubleshooting and testing.

The following procedure explains how to set up verbose logging which increases the level of detail in the Pentaho Server logs for security-related messages.

Procedure

  1. Stop the Pentaho Server with the following script

    sh /usr/local/pentaho/server/pentaho-server/stop-pentaho.sh
  2. Open the /pentaho/server/pentaho-server/tomcat/webapps/pentaho/WEB-INF/classes/log4j2.xml file with a text editor.

  3. Change or add the ThresholdFilter value in the <Console> or <RollingFile> sections to one of the following logging levels: WARN, ERROR, FATAL, or DEBUG (depending on which level you prefer):

    < Console name="PENTAHOCONSOLE" >
    <ThresholdFilter level="ERROR"/>
    <PatternLayout><Pattern>%d{ABSOLUTE} %-5p [%c{1}] %m%n</Pattern>
    </PatternLayout>
    </Console>
    
  4. Add the following log statements directly above the root element:

    <!-- all Spring Security classes will be set to DEBUG -->
    <Logger name="org.springframework.security" level=”DEBUG”>
    <!-- all Pentaho security-related classes will be set to DEBUG -->
    <Logger name="org.pentaho.platform.engine.security" level=”DEBUG”>
    <Logger name="org.pentaho.platform.plugin.services.security" level=”DEBUG”>
    
  5. Save and close the file, then edit the Spring Security configuration file that corresponds with your security back end in the /pentaho/server/pentaho-server/pentaho-solutions/system/ directory. The file will be one of the following options:

    • applicationContext-spring-security-memory.xml
    • applicationContext-spring-security-jdbc.xml
    • applicationContext-spring-security-ldap.xml
  6. Find the daoAuthenticationProvider bean definition, then add the following property anywhere inside of it (before the </bean> tag):

    <property name="hideUserNotFoundExceptions" value="false" />
  7. Save the file and close the text editor.

  8. Start the Pentaho Server with the following script:

    sh /usr/local/pentaho/server/pentaho-server/start-pentaho.sh

Results

For this example, Pentaho Server security logging is now globally set to DEBUG, which provides verbose logging for debugging security configuration problems. All Pentaho Server messages will be collected in the /pentaho/server/pentaho-server/logs/pentaho.log file.

Next steps

When you are finished configuring and testing the Pentaho Server, you should decrease verbose logging down to a less detailed level, such as ERROR, to prevent pentaho.log from growing too large.

Enable extra LDAP security logging

If you need more LDAP-related security details in pentaho.log, or if you are specifically having difficulty with LDAP authentication configuration, perform the following steps to set up verbose logging.
NoteThese instructions are for testing and pre-production only. User names and passwords will be displayed in the log file in plain text.

Procedure

  1. Stop the Pentaho Server

  2. Go to the /pentaho/server/pentaho-server/pentaho-solutions/system directory and open the applicationContext-spring-security-ldap.xml file with a text editor.

  3. Locate the bean declaration for DefaultLdapAuthenticationProvider and replace the constructor-arg bean with the following new bean:

    Old Bean:

    <constructor-arg>
    <ref bean="authenticator" />
    </constructor-arg>

    New Bean:

    <constructor-arg>
    <ref bean="ldapAuthenticatorProxy" />
    </constructor-arg>
  4. In the same directory, locate and open the pentaho-spring-beans.xml file.

  5. Add the following import line to the list of files:

    <import resource="applicationContext-logging.xml" />
  6. Save and close the file.

  7. Locate the /pentaho-server/tomcat/webapps/pentaho/WEB-INF/classes directory and open the log4j2.xml file with a text editor.

  8. Add this category to the log4j2.xml file.

    <Logger name="org.springframework.security.providers" level="DEBUG"/>
  9. Save and close the file, then start the Pentaho Server.

Results

You will now have verbose LDAP-specific log messages in pentaho.log, which include login credentials for every user that tries to log on.

Log output security analysis

The following examples help to determine the location of security configuration issues in the pentaho.log:

  • When you request a page that is protected, but you are not yet logged on, you should see an exception in the log which looks like the following text:
    DEBUG [ExceptionTranslationFilter] Access is denied (user is anonymous);
                redirecting to authentication entry point org.springframework.security.AccessDeniedException:
                Access is denied
  • When the user name and/or password does not match what is stored in the back end, you should see a log message like the following text:
    WARN [LoggerListener] Authentication event
                AuthenticationFailureBadCredentialsEvent: suzy; details:
                org.springframework.security.ui.WebAuthenticationDetails@fffd148a: RemoteIpAddress: 127.0.0.1;
                SessionId: 976C95033136070E0200D6DA26CB0277; exception: Bad credentials
  • When the user name and password match, you should see a log message that looks like the following example:
    WARN [LoggerListener] Authentication event InteractiveAuthenticationSuccessEvent:
                suzy; details: org.springframework.security.ui.WebAuthenticationDetails@fffd148a: RemoteIpAddress:
                127.0.0.1; SessionId: 976C95033136070E0200D6DA26CB0277 DEBUG
                [HttpSessionContextIntegrationFilter] SecurityContext stored to HttpSession:
                'org.springframework.security.context.SecurityContextImpl@2b86afeb: Authentication:
                org.springframework.security.providers.UsernamePasswordAuthenticationToken@2b86afeb: Username:
                org.springframework.security.userdetails.ldap.LdapUserDetailsImpl@d7f51e; Password: [PROTECTED];
                Authenticated: true; Details: org.springframework.security.ui.WebAuthenticationDetails@fffd148a:
                RemoteIpAddress: 127.0.0.1; SessionId: 976C95033136070E0200D6DA26CB0277; Granted
                Authorities: ROLE_CTO, ROLE_IS, ROLE_AUTHENTICATED'
After the InteractiveAuthenticationSuccessEvent, one of the filters will show the roles fetched for the authenticated user. Compare these roles to the page-role mapping found in the filterInvocationInterceptor bean in applicationContext-spring-security.xml.

If you are troubleshooting LDAP problems, look for log output similar to the following text:

DEBUG [DirMgrBindAuthenticator] (LoggingInterceptor) Return value: LdapUserInfo:
            org.springframework.security.providers.ldap.LdapUserInfo@1f31c64[dn=uid=suzy,ou=users,ou=system,attributes={mail=mail:
            suzy.pentaho@pentaho.org, uid=uid: suzy, userpassword=userpassword: [B@e17c9c,
            businesscategory=businesscategory: cn=cto,ou=roles,ou=system, cn=is,ou=roles,ou=system,
            objectclass=objectClass: organizationalPerson, person, groupOfUniqueNames,
            inetOrgPerson, top, uniquemember=uniquemember: cn=cto, ou=roles, cn = is , ou = roles,
            sn=sn: Pentaho, cn=cn: suzy}]

LDAP roles issues with 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.

Open /pentaho-solutions/system/applicationContext-spring-security.xml in a text editor. At the bottom of this file, you will find a number of entries 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. For this example, both Anonymous and Authenticated gain access.

We replace Authenticated with pentahoUsers 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 make the following changes.

From:

<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>

From:

<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 on to a solution repository from the PDI client before you switch authentication to LDAP, then the repository IDs and security structures will be broken. You will not see an error message, but the solution repository explorer will be empty and you will not be able to create new folders or save PDI content.

To fix the problem, you will have to delete the security settings established with the previously used authentication method, which will force the Pentaho Server to regenerate them for LDAP.

NoteFollowing this procedure will destroy any previously definedPentaho Repository users, roles, and access controls. You should back up the files that you delete in these instructions.

Procedure

  1. Stop the Pentaho Server.

  2. Delete the security and default directories from the following directory: /pentaho-solutions/system/jackrabbit/repository/workspaces/

  3. Start the Pentaho Server.

Results

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

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 Pentaho 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 Pentaho Server.

Perform the following steps to force case-sensitivity for user names and fix this potential security risk:

Procedure

  1. Stop the Pentaho Server.

  2. Edit the /pentaho/server/pentaho-server/pentaho-solutions/system/applicationContext-spring-security-ldap.xml file.

  3. Find <bean class="org.pentaho.platform.plugin.services.security.userrole.ldap.DefaultLdapAuthenticationProvider">, and below the last </constructor-arg> element therein, and add the <property> definition shown in the following example:

    <property name="userDetailsContextMapper">
        <ref bean="ldapContextMapper" />
    </property>
  4. 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>
  5. Start the Pentaho Server.

Results

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

Connection timeout issues when using CAS

Connection timeout issues when using CAS with the Pentaho Server can result in the inability to login or re-load data in the web client page until you refresh the page. If you have problems with the session timing out, perform the following steps to configure the session timeout:

Procedure

  1. Stop the Pentaho Server.

  2. Navigate to the pentaho-server/tomcat/webapps/pentaho/WEB-INF directory and open the web.xml file with any text editor.

    1. Find the session-config property and edit the session-timeout value (the default value is 120 minutes) to increase the period to a value that is greater than the setting used for your CAS server session timeout value:

      <session-config>
        <tracking-mode>COOKIE</tracking-mode>
        <session-timeout>120</session-timeout>
      </session-config>
    2. Locate the Pentaho Web Context Filter and add the following init-param

      <init-param>
        <param-name>ssoEnabled</param-name>
        <param-value>true</param-value>
      </init-param
    3. Save and close the file.

  3. Activate the session timeout dialog box:

    1. Navigate to the pentaho-server/pentaho-solutions/system directory and open the applicationContext-spring-security-cas.xml file then locate the httpSessionPentahoSessionContextIntegrationFilter bean id.
    2. Find the ssoEnabled property and set the value from true to false.
    3. Save and close the file.
  4. Restart the Pentaho Server.

Results

If the session does timeout, a session timeout dialog box will now warn users when the session expires and then will reauthenticate the session through CAS when the dialog box is closed.

Cannot change Administrator password in PUC

When you add an administrator account in the Pentaho User Console (PUC), you have two administrator passwords: the default admin password and another password for the additional administrator account. When you try to change the password for the additional administrator account, a message might appear informing you that the system cannot change the password. To resolve this issue, you must enter the password of the currently logged-in user with administrator permissions in the Administrator password field.

Change PUC Password dialog box