WebGUI Login Local Database working when Radius is working
-
Local database is used if an error is received from the RADIUS server, which includes a login failure. Otherwise how could you recover if the RADIUS server was actually up/responding but rejecting requests improperly?
-
Okay but in my case I'm not receiving an error. It's authenticating users via the radius server and allowing me to login to the webgui. it's just also allowing the local admin account to login.
Looking at the system log i do not see any radius errors. Is there somewhere else i should be looking? Authentication in diag. also works perfectly fine and shows my account assigned to "admins" group.
-
With the admin user or other users as well? IIRC the admin user is a special case, but I'd have to trace out the code to check for sure.
The usual way this happens is, try to login, get a failure from the RADIUS server (e.g. auth failed because the password is wrong or that user doesn't exist), at which point it allows the local login.
-
I only have the admin local user, i have not tired others. I will try next week.
the usual way this happens is, try to login, get a failure from the RADIUS server (e.g. auth failed because the password is wrong or that user doesn't exist), at which point it allows the local login.
So all i have to do is try a random login that fails with radius and it will fall back to local?
If the admin user is a special case that makes sense. If all local users allowed to login after a failed radius login attempt, that seems a bit too vulnerable to me. I can understand if the radius server is not responding to allow ALL local users, but a failed attempt is a bit too much IMO.
-
I just tested this. With Radius selected both Radius and Local User Database are allowed to login.
-
Following along in the code, it always checks both the configured auth server and the local database for a GUI login. If either one succeeds, then the login is allowed. It doesn't wait for a fallback.
-
Is there any desire for a fallback option from the pfsense team? I could organize a bounty for the changes but if it's just going to be a patch rather then in base I would rather just hack something together myself.
-
Why would it be necessary? Under what circumstances would that be required or preferred?
If you don't have any other local accounts and keep the admin password synchronized (or randomized for that matter, and secured properly) there is no downside to the current method.
-
The issue is sometimes i have someone who isn't me logging into the pfSense with the admin/local account. (pfSense cannot reach the radius server/ISP Down) Once they have this login, they can log into it regardless if radius is working or not.
If fall-backed worked, as long as the radius server was responding that admin password is useless. I have to worry a lot less that all my pfsense's admin passwords are secure because they won't work if radius is responding.
The only proper solution i see currently is have all my pfsense's admin password be different. This is like 100+ for me, so that's another database i have to manage and keep secure. Even if i did do this, i still think it's slightly more secure to have radius be the primary and fall back to local, as it's one or more less account's that can be used to access the system.
I'm interchanging admin/local users here, if admin was a special account and all other local users were fall-backed that would be fine too, as i would never give out the admin account to anyone.
-
Still doesn't make much sense to me. Ideally they should all be different anyhow and tracked separately (and random, secure, etc). Password managers are tailor made for that role. Perhaps that's why I'm not seeing the benefit – doing what you suggest for the reason you suggest would enable poor security practices.