Support Questions

Find answers, ask questions, and share your expertise

Apache Ranger Admin UI Login Question

avatar
Expert Contributor

I am running Ranger Admin 2.4.0. Right now I have it synced with LDAP and am able to login to the Ranger Admin UI via my LDAP username and password. When I try upgrading to Ranger Admin 2.5.0 using the same configurations I am getting these errors in the logs.

catalina.out - 

java.lang.RuntimeException: Failed to create user drew.nicolette in x_portal_user table. retrying
at org.apache.ranger.biz.XUserMgr$ExternalUserCreator.createExternalUser(XUserMgr.java:3314)
at org.apache.ranger.biz.XUserMgr$ExternalUserCreator.run(XUserMgr.java:3288)
at org.apache.ranger.common.db.RangerTransactionSynchronizationAdapter.addRunnable(RangerTransactionSynchronizationAdapter.java:136)
at org.apache.ranger.common.db.RangerTransactionSynchronizationAdapter.executeOnTransactionCommit(RangerTransactionSynchronizationAdapter.java:82)
at org.apache.ranger.biz.XUserMgr.createServiceConfigUser(XUserMgr.java:2601)
at org.apache.ranger.biz.XUserMgr$$FastClassBySpringCGLIB$$57c6d473.invoke(<generated>)
at org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:218)
at org.springframework.aop.framework.CglibAopProxy.invokeMethod(CglibAopProxy.java:386)
at org.springframework.aop.framework.CglibAopProxy.access$000(CglibAopProxy.java:85)
at org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:703)
at org.apache.ranger.biz.XUserMgr$$EnhancerBySpringCGLIB$$c3461920.createServiceConfigUser(<generated>)
at org.apache.ranger.security.web.authentication.RangerAuthSuccessHandler.onAuthenticationSuccess(RangerAuthSuccessHandler.java:96)
at org.springframework.security.web.authentication.AbstractAuthenticationProcessingFilter.successfulAuthentication(AbstractAuthenticationProcessingFilter.java:329)
at org.springframework.security.web.authentication.AbstractAuthenticationProcessingFilter.doFilter(AbstractAuthenticationProcessingFilter.java:237)
at org.springframework.security.web.authentication.AbstractAuthenticationProcessingFilter.doFilter(AbstractAuthenticationProcessingFilter.java:217)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:346)
at org.springframework.security.web.authentication.logout.LogoutFilter.doFilter(LogoutFilter.java:103)
at org.springframework.security.web.authentication.logout.LogoutFilter.doFilter(LogoutFilter.java:89)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:346)
at org.springframework.security.web.header.HeaderWriterFilter.doHeadersAfter(HeaderWriterFilter.java:90)
at org.springframework.security.web.header.HeaderWriterFilter.doFilterInternal(HeaderWriterFilter.java:75)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:117)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:346)
at org.springframework.security.web.context.request.async.WebAsyncManagerIntegrationFilter.doFilterInternal(WebAsyncManagerIntegrationFilter.java:55)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:117)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:346)
at org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:112)
at org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:82)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:346)
at org.springframework.security.web.session.ForceEagerSessionCreationFilter.doFilterInternal(ForceEagerSessionCreationFilter.java:45)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:117)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:346)
at org.springframework.security.web.session.DisableEncodeUrlFilter.doFilterInternal(DisableEncodeUrlFilter.java:42)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:117)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:346)
at org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:221)
at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:186)
at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:354)
at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:267)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:181)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:156)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:168)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:90)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:483)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:130)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:93)
at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:679)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:74)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:342)
at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:617)
at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:63)
at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:934)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1698)
at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:52)
at org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191)
at org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:750)
Caused by: javax.persistence.TransactionRequiredException: No EntityManager with actual transaction available for current thread - cannot reliably process 'persist' call
at org.springframework.orm.jpa.SharedEntityManagerCreator$SharedEntityManagerInvocationHandler.invoke(SharedEntityManagerCreator.java:300)
at com.sun.proxy.$Proxy33.persist(Unknown Source)
at org.apache.ranger.common.db.BaseDao.create(BaseDao.java:110)
at org.apache.ranger.biz.UserMgr.createUser(UserMgr.java:161)
at org.apache.ranger.biz.UserMgr$$FastClassBySpringCGLIB$$3bbcf0cf.invoke(<generated>)
at org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:218)
at org.springframework.aop.framework.CglibAopProxy.invokeMethod(CglibAopProxy.java:386)
at org.springframework.aop.framework.CglibAopProxy.access$000(CglibAopProxy.java:85)
at org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:703)
at org.apache.ranger.biz.UserMgr$$EnhancerBySpringCGLIB$$a7bf07b4.createUser(<generated>)
at org.apache.ranger.biz.XUserMgr$ExternalUserCreator.createExternalUser(XUserMgr.java:3309)

 

ranger-admin.log

2025-02-12 20:48:12,287 [https-jsse-nio-6182-exec-5] INFO [SpringEventListener.java:76] Login Successful:drew.nicolette | Ip Address:172.34.100.196 | sessionId=0A3BABC02CC58F33F6A7055DAD1FAE26 | Epoch=1739393292287
2025-02-12 20:48:12,293 [https-jsse-nio-6182-exec-5] ERROR [SessionMgr.java:486] Error getting user for loginId=drew.nicolette 


However, the fix I noticed is to run usersync along side of ranger admin. This allowed me to login to the Ranger Admin UI.

Does anyone know if this is required? Any help would be greatly appreciated!

@Shelton 

1 ACCEPTED SOLUTION

avatar
Master Mentor

@drewski7 

The error message says there's no EntityManager with an actual transaction available. That suggests that the code trying to persist the user isn't running within a transactional context. In Spring applications, methods that modify the database usually need to be annotated with `@Transactional` to ensure they run within a transaction.

Looking at the stack trace, the error occurs in `XUserMgr$ExternalUserCreator.createExternalUser`, which calls `UserMgr.createUser`, which in turn uses `BaseDao.create`. The `create` method in `BaseDao` is trying to persist an entity but there's no active transaction. So maybe the `createUser` method or the code calling it isn't properly transactional.

In version 2.4.0, this worked, so something must have changed in 2.5.0. Perhaps the upgrade introduced changes in how transactions are managed. Maybe a method that was previously transactional no longer is, or the transaction boundaries have shifted.

Step 1: Verify Database Schema Compatibility

Ranger 2.5.0 may require schema updates. Ensure the database schema is compatible with the new version:

    1. Check Upgrade Documentation:
      Review the Ranger 2.5.0 Release Notes for required schema changes.
      Example: If migrating from 2.4.0 to 2.5.0, you may need to run SQL scripts like x_portal_user_DDL.sql or apache-ranger-2.5.0-schema-upgrade.sql.

    2. Run Schema Upgrade Scripts:
      Locate the schema upgrade scripts in the Ranger installation directory (ranger-admin/db/mysql/patches) and apply them:

      Spoiler
      mysql -u root -p ranger < apache-ranger-2.5.0-schema-upgrade.sql
    3. Validate the Schema:
      Confirm that the x_portal_user table exists and has the expected columns (e.g., login_id, user_role).

      Step 2: Check Transaction Management Configuration

      The error suggests a missing @Transactional annotation or misconfigured transaction manager in Ranger 2.5.0:

      1. Review Code/Configuration Changes:
        Compare the transaction management configurations between Ranger 2.4.0 and 2.5.0. Key files:

        • ranger-admin/ews/webapp/WEB-INF/classes/conf/application.properties

        • ranger-admin/ews/webapp/WEB-INF/classes/spring-beans.xml

Apache Ranger JIRA:
Search for issues like RANGER-XXXX related to transaction management in Ranger 2.5.0.

Ensure Transactional Annotations:
In Ranger 2.5.0, the method createUser in UserMgr.java or its caller must be annotated with @Transactional to ensure database operations run in a transaction.

Spoiler
@Transactional
public void createUser(...) { ... }

3. Debug Transaction Boundaries:
Enable transaction logging in log4j.properties to trace transaction activity

Spoiler
log4j.logger.org.springframework.transaction=DEBUG
log4j.logger.org.springframework.orm.jpa=DEBUG

Step 3: Manually Create the User (Temporary Workaround)

If the user drew.nicolette is missing from x_portal_user, manually insert it into the database:

Spoiler
INSERT INTO x_portal_user (login_id, password, user_role, status)
VALUES ('drew.nicolette', 'LDAP_USER_PASSWORD_HASH_IF_APPLICABLE', 'ROLE_USER', 1);

Note: This bypasses the transaction error but is not a permanent fix.

Step 4: Verify LDAP Configuration

Ensure LDAP settings in ranger-admin/ews/webapp/WEB-INF/classes/conf/ranger-admin-site.xml are correct for Ranger 2.5.0:

<property>
  <name>ranger.authentication.method</name>
  <value>LDAP</value>
</property>
<property>
  <name>ranger.ldap.url</name>
  <value>ldap://your-ldap-server:389</value>
</property>


Step 5: Check for Known Issues

    1. Apache Ranger JIRA:
      Search for issues like RANGER-XXXX related to transaction management in Ranger 2.5.0.

      2. Apply Patches:
      If a patch exists (e.g., for missing @Transactional annotations), apply it to the Ranger 2.5.0 codebase.

      Step 6: Test with a New User

      1. Attempt to log in with a different LDAP user to see if the issue is specific to drew.nicolette or a systemic problem.

      2. If the error persists for all users, focus on transaction configuration or schema issues.

      If only drew.nicolette fails, check for conflicts in the x_portal_user table (e.g., duplicate entries).

      Final Checks

      1. Logs: Monitor ranger-admin.log and catalina.out for transaction-related errors after applying fixes.

      2. Permissions: Ensure the database user has write access to the x_portal_user table.

      3. Dependencies: Confirm that Spring and JPA library versions match Ranger 2.5.0 requirements.

      Happy hadooping

  1.  

View solution in original post

4 REPLIES 4

avatar
Master Collaborator

Hello @drewski7 

Thank you for reaching out to the community

Just want to clarify one thing to fix this issue you did install Ranger user sync or you configure ldap auth with user sync as well along with Ranger admin

Usually, to login to Rager admin UI with ldap we just need to configure ldap configuration in Ranger Admin configuration and this should be enough. Usersync will sync users and groups to Ranger which you can use to assign permissions later from Ranger using polcies

 

avatar
Expert Contributor

@upadhyayk04 So for Ranger Admin, I configured it to use LDAP and it wasn't enough to login to the UI in version 2.5.0. Once I configured both Ranger Admin and Ranger Usersync it worked. 

I am under the same assumption as you. I thought just configuring the Ranger Admin to use LDAP was enough but in this case it wasn't.

avatar
Master Collaborator

Hello @drewski7 I have seen Ranger Admin working with LDAP users without configuring ldap configuration in Ranger usersync

By the way what is the CDP version you are using?

avatar
Master Mentor

@drewski7 

The error message says there's no EntityManager with an actual transaction available. That suggests that the code trying to persist the user isn't running within a transactional context. In Spring applications, methods that modify the database usually need to be annotated with `@Transactional` to ensure they run within a transaction.

Looking at the stack trace, the error occurs in `XUserMgr$ExternalUserCreator.createExternalUser`, which calls `UserMgr.createUser`, which in turn uses `BaseDao.create`. The `create` method in `BaseDao` is trying to persist an entity but there's no active transaction. So maybe the `createUser` method or the code calling it isn't properly transactional.

In version 2.4.0, this worked, so something must have changed in 2.5.0. Perhaps the upgrade introduced changes in how transactions are managed. Maybe a method that was previously transactional no longer is, or the transaction boundaries have shifted.

Step 1: Verify Database Schema Compatibility

Ranger 2.5.0 may require schema updates. Ensure the database schema is compatible with the new version:

    1. Check Upgrade Documentation:
      Review the Ranger 2.5.0 Release Notes for required schema changes.
      Example: If migrating from 2.4.0 to 2.5.0, you may need to run SQL scripts like x_portal_user_DDL.sql or apache-ranger-2.5.0-schema-upgrade.sql.

    2. Run Schema Upgrade Scripts:
      Locate the schema upgrade scripts in the Ranger installation directory (ranger-admin/db/mysql/patches) and apply them:

      Spoiler
      mysql -u root -p ranger < apache-ranger-2.5.0-schema-upgrade.sql
    3. Validate the Schema:
      Confirm that the x_portal_user table exists and has the expected columns (e.g., login_id, user_role).

      Step 2: Check Transaction Management Configuration

      The error suggests a missing @Transactional annotation or misconfigured transaction manager in Ranger 2.5.0:

      1. Review Code/Configuration Changes:
        Compare the transaction management configurations between Ranger 2.4.0 and 2.5.0. Key files:

        • ranger-admin/ews/webapp/WEB-INF/classes/conf/application.properties

        • ranger-admin/ews/webapp/WEB-INF/classes/spring-beans.xml

Apache Ranger JIRA:
Search for issues like RANGER-XXXX related to transaction management in Ranger 2.5.0.

Ensure Transactional Annotations:
In Ranger 2.5.0, the method createUser in UserMgr.java or its caller must be annotated with @Transactional to ensure database operations run in a transaction.

Spoiler
@Transactional
public void createUser(...) { ... }

3. Debug Transaction Boundaries:
Enable transaction logging in log4j.properties to trace transaction activity

Spoiler
log4j.logger.org.springframework.transaction=DEBUG
log4j.logger.org.springframework.orm.jpa=DEBUG

Step 3: Manually Create the User (Temporary Workaround)

If the user drew.nicolette is missing from x_portal_user, manually insert it into the database:

Spoiler
INSERT INTO x_portal_user (login_id, password, user_role, status)
VALUES ('drew.nicolette', 'LDAP_USER_PASSWORD_HASH_IF_APPLICABLE', 'ROLE_USER', 1);

Note: This bypasses the transaction error but is not a permanent fix.

Step 4: Verify LDAP Configuration

Ensure LDAP settings in ranger-admin/ews/webapp/WEB-INF/classes/conf/ranger-admin-site.xml are correct for Ranger 2.5.0:

<property>
  <name>ranger.authentication.method</name>
  <value>LDAP</value>
</property>
<property>
  <name>ranger.ldap.url</name>
  <value>ldap://your-ldap-server:389</value>
</property>


Step 5: Check for Known Issues

    1. Apache Ranger JIRA:
      Search for issues like RANGER-XXXX related to transaction management in Ranger 2.5.0.

      2. Apply Patches:
      If a patch exists (e.g., for missing @Transactional annotations), apply it to the Ranger 2.5.0 codebase.

      Step 6: Test with a New User

      1. Attempt to log in with a different LDAP user to see if the issue is specific to drew.nicolette or a systemic problem.

      2. If the error persists for all users, focus on transaction configuration or schema issues.

      If only drew.nicolette fails, check for conflicts in the x_portal_user table (e.g., duplicate entries).

      Final Checks

      1. Logs: Monitor ranger-admin.log and catalina.out for transaction-related errors after applying fixes.

      2. Permissions: Ensure the database user has write access to the x_portal_user table.

      3. Dependencies: Confirm that Spring and JPA library versions match Ranger 2.5.0 requirements.

      Happy hadooping

  1.