[Freeipa-devel] WIP: ipa trust command

[Simo Sorce]

On Mon, 2011-12-12 at 19:49 +0200, Alexander Bokovoy wrote:
> Hi,
> 
> I'm working on ticket #1821 to introduce FreeIPA 3.0 AD trusts 
> management CLI and GUI. It is quite apparent that most of management 
> commands will be similar to all future trust types (AD, IPA, etc), 
> thus, it makes sense to develop a generalized `ipa trust' family of 
> commands that would apply to all types of trusts.
> 
> Let's start with CLI. Below is a first cut at how I see trust 
> management command line interface. Comments, corrections, and critique 
> are all welcomed.
> 
> One of FreeIPA v3.0 major features will be support for cross-realm 
> trusts with the emphasis on trusts to Active Directory domains. This 
> documents attempts to design a common interface for managing trusts 
> with FreeIPA tools (command line and GUI).
> 
> `ipa trust'
> ===========
> 
> `ipa trust' is a common family of operations on trusts. Trusts can be:
>  * created (ipa trust-add)
>  * listed (ipa trust-find)
>  * viewed (ipa trust-show)
>  * removed (ipa trust-del)
> 
> 1. Adding a trust
> 
> `ipa trust-add' sets up a trust agreement with another realm. The 
> command requires to know realm of the trust being added, its 
> administrator rights, and type of the trust to establish.
> 
> Proposed syntax:
> ipa trust-add <realm> --type ads|ipa|kerberos|etc --realmadmin <Name> 
> --password <Value> [type-specific parameters]
> 
> 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).

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 ...

> 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).

> 4. Removal of existing trus
> 
> `ipa trust-del' removes existing trust agreement
> 
> 5. Access rights
> 
> Trust  management requires modification of FreeIPA LDAP database 
> instance and  potentially external resources specific to the trust 
> nature. cn=trusts,$SUFFIX  is used as a container to store information 
> about trusts with containers  inside it for different types of trusts. 
> 
> Currently FreeIPA 3.0  implements cn=ad,cn=trusts,$SUFFIX tree for 
> Active Directory-related trusts.
> 
> Trust management implies limited access which should be implemented 
> with the help of 389-ds ACIs.
> 
> In  order to give users access to the trust management, group of trust  
> administrators would be created, thus ACI would limit exposure to  
> cn=trusts,$SUFFIX tree to this group and additional trust 
> implementation-specific system users defined at cn=trusts,cn=sysaccounts,cn=etc,$SUFFIX. 
> 
> Currently AD trusts implement following ACIs per trust:
> 1. Trust information:
>       (target = "ldap:///cn=$DOMAIN,cn=ad,cn=trusts,$SUFFIX")
>       (targetattr = "ipaNTTrustType || ipaNTTrustAttributes || 
>                      ipaNTTrustDirection || 
>                      ipaNTTrustPartner || ipaNTFlatName || 
>                      ipaNTTrustAuthOutgoing || 
>                      ipaNTTrustAuthIncoming || 
>                      ipaNTSecurityIdentifier || 
>                      ipaNTTrustForestTrustInfo || 
>                      ipaNTTrustPosixOffset || 
>                      ipaNTSupportedEncryptionTypes")
>       (version 3.0;acl "Allow samba user to create and delete trust accounts";
>          allow (write,add,delete) userdn = "ldap:///$SAMBA_USER_DN";)
> 
> 2. NT Passwords:
>       (targetattr = "ipaNTHash")
>       (version 3.0; acl "Samba user can read NT passwords";
>          allow (read) userdn="ldap:///$SAMBA_USER_DN";)
> 
> where  $SAMBA_USER_DN is DN of special user defined at  
> uid=samba,cn=sysaccounts,cn=etc,$SUFFIX for the purpose of reading  
> ipaNTHash attribute (NT passwords) of existing users and accessing 
> trust information from the ipa-sam database plugin for Samba.
> 
> 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.

> Instead, macro ACI could be created that would allow access to the trust information 
> based on the part of DN of the system user:
> 
> uid=<user name>,cn=<trust type>,cn=trusts,cn=sysaccounts,cn=etc,$SUFFIX
> 
> which for AD trusts would be
> 
> uid=samba,cn=ad,cn=trusts,cn=sysaccounts,cn=etc,$SUFFIX
> 
> and ACI would be modified to have follow allow stanza:
> 
>      (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.

So I'd say ACK for the second part and NACK for the first.

> This approach would allow us to have a single ACI macro for system 
> accounts of all types of trusts for all realms and then a single ACI 
> per trust type.

We need a single ACI, just not with macros, we can have all we need with
a simpler ACI, and simpler always wins :)

Simo.

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