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: segfault at 0 ip 00007ffa13fc9fc6 sp 00007ffd9910f3c8 error 4 in libc-2.17.so[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(ExternalProcessUnixAuthenticationProvider.java:127) [dfm-core.jar:7.1]
at org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:156) [spring-security-core.jar:3.2.3.RELEASE]
at com.netapp.dfm.app.common.authentication.CachingAuthenticationManager.authenticate(CachingAuthenticationManager.java:174) [dfm-app-common.jar:7.1]
at org.springframework.security.web.authentication.UsernamePasswordAuthenticationFilter.attemptAuthentication(UsernamePasswordAuthenticationFilter.java:94) [spring-security-web.jar:3.2.3.RELEASE]
at org.springframework.security.web.authentication.AbstractAuthenticationProcessingFilter.doFilter(AbstractAuthenticationProcessingFilter.java:211) [spring-security-web.jar:3.2.3.RELEASE]
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) [spring-security-web.jar:3.2.3.RELEASE]
at com.netapp.dfm.core.authentication.TemporaryTokenAuthenticationFilter.doFilter(TemporaryTokenAuthenticationFilter.java:63) [dfm-core.jar:7.1]
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: https://library.netapp.com/ecm/ecm_download_file/ECMLP2553755).
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:[127.0.0.1]::Authentication failed for xxxx_x_xxxxxxx [org.springframework.security.web.authentication.WebAuthenticationDetails@fffed504: RemoteIpAddress: 127.0.0.1; SessionId: K1uEbUk2c490MaATo4GdPITo]: org.springframework.security.authentication.BadCredentialsException: 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.