Артур Файзуллин wrote:
What rule must be present for replica to work? :) (in order to remove
allow-all rule)
I mean may be there is somewhere a guide to write rules for strict
allows?

During the installation we check that communication works between the two servers, so ssh is needed between masters (https://fedorahosted.org/freeipa/ticket/3298). You should be able to use --skip-conncheck to avoid this.

I don't think we have any suggestions for rules, just documentation on how to write them in general.

rob


В Пт., 30/11/2012 в 13:24 -0500, Rob Crittenden пишет:
Natxo Asenjo wrote:
hi,

the default hbac rule 'allow_all' is nice for testing, but for a
production environment I am not so sure ;-)

We do not want our users getting a shell in our kdc servers or in the
database servers for instance. We want them to use the postgresql
service, but not login the database server with a shell. Many more
examples are conceivable, of course.

Is it possible to have this policy adapted to 'everything but ssh' for
instance? That is, disable ssh logins unless explicitely allowed by
another policy. This would be the equivalent of 'Remote Desktop Users'
in an AD domain. Uses may login at the console everywhere (their
workstations), but if they need to login interactively in a server
then they need to be a member of this group. This does not prevent
them from using other resources like shares, printers, e-mail,
databases, ...

I am just afraid that unless this becomes the default during the
installation, most ipa environments will stay like this which could be
an unexpected security problem. No one but kerberos admins should have
shell access to the kdc in a kerberos realm.

Our expectation was that this default rule would be deleted by sites
that want to use HBAC, and that specially crafted rules would replace
it. There is an install option to not create this rule at all,
--no_hbac_allow.

Still, your suggestion makes sense. Better to be secure out-of-the-box.

I created an enhancement ticket for this,
https://fedorahosted.org/freeipa/ticket/3278

The tricky part is probably going to be around replicas, automatically
adding and removing access to them for the rule.

rob

_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users


_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users


_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Reply via email to