[Freeipa-devel] WIP: ipa trust command

[Sumit Bose]

On Mon, Dec 12, 2011 at 07:49:04PM +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).

Thank you for the nice overview, see comments below

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

As Simo already mentioned theses should be two separate step and `ipa
trust-add' should just check is the needed components to create AD
trusts are already installed on the IPA server.

Additionally I think we need some commands to define a UID range for the
trusted domains, especially for AD trusts. For the domain given with the
`ipa trust-add' command we could just use another command line option.
But if this domain already has trusts to other domains it will become
difficult to handle this with options to `ipa trust-add'. So I would
suggest to add a new command to the `ipa trust' family which can set UID
ranges for domains before the trust is created. If the trust is already
created we may still allow to change the range but with a strong warning
that existing UIDs and GIDs will change.

bye,
Sumit


> 
> 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
> 
> 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.
> 
> 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";)
> 
> 
> 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.
> 
> Macro ACI are explained at 
> http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Access_Control-Advanced_Access_Control_Using_Macro_ACIs.html
> 
> 
> -- 
> / Alexander Bokovoy
> 
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel