Suddenly can't log in to JSS, multiple servers, different JAMF versions, different browsers

lisanelson2
New Contributor III

We have 2 on-premises JAMF instances, running different versions of JAMF, on different servers.

The day before yesterday, I was suddenly unable to log into the JSS on one of them; I enter my username and password, it sits there for a second, and returns me to the username/password dialogue with no comment or error. Restarting tomcat didn't help. Rebooting the server did. Meanwhile, the other server was still fine. (So it's not my browser.)

Today, both of them have the same problem. As far as I'm aware, beyond Windows updates, nothing has changed.

Is anyone else seeing this? Or is it just our environment?

Thanks,
Lisa.

11 REPLIES 11

sdagley
Esteemed Contributor II

@lisanelson2 Are you trying to sign in using an AD based account, or a local account on your JSS? It could be that the certificate for your AD/LDAP server has expired (we experienced the same behavior you describe when our AD team updated their certificate without notification). If you have a backup non-AD account try using it to test this theory.

lisanelson2
New Contributor III

AD-based, but why would rebooting the server briefly fix a problem with an expired certificate? I would have thought an expired certificate would be a permanent hard no in all cases.

sdagley
Esteemed Contributor II

No, a reboot should not help with the problem if it's an issue with the AD cert. I meant to add a note on that to my previous reply but I'm multitasking this morning. I'd still suggest trying to log in with a non-AD account.

lisanelson2
New Contributor III

Aren't we all.

I don't think I have any non-AD accounts configured. This instance is VERY old now and if it ever did have local accounts, I have long since forgotten the passwords. Still, now that I can get back in, I can at least look at rectifying that for the future. Meanwhile, though, I had a look at the server logs and it appears to be due to an LDAP timeout. Which makes no sense at all.

sdagley
Esteemed Contributor II

So not a cert issue, but you mentioned Windows updates so maybe the AD controllers were being patched and you just had bad timing trying to log in?

lisanelson2
New Contributor III

I wouldn't have thought so. Not least because of the other day when only one instance of the problem and the other didn't. Also, if it was a timing issue, I wouldn't expect a reboot to fix it – that would indicate extremely lucky timing all 3 times I have now done it. Everything points to it being something on the server itself, otherwise rebooting should have no effect. You see why I'm puzzled.

sdagley
Esteemed Contributor II

Yep, not may things more annoying than an inconsistent issue. Maybe ask your AD team if there's something wonky on their end. We had an issue in our environment a few years ago where one of the load balanced domain controllers wasn't updating properly and they were seeing inconsistent login problems on Windows systems until they managed to isolate that server.

mm2270
Legendary Contributor III

Not a solution for your issue, but a general comment.

I would make sure you have at least one local only account in Jamf, which can act as your, let's call it "root" account for lack of a better term. This is important when pairing Jamf Pro with local LDAP or an IdP, because if those connections break for any reason, you won't have a way to get back into the console to correct it, at least not short of doing some kind of direct MySQL db manipulation. Recommendation would be to use a secure and complex password for it, and have as few people know it as possible to limit the exposure and risk.

SCCM
Contributor III

Reboot the server, log in and quickly create a local admin user account for testing. To see if thats working when your AD one isnt. there might be somthing in the jamf logs (if its getting that far)

lisanelson2
New Contributor III

We are none the wiser as to why this happened, and it hasn't happened since.

However, I took everyone's quite sensible points about needing a local account on board and did some research into the documentation we did back when we set these things up 10 years ago and indeed, we do actually have a local get-out-of-jail-free admin account, so we are not going to find ourselves locked out!

Thanks to everyone who took time to reply. If it happens again, this time I'll know to look at the server logs.

Thanks,
Lisa.

JustinV
Contributor

Awesome discussions on this thread, dropping this relevant link on creating local accounts: https://learn.jamf.com/bundle/jamf-pro-documentation-10.48.0/page/Local_Accounts.html

Best,

Justin