这是indexloc提供的服务,不要输入任何密码
Skip to content

Conversation

@jwsi
Copy link
Contributor

@jwsi jwsi commented May 21, 2019

These changes allow for the ability for the admin account to be synced between HA pairs.

The following functionality is introduced:

  1. All admin account changes are synced to a partner.
  2. When the admin password is changed on the primary node, the secondary is updated accordingly and the primary HA sync password is also updated to prevent future auth errors occuring during sync.

Important Notes:

  • When an admin account password is changed, the config.xml file will be updated accordingly on the secondary. In xmlrpc.php there is a function called auth which 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 made filter_configure a private function to remove this possibility.

James.

@jim-p
Copy link
Contributor

jim-p commented May 21, 2019

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.

@jwsi
Copy link
Contributor Author

jwsi commented May 21, 2019

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.

@jim-p
Copy link
Contributor

jim-p commented May 21, 2019

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.

@jwsi
Copy link
Contributor Author

jwsi commented May 21, 2019

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.

netgate-git-updates pushed a commit that referenced this pull request Oct 31, 2019
Similar to closed PR #3558 from overhacked, but with a number of
changes.
netgate-git-updates pushed a commit that referenced this pull request Nov 25, 2019
* 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
@rbgarga
Copy link
Member

rbgarga commented Feb 7, 2020

No recent updates since May 2019. Closing.

@rbgarga rbgarga closed this Feb 7, 2020
@vktg vktg mentioned this pull request Mar 7, 2020
2 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants