As soon as log in to JSS web, logged out

@m.entholzner

I've seen a few other cases where changing the UserID mapping to sAMAccountName seemed to take care of the issue as well; I've added that to the workaround of PI-003395 as something to try.

Thanks!
Amanda Wulff
Jamf Support

Amanda,
A JSS admin from another department here contacted me as he was having the same issue. I told him what I did, changing uSNCreated to sAMAccountName for User ID and he said that resolved the problem for him also.

Thanks,
AJ.

I can confirm we had this issue once we upgraded from 9.96 to 9.97. Our LDAP users could log in, but not LDAP group members. Adding the sAMAccountName for User ID got us working again.

Brett

The sAMAccountName change did not work for us. And now that 9.97 is a critical update, we have a problem! Please can JAMF fix this?

You should probably get in contact with JAMF support. They are good about working with you through issues.

@aamjohns We have been in contact since 9.97 originally came out. It's a known issue, PI-003395. But it isn't fixed yet. So we cannot upgrade to 9.97.

I wanted to add that I'm seeing this after upgrading from 9.96 to 9.971488392992 (security hotfix). No AD changes or LDAP changes, but I'm getting random kickouts from instant to a few minutes.

@andykang seeing the same thing here. Was on a support call this morning and thought we had it resolved. But I had it happen again this afternoon.

@Brad_G Are you using uSNCreated for User ID mapping or sAMAccountName?

Do you see this in your server logs?

2017-03-08 14:51:47,673 [ERROR] [Tomcat-18 ] [GlobalExceptionHandler ] - 500 [] java.lang.NullPointerException at java.util.AbstractCollection.addAll(AbstractCollection.java:343) at com.jamfsoftware.uapi.dto.mappers.AuthorizationDtoMapper.createSiteAccountDto(AuthorizationDtoMapper.java:88) at com.jamfsoftware.uapi.dto.mappers.AuthorizationDtoMapper.getCurrentAuthorizationDto(AuthorizationDtoMapper.java:49) at com.jamfsoftware.uapi.resources.AuthRs.getCurrentAuthorization(AuthRs.java:95) at sun.reflect.GeneratedMethodAccessor431.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.springframework.web.method.support.InvocableHandlerMethod.doInvoke(InvocableHandlerMethod.java:222) at org.springframework.web.method.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:137) at org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:110) at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.invokeHandlerMethod(RequestMappingHandlerAdapter.java:814) at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.handleInternal(RequestMappingHandlerAdapter.java:737) at org.springframework.web.servlet.mvc.method.AbstractHandlerMethodAdapter.handle(AbstractHandlerMethodAdapter.java:85) at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:959) at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:893) at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:970) at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:872) at javax.servlet.http.HttpServlet.service(HttpServlet.java:648) at org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:846) at javax.servlet.http.HttpServlet.service(HttpServlet.java:729) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:292) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207) at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207) at com.jamfsoftware.jss.frontend.JSSLoadingFilter.doFilter(JSSLoadingFilter.java:59) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:212) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:141) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:509) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1104) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:684) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1520) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1476) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:745)

We upgraded to 9.97.1488392992 a couple of days ago (from 9.96) , and immediately our AD group logins started failing as described above. I can reliably trigger the behaviour by setting "User Mappings" -> "User ID" to either blank, or to "uidNumber" (which is empty in this domain; but was populated in our previous domain). If I set "User ID" to "uSNCreated" logins work immediately.

Thus, the bug in 9.97 is that you must have a non-zero "User ID" to login, but you didn't in previous versions.

Also, we were using "gidNumber" in "User Group Mappings" -> "Group ID", which in this domain is also blank (thus returns null). Logins still work if I leave this at 'gidNumber", "" (blank), or "uSNCreated". I've left it at "uSNCreated" for now.

We encountered the same issue in 2 different situations, both in clustered environments (no LDAP, though).
As soon as I logged in, I was kicked out of the JSS session and returned to the login window.
It turned out to be the NTP settings that caused differences between the time on the JSS servers and the MySQL server. Once the time was set correctly on all servers, everything worked fine.
I guess that when LDAP is involved, if NTP is not set to match the DC time, authentication will be rejected and it should lead to similar behavior.

To confirm what @julianradu reports with non-synchronized time causing this behavior, we saw the same thing last week in the DC CJA class using 9.97 .

It sounds like there are two issues here:

LDAP User ID Mapping
uSNCreated mapping causes random logouts with 9.97x whereas it was fine with 9.96. Switching to sAMAccountName fixes this (I've verified this in my own environment). Using uidNumber causes all logins to fail , although setting this to uSNCreated can resolve this.

Time Drift
If MySQL (or LDAP/DC) server time and JSS server time is not synced, all logins fail.

Hi Everyone,

I have found an inconsistency. My account was being affected (AD account), though it was not added as an individual. The AD group my account is a member of was added instead. After our last upgrade (to 9.97), we started to see the problem happening randomly. I ended up creating a local account for myself and the problem no longer happens. I then added my AD account individually and used it again, with the issue no longer occurring.

Long and the short - there seems to be an issue with AD groups added to the JSS for administration. Individual local and AD accounts added are not affected.

Please test this yourselves as every environment could be different.

Brad

We're seeing this in our environment; we were on 9.98 and hoped updating to 9.10 would make the issue go away. Unfortunately our test server on 9.10 won't keep anyone logged in. I'll post a solve if we find one.