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

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.

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.

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.

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?

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.

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.

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.

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)

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.

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