On 19.9.2013 21:08, Alexander Bokovoy wrote:
Attached patch adds IPA CLI to manage trust subdomains.
ipa trust-domain-fetch <trust> -- fetch list of subdomains from AD
side and add new ones to IPA
ipa trust-domain-find <trust> -- show all available subdomains ipa
trust-domain-del <trust> <domain> -- remove subdomain from IPA view
ipa trust-domain-mod <trust> <domain> -- modify subdomain parameters
(work in progress)
IPA KDC needs also information for authentication paths to subdomains in
case they are not hierarchical under AD forest trust root. This
information is managed via capaths section in krb5.conf. SSSD should be
able to generate it once ticket
https://fedorahosted.org/sssd/ticket/2093 is resolved.
part of https://fedorahosted.org/freeipa/ticket/3909
The patch implements some dark magic to get around IPA framework
-- CLI commands belong to 'trust' family but operate on 'subdomain'
-- 'subdomain' objects are stored under trust container, thus making
container_dn dependent on a particular trust:
The latter is a design decision since our KDC driver loads all objects
with objectclass=ipaNTTrustedDomain from cn=ad,cn=trusts,$SUFFIX using
subtree scope. With this design no changes were needed in ipa-kdb at all
to support subdomains.
NACK, this patch breaks several conventions we use in the framework:
1) The object is named "subdomain", but the commands are named
"trust_domain_*". Please use the object name as the base for command
names. I would suggest renaming the object to "trustdomain", as the
framework does not allow underscores in object names, and "subdomain"
sounds a little bit too generic.
2) There is already support for objects inside objects in the framework,
there's no need to reinvent this. See the parent_object attribute of
LDAPObject and the dns plugin for practical example.
3) Create commands are usually named "*_add", not "*_create".
4) The "trust_domain_fetch" command gives the impression it operates on
top of a trust domain, but it actually operates on top of a trust. I
think it should be renamed to better reflect this.
Freeipa-devel mailing list