-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Issue 9539 #4068
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Issue 9539 #4068
Conversation
|
I'm not convinced this is the best course of action. Some people like to keep separate admin account passwords on each node, and this breaks that behavior. I can see syncing some account properties such as SSH keys but I don't believe we should clobber the credentials. Changing the behavior in this way by default will catch a number of people off guard in a negative way (POLA violation). Another option is to not change anything, but document on the XMLRPC sync settings and elsewhere that admin will not sync. |
|
In all fairness I'd agree with the above. I just assumed from the issue tracker that this functionality was requested. Personally, I think that if there is a requirement for keeping separate admin account passwords on each node, then in my opinion it would make sense to segregate the SSH keys and other ancillary account properties too. Otherwise, a hybrid solution feels as though it's neither segregated nor synced. In addition to the above, it's not really that much effort to log into a secondary node and add an SSH key versus the potential ramifications that may occur due to unintentionally allowing SSH access to a pfSense instance without realising. Open to suggestions, but maybe it's worth just documenting that the admin account will not sync. |
|
Yeah it's a bit confusing as-is but maybe that could be solved with documentation. I had initially thought it seemed like a bug but the more I thought about it, the more the current behavior made sense in that context. What we could do, however, is have a separate checkbox in the sync options to sync the admin account. Disabled by default, then someone could opt into the behavior. |
|
Yeah, the more I delve into this, the more it seems that the current implementation is rather well defined. I think documentation is a good addition regardless of the approach chosen. However, I like the idea of having a separate checkbox in the sync options specifically for the admin account. Seems like the best of both worlds if a specific option is available to users. This then clearly communicates the behaviour of the config sync wrt. admin accounts and ensures that a user consents to the admin account being synced to a secondary node if they wish to do so. |
Similar to closed PR #3558 from overhacked, but with a number of changes.
* Changed from /var/etc/openvpn[-csc]/<mode><id>.<file> to /var/etc/openvpn/<mode><id>/<x> * This keeps all settings for each client and server in a clean structure * Move to CApath style CA structure for OpenVPN, which implements #9915 * Reused some code from trust store functions to generate the new CApath format, since the layout is identical. Issue #4068
|
No recent updates since May 2019. Closing. |
These changes allow for the ability for the admin account to be synced between HA pairs.
The following functionality is introduced:
Important Notes:
authwhich authenticates the entity making changes to the device. Obviously this cannot be called if the config.xml file has been updated with the new credentials, but the PHP session is still using the old credentials. Therefore, I have madefilter_configurea private function to remove this possibility.James.