As soon as log in to JSS web, logged out

[aamjohns]

This will be quick I have to catch my ride home but...
The techs informed me that they cannot login to the JSS. I check and they log in, a page appears very briefly, and then they are logged out (logout.html). This just repeats.

I've tried what I have found on here. Clearing cache, making sure LDAP is bound and working. In the known issues for 9.77 I saw at the top if they failed the login, they would get stuck in this loop and the address needed to be manually corrected, but I don't see anything to correct.

I've had them try on my computer (I don't have any issues) and it happens to them. I've logged in on their computers and it works fine for me.

I'm on the hotfix version of 9.97.1xxx and it is installed on a Win2008R2 server. I thought the problem started today but I found out one of the techs noticed it before Christmas. And I was out.

I wanted to get this posted because it is going to bother me all night and I am hoping someone will know what needs to be done to fix this.

Thanks,
AJ.

[DI_Casper]

The problem for me was that one of my colleagues changed the OU name where the LDAP Server Account lives. Therefore, it wasn't able to query Active Directory and I couldn't sign in with my AD account.

I had to sign in with my standard account and edit the LDAP Server information to reflect the new Distinguished Username.

Let me know if this helps.

- Bryan

[aamjohns]

Hi Bryan,
I appreciate your response. I checked the LDAP config in the JSS and everything seems correct. It works. It will return info on user accounts (our techs), groups, and if the account is in a group. Plus I can log in with my ADS account.

I do appreciate you sharing what the problem was for you. At least it gives me something to focus on more. Maybe something has changed somehow that is causing this issue. But the fact that LDAP seems to be working makes it seem to be different than your problem and solution.

I thought this all started yesterday. That is when one of the techs brought it to my attention. Then I had the other techs try and they are all having the same issue. Then I was talking to one of them and he informed me it happened to him starting a few weeks ago, while I was off for the week of Christmas. I am our ADS guy and I didn't change anything so I am not sure what started this.

I could try adding some techs by user account rather than by group membership and see if that changes anything. I've also been looking at the logging.html page to look for clues and I haven't really found an exact correlation in the log data. I will continue to work using the log to see if I can find something that directly correlates to this.

I didn't really have time to mention everything I've done for troubleshooting. I've had the techs try different browsers, clearing their cache and history, try on different computers, and I double checked the xml config for JSS and ran a repair install.

I saw in the 9.97 release notes right at the top it says this:

Entering incorrect credentials on the JSS login page redirects to /logout.html which causes the next login attempt to fail unless the URL is changed manually.

[aamjohns]

Here is from the log on the server. Maybe I need to include more but this shows how I am sent to the logout page.

2017-01-06 08:05:42,981 [INFO ] [Tomcat-10 ] [LoggingPreparedStatement ] - SELECT key_pair_value FROM user_preferences WHERE username='aamjohns' AND key_pair_name='userContentEbookSearchMethod' 2017-01-06 08:05:42,997 [INFO ] [Tomcat-10 ] [LoggingPreparedStatement ] - SELECT key_pair_value FROM user_preferences WHERE username='aamjohns' AND key_pair_name='userContentMobileAppSearchMethod' 2017-01-06 08:05:42,997 [INFO ] [Tomcat-10 ] [LoggingPreparedStatement ] - SELECT key_pair_value FROM user_preferences WHERE username='aamjohns' AND key_pair_name='userContentOSXAppSearchMethod' 2017-01-06 08:05:42,997 [INFO ] [Tomcat-10 ] [LoggingPreparedStatement ] - INSERT INTO jss_access_logs (timestamp_epoch, username, ip_address, entry_point, status) VALUES (1483707942997, 'aamjohns', '149.166.x.x, 'JSS', 'Successful Login') 2017-01-06 08:05:42,997 [INFO ] [Tomcat-9 ] [LoggingPreparedStatement ] - SELECT FROM eula_acceptance_logs WHERE eula_version='2015.03.16' 2017-01-06 08:05:42,997 [DEBUG] [Tomcat-9 ] [HTMLController ] - Requested URI: index.html 2017-01-06 08:05:42,997 [DEBUG] [Tomcat-9 ] [HTMLController ] - Executing HTMLResponse: DashboardAction 2017-01-06 08:05:42,997 [DEBUG] [Tomcat-9 ] [HTMLResponse ] - Requested URI: /index.html 2017-01-06 08:05:42,997 [DEBUG] [Tomcat-9 ] [DashboardAction ] - Preparing dashboard for aamjohns 2017-01-06 08:05:42,997 [INFO ] [Tomcat-9 ] [LoggingPreparedStatement ] - SELECT key_pair_value FROM user_preferences WHERE username='aamjohns' AND key_pair_name='dashboard' 2017-01-06 08:05:43,013 [INFO ] [Tomcat-9 ] [LoggingPreparedStatement ] - SELECT COUNT(computer_id) as cnt FROM computers_denormalized WHERE is_managed=1 2017-01-06 08:05:43,013 [INFO ] [Tomcat-9 ] [LoggingPreparedStatement ] - SELECT COUNT(computer_id) as cnt FROM computers_denormalized WHERE is_managed=0 2017-01-06 08:05:43,013 [INFO ] [Tomcat-9 ] [LoggingPreparedStatement ] - SELECT COUNT(mobile_device_id) as cnt FROM mobile_devices_denormalized WHERE is_managed=1 AND is_personal=0 2017-01-06 08:05:43,013 [INFO ] [Tomcat-9 ] [LoggingPreparedStatement ] - SELECT COUNT(mobile_device_id) as cnt FROM mobile_devices_denormalized WHERE is_managed=0 2017-01-06 08:05:43,028 [DEBUG] [Tomcat-9 ] [TomcatSettingsHelper ] - Reading server.xml: C:Program FilesJSSTomcatconfserver.xml 2017-01-06 08:05:43,106 [DEBUG] [Tomcat-9 ] [TomcatSettingsHelper ] - Ignoring alias: cacert 2017-01-06 08:05:43,106 [DEBUG] [Tomcat-9 ] [TomcatSettingsHelper ] - Reading server.xml: C:Program FilesJSSTomcatconfserver.xml 2017-01-06 08:05:43,106 [DEBUG] [Tomcat-9 ] [TomcatSettingsHelper ] - Ignoring alias: cacert 2017-01-06 08:05:43,387 [DEBUG] [Tomcat-19 ] [DefaultLDAPLookupService ] - Open LDAP Connection to ads.iu.edu (AD) 2017-01-06 08:05:43,387 [INFO ] [Tomcat-19 ] [LoggingPreparedStatement ] - SELECT FROM keystores WHERE type='LDAPS' 2017-01-06 08:05:43,387 [DEBUG] [Tomcat-19 ] [DefaultLDAPLookupService ] - Search Filter: (&(&(objectClass=organizationalPerson)(objectClass=person)(objectClass=top)(objectClass=user))(uSNCreated=)) 2017-01-06 08:05:43,403 [DEBUG] [Tomcat-19 ] [DefaultLDAPLookupService ] - Closing LDAP Connect 2017-01-06 08:05:43,449 [DEBUG] [Tomcat-1 ] [HTMLController ] - Requested URI: logout.html 2017-01-06 08:05:43,449 [DEBUG] [Tomcat-1 ] [HTMLController ] - Executing HTMLResponse: LogoutHTMLResponse 2017-01-06 08:05:43,449 [DEBUG] [Tomcat-1 ] [HTMLResponse ] - Requested URI: /logout.html

[aamjohns]

In the logging this is where I see the difference between my one account that works and the other account I added for testing, that does not work
Success:

2017-01-06 09:23:37,793 [INFO ] [Tomcat-22 ] [LoggingPreparedStatement ] - INSERT INTO jss_access_logs (timestamp_epoch, username, ip_address, entry_point, status) VALUES (1483712617793, 'tsstad02', '149.166.x.x', 'JSS', 'Successful Login') 2017-01-06 09:23:37,809 [INFO ] [Tomcat-8 ] [LoggingPreparedStatement ] - SELECT * FROM eula_acceptance_logs WHERE eula_version='2015.03.16' 2017-01-06 09:23:37,809 [DEBUG] [Tomcat-8 ] [HTMLController ] - Requested URI: index.html 2017-01-06 09:23:37,809 [DEBUG] [Tomcat-8 ] [HTMLController ] - Executing HTMLResponse: DashboardAction 2017-01-06 09:23:37,809 [DEBUG] [Tomcat-8 ] [HTMLResponse ] - Requested URI: /index.html 2017-01-06 09:23:37,809 [DEBUG] [Tomcat-8 ] [DashboardAction ] - Preparing dashboard for tsstad02

Failure:

2017-01-06 09:23:24,299 [INFO ] [Tomcat-11 ] [LoggingPreparedStatement ] - INSERT INTO jss_access_logs (timestamp_epoch, username, ip_address, entry_point, status) VALUES (1483712604299, 'aamjohns', '149.166.x.x', 'JSS', 'Successful Login') 2017-01-06 09:23:24,330 [INFO ] [Tomcat-6 ] [LoggingPreparedStatement ] - SELECT * FROM eula_acceptance_logs WHERE eula_version='2015.03.16' 2017-01-06 09:23:24,330 [DEBUG] [Tomcat-6 ] [HTMLController ] - Requested URI: logout.html 2017-01-06 09:23:24,330 [DEBUG] [Tomcat-6 ] [HTMLController ] - Executing HTMLResponse: LogoutHTMLResponse 2017-01-06 09:23:24,330 [DEBUG] [Tomcat-6 ] [HTMLResponse ] - Requested URI: /logout.html 2017-01-06 09:23:24,330 [DEBUG] [Tomcat-16 ] [HTMLController ] - Drawing login page.

[mrmiller]

You are not alone...I've spent hours trying to figure it out.

[aamjohns]

Hi,
I just took a look at the eula_acceptance_logs table and the only entry in it is my tsstad02 account. I'm guessing if I copied the values in the row but changed the username to be another, I might be able to then log in with that username.

I don't particularly want to start messing with the tables without a better understanding of what's going on here and what is causing this. If I did the above, would it fail all over again with a never version of JSS installed?

[were_wulff]

@aamjohns ,

On the LDAP accounts that aren't working right, were any changes, even minor ones, made to the OU for your techs prior to the issue starting?

I ask because we do have an issue where the JSS is caching that information and, if the OU for the user(s)/user group(s) changes, it can cause them to be unable to log in until we get the JSS' cache cleared out.

If the OU has changed recently, the workaround is a little odd as it doesn't sound like it'd be related, but if you select any already existing configuration profile or policy, click edit, then save (without making changes), it causes the JSS to update it caching and the accounts that aren't logging in properly usually start working again.

If the OU hasn't changed recently that you're aware of, it'd be a good idea to get in touch with your TAM if you haven't already, so they can dig into it a bit deeper with you.

Thanks!
Amanda Wulff
Jamf Support

[aamjohns]

Hello Amanda,
Not to my knowledge. The accounts are managed by the University. They reside in the domain's root Accounts OU. We have a section of the domain structure where we can manage OU's and policy. Nothing there has changed. Nothing was moved or permissions changed.

I will perform the steps you suggested to see what that does. I looked at the properties of on of the tech's accounts and I didn't see anything unusual. In addition, this morning I added my personal domain account to one of the ADS groups so I could use it to login. Since this account has never logged into the JSS, there should not be any incorrect information stored (I would think) yet the same problem exists for it. I did notice in the LDAP query an empty value

Open LDAP Connection to ads.iu.edu (AD) 2017-01-06 09:23:11,912 [INFO ] [Tomcat-20 ] [LoggingPreparedStatement ] - SELECT * FROM keystores WHERE type='LDAPS' 2017-01-06 09:23:11,912 [DEBUG] [Tomcat-20 ] [DefaultLDAPLookupService ] - Search Filter: (&(&(objectClass=organizationalPerson)(objectClass=person)(objectClass=top)(objectClass=user))(uSNCreated=))

Now look at my account that works. uSNCreated= is not in the LDAP query

SELECT * FROM keystores WHERE type='LDAPS' 2017-01-06 09:23:37,512 [DEBUG] [Tomcat-1 ] [DefaultLDAPLookupService ] - Search Filter: (&(&(objectClass=organizationalPerson)(objectClass=person)(objectClass=top)(objectClass=user))(sAMAccountName=tsstad02))

I will try flushing the cache and write back.

Thank you,
AJ.

[aamjohns]

I opened a policy 'Edit' and then saved the policy. No changes. Logged out and then tried to log in with an account that gets kicked out and it is still doing it.

[aamjohns]

It appears I found a work-around. If I added the ads account by username, as a JSS user, the account that previously would get kicked back to logout.html can login and work.

Fortunately we only have about 10 accounts so to keep everyone working I can add them by username and hopefully that will allow them to work until this issue is further investigated.

To others like @mrmiller, if you are using groups to give access, you might want to try specifying by account and see if that works for you. I would be curious to know.

Thanks,
AJ.

[were_wulff]

@aamjohns

Shoot, but not surprising; the issue we have is specific to an OU being changed on the AD side of things, and if an OU wasn't changed that wouldn't be the issue. Good to rule it out at least.

If you look at the LDAP server settings once you're into the JSS, if you look through the LDAP Attribute Mappings, is your UserID mapping set to uSNCreated? If it is, that'd be why we're seeing that in at least some of the logs; if it's not supposed to be using that particular mapping and should be using something else for that mapping that could result in a failure. From the log snippets, it looks like uSNCreated might need to be sAMAccountName instead.

A quick look through similar cases on our end seems to point toward there being an issue with the distinguished names set in the LDAP server settings for the affected accounts or something incorrect about the LDAP service account entered into the JSS; if those haven't been double checked for all of the LDAP servers you've got set up, it'd be worth going over them just to make sure nothing got changed and that everything is what it should be as well.

Thanks!
Amanda Wulff
Jamf Support

[aamjohns]

Hi Amanda,
The account used for LDAP is functioning, and the settings are the same as they have been for years. The mapping for uSNCreated goes to user_object_map_id_to. sAMAccountName goes to user_object_map_username_to.

I am not trying to argue with you at all. I appreciate you suggestions. I'm just thinking that all 3 tests in the LDAP portion of the JSS succeed, and the fact that putting the ads user in by account name allows them to log in tells me the LDAP is working. The problem may have to do with groups. My account, which never stopped working, was added in by username. Everyone else's access to the JSS is done by ADS group membership. And as I posted above, if I add a user by username, rather than relying on group membership, they can log in.

I have reviewed our LDAP config thoroughly 3 times. I have double checked it against other software to make sure no values have changed. I does seem like the issue is LDAP but it may be related to enumerating the members of groups. I want to do some more testing.

I did try taking an account that I added by username and removing it and relying on its group membership and it once again failed.

One other thing, I confirmed that uSNCreated is a readable property of a domain account and each account has a value. The fact that we see the LDAPS query including that property but not specifying a value is probably why it fails.

I guess I will send all this to my TAM and add our techs by username as a work around until the resolution is found. Also, as mrmiller has stated, and other thread(s) have shown, I'm not the only one running into this issue.

Thanks,
AJ.

[were_wulff]

@aamjohns

Didn't figure you were; the suggestions I was making were/are based primarily off of other cases we've had with the same symptoms and similar log entries, so I figured they were at least worth ruling out, especially since they were all pretty easy (but potentially easily overlooked) things to tweak if necessary.

We do have one other issue where, if you accidentally put in the wrong credentials once, it'll redirect you to the logout page and keep you there without notice, and you have to enter in the right credentials 2+ times before it works, but that doesn't seem like it'd apply here either.

In the back of my head, I keep thinking that we have a couple known issues with LDAP groups but, for the life of me, I can't find any related to logins, the ones I've found are relating to scoping, which doesn't apply to this issue. There are a couple open cases from other customers on the issue that you're seeing, and I have checked those, but they're all still being worked on and there hasn't been a 'solution provided' yet that I've found. :)
I can't mention case numbers here for privacy reasons, but your TAM can message me to ask for the ones that I found so they can look over those case notes and see if anything there would be helpful for your case.

It'd definitely be worth getting in touch with your TAM; this is one of those things that'd likely be a lot faster/easier to go over on a WebEx rather than a back and forth in text.

Edit: A couple of cases that were solved looks like they were solved by removing theLDAP group from User Groups then re-adding the LDAP Group and saving. That might be worth a shot.

Thanks!
Amanda Wulff
Jamf Support

[aamjohns]

Hi Amanda,
Thank you for the information today, and your help. I have reached out to my TAM and I will include what you said about cross comparison of cases.

Thank you again,
AJ.

[were_wulff]

@aamjohns

I DID find one closed case that had this as the solution:

1. Remove LDAP group from User Groups
2. Re-added the LDAP Group

That may be worth a shot if it hasn't been tried already.

Amanda Wulff
Jamf Support

[aamjohns]

Hi Amanda,
I will give this a try and let you know.

AJ.

[aamjohns]

I am sorry to report Amanda that it did not work. I also verified all systems involved have the same time. Thank you for giving me something to try.
-BTW I have sent in information at the request of my TAM.

AJ.

[were_wulff]

@aamjohns

Yeah, I caught the last e-mail sent to your TAM. :(

It's so odd that that one uSNCreated shows up with no information on the failed logins; that does still kind of point to something having been messed up on the backend (of the JSS, not of your AD environment!), which is why I was hoping just deleting the user groups, saving, and re-adding those user groups then saving again would clear it up.

I haven't checked to see if your TAM has mentioned it yet, but I did file a PI for this issue as I was able to find 7 cases, including yours, that are all experiencing this exact behavior. Most of those cases are still actively being worked on, and the only one that was closed is the one that was able to be fixed by deleting and re-adding the LDAP groups.

We have it filed under PI-003395 and one of my team mates is working on testing it out to see if he can replicate it in house as well.

I was able to replicate it 1 out of 3 times while doing a JSS upgrade to 9.97, so it seems to be an intermittent failure when it does fail, but we haven't yet figured out the why or what of it.
In my case, the deleting/re-adding the groups fixed whatever was going wrong on the backend, and, of course, blowing away the whole LDAP server and re-adding it likely would have worked too, but that's not really a viable workaround for most live environments considering how much scoping and app deployment is often done by LDAP users & groups.

I did note, in the workaround section for PI-003395, that deleting/re-adding the LDAP user groups does not work 100% of the time, so it seems likely that there's more than one thing on the backend that can go wrong when this happens but, again, we're not sure what just yet as we're still in the early stages of figuring out what's happening too.

I also found, looking through other case notes, that the JSS Access log does usually show a successful login, then an immediate logout when this issue pops up, and we're not sure why that's happening yet either.

Your case is currently attached to PI-003395.

Thanks again for your patience with this issue,

Amanda Wulff
Jamf Support

[mrmiller]

Yes @aamjohns , creating individual accounts will work the problem is just related to using groups.

[aamjohns]

@Amanda,
Amanda I tried something you suggested earlier, I changed the value in the LDAP mapping for User ID. Instead of using uSNCreated, I put in sAMAccountName and now the techs can log in. I informed the tech person I am emailing with at Jamf about this change and asked whether it could have a negative down the road.

I thought I would tell you though.

Thanks,
AJ.

[were_wulff]

@aamjohns

Glad to hear that worked!

I'd still be curious to find out how it got changed in the first place as, since it was obviously working previously, it had to have been changed somehow.

Do you happen to have change management logs enabled? That might help give a clue as to what the JSS thinks happened (or would tell you if someone did change the attribute and forgot they'd done so).
If it turns out someone changed it and forgot, well, that sort of thing honestly happens more than you'd expect.
If it doesn't show that anyone made the change, and it just seems to have randomly done it during/after the upgrade process, that's a little more concerning.

Amanda Wulff
Jamf Support

[aamjohns]

Hi Amanda,
I took screenshots of the server config in case I left here and someone else was going to take over. So it has always had that setting. And the support person I have been emailing with said that was the correct setting also. So the question is, is suppose, why is it now causing an issue? The search filter is not succeeding with a blank parameter so this seems to be a work-around. I've check the logs and I don't really see anything unusual. It looks pretty much the same as when I log in with my account that is not in a group, but is an ADS account.

uSNCreated is also used on the User Group Mappings tab, for the Group ID. And I still have it in there. I only made the change on the user mapping section.

This may be a temporary work-around until this issue is resolved. I just needed a way for our techs to be able to log in and do what they needed. It does not appear that this is causing any issues.

2017-01-06 16:02:56,235 [INFO ] [Tomcat-25 ] [LoggingPreparedStatement ] - INSERT INTO jss_access_logs (timestamp_epoch, username, ip_address, entry_point, status) VALUES (1483736576235, 'aamjohns', '149.166.x.x', 'JSS', 'Successful Login') 2017-01-06 16:02:56,235 [INFO ] [Tomcat-24 ] [LoggingPreparedStatement ] - SELECT FROM eula_acceptance_logs WHERE eula_version='2015.03.16' 2017-01-06 16:02:56,235 [DEBUG] [Tomcat-24 ] [HTMLController ] - Requested URI: index.html 2017-01-06 16:02:56,235 [DEBUG] [Tomcat-24 ] [HTMLController ] - Executing HTMLResponse: DashboardAction 2017-01-06 16:02:56,235 [DEBUG] [Tomcat-24 ] [HTMLResponse ] - Requested URI: /index.html 2017-01-06 16:02:56,235 [DEBUG] [Tomcat-24 ] [DashboardAction ] - Preparing dashboard for aamjohns 2017-01-06 16:02:56,235 [INFO ] [Tomcat-24 ] [LoggingPreparedStatement ] - SELECT key_pair_value FROM user_preferences WHERE username='aamjohns' AND key_pair_name='dashboard' 2017-01-06 16:02:56,251 [INFO ] [Tomcat-24 ] [LoggingPreparedStatement ] - SELECT COUNT(computer_id) as cnt FROM computers_denormalized WHERE is_managed=1 2017-01-06 16:02:56,251 [INFO ] [Tomcat-24 ] [LoggingPreparedStatement ] - SELECT COUNT(computer_id) as cnt FROM computers_denormalized WHERE is_managed=0 2017-01-06 16:02:56,251 [INFO ] [Tomcat-24 ] [LoggingPreparedStatement ] - SELECT COUNT(mobile_device_id) as cnt FROM mobile_devices_denormalized WHERE is_managed=1 AND is_personal=0 2017-01-06 16:02:56,251 [INFO ] [Tomcat-24 ] [LoggingPreparedStatement ] - SELECT COUNT(mobile_device_id) as cnt FROM mobile_devices_denormalized WHERE is_managed=0 2017-01-06 16:02:56,266 [DEBUG] [Tomcat-24 ] [TomcatSettingsHelper ] - Reading server.xml: C:Program FilesJSSTomcatconfserver.xml 2017-01-06 16:02:56,344 [DEBUG] [Tomcat-24 ] [TomcatSettingsHelper ] - Ignoring alias: cacert 2017-01-06 16:02:56,344 [DEBUG] [Tomcat-24 ] [TomcatSettingsHelper ] - Reading server.xml: C:Program FilesJSSTomcatconfserver.xml 2017-01-06 16:02:56,344 [DEBUG] [Tomcat-24 ] [TomcatSettingsHelper ] - Ignoring alias: cacert 2017-01-06 16:02:56,797 [DEBUG] [Tomcat-2 ] [DefaultLDAPLookupService ] - Open LDAP Connection to ads.iu.edu (AD) 2017-01-06 16:02:56,797 [INFO ] [Tomcat-2 ] [LoggingPreparedStatement ] - SELECT FROM keystores WHERE type='LDAPS' 2017-01-06 16:02:56,797 [DEBUG] [Tomcat-2 ] [DefaultLDAPLookupService ] - Search Filter: (&(|(objectClass=organizationalPerson)(objectClass=person)(objectClass=top)(objectClass=user))(sAMAccountName=aamjohns)) 2017-01-06 16:02:56,797 [DEBUG] [Tomcat-2 ] [DefaultLDAPLookupService ] - LDAP parse User 2017-01-06 16:02:56,797 [DEBUG] [Tomcat-2 ] [DefaultLDAPLookupService ] - Parse LDAP extension attributes 2017-01-06 16:02:56,797 [DEBUG] [Tomcat-2 ] [DefaultLDAPLookupService ] - Done parsing LDAP extension attributes 2017-01-06 16:02:56,797 [DEBUG] [Tomcat-2 ] [DefaultLDAPLookupService ] - Closing LDAP Connect 2017-01-06 16:02:56,797 [DEBUG] [Tomcat-2 ] [DefaultLDAPLookupService ] - Lookup LDAPServer [ID=1, Name=ads.iu.edu (AD)] for group [IN-MDEP-Casper-Admins] 2017-01-06 16:02:56,797 [DEBUG] [Tomcat-2 ] [DefaultLDAPLookupService ] - Open LDAP Connection to ads.iu.edu (AD) 2017-01-06 16:02:56,797 [INFO ] [Tomcat-2 ] [LoggingPreparedStatement ] - SELECT FROM keystores WHERE type='LDAPS' 2017-01-06 16:02:56,797 [DEBUG] [Tomcat-2 ] [DefaultLDAPLookupService ] - Starting batch... 2017-01-06 16:02:56,797 [DEBUG] [Tomcat-2 ] [DefaultLDAPLookupService ] - Filter: (&(&(|(objectClass=organizationalPerson)(objectClass=person)(objectClass=top)(objectClass=user))(|(sAMAccountName=aamjohns)))(|(memberOf:1.2.840.113556.1.4.1941:=CN=IN-MDEP-Casper-Admins,OU=Casper,OU=Groups,OU=IN-MDEP,OU=IN,DC=ads,DC=iu,DC=edu))) 2017-01-06 16:02:56,797 [DEBUG] [Tomcat-2 ] [DefaultLDAPLookupService ] - Closing LDAP Connect 2017-01-06 16:02:56,797 [DEBUG] [Tomcat-2 ] [DefaultLDAPLookupService ] - Lookup LDAPServer [ID=1, Name=ads.iu.edu (AD)] for group [IN-MDEP-Casper-Techs] 2017-01-06 16:02:56,797 [DEBUG] [Tomcat-2 ] [DefaultLDAPLookupService ] - Open LDAP Connection to ads.iu.edu (AD) 2017-01-06 16:02:56,797 [INFO ] [Tomcat-2 ] [LoggingPreparedStatement ] - SELECT FROM keystores WHERE type='LDAPS' 2017-01-06 16:02:56,797 [DEBUG] [Tomcat-2 ] [DefaultLDAPLookupService ] - Starting batch... 2017-01-06 16:02:56,797 [DEBUG] [Tomcat-2 ] [DefaultLDAPLookupService ] - Filter: (&(&(|(objectClass=organizationalPerson)(objectClass=person)(objectClass=top)(objectClass=user))(|(sAMAccountName=aamjohns)))(|(memberOf:1.2.840.113556.1.4.1941:=CN=IN-MDEP-Casper-Techs,OU=Casper,OU=Groups,OU=IN-MDEP,OU=IN,DC=ads,DC=iu,DC=edu))) 2017-01-06 16:02:56,812 [DEBUG] [Tomcat-2 ] [DefaultLDAPLookupService ] - LDAP parse User 2017-01-06 16:02:56,812 [DEBUG] [Tomcat-2 ] [DefaultLDAPLookupService ] - Parse LDAP extension attributes 2017-01-06 16:02:56,812 [DEBUG] [Tomcat-2 ] [DefaultLDAPLookupService ] - Done parsing LDAP extension attributes 2017-01-06 16:02:56,812 [DEBUG] [Tomcat-2 ] [DefaultLDAPLookupService ] - Closing LDAP Connect

[were_wulff]

@aamjohns

That's a little concerning that it used to work then, after the upgrade, with no mappings changed on the AD side of things or in the JSS UI, it stopped working and was passing that blank variable for the field.

I wish I could tell you why it stopped working after the upgrade, but I honestly have no idea what would have caused that; that will go into the information pile we're looking at to try and figure out that PI and why others are having similar issues with their AD user group logins after the upgrade, and I did pass it along, along with this thread URL (which is in the PI too) to the others that are working on it.

There shouldn't be any issues that I can think of that'd pop up from changing that mapping; the JSS can't make changes to the AD side so nothing there would be affected, and if you're not seeing issues with any scoping after making the change it should be safe to leave it for now as a workaround for now.

Amanda Wulff
Jamf Support

[aamjohns]

Hi Amanda,
Sorry for the delay - was out sick. Looking at the logs it seems like it is almost a natural fit. It seems like the search filter is fine and gets the results it needs so unless i hear otherwise, I will just leave it. Also it is also used in User Group Mappings for the Group ID. I have not seen anything in the logs that mentions this or indicates an error, but it might be something to include when checking all of this out.

Thank you,
AJ.

[m_entholzner]

We have seen this with multiple customers too. The behaviours were a bit different.

Customer 1: the JSS kicked us really instantly
Customer 2: the kicks varied from instantly to five minutes, or when editing a policy, cloning an item or any random event.

I changed the UserID mapping on both customers to sAMAccountName and both JSS instances didn't kick me since then.

Regards,
Michael

[were_wulff]

@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

[aamjohns]

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.

[brettml]

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

[grahamrpugh]

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?

[aamjohns]

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

[grahamrpugh]

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

[andykang]

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.

[Brad_G]

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

[andykang]

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

[mfcfadmin]

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.

[JulianRadu]

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.

[sdagley]

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 .

[andykang]

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.

[rohdeb]

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