Active IQ Unified Manager Discussions

OCUM 7.1 LDAP auth problem




I installed the OCUM 7.1 on a RHEL 7.2 physical box without any problem


I configured the remote authentication using the "Other" settings (Same config as a running OCUM 6.4).

Some accounts created in 7.1 as remote user are able to log-in, some of them not.


This users don't get a denied message, there is just no response.

I get a denied if I want to log-in with a user thats not permitted to log in.


The LDAP connection is working, I checked it in the settings. 


If the log-in failes with no response, I see the following message in /var/log/messages


Feb 21 11:07:48 snocumm1539 kernel: authenticate[6847]: segfault at 0 ip 00007ffa13fc9fc6 sp 00007ffd9910f3c8 error 4 in[7ffa13e98000+1b6000]

and some more in the jboss server.log


2017-02-21 11:07:48,362 ERROR [io.undertow.request] (default task-256) UT005023: Exception handling request to /um/login: java.lang.RuntimeException: Error while attempting authentication:

	at com.netapp.dfm.core.authentication.ExternalProcessUnixAuthenticationProvider.authenticate( [dfm-core.jar:7.1]
	at [spring-security-core.jar:3.2.3.RELEASE]
	at [dfm-app-common.jar:7.1]
	at [spring-security-web.jar:3.2.3.RELEASE]
	at [spring-security-web.jar:3.2.3.RELEASE]
	at$VirtualFilterChain.doFilter( [spring-security-web.jar:3.2.3.RELEASE]
	at com.netapp.dfm.core.authentication.TemporaryTokenAuthenticationFilter.doFilter( [dfm-core.jar:7.1]


LDAP login on the RHEL host works.


Some Ideas?









The problem is most probably here:

"LDAP login on the RHEL host works"


Some authentication servers will only do one connection per client (like SSSD). Generally OCUM comes with its own client and until now it cannot delegate LDAP authentication to the host.

It might work correctly for a while if you deactivate the ldap client on the RHEL host, restart the ocum services like service ocieau stop, then service ocie restart, service ocieau start and then re-activate the LDAP client on the host.


The clean solution would be to use the OCUM LDAP client only and none on the host.




Are the account that fail to successfully login members of nested groups?  If so, disable nested groups and test their login - there is a checkbox on the Remote Authentication configuration screen for disabling nested users (Page 33 of the RHEL ISG:




I encountered a similar situation.


Did a fresh install of OCUM 7.1 on a RHEL7.2


Applied the exact same config like we had on the old ocum 6.3.


Remote Authentication Test works fine, the Remote group is found but my users can not login.


Opened a Case with Netapp on this. If I get a solution I will post it here 😉


After I removed sssd-ldap all worked 😄


Hi Hannes,


your solution will be: it's not supported 🙂


It doesn't matter if it had worked before or if the logfiles are spammed with java exceptions or segmentation faults.

The LDAP auth was destroyed while changing to OCUM 7.x.


The GUI dialogue "Do you want to change your settings" answered with "No" is still buggy.




Hi Marcus,


I think you are right, there is definitely something wrong with the LDAP/AD integration ... But I don't know what 😕


I think it must be at least partly an OCUM application problem, because I see similar behaviour to what you describe in the VMware based OCUM appliance package.


On a newly installed 7.1P1 Vmware based OCUM system I can no longer login using an AD account.


Remote authenticated login _did_ work initially, after the installation, immediately after remote authentication was enabled. But now it fails for no obvious reason.


In the OCUM audit.log file I see errors like this:

Apr 07 13:27:32 [:NOTIC]::WEB:err:[]::Authentication failed for xxxx_x_xxxxxxx [ RemoteIpAddress:; SessionId: K1uEbUk2c490MaATo4GdPITo]: Authenticating token for ldap user not successful.


Ironically the "Test Authentication" button in the OCUM Web UI works every time. It returns success, along with convincing infomation about the attributes and group membership of the account name tested.


A second older OCUM server (also VMware based, version 7.1, upgraded from 6.x), configured with exactly the same remote auth configuration and authenticating against the same AD server functions normally. Using the same user account name I can login in to that server without any problem.


Go figure 😕


BTW, you are right, something also goes wrong in the Web UI when you answer "no" to "do you want to save your changes".






I'm having the exact same issue w/ 7.1P1 OCUM VMWare appliance.


We are trying to take advantage of Domain Admins (would like to use a security group but don't see an option to specify LDAP Group) and whether we check "Nested Group" or not it doesn't authenticate, testing works just fine, and finds all accounts we try but does not work when trying to actually login. I'm opening up a case w/ Support to see if they have resolution as I really hate logging in w/ a local account.




the AD authentication itself works fine for users that do *not* have rights on the server.

Our workarround is to use non admin users in OCUM.


You specify the AD group that should be used for authentication with the option "remote group".




I have tested this and it appears to be entirely to do with the application.


Authentication test works

Adding group works (For reason there a few random upper case letters in our AD group and the gui reflects this )


Login appers to work but nothing happens, login and password windows just go blank and this errors appear in the /var/log/messages;


kernel: authenticate[17114]: segfault at 0 ip 00007ff408defad6 sp 00007fff47db3b88 error 4 in


I believe authentication has worked as no more ldap queries are attempted until you use a different username 



When winbind is stopped, it works straight away without restarting any OCUM services.

When Windbind is started again it reloads the web gui and I can continue, but the above issue occurs for other users.


I belive that when the application was written it was probably design for a black box with just admin login and no remote auth, like the OVA.


The current solution is to have local accounts.