[SOLVED] Changes to i.e. FW-Rules or Dashboard with AD-Acc not working in GUI
-
Since the update from 2.2.3 to 2.3.3 it is no longr possible to make any changes to the Dashboard or Firewall-Rules in the WebGUI. Nothinh gets saved. This problem only occurs with Active Directory Accounts, with the local admin - Account it is possible to make the changes.
I would provide more Information but i cant find any errors in the System Logs.
Thanks in advance
-
-1. Have been using AD accounts pretty much exclusively for a couple of years, can assure you that it works just fine. Some info missing here to debug anything.
-
I would provide more information, but I don't know where to get the information you need. As mentioned before, I can't find any error in the logs. I use AD - Accounts also exclusively, but doesn't change the fact, that it isn't working anymore since I updated to 2.3.3 :-\
Before the update I was able to do evry change with AD - Accounts, now nothing gets saved (changes in dashboard or firewall rules)
Also found this thread, at the last post is mentioned the same problem but sadly no solution.
https://forum.pfsense.org/index.php?topic=112256.0I tried the following to get a solution:
- checked via GUI the logs -> no error message listed
- checked the logs in /var/log/… -> no error message listed
- tested authentication -> works
- deleted group for AD Users and created it again with all priviliges -> still not ables to save any changes
-
No one any hints or tips what to check to find a solution without doing a reinstall?
Thanks in advance
-
Your group permissions most likely have "Deny Config Write" set. Edit the group, uncheck that.
Don't ctrl-a the permissions list.
-
Thank you very much. This was the solution.
I check on an older install (2.2.3), if the permission is also there. It is there, but the users belonging to that group can do config changes. Wasn't that working on older versions?
-
The fact that it was working was an obvious bug.
-
The permission was not bring properly honored in old versions because of a bug. We fixed the glitch.
Invalid configurations "broke" when we fixed said glitch, but they were never valid. It was that or clear the privilege on upgrade, and for a bug like that we went with the secure choice.
