Using LDAP auth, creating new LOCAL user causes error: no page assigned to user
-
We've enabled auth against our Active directory, which works find, however now when i create a new local user, i get "no page assigned to user"
Googling for answers kept leading me old bugs and issues with the LDAP user as opposed to creating a new LOCAL user, so I'm just going to ask directly.
When switching to LDAP auth does this turn off local authentication? I noticed this doesn't affect other user privilages, such as allowing ssh access/rsync for the new local user, it just affects getting into the webUI dispite giving the local user admin privs.
-
I know this post is old, but figured easier to re-hash and search for a single post vs multiple for others with this issue. I am getting LDAP setup and local user that is part of admins doesn't work. the built in default "admin" acct does still function ok. anyone know why or the workaround? simply turning off the LDAP server option allows a local user to auth on webpageGUI fine.
-
Pull request: https://github.com/pfsense/pfsense/pull/1628
The code for authenticating user/password was correctly falling back to the local user database if the LDAP authentication failed. But the code that decided what groups the user is in and what pages the user should have access to was insisting on only using groups from LDAP.
This pull request makes it happy on my test system. See if it works for you.
It changes the code for deciding what GUI pages a user gets to see - so there could be unintended side-effects that might allow a user to see different/more GUI pages than expected. I can't think of what might go wrong, but it is a security-related change, so needs more discussion, thought, review, test than the average dumb-bugfix. -
I am still trying to get my LDAP/AD working so that does explain the failure. The normal default admin acct can login without the error and both are same group so it seemed a bit weird.
-
You applied the patch ?
-
Pull request: https://github.com/pfsense/pfsense/pull/1628
The code for authenticating user/password was correctly falling back to the local user database if the LDAP authentication failed. But the code that decided what groups the user is in and what pages the user should have access to was insisting on only using groups from LDAP.so i got my AD working ok now had the values right but figured out with ping diagnostics that it wasn't using the DNS properly. DNS resolver setup for internal domain fixes that with FQDN names.
still can login with default admin group but not the second local admin acct when AD activated. we can fall back to using ADMIN in emergency scenario I guess. we have carp using that acct so figured less it was used the better. with only two admins here touching the box this shouldn't be a huge deal as we both have same priv levels.
think i will wait and not apply the patch based on this.
thanks for the tips!
-
I don't have any actual LDAP server set up. So my testing is only with the case when my "fake" LDAP server is not responding.
It would be nice for someone with a working LDAP server to test the patch and confirm that:- Normal logins for users that exist on the LDAP server still work.
- Logins for users that are just local on the pfSense box now work also.
-
I don't have any actual LDAP server set up. So my testing is only with the case when my "fake" LDAP server is not responding.
It would be nice for someone with a working LDAP server to test the patch and confirm that:- Normal logins for users that exist on the LDAP server still work.
- Logins for users that are just local on the pfSense box now work also.
I'd love to, but the patch does not apply…
Output of full patch apply test: /usr/bin/patch --directory=/ -t -p1 -i /var/patches/55388a18350f0.patch --check --forward --ignore-whitespace Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |From fe65bb3a4b183024989c001053c652f471317af1 Mon Sep 17 00:00:00 2001 |From: Phil Davis |Date: Tue, 21 Apr 2015 12:38:08 +0545 |Subject: [PATCH] Fall back to getting local user pages and groups | |if the groups could not be found from LDAP and there is a local user. |--- | etc/inc/priv.inc | 9 +++++---- | 1 file changed, 5 insertions(+), 4 deletions(-) | |diff --git a/etc/inc/priv.inc b/etc/inc/priv.inc |index ee6e876..a15254d 100644 |--- a/etc/inc/priv.inc |+++ b/etc/inc/priv.inc -------------------------- Patching file etc/inc/priv.inc using Plan A... No such line 292 in input file, ignoring Hunk #1 failed at 292. Hunk #2 succeeded at 289 (offset -43 lines). 1 out of 2 hunks failed while patching etc/inc/priv.inc done -
My pull request is against master, which has a whole lot of code-style changes that will come in 2.3 but are not in RELENG_2_2 branch.
You can just put the whole /etc/inc/priv.inc from that pull request onto your system.
Or I made a version of the changes against RELENG_2_2:
https://github.com/phil-davis/pfsense/commit/5c8c92131618582bb0ccb685129ab3025339b2e1
That should apply cleanly. -
Thanks. Applies and works just fine for both 1/ and 2/.
