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 _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel