[Freeipa-devel] WIP: ipa trust command

[Alexander Bokovoy]

On Mon, 12 Dec 2011, Simo Sorce wrote:
> > Creates a trust between FreeIPA realm and another realm of selected 
> > type. Only 'ads' type is currently supported.
> > 
> > For 'ads' type running `ipa trust-add' would be equivalent to 
> > following sequence:
> >  * ipa-adtrust-install
> >  * net rpc trust create
> 
> I think this is problematic in one regard. It can work only on one
> specific server (a general problem of ipa-adtrust-install).
We really need to solve a problem of replicated files distribution.

In case of ipa-adtrust-install what we have is following:
1. Simple smb.conf generated from a static template with information 
   available everywhere on replicas:
     - CIFS domain name and Kerberos realm name,
     - DN of a system account SMB_DN to access trust information, 
     - $SUFFIX
2. smbpasswd with a random password set for the system account SMB_DN
3. Need to restart few services on replicas once AD trust is 
   configured

Out of (1)-(3) we only lack (2). However, we can get around this by 
generating one system account for SMB_DN per replica:

uid=<servername>,cn=ad,cn=trusts,cn=sysaccounts,cn=etc,$SUFFIX

and set a password for each of it separately on the replica.
This is also why I'm advocating for multiple uids within a trust type.

For (3) we need to initiate services restart/config file generation 
with root privileges. This could be done by a separate daemon that 
binds to a local LDAP instance and triggers its actions by a 
replication update. An idea of this daemon was floating around for 
quite long and I think it is one of few options we are left.

So, setting up AD trust (or any other trust type when they will be 
available) on one master would trigger performing similar actions on 
other replicas automatically -- given that all needed information can 
be conveyed through LDAP objects as in this particular case.

In case replica will receive update in cn=trusts,$SUFFIX, the daemon 
would run associated action script and perform remaining configuration 
steps. This would require slight refactoring of adtrustinstance.py but 
nothing unreasonable.

> I am not sure how to fix it though. Ideally once you create a trust all
> IPA servers in the domain should be able to properly handle it. But at
> this moment only servers on which you explicitly run
> ipa-adtrust-instalkl can.
> 
> Actually even worse, I think ipa-adtrust-install will fail with multiple
> servers because the uid=samba user have a random password that cannot be
> communicated to other servers ...
And this is the case where multiple accounts would help.

> 
> > 2. Listing trusts
> > 
> > `ipa trust-find' will show all trusts with other realms corresponding 
> > certain criteria.
> > 
> > Proposed syntax:
> > ipa trust-find [CRITERIA] [options]
> > 
> > where CRITERIA is tested against realms of existing trusts
> > 
> > Options might include:
> >  * --type ads|ipa|kerberos|etc -- type of the trust
> > 
> > 
> > 3. Viewing details of trust
> > 
> > `ipa trust-show' exposes details of the established trust agreement 
> > with a specified realm. 
> > 
> > Proposed syntax:
> > ipa trust-show <realm> [options]
> > 
> > Details shown will depend on the type of trust with following 
> > information available for all trusts:
> >  * realm name
> >  * trust type
> 
> You may want to add trust direction here. I think we may want to support
> incoming only trusts with AD in future (ie we trust AD but AD admins do
> not want to trust IPA).
Yes, and maybe few other existing attributes that are already defined 
by our schema as ipaNT*.

> > Current approach requires creating separate ACIs per each trust and 
> > using the same system user account for all of them. As a consequence, 
> > ACIs are added during trust creation and require Directory Manager 
> > privileges which should be discouraged for 'ipa trust' set of 
> > commands.
> 
> We should just use cn=* in the ACI instead of CN=$DOMAIN and add ACIs
> only once.
No, look below for the proposed ACI -- it uses ($dn) to limit trust 
access per type -- i.e. uids defined for different trust types will 
not be able to modify/delete other trusts.

> >      (target = "ldap:///($dn),cn=trusts,$SUFFIX")
> >      (targetattr = "ipaNTTrustType || ipaNTTrustAttributes || 
> >                     ipaNTTrustDirection || 
> >                     ipaNTTrustPartner || ipaNTFlatName || 
> >                     ipaNTTrustAuthOutgoing || 
> >                     ipaNTTrustAuthIncoming || 
> >                     ipaNTSecurityIdentifier || 
> >                     ipaNTTrustForestTrustInfo || 
> >                     ipaNTTrustPosixOffset || 
> >                     ipaNTSupportedEncryptionTypes")
> >      (version 3.0;acl "Allow trust system user to create and delete trust accounts";
> >          allow (write,add,delete) userdn="ldap:///uid=*,($dn),cn=trusts,cn=sysaccounts,cn=etc,$SUFFIX";)
> > 
> >      (targetattr = "ipaNTHash")
> >      (version 3.0; acl "Samba user can read NT passwords";
> >          allow (read) userdn="ldap:///uid=*,cn=ad,cn=trusts,cn=sysaccounts,cn=etc,$SUFFIX";)
> > 
> > And trust admins ACI:
> > 
> >      (target = "ldap:///cn=trusts,$SUFFIX")
> >      (targetattr = "*")
> >      (version 3.0; acl "Trust management";
> >          allow (all) groupdn="ldap:///cn=trust admins,cn=groups,cn=accounts,$SUFFIX";)
> 
> Although I think we need 'trust admins' ACIs, I do not think we need the
> macro ACI for uid=samba. We do not need multiple users for trusts, only
> trusts that involve samba needs a separate user at this moment.
Multiple system users (each per replica) will help triggering replica 
initiation for the trust.

-- 
/ Alexander Bokovoy