Unable to log into Web Admin

You might have locked yourself out and the timeout hasn't expired.

Check /var/log/aua.log for more information such as "Bad password" and "Too many failures from client IP, still blocked for n seconds".

I did that a couple times, I get the email saying I am locked out, but I have waited sufficient time (the timeout is 10 minutes), so I know that isn't the case.  Also, would it allow me into SSH if the account was locked out?  If so, that seems like quite a flaw.

The SSH and WebAdmin accounts aren't the same, are they?  (loginuser/root vs admin/whatever local)

I haven't spent much time looking into AUA beyond getting extra SSH users around it with ssh keys.  https://community.sophos.com/products/unified-threat-management/astaroorg/f/51/t/22266

Regarding your backup situation: Have you looked into backup.plx for command line backups?  How to create a new backup from the command Line on Sophos UTM 

Without getting to the root cause of the access issue you might be carrying the problem forward in the backup.   (Even if that doesn't work there are certainly options other than rebuild from scratch, too.)

Your previous posts all looked auth/DC-ish.  Got support?

The accounts are different, to a point.  I was able to get into the shell and execute a password reset for the system accounts, but they don't let me in either (As an aside, I can't get it via VPN, so it isn't just the web interface).  I've no problems with the DCs, because they work for everything else, the reboots were just in case; I have seen services stop working before and causing an issue, though that is the Windows to Windows world.  It's like the UTM just trashed the user database.
If I have to start over, I will, but since this isn't the first time this happened, I am wary of it actually solving anything.  Ever since the upgrade from Astaro to Sophos, there have been little strange things like this.  I hate to leave it, but I am not sure that I can stick with a product that will randomly trash the user database or just refuse to let any of my accounts authorize.  Maybe a fresh build is in order just like a Windows box.

I'm not seeing any such complaints elsewhere.  Try some basic things.  Close all browser windows, open one and clear the local cache.  From the command line, run ifconfig on the interface through which you've been accessing.  If this is your own hardware, run non-destructive hard drive diagnostics on it.  Etc.

If you've had no luck with that, show us what you've done to reset the admin password.  If you want to re-image on a new piece of hardware, you might consider The Zeroeth Rule in Rulz after taking teched's advice to do a backup from the command line.

Cheers - Bob

I'm not saying it is a product failure as a whole, so please don't misunderstand me.  I'm saying perhaps my major version upgrade didn't go as smoothly as others.  After all, I'd never just upgrade a new OS on a Windows box, I'd always start fresh.  It has spiraled worse, and now I can't even SSH in.  That means I am going to rebuild the box tonight, and I will take the Rulez as a starting point.  It isn't the end of the world, it mostly affects my son and his games.  It just bugs me that I can't pinpoint a cause and say that it is/will be fixed, I like things to make sense and have nice neat packages tied up.  Not the best choice for tech support. [:D]

Thanks for the suggestions, that's all I could realistically hope for.

Follow-up on what happened, or at least the part I could fix: I have no idea why the system would not allow any SSH or any locally authenticated user, so that is a bit of a mystery still.  After another hard reboot, though, it allowed me to log in as admin, and that is when I discovered my problem.
About a week ago, I moved one of my service accounts to a new OU in AD.  That naturally caused the DN to change, and the UTM no longer had any way to do LDAP calls to authenticate users.  [:O]  The only mystery I have there is why it waited a week to lose that information instead of taking effect right away.  As well, I do not know why it would not authenticate locally, but at least I am in now and can make a current backup and prepare for the unlikely event that this happens again.

Thanks to all for the suggestions.

Definitely want to always retain a locally-authenticable admin account for emergency use when the backend is down.  My other belts-and-suspenders rule is to always keep at least one interface configured as Standard Ethernet so you can admin the box if your VLAN switch is down.

Cheers - Bob

That's what started the mystery, Bob.  I had two locally defined admins for this, and neither worked until after the hard reboot.  I'm all about redundancies, that is why I have a virtual and a physical DC.  The last company I worked for had everything virtualized and duplicated on two clusters, but that didn't help them.  One day a cluster failed and since the load balancer was also virtual, nothing failed over.  Two virtualized DCs and no local access to the host.  It took 8 hours to get back up and knocked down three production facilities in two countries in the process.  I'm not sure what more could have been done to prepare, and that is the part that still bugs me.  Oh well, I deal with things far more quirky on a daily basis, so I'll just mark it solved and move on.