[Freeipa-devel] [PATCHES 509-514] replica promotion: use host credentials when setting up replication

[Simo Sorce]

On Thu, 2015-11-19 at 15:43 +0100, Jan Cholasta wrote:
> Hi,
> 
> the attached patches fix <https://fedorahosted.org/freeipa/ticket/3416> 
> and <https://fedorahosted.org/freeipa/ticket/5401>.
> 
> I worked around the issue of checking if the user is privileged to 
> perform replica promotion by using host credentials instead. The host 
> must be a member of the IPA servers host group "ipaservers" in order to 
> be able to promote itself. Using host credentials will also allow 
> replica install using one-time password.
> 
> User credentials are still used for connection check and to 
> automatically add the host to ipaservers if the user is privileged to do 
> that.
> 
> Simo, is this approach OK? Could you check the new ACIs in patches 510 
> and 513?
> 
> I have a couple of questions:
> 
> 1) Why are custodia keys for the replica added to LDAP using connection 
> to the remote master instead of local ldapi connection? Is it to 
> eliminate race conditions caused by replication timeout from the replica 
> to the remote master?

Yes it is critical for that reason.

> If the code was changed to use ldapi and wait until the key appears in 
> custodia on the remote master, we could lose the "IPA server hosts can 
> create own Custodia secrets" and "IPA server hosts can manage own 
> Custodia secrets" ACIs from patch 510. Not sure if it's worth the change 
> though.

Not worth the change, as it has the same security properties.

> 2) Why is 'memberPrincipal' used in cn=custodia instead of 'member'?
> 
> If 'member' was used instead, we would gain referential integrity and 
> the ability to add ACIs based on the attribute (think 
> userattr="member#USERDN").

To avoid referential integrity and mixup with other group objects, it
was intentional.

> 3) Why is 'memberPrincipal' used in cn=custodia at all?
> 
> The hostname of the replica is already in 'cn', so instead of searching 
> cn=custodia for entries matching (memberPrincipal=host/$HOSTNAME), we 
> could get cn={enc,sig}/$HOSTNAME,cn=custodia directly.

They idea was to be flexible, in a future we might have some shared
keys, then the only way to properly resolve keys would be to use a
multivalued attribute.
Or we may want to have multiple keys sets for the same principal (it
doesn't have to be a host technically, it could be a service or even a
user in the future), and a naming based convention would make it harder
to deal with that.


On the patches
--
509:
- commit says only: "aci: add IPA servers host group 'ipaservers'"
but it does other things like changing how CA renewal certificate acis
are added, I think that must be separated in another patch.

- Why "Manage Host Keytab"  aci has been changed to exclude ipaservers ?

- Why adding the host to the ipaservers group is done in the
krbinstance ? I would expect LDAP ops to be mostly done in the
DSinstance.

- I do not see where the host is added to the ipaservers group on
upgrade.

510:
- We should probably tightenup the ACI to allos host X to only add
memberPrincipal = X and no other value, also the host should not be
allowed to change the memberPrincipal attribute only the keys.
If we can't express this in ACIs we can live with the ones you propose
though.

511:
ack, but I think you should catch potential exceptions from the
os.rmdir, as it will throw if there is some other file in the dir (for
whatever reason). The exception can be safely ignored, we just do not
want to blow up with a traceback here.

512:
- I do not think this is correct, it seem to me you are overriding the
local ccache (if any) with the host keytab. If I read this right, this
means that if you run kinit admin && ipa-replica-install then you will
kind your admin credentials gone and a host TGT instead. Am I reading
this change correctly ?

513:
Nack
- Should be folded into 510
- Should not allow all hosts in the domain but only ipaservers for aal
three changes

514:
- Should be folded in 512, they are completely interdependent changes.
- I do not understand how this works. promote_check() runs before
promote() and will fail if the host is not already in the ipaservers
group, so you will never be able to actually add the host to the group ?
sounds like chicken-egg ... or what am I missing ?

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York