Hello,
in a situation when freeipa is exposed interface to the internet, there would be bolts trying to bruteforce admin account that made it locked. I come with modsecurity setting for the nss.conf:
SecRule ARGS:user "@contains admin" "id:1234,deny,status:403"'
Admin user is no longer avaliable from UI, Kerberos login is not affected, cli and WebUI login for other users are not affected. Can it brake something?
Andrey Bondarenko via FreeIPA-users wrote:
Hello,
in a situation when freeipa is exposed interface to the internet, there would be bolts trying to bruteforce admin account that made it locked. I come with modsecurity setting for the nss.conf:
SecRule ARGS:user "@contains admin" "id:1234,deny,status:403"'
Admin user is no longer avaliable from UI, Kerberos
login is not affected, cli and WebUI login for other users are not affected. Can it brake something?
It most likely also locks admin out of using the API which would break things if you actually use it.
Note that for the most part [1], if not everywhere, there is nothing special about the user named admin. The admins group holds all the power. So you may be better off adding other users to admins and locking the admin account manually (keep it around just in case and enable only when/if necessary).
rob
[1] I think that as of 4.7 all places where admin was hardcoded is gone. Before some point it was hardcoded in, IIRC, ipa-replica-install somewhere.
Unfortunately we have to use admin. Seems it does not brake API though, I've used different tests with 'admin' and it all passes. I am looking for the situation where 'admin' is a part of the POST as an argument like it is during the form based login.
On Wed, Feb 6, 2019 at 2:14 PM Rob Crittenden rcritten@redhat.com wrote:
Andrey Bondarenko via FreeIPA-users wrote:
Hello,
in a situation when freeipa is exposed interface to the internet, there would be bolts trying to bruteforce admin account that made it locked. I come with modsecurity setting for the nss.conf:
SecRule ARGS:user "@contains admin" "id:1234,deny,status:403"'
Admin user is no longer avaliable from UI, Kerberos
login is not affected, cli and WebUI login for other users are not affected. Can it brake something?
It most likely also locks admin out of using the API which would break things if you actually use it.
Note that for the most part [1], if not everywhere, there is nothing special about the user named admin. The admins group holds all the power. So you may be better off adding other users to admins and locking the admin account manually (keep it around just in case and enable only when/if necessary).
rob
[1] I think that as of 4.7 all places where admin was hardcoded is gone. Before some point it was hardcoded in, IIRC, ipa-replica-install somewhere.
freeipa-users@lists.fedorahosted.org