Re: [Freeipa-devel] [PATCH] 0118 add support for subdomains
On 10/04/2013 09:40 AM, Alexander Bokovoy wrote: > On Fri, 04 Oct 2013, Alexander Bokovoy wrote: >> On Fri, 04 Oct 2013, Alexander Bokovoy wrote: >>> On Thu, 03 Oct 2013, Martin Kosek wrote: On 10/03/2013 03:10 PM, Alexander Bokovoy wrote: > On Wed, 02 Oct 2013, Sumit Bose wrote: >>> Please note that I did not test with more than 1 subdomain, since I >>> do not have more ADs available. >>> >> >> I have done some testing as well and the patches are working as expected >> except the trustdomain-disable issue Tomas mentioned. But I think it >> would be sufficient to add a comment to the release notes and fix this >> with the next release to not delay this release anymore. >> >> The patches are also working for trusts which were added with older >> releases. So ACK from my side for the functional part. > New patchset is attached. I've fixed all outstanding issues and > implemented proper SID filtering for subdomains. In addition, I've > added MS-PAC cache eviction when we change blacklists from IPA side > and forced removal of the domain from SID blacklist if the domain is > being removed by trustdomain-del. > 1) Minor issue in 0118: +if keys[0].lower() == keys[1].lower(): +raise errors.ValidationError(name='trustdomain_enable', +error=_("Root domain of the trust is always enabled for the existing trust")) The error message looks weird (double trustdomain_enable) # ipa trustdomain-enable realm domain ipa: ERROR: invalid 'trustdomain_enable': Root domain of the trust is always enabled for the existing trust I would rather do something like +raise errors.ValidationError(name='domain', 2) trustconfig-enable and trustconfig-disable should use standard output like other enable/disable methods. See user-enable/user-disable for example. Current situation puts all the authoritative information to summary which: a) Does not look nice in terminal # ipa trustdomain-disable very.long.long.long.realm very.long.long.long.domain Domain very.long.long.long.domain of trust very.long.long.long.realm is not allowed to access IPA resources b) How am I supposed to parse an information about the result if all I get is a text in summary? Using standard errors and output values will allow easier consumption of the API later (like in Web UI). I am attaching a patch (0001) how to make it consistent with other enable/disable commands. Example: # ipa trustdomain-disable realm domain ipa: ERROR: This entry is already disabled # ipa trustdomain-enable realm domain - Enabled trust domain "domain" - 3) Let's use standard primary key for the trustdomain object. This will let us overcome some hacks and also let us use handle_not_found method - patch attached (0002). 0002 also changes some ValidationError errors to standard errors, just for being consistent with the rest of the API. Note that in order to make primary_key=True, I had to enhance trustdomain_del command to manage multiple domains. I think these API fixes are a must, it would be very hard to amend the API later. If these patches are squashed to your 0118, it would be ACK from me to the Python side. I will let C parts and a functional test to Sumit's mighty hands. >>> Thanks. I've merged these changes, along with a API.txt correction. In >>> my tests these worked fine. >>> >>> I'll resend 0118 shortly. >> New edition of 0118 attached. > ... and updated 0124 to match the 0118. > Thanks Alexander and Sumit! The patches seem to work now - ACK. Pushed all to master, ipa-3-3. I just also updated our spec to require new SSSD. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0118 add support for subdomains
On Fri, 04 Oct 2013, Alexander Bokovoy wrote: On Fri, 04 Oct 2013, Alexander Bokovoy wrote: On Thu, 03 Oct 2013, Martin Kosek wrote: On 10/03/2013 03:10 PM, Alexander Bokovoy wrote: On Wed, 02 Oct 2013, Sumit Bose wrote: Please note that I did not test with more than 1 subdomain, since I do not have more ADs available. I have done some testing as well and the patches are working as expected except the trustdomain-disable issue Tomas mentioned. But I think it would be sufficient to add a comment to the release notes and fix this with the next release to not delay this release anymore. The patches are also working for trusts which were added with older releases. So ACK from my side for the functional part. New patchset is attached. I've fixed all outstanding issues and implemented proper SID filtering for subdomains. In addition, I've added MS-PAC cache eviction when we change blacklists from IPA side and forced removal of the domain from SID blacklist if the domain is being removed by trustdomain-del. 1) Minor issue in 0118: +if keys[0].lower() == keys[1].lower(): +raise errors.ValidationError(name='trustdomain_enable', +error=_("Root domain of the trust is always enabled for the existing trust")) The error message looks weird (double trustdomain_enable) # ipa trustdomain-enable realm domain ipa: ERROR: invalid 'trustdomain_enable': Root domain of the trust is always enabled for the existing trust I would rather do something like +raise errors.ValidationError(name='domain', 2) trustconfig-enable and trustconfig-disable should use standard output like other enable/disable methods. See user-enable/user-disable for example. Current situation puts all the authoritative information to summary which: a) Does not look nice in terminal # ipa trustdomain-disable very.long.long.long.realm very.long.long.long.domain Domain very.long.long.long.domain of trust very.long.long.long.realm is not allowed to access IPA resources b) How am I supposed to parse an information about the result if all I get is a text in summary? Using standard errors and output values will allow easier consumption of the API later (like in Web UI). I am attaching a patch (0001) how to make it consistent with other enable/disable commands. Example: # ipa trustdomain-disable realm domain ipa: ERROR: This entry is already disabled # ipa trustdomain-enable realm domain - Enabled trust domain "domain" - 3) Let's use standard primary key for the trustdomain object. This will let us overcome some hacks and also let us use handle_not_found method - patch attached (0002). 0002 also changes some ValidationError errors to standard errors, just for being consistent with the rest of the API. Note that in order to make primary_key=True, I had to enhance trustdomain_del command to manage multiple domains. I think these API fixes are a must, it would be very hard to amend the API later. If these patches are squashed to your 0118, it would be ACK from me to the Python side. I will let C parts and a functional test to Sumit's mighty hands. Thanks. I've merged these changes, along with a API.txt correction. In my tests these worked fine. I'll resend 0118 shortly. New edition of 0118 attached. ... and updated 0124 to match the 0118. -- / Alexander Bokovoy >From 34dc771417b247de180fe490da9fe9cb09644fee Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Thu, 3 Oct 2013 12:30:44 +0200 Subject: [PATCH 8/8] ipa-kdb: Handle parent-child relationship for subdomains When MS-PAC information is re-initialized, record also parent-child relationship between trust root level domain and its subdomains. Use parent incoming SID black list to check if child domain is not allowed to access IPA realm. We also should really use 'cn' of the entry as domain name. ipaNTTrustPartner has different meaning on wire, it is an index pointing to the parent domain of the domain and will be 0 for top level domains or disjoint subdomains of the trust. Finally, trustdomain-enable and trustdomain-disable commands should force MS-PAC cache re-initalization in case of black list change. Trigger that by asking for cross-realm TGT for HTTP service. --- daemons/ipa-kdb/ipa_kdb_mspac.c | 109 ipalib/plugins/trust.py | 6 +++ 2 files changed, 105 insertions(+), 10 deletions(-) diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c index e20de36..ff67391 100644 --- a/daemons/ipa-kdb/ipa_kdb_mspac.c +++ b/daemons/ipa-kdb/ipa_kdb_mspac.c @@ -37,6 +37,8 @@ struct ipadb_adtrusts { int len_sid_blacklist_incoming; struct dom_sid *sid_blac
Re: [Freeipa-devel] [PATCH] 0118 add support for subdomains
On Thu, 03 Oct 2013, Sumit Bose wrote: On Thu, Oct 03, 2013 at 06:04:24PM +0200, Martin Kosek wrote: On 10/03/2013 03:10 PM, Alexander Bokovoy wrote: > On Wed, 02 Oct 2013, Sumit Bose wrote: >>> Please note that I did not test with more than 1 subdomain, since I >>> do not have more ADs available. >>> >> >> I have done some testing as well and the patches are working as expected >> except the trustdomain-disable issue Tomas mentioned. But I think it >> would be sufficient to add a comment to the release notes and fix this >> with the next release to not delay this release anymore. >> >> The patches are also working for trusts which were added with older >> releases. So ACK from my side for the functional part. > New patchset is attached. I've fixed all outstanding issues and > implemented proper SID filtering for subdomains. In addition, I've > added MS-PAC cache eviction when we change blacklists from IPA side > and forced removal of the domain from SID blacklist if the domain is > being removed by trustdomain-del. > 1) Minor issue in 0118: +if keys[0].lower() == keys[1].lower(): +raise errors.ValidationError(name='trustdomain_enable', +error=_("Root domain of the trust is always enabled for the existing trust")) The error message looks weird (double trustdomain_enable) # ipa trustdomain-enable realm domain ipa: ERROR: invalid 'trustdomain_enable': Root domain of the trust is always enabled for the existing trust I would rather do something like +raise errors.ValidationError(name='domain', 2) trustconfig-enable and trustconfig-disable should use standard output like other enable/disable methods. See user-enable/user-disable for example. Current situation puts all the authoritative information to summary which: a) Does not look nice in terminal # ipa trustdomain-disable very.long.long.long.realm very.long.long.long.domain Domain very.long.long.long.domain of trust very.long.long.long.realm is not allowed to access IPA resources b) How am I supposed to parse an information about the result if all I get is a text in summary? Using standard errors and output values will allow easier consumption of the API later (like in Web UI). I am attaching a patch (0001) how to make it consistent with other enable/disable commands. Example: # ipa trustdomain-disable realm domain ipa: ERROR: This entry is already disabled # ipa trustdomain-enable realm domain - Enabled trust domain "domain" - 3) Let's use standard primary key for the trustdomain object. This will let us overcome some hacks and also let us use handle_not_found method - patch attached (0002). 0002 also changes some ValidationError errors to standard errors, just for being consistent with the rest of the API. Note that in order to make primary_key=True, I had to enhance trustdomain_del command to manage multiple domains. I think these API fixes are a must, it would be very hard to amend the API later. If these patches are squashed to your 0118, it would be ACK from me to the Python side. I will let C parts and a functional test to Sumit's mighty hands. Functional it is an ACK to all patches except 0123. The trustdomain-disabled issue found by Tomas is fixed with 0124. Patch 0123 is not needed and breaks setups with unpatched MIT Kerberos, which currently are more or less all. It does not allow users from the trusted forest root to get tickets for the IPA domain. In this case the TGT does not have any transited data, because it is a direct trust, but the client realm is not ours. So the plugin returns KRB5_PLUGIN_NO_HANDLE which is interpreted as an error in current MIT Kerberos versions. I would recommend to just drop the patch for this release and include an improved version in the next. I've fixed 0123 by allowing to proceed with the trust checks in case of empty transited realm and both client and server realms are not ours. The result will be success in case both client and server realms are either our realm or belong to any of the trusted domains. For this case empty transited realm considered a match. For me following cases work now: - principal from our realm asking for ticket of a service in our realm - principal from root level trusted domain asking for a ticket of a service in our realm - principal from a trusted domain asking for a ticket of a service in our realm - principal from our realm asking for a ticket of a service in a root level trusted domain - principal from our realm asking for a ticket of a service in a trusted domain These are supported use cases without your PoC patches, the last one works due to manual configuration file written by SSSD 1.11.
Re: [Freeipa-devel] [PATCH] 0118 add support for subdomains
On Fri, 04 Oct 2013, Alexander Bokovoy wrote: On Thu, 03 Oct 2013, Martin Kosek wrote: On 10/03/2013 03:10 PM, Alexander Bokovoy wrote: On Wed, 02 Oct 2013, Sumit Bose wrote: Please note that I did not test with more than 1 subdomain, since I do not have more ADs available. I have done some testing as well and the patches are working as expected except the trustdomain-disable issue Tomas mentioned. But I think it would be sufficient to add a comment to the release notes and fix this with the next release to not delay this release anymore. The patches are also working for trusts which were added with older releases. So ACK from my side for the functional part. New patchset is attached. I've fixed all outstanding issues and implemented proper SID filtering for subdomains. In addition, I've added MS-PAC cache eviction when we change blacklists from IPA side and forced removal of the domain from SID blacklist if the domain is being removed by trustdomain-del. 1) Minor issue in 0118: +if keys[0].lower() == keys[1].lower(): +raise errors.ValidationError(name='trustdomain_enable', +error=_("Root domain of the trust is always enabled for the existing trust")) The error message looks weird (double trustdomain_enable) # ipa trustdomain-enable realm domain ipa: ERROR: invalid 'trustdomain_enable': Root domain of the trust is always enabled for the existing trust I would rather do something like +raise errors.ValidationError(name='domain', 2) trustconfig-enable and trustconfig-disable should use standard output like other enable/disable methods. See user-enable/user-disable for example. Current situation puts all the authoritative information to summary which: a) Does not look nice in terminal # ipa trustdomain-disable very.long.long.long.realm very.long.long.long.domain Domain very.long.long.long.domain of trust very.long.long.long.realm is not allowed to access IPA resources b) How am I supposed to parse an information about the result if all I get is a text in summary? Using standard errors and output values will allow easier consumption of the API later (like in Web UI). I am attaching a patch (0001) how to make it consistent with other enable/disable commands. Example: # ipa trustdomain-disable realm domain ipa: ERROR: This entry is already disabled # ipa trustdomain-enable realm domain - Enabled trust domain "domain" - 3) Let's use standard primary key for the trustdomain object. This will let us overcome some hacks and also let us use handle_not_found method - patch attached (0002). 0002 also changes some ValidationError errors to standard errors, just for being consistent with the rest of the API. Note that in order to make primary_key=True, I had to enhance trustdomain_del command to manage multiple domains. I think these API fixes are a must, it would be very hard to amend the API later. If these patches are squashed to your 0118, it would be ACK from me to the Python side. I will let C parts and a functional test to Sumit's mighty hands. Thanks. I've merged these changes, along with a API.txt correction. In my tests these worked fine. I'll resend 0118 shortly. New edition of 0118 attached. -- / Alexander Bokovoy >From 1e5d4090d53ce0e889f05359685efd8819771826 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Wed, 18 Sep 2013 17:04:19 +0200 Subject: [PATCH 2/8] trusts: support subdomains in a forest Add IPA CLI to manage trust domains. ipa trust-fetch-domains -- fetch list of subdomains from AD side and add new ones to IPA ipa trustdomain-find -- show all available domains ipa trustdomain-del -- remove domain from IPA view about ipa trustdomain-enable -- allow users from trusted domain to access resources in IPA ipa trustdomain-disable -- disable access to resources in IPA from trusted domain By default all discovered trust domains are allowed to access IPA resources 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 --- API.txt | 88 + ipalib/plugins/trust.py | 329 ipaserver/dcerpc.py | 54 3 files changed, 420 insertions(+), 51 deletions(-) diff --git a/API.txt b/API.txt index 761d1d1..40871f6 100644 --- a/API.txt +++ b/API.txt @@ -3423,6 +3423,17 @@ option: Str('version?', exclude='webui') output: Outp
Re: [Freeipa-devel] [PATCH] 0118 add support for subdomains
On Thu, 03 Oct 2013, Martin Kosek wrote: On 10/03/2013 03:10 PM, Alexander Bokovoy wrote: On Wed, 02 Oct 2013, Sumit Bose wrote: Please note that I did not test with more than 1 subdomain, since I do not have more ADs available. I have done some testing as well and the patches are working as expected except the trustdomain-disable issue Tomas mentioned. But I think it would be sufficient to add a comment to the release notes and fix this with the next release to not delay this release anymore. The patches are also working for trusts which were added with older releases. So ACK from my side for the functional part. New patchset is attached. I've fixed all outstanding issues and implemented proper SID filtering for subdomains. In addition, I've added MS-PAC cache eviction when we change blacklists from IPA side and forced removal of the domain from SID blacklist if the domain is being removed by trustdomain-del. 1) Minor issue in 0118: +if keys[0].lower() == keys[1].lower(): +raise errors.ValidationError(name='trustdomain_enable', +error=_("Root domain of the trust is always enabled for the existing trust")) The error message looks weird (double trustdomain_enable) # ipa trustdomain-enable realm domain ipa: ERROR: invalid 'trustdomain_enable': Root domain of the trust is always enabled for the existing trust I would rather do something like +raise errors.ValidationError(name='domain', 2) trustconfig-enable and trustconfig-disable should use standard output like other enable/disable methods. See user-enable/user-disable for example. Current situation puts all the authoritative information to summary which: a) Does not look nice in terminal # ipa trustdomain-disable very.long.long.long.realm very.long.long.long.domain Domain very.long.long.long.domain of trust very.long.long.long.realm is not allowed to access IPA resources b) How am I supposed to parse an information about the result if all I get is a text in summary? Using standard errors and output values will allow easier consumption of the API later (like in Web UI). I am attaching a patch (0001) how to make it consistent with other enable/disable commands. Example: # ipa trustdomain-disable realm domain ipa: ERROR: This entry is already disabled # ipa trustdomain-enable realm domain - Enabled trust domain "domain" - 3) Let's use standard primary key for the trustdomain object. This will let us overcome some hacks and also let us use handle_not_found method - patch attached (0002). 0002 also changes some ValidationError errors to standard errors, just for being consistent with the rest of the API. Note that in order to make primary_key=True, I had to enhance trustdomain_del command to manage multiple domains. I think these API fixes are a must, it would be very hard to amend the API later. If these patches are squashed to your 0118, it would be ACK from me to the Python side. I will let C parts and a functional test to Sumit's mighty hands. Thanks. I've merged these changes, along with a API.txt correction. In my tests these worked fine. I'll resend 0118 shortly. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0118 add support for subdomains
On Thu, Oct 03, 2013 at 06:04:24PM +0200, Martin Kosek wrote: > On 10/03/2013 03:10 PM, Alexander Bokovoy wrote: > > On Wed, 02 Oct 2013, Sumit Bose wrote: > >>> Please note that I did not test with more than 1 subdomain, since I > >>> do not have more ADs available. > >>> > >> > >> I have done some testing as well and the patches are working as expected > >> except the trustdomain-disable issue Tomas mentioned. But I think it > >> would be sufficient to add a comment to the release notes and fix this > >> with the next release to not delay this release anymore. > >> > >> The patches are also working for trusts which were added with older > >> releases. So ACK from my side for the functional part. > > New patchset is attached. I've fixed all outstanding issues and > > implemented proper SID filtering for subdomains. In addition, I've > > added MS-PAC cache eviction when we change blacklists from IPA side > > and forced removal of the domain from SID blacklist if the domain is > > being removed by trustdomain-del. > > > > 1) Minor issue in 0118: > > +if keys[0].lower() == keys[1].lower(): > +raise errors.ValidationError(name='trustdomain_enable', > +error=_("Root domain of the trust is always enabled for the > existing trust")) > > The error message looks weird (double trustdomain_enable) > > # ipa trustdomain-enable realm domain > ipa: ERROR: invalid 'trustdomain_enable': Root domain of the trust is always > enabled for the existing trust > > I would rather do something like > > +raise errors.ValidationError(name='domain', > > > 2) trustconfig-enable and trustconfig-disable should use standard output like > other enable/disable methods. See user-enable/user-disable for example. > Current > situation puts all the authoritative information to summary which: > a) Does not look nice in terminal > # ipa trustdomain-disable very.long.long.long.realm very.long.long.long.domain > > Domain very.long.long.long.domain of trust very.long.long.long.realm is not > allowed to access IPA resources > > b) How am I supposed to parse an information about the result if all I get is > a > text in summary? Using standard errors and output values will allow easier > consumption of the API later (like in Web UI). > > I am attaching a patch (0001) how to make it consistent with other > enable/disable commands. Example: > > # ipa trustdomain-disable realm domain > ipa: ERROR: This entry is already disabled > > # ipa trustdomain-enable realm domain > - > Enabled trust domain "domain" > - > > 3) Let's use standard primary key for the trustdomain object. This will let us > overcome some hacks and also let us use handle_not_found method - patch > attached (0002). > > 0002 also changes some ValidationError errors to standard errors, just for > being consistent with the rest of the API. > > Note that in order to make primary_key=True, I had to enhance trustdomain_del > command to manage multiple domains. > > > I think these API fixes are a must, it would be very hard to amend the API > later. If these patches are squashed to your 0118, it would be ACK from me to > the Python side. I will let C parts and a functional test to Sumit's mighty > hands. Functional it is an ACK to all patches except 0123. The trustdomain-disabled issue found by Tomas is fixed with 0124. Patch 0123 is not needed and breaks setups with unpatched MIT Kerberos, which currently are more or less all. It does not allow users from the trusted forest root to get tickets for the IPA domain. In this case the TGT does not have any transited data, because it is a direct trust, but the client realm is not ours. So the plugin returns KRB5_PLUGIN_NO_HANDLE which is interpreted as an error in current MIT Kerberos versions. I would recommend to just drop the patch for this release and include an improved version in the next. Patch 0124 look good although the new parent_name member looks a bit useless to me. I also find the name ipadb_free_sid_blacklists() a bit irritating because it is not clear (from the name) if it should be used to free the lists of SID strings or of struct dom_sid. But both can be fixed (if needed) later when we touch this part of the code again to include support for transitively trusted forests. bye, Sumit > > Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0118 add support for subdomains
On 10/03/2013 03:10 PM, Alexander Bokovoy wrote: > On Wed, 02 Oct 2013, Sumit Bose wrote: >>> Please note that I did not test with more than 1 subdomain, since I >>> do not have more ADs available. >>> >> >> I have done some testing as well and the patches are working as expected >> except the trustdomain-disable issue Tomas mentioned. But I think it >> would be sufficient to add a comment to the release notes and fix this >> with the next release to not delay this release anymore. >> >> The patches are also working for trusts which were added with older >> releases. So ACK from my side for the functional part. > New patchset is attached. I've fixed all outstanding issues and > implemented proper SID filtering for subdomains. In addition, I've > added MS-PAC cache eviction when we change blacklists from IPA side > and forced removal of the domain from SID blacklist if the domain is > being removed by trustdomain-del. > 1) Minor issue in 0118: +if keys[0].lower() == keys[1].lower(): +raise errors.ValidationError(name='trustdomain_enable', +error=_("Root domain of the trust is always enabled for the existing trust")) The error message looks weird (double trustdomain_enable) # ipa trustdomain-enable realm domain ipa: ERROR: invalid 'trustdomain_enable': Root domain of the trust is always enabled for the existing trust I would rather do something like +raise errors.ValidationError(name='domain', 2) trustconfig-enable and trustconfig-disable should use standard output like other enable/disable methods. See user-enable/user-disable for example. Current situation puts all the authoritative information to summary which: a) Does not look nice in terminal # ipa trustdomain-disable very.long.long.long.realm very.long.long.long.domain Domain very.long.long.long.domain of trust very.long.long.long.realm is not allowed to access IPA resources b) How am I supposed to parse an information about the result if all I get is a text in summary? Using standard errors and output values will allow easier consumption of the API later (like in Web UI). I am attaching a patch (0001) how to make it consistent with other enable/disable commands. Example: # ipa trustdomain-disable realm domain ipa: ERROR: This entry is already disabled # ipa trustdomain-enable realm domain - Enabled trust domain "domain" - 3) Let's use standard primary key for the trustdomain object. This will let us overcome some hacks and also let us use handle_not_found method - patch attached (0002). 0002 also changes some ValidationError errors to standard errors, just for being consistent with the rest of the API. Note that in order to make primary_key=True, I had to enhance trustdomain_del command to manage multiple domains. I think these API fixes are a must, it would be very hard to amend the API later. If these patches are squashed to your 0118, it would be ACK from me to the Python side. I will let C parts and a functional test to Sumit's mighty hands. Martin From df0ffda6b74f48557c4bdfd1b729e9ad801901b0 Mon Sep 17 00:00:00 2001 From: Martin Kosek Date: Thu, 3 Oct 2013 16:30:21 +0200 Subject: [PATCH] Make trustdomain-enable and trustdomain-disable output consistent --- ipalib/plugins/trust.py | 44 1 file changed, 16 insertions(+), 28 deletions(-) diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py index d909b3f1be4bb19c667ee34cbda1316aaa905970..26182f38d5a6593405762ab4e76859aa5068de9d 100644 --- a/ipalib/plugins/trust.py +++ b/ipalib/plugins/trust.py @@ -1272,17 +1272,15 @@ def execute(self, *keys, **options): class trustdomain_enable(LDAPQuery): __doc__ = _('Allow use of IPA resources by the domain of the trust') -has_output = ( -output.summary, -) - +has_output = output.standard_value takes_args = trustdomain.trustdomain_args +msg_summary = _('Enabled trust domain "%(value)s"') def execute(self, *keys, **options): ldap = self.api.Backend.ldap2 if keys[0].lower() == keys[1].lower(): -raise errors.ValidationError(name='trustdomain_enable', +raise errors.ValidationError(name='domain', error=_("Root domain of the trust is always enabled for the existing trust")) try: trust_dn = self.obj.get_dn(keys[0], trust_type=u'ad') @@ -1290,46 +1288,40 @@ def execute(self, *keys, **options): except errors.NotFound: raise errors.ValidationError(name=_('AD trust'), error=_('Valid trust name is required')) -result = dict() -result['trust'] = unicode(keys[0]) -result['domain']
Re: [Freeipa-devel] [PATCH] 0118 add support for subdomains
On 2.10.2013 23:01, Alexander Bokovoy wrote: On Wed, 02 Oct 2013, Tomas Babej wrote: 2.) The trust-fetch-domains has somewhat confusing options: [tbabej@vm-147 labtool]$ ipa trust-fetch-domains tbad.idm.lab.eng.brq.redhat.com --help Usage: ipa [global-options] trust-fetch-domains REALM [options] Refresh list of the domains associated with the trust Options: -h, --help show this help message and exit --rightsDisplay the access rights of this entry (requires --all). See ipa man page for details. --all Retrieve and print all attributes from the server. Affects command output. --raw Print entries as stored on the server. Only affects output format. Yep, I'll switch it to use the same LDAPQuery class as trustdomain-enable/disable use now. Since trust-fetch-domains returns a list of entries, I think --all and --raw should stay, to be consistent with other commands which return entries. Just make sure they work by passing them through to trustdomain_add. Honza -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0118 add support for subdomains
On Thu, Oct 03, 2013 at 12:01:35AM +0300, Alexander Bokovoy wrote: > On Wed, 02 Oct 2013, Tomas Babej wrote: > >>>I'll send new patchset shortly. > >>New patchset is attached. > >> > >>1. Added test update for ipalib/frontend.py changes > >>2. Used LDAPQuery as base for trustdomain_enable|disable commands as > >> suggested by Honza. > >>3. Fixed issues with removal of trust account password authentication > >>4. Added support to use AD administrator credentials when fetching > >> subdomains information when we establish trust as Kerberos will not > >> be available for cross-realm operations yet. > >>5. Patch 0123 is not part of the patchset and should not be committed, > >> we will discuss exact semantics of transition checks with MIT > >> Kerberos upstream first. > >>6. Fixed few error paths and dead-end cases like attempt to disable root > >> domain of the trust (renders trust dead) or enabling it (it is always > >> enabled). > >>7. Made clear that deleting root domain of the trust is not possible, > >> use trust-del instead. > >>8. Removed whitespaces where saw. > >> > >> > >> > > > >Thanks! > > > >This fixes most of the issues I had. > > > >To summarize, two issues from the today's functional testing we > >already discussed on IRC: > > > >1.) The blacklisting for the child domain does not work (it works > >fine for the root domain). > >Thus, ipa trustdomain-disable for the child domain does not reject > >access to the IPA's resources: > > > >[tbabej@vm-147 labtool]$ ipa trustdomain-disable > >tbad.idm.lab.eng.brq.redhat.com > >child.tbad.idm.lab.eng.brq.redhat.com > > > >Domain child.tbad.idm.lab.eng.brq.redhat.com of trust > >tbad.idm.lab.eng.brq.redhat.com is already not allowed to access > >IPA resources > > > >[tbabej@vm-147 labtool]$ kdestroy > >[tbabej@vm-147 labtool]$ kvno -S ldap `hostname` > >kvno: Credentials cache file '/run/user/536/krb5cc/tkt1sLaOS' not > >found while getting client principal name > >[tbabej@vm-147 labtool]$ kinit > >administra...@child.tbad.idm.lab.eng.brq.redhat.com > >Password for administra...@child.tbad.idm.lab.eng.brq.redhat.com: > >[tbabej@vm-147 labtool]$ klist > >Ticket cache: DIR::/run/user/536/krb5cc/tktS7Bkhj > >Default principal: administra...@child.tbad.idm.lab.eng.brq.redhat.com > > > >Valid starting Expires Service principal > >10/02/2013 21:28:52 10/03/2013 07:28:52 > >krbtgt/child.tbad.idm.lab.eng.brq.redhat@child.tbad.idm.lab.eng.brq.redhat.com > > renew until 10/03/2013 21:28:46 > >[tbabej@vm-147 labtool]$ kvno -S ldap `hostname` > >ldap/vm-147.dom147.tbad.idm.lab.eng.brq.redhat@dom147.tbad.idm.lab.eng.brq.redhat.com: > >kvno = 2 > > > >We should have been denied access here. > Right. This is *very good* finding. Since we put information about black > list only to the root level domain of the trust, we need to reference > the root level domain when checking a subdomain. We don't do that right > now and it is needed also in Sumit's patches so I'll work on merging > them. > > Here is my plan: make a helper that identifies root domain for the > trusted domain (Sumit's code already has this), fetch root domain of > the trust > and validate this domain's SID against black list associated with the > root domain in filter_logon_info(). Since it looks like the forest root<->member domain relationship is needed in various places I wonder if it would be easier in the long run to add this explicitly to the member domain objects e.g. with the help of a new objectclass ipaNTForestMember with a mandatory attribute ipaNTForest or ipaNTMemberOfForest? I think this would also help to make the handling of member domains in transitively trusted forests easier. bye, Sumit ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0118 add support for subdomains
On Wed, Oct 02, 2013 at 10:31:21PM +0200, Tomas Babej wrote: > On 10/01/2013 05:15 PM, Alexander Bokovoy wrote: > >On Mon, 30 Sep 2013, Alexander Bokovoy wrote: > >>On Mon, 30 Sep 2013, Tomas Babej wrote: > >>>On 09/28/2013 10:01 PM, Alexander Bokovoy wrote: > On Fri, 27 Sep 2013, Sumit Bose wrote: > >On Fri, Sep 27, 2013 at 03:53:08PM +0300, Alexander Bokovoy wrote: > >>On Mon, 23 Sep 2013, Alexander Bokovoy wrote: > >>>On Mon, 23 Sep 2013, Alexander Bokovoy wrote: > On Mon, 23 Sep 2013, Alexander Bokovoy wrote: > >On Mon, 23 Sep 2013, Martin Kosek wrote: > However, we don't have trust type available so it needs > >>to discovered > every time. This doesn't play well with the framework, it > >>is simply not > expecting dynamic containers. > >>> > >>>This doesn't sound like a big obstacle to me. Right now > >>the trust_type lookup > >>>is done in trust_show.execute() for some reason, which is > >>not the best place to > >>>do it IMHO. Doing it in trust.get_dn() instead should > >>simplify things enough to > >>>make parent_object work. > >> > >>Yup, get_dn() is the method where object DN lookup should > >>be done. See for > >>example host.py plugin get_dn method, we also do a dynamic > >>lookup for correct > >>host name. > >I'll see if that would work. > > > >>the best way to implement dynamic DN gathering is the > >>get_dn() method. That > >>way, it could be implemented in one place and all commands > >>could take advantage > >>of it instead of re-implementing it several times in > >>pre_callback - this is > >>just hackish. > >I'd suggest you look into the code. The commands use > >>pre_callback for a > >different purpose than implementing dynamic DN gathering. > > > >>I think it would have been very useful to have a design > >>page before sending a > >>patch. It is then easier to make design decisions without > >>having to dig into > >>the patch. > >The design page is there for long time: > >http://www.freeipa.org/page/V3/Transitive_Trusts > Ok, here is new version of the patch and updated > version of my 0117 > patch as Sumit noticed I've sent wrong version. > >>>Ok, here is updated 0118 which fixes API.txt change for > >>trustdomain_add > >>>-- I renamed trustdomain_create to trustdomain_add but > >>>forgot to rerun > >>>makeapi. > >>New edition attached for all subdomain-related patches: > > > >I did some tests and all is working as expected. > > > >> > >>freeipa-abbra-0117-ipaserver-dcerpc.py-populate-forest-trust-informatio-3.patch > >> > >> > >>Use realmdomains to report name suffix routes at the > >>time we establish trust > >> > >>freeipa-abbra-0118-trusts-support-subdomains-in-a-forest-3.patch > >>Introduce trustdomain-* commands to fetch list of domains associated > >>with a forest trust and allow filtering them off > > > >We talked on irc that ipaNTSupportedEncryptionTypes in the filter > >for the trusted domains should be replace by a different attribute. > >Because of an error in ipasam the > >ipaNTSupportedEncryptionTypes is only > >set in recent versions and might not be present in the > >directory trees of > >older versions. > Fixed in the attached patch 0118 version 4. > > Also attached first attempt to implement transiting through trusted > domains, as patch 0123. In this patch we grant transition only if all > three realms (client, transited realm, and server realm) match any of > our trusted domains and our domain. This is probably a bit > wider but it > worked for me bidirectionally, from a child domain to a > service in IPA, > and from IPA realm to a service in a child domain of a forest trust. > > > > ___ > Freeipa-devel mailing list > Freeipa-devel@redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > >>> > >>>Hi, > >>> > >>>here are my comments: > >>> > >>>*PATCH 117* > >>> > >>>+def get_realmdomains(self): > >>>+""" > >>>+Generate list of records for forest trust information about > >>>+our realm domains. Note that the list generated currently > >>>+includes only top level domains, no exclusion > >>>domains, and no TDO objects > >>>+as we handle the latter in a separte way > >>>+""" > >>> > >>>A nitpick typo: separte -> separate. > >>Fixed. > >> > >>> > >>>Also, there's trailing whitespace in the patch: > >>> > >>>Applying: ipaserver/dcerpc.py: populate forest trust > >>>information using realmdomains > >>>/home/tbabej/dev/freeipa/.git/rebase-apply/patch:62: trailing > >>>w
Re: [Freeipa-devel] [PATCH] 0118 add support for subdomains
On Wed, 02 Oct 2013, Tomas Babej wrote: I'll send new patchset shortly. New patchset is attached. 1. Added test update for ipalib/frontend.py changes 2. Used LDAPQuery as base for trustdomain_enable|disable commands as suggested by Honza. 3. Fixed issues with removal of trust account password authentication 4. Added support to use AD administrator credentials when fetching subdomains information when we establish trust as Kerberos will not be available for cross-realm operations yet. 5. Patch 0123 is not part of the patchset and should not be committed, we will discuss exact semantics of transition checks with MIT Kerberos upstream first. 6. Fixed few error paths and dead-end cases like attempt to disable root domain of the trust (renders trust dead) or enabling it (it is always enabled). 7. Made clear that deleting root domain of the trust is not possible, use trust-del instead. 8. Removed whitespaces where saw. Thanks! This fixes most of the issues I had. To summarize, two issues from the today's functional testing we already discussed on IRC: 1.) The blacklisting for the child domain does not work (it works fine for the root domain). Thus, ipa trustdomain-disable for the child domain does not reject access to the IPA's resources: [tbabej@vm-147 labtool]$ ipa trustdomain-disable tbad.idm.lab.eng.brq.redhat.com child.tbad.idm.lab.eng.brq.redhat.com Domain child.tbad.idm.lab.eng.brq.redhat.com of trust tbad.idm.lab.eng.brq.redhat.com is already not allowed to access IPA resources [tbabej@vm-147 labtool]$ kdestroy [tbabej@vm-147 labtool]$ kvno -S ldap `hostname` kvno: Credentials cache file '/run/user/536/krb5cc/tkt1sLaOS' not found while getting client principal name [tbabej@vm-147 labtool]$ kinit administra...@child.tbad.idm.lab.eng.brq.redhat.com Password for administra...@child.tbad.idm.lab.eng.brq.redhat.com: [tbabej@vm-147 labtool]$ klist Ticket cache: DIR::/run/user/536/krb5cc/tktS7Bkhj Default principal: administra...@child.tbad.idm.lab.eng.brq.redhat.com Valid starting Expires Service principal 10/02/2013 21:28:52 10/03/2013 07:28:52 krbtgt/child.tbad.idm.lab.eng.brq.redhat@child.tbad.idm.lab.eng.brq.redhat.com renew until 10/03/2013 21:28:46 [tbabej@vm-147 labtool]$ kvno -S ldap `hostname` ldap/vm-147.dom147.tbad.idm.lab.eng.brq.redhat@dom147.tbad.idm.lab.eng.brq.redhat.com: kvno = 2 We should have been denied access here. Right. This is *very good* finding. Since we put information about black list only to the root level domain of the trust, we need to reference the root level domain when checking a subdomain. We don't do that right now and it is needed also in Sumit's patches so I'll work on merging them. Here is my plan: make a helper that identifies root domain for the trusted domain (Sumit's code already has this), fetch root domain of the trust and validate this domain's SID against black list associated with the root domain in filter_logon_info(). Here is MS-PAC dump I've got for the user from a subdomain. Note that its info.info.info3.sids array contains a SID of root domain's object. Successfully validated Kerberos PAC pac_data: struct PAC_DATA num_buffers : 0x0005 (5) version : 0x (0) buffers: ARRAY(5) buffers: struct PAC_BUFFER type : PAC_TYPE_LOGON_INFO (1) _ndr_size: 0x01e8 (488) info : * info : union PAC_INFO(case 1) logon_info: struct PAC_LOGON_INFO_CTR info : * info: struct PAC_LOGON_INFO info3: struct netr_SamInfo3 base: struct netr_SamBaseInfo logon_time : Wed Oct 2 10:00:50 PM 2013 CEST logoff_time : Thu Sep 14 04:48:05 AM 30828 CEST kickoff_time : Thu Sep 14 04:48:05 AM 30828 CEST last_password_change : Wed Mar 13 05:15:57 PM 2013 CET allow_password_change: Thu Mar 14 05:15:57 PM 2013 CET force_password_change: Thu Sep 14 04:48:05 AM 30828 CEST account_name: struct lsa_String length : 0x001a (26)
Re: [Freeipa-devel] [PATCH] 0118 add support for subdomains
On 10/01/2013 05:15 PM, Alexander Bokovoy wrote: On Mon, 30 Sep 2013, Alexander Bokovoy wrote: On Mon, 30 Sep 2013, Tomas Babej wrote: On 09/28/2013 10:01 PM, Alexander Bokovoy wrote: On Fri, 27 Sep 2013, Sumit Bose wrote: On Fri, Sep 27, 2013 at 03:53:08PM +0300, Alexander Bokovoy wrote: On Mon, 23 Sep 2013, Alexander Bokovoy wrote: On Mon, 23 Sep 2013, Alexander Bokovoy wrote: On Mon, 23 Sep 2013, Alexander Bokovoy wrote: On Mon, 23 Sep 2013, Martin Kosek wrote: However, we don't have trust type available so it needs to discovered every time. This doesn't play well with the framework, it is simply not expecting dynamic containers. This doesn't sound like a big obstacle to me. Right now the trust_type lookup is done in trust_show.execute() for some reason, which is not the best place to do it IMHO. Doing it in trust.get_dn() instead should simplify things enough to make parent_object work. Yup, get_dn() is the method where object DN lookup should be done. See for example host.py plugin get_dn method, we also do a dynamic lookup for correct host name. I'll see if that would work. the best way to implement dynamic DN gathering is the get_dn() method. That way, it could be implemented in one place and all commands could take advantage of it instead of re-implementing it several times in pre_callback - this is just hackish. I'd suggest you look into the code. The commands use pre_callback for a different purpose than implementing dynamic DN gathering. I think it would have been very useful to have a design page before sending a patch. It is then easier to make design decisions without having to dig into the patch. The design page is there for long time: http://www.freeipa.org/page/V3/Transitive_Trusts Ok, here is new version of the patch and updated version of my 0117 patch as Sumit noticed I've sent wrong version. Ok, here is updated 0118 which fixes API.txt change for trustdomain_add -- I renamed trustdomain_create to trustdomain_add but forgot to rerun makeapi. New edition attached for all subdomain-related patches: I did some tests and all is working as expected. freeipa-abbra-0117-ipaserver-dcerpc.py-populate-forest-trust-informatio-3.patch Use realmdomains to report name suffix routes at the time we establish trust freeipa-abbra-0118-trusts-support-subdomains-in-a-forest-3.patch Introduce trustdomain-* commands to fetch list of domains associated with a forest trust and allow filtering them off We talked on irc that ipaNTSupportedEncryptionTypes in the filter for the trusted domains should be replace by a different attribute. Because of an error in ipasam the ipaNTSupportedEncryptionTypes is only set in recent versions and might not be present in the directory trees of older versions. Fixed in the attached patch 0118 version 4. Also attached first attempt to implement transiting through trusted domains, as patch 0123. In this patch we grant transition only if all three realms (client, transited realm, and server realm) match any of our trusted domains and our domain. This is probably a bit wider but it worked for me bidirectionally, from a child domain to a service in IPA, and from IPA realm to a service in a child domain of a forest trust. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Hi, here are my comments: *PATCH 117* +def get_realmdomains(self): +""" +Generate list of records for forest trust information about +our realm domains. Note that the list generated currently +includes only top level domains, no exclusion domains, and no TDO objects +as we handle the latter in a separte way +""" A nitpick typo: separte -> separate. Fixed. Also, there's trailing whitespace in the patch: Applying: ipaserver/dcerpc.py: populate forest trust information using realmdomains /home/tbabej/dev/freeipa/.git/rebase-apply/patch:62: trailing whitespace. Only top level name and top level name exclusions are handled here. /home/tbabej/dev/freeipa/.git/rebase-apply/patch:174: trailing whitespace. warning: 2 lines add whitespace errors. Fixed. *PATCH 119* We also need to change the frontend tests that cover this functionality: == FAIL: Test the ``ipalib.frontend.Command.args`` instance attribute. -- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/home/tbabej/dev/freeipa/ipatests/test_ipalib/test_frontend.py", line 283, in test_args assert str(e) == 'arg2: required argument after optional' AssertionError See ipatests/test_ipalib/test_frontend.py, line 281: # Test ValueError, required after optional: e = raises
Re: [Freeipa-devel] [PATCH] 0118 add support for subdomains
On Mon, 30 Sep 2013, Tomas Babej wrote: On 09/28/2013 10:01 PM, Alexander Bokovoy wrote: On Fri, 27 Sep 2013, Sumit Bose wrote: On Fri, Sep 27, 2013 at 03:53:08PM +0300, Alexander Bokovoy wrote: On Mon, 23 Sep 2013, Alexander Bokovoy wrote: On Mon, 23 Sep 2013, Alexander Bokovoy wrote: On Mon, 23 Sep 2013, Alexander Bokovoy wrote: On Mon, 23 Sep 2013, Martin Kosek wrote: However, we don't have trust type available so it needs to discovered every time. This doesn't play well with the framework, it is simply not expecting dynamic containers. This doesn't sound like a big obstacle to me. Right now the trust_type lookup is done in trust_show.execute() for some reason, which is not the best place to do it IMHO. Doing it in trust.get_dn() instead should simplify things enough to make parent_object work. Yup, get_dn() is the method where object DN lookup should be done. See for example host.py plugin get_dn method, we also do a dynamic lookup for correct host name. I'll see if that would work. the best way to implement dynamic DN gathering is the get_dn() method. That way, it could be implemented in one place and all commands could take advantage of it instead of re-implementing it several times in pre_callback - this is just hackish. I'd suggest you look into the code. The commands use pre_callback for a different purpose than implementing dynamic DN gathering. I think it would have been very useful to have a design page before sending a patch. It is then easier to make design decisions without having to dig into the patch. The design page is there for long time: http://www.freeipa.org/page/V3/Transitive_Trusts Ok, here is new version of the patch and updated version of my 0117 patch as Sumit noticed I've sent wrong version. Ok, here is updated 0118 which fixes API.txt change for trustdomain_add -- I renamed trustdomain_create to trustdomain_add but forgot to rerun makeapi. New edition attached for all subdomain-related patches: I did some tests and all is working as expected. freeipa-abbra-0117-ipaserver-dcerpc.py-populate-forest-trust-informatio-3.patch Use realmdomains to report name suffix routes at the time we establish trust freeipa-abbra-0118-trusts-support-subdomains-in-a-forest-3.patch Introduce trustdomain-* commands to fetch list of domains associated with a forest trust and allow filtering them off We talked on irc that ipaNTSupportedEncryptionTypes in the filter for the trusted domains should be replace by a different attribute. Because of an error in ipasam the ipaNTSupportedEncryptionTypes is only set in recent versions and might not be present in the directory trees of older versions. Fixed in the attached patch 0118 version 4. Also attached first attempt to implement transiting through trusted domains, as patch 0123. In this patch we grant transition only if all three realms (client, transited realm, and server realm) match any of our trusted domains and our domain. This is probably a bit wider but it worked for me bidirectionally, from a child domain to a service in IPA, and from IPA realm to a service in a child domain of a forest trust. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Hi, here are my comments: *PATCH 117* +def get_realmdomains(self): +""" +Generate list of records for forest trust information about +our realm domains. Note that the list generated currently +includes only top level domains, no exclusion domains, and no TDO objects +as we handle the latter in a separte way +""" A nitpick typo: separte -> separate. Fixed. Also, there's trailing whitespace in the patch: Applying: ipaserver/dcerpc.py: populate forest trust information using realmdomains /home/tbabej/dev/freeipa/.git/rebase-apply/patch:62: trailing whitespace. Only top level name and top level name exclusions are handled here. /home/tbabej/dev/freeipa/.git/rebase-apply/patch:174: trailing whitespace. warning: 2 lines add whitespace errors. Fixed. *PATCH 119* We also need to change the frontend tests that cover this functionality: == FAIL: Test the ``ipalib.frontend.Command.args`` instance attribute. -- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/home/tbabej/dev/freeipa/ipatests/test_ipalib/test_frontend.py", line 283, in test_args assert str(e) == 'arg2: required argument after optional' AssertionError See ipatests/test_ipalib/test_frontend.py, line 281: # Test ValueError, required after optional: e = raises(ValueError, self.get_instance, args=('arg1?', 'arg2')) assert str(e) == 'arg2: required arg
Re: [Freeipa-devel] [PATCH] 0118 add support for subdomains
On 09/28/2013 10:01 PM, Alexander Bokovoy wrote: On Fri, 27 Sep 2013, Sumit Bose wrote: On Fri, Sep 27, 2013 at 03:53:08PM +0300, Alexander Bokovoy wrote: On Mon, 23 Sep 2013, Alexander Bokovoy wrote: >On Mon, 23 Sep 2013, Alexander Bokovoy wrote: >>On Mon, 23 Sep 2013, Alexander Bokovoy wrote: >>>On Mon, 23 Sep 2013, Martin Kosek wrote: >>However, we don't have trust type available so it needs to discovered >>every time. This doesn't play well with the framework, it is simply not >>expecting dynamic containers. > >This doesn't sound like a big obstacle to me. Right now the trust_type lookup >is done in trust_show.execute() for some reason, which is not the best place to >do it IMHO. Doing it in trust.get_dn() instead should simplify things enough to >make parent_object work. Yup, get_dn() is the method where object DN lookup should be done. See for example host.py plugin get_dn method, we also do a dynamic lookup for correct host name. >>>I'll see if that would work. >>> the best way to implement dynamic DN gathering is the get_dn() method. That way, it could be implemented in one place and all commands could take advantage of it instead of re-implementing it several times in pre_callback - this is just hackish. >>>I'd suggest you look into the code. The commands use pre_callback for a >>>different purpose than implementing dynamic DN gathering. >>> I think it would have been very useful to have a design page before sending a patch. It is then easier to make design decisions without having to dig into the patch. >>>The design page is there for long time: >>>http://www.freeipa.org/page/V3/Transitive_Trusts >>Ok, here is new version of the patch and updated version of my 0117 >>patch as Sumit noticed I've sent wrong version. >Ok, here is updated 0118 which fixes API.txt change for trustdomain_add >-- I renamed trustdomain_create to trustdomain_add but forgot to rerun >makeapi. New edition attached for all subdomain-related patches: I did some tests and all is working as expected. freeipa-abbra-0117-ipaserver-dcerpc.py-populate-forest-trust-informatio-3.patch Use realmdomains to report name suffix routes at the time we establish trust freeipa-abbra-0118-trusts-support-subdomains-in-a-forest-3.patch Introduce trustdomain-* commands to fetch list of domains associated with a forest trust and allow filtering them off We talked on irc that ipaNTSupportedEncryptionTypes in the filter for the trusted domains should be replace by a different attribute. Because of an error in ipasam the ipaNTSupportedEncryptionTypes is only set in recent versions and might not be present in the directory trees of older versions. Fixed in the attached patch 0118 version 4. Also attached first attempt to implement transiting through trusted domains, as patch 0123. In this patch we grant transition only if all three realms (client, transited realm, and server realm) match any of our trusted domains and our domain. This is probably a bit wider but it worked for me bidirectionally, from a child domain to a service in IPA, and from IPA realm to a service in a child domain of a forest trust. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Hi, here are my comments: *PATCH 117* +def get_realmdomains(self): +""" +Generate list of records for forest trust information about +our realm domains. Note that the list generated currently +includes only top level domains, no exclusion domains, and no TDO objects +as we handle the latter in a separte way +""" A nitpick typo: separte -> separate. Also, there's trailing whitespace in the patch: Applying: ipaserver/dcerpc.py: populate forest trust information using realmdomains /home/tbabej/dev/freeipa/.git/rebase-apply/patch:62: trailing whitespace. Only top level name and top level name exclusions are handled here. /home/tbabej/dev/freeipa/.git/rebase-apply/patch:174: trailing whitespace. warning: 2 lines add whitespace errors. *PATCH 119* We also need to change the frontend tests that cover this functionality: == FAIL: Test the ``ipalib.frontend.Command.args`` instance attribute. -- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/home/tbabej/dev/freeipa/ipatests/test_ipalib/test_frontend.py", line 283, in test_args assert str(e) == 'arg2: required argument after optional' AssertionError See ipatests/test_ipalib/test_frontend.py, line 281: # Test ValueError, required after optional: e = raises(ValueError, self.get_instance, args=('arg1?', 'arg
Re: [Freeipa-devel] [PATCH] 0118 add support for subdomains
On Mon, 30 Sep 2013, Sumit Bose wrote: On Sat, Sep 28, 2013 at 11:01:34PM +0300, Alexander Bokovoy wrote: On Fri, 27 Sep 2013, Sumit Bose wrote: >On Fri, Sep 27, 2013 at 03:53:08PM +0300, Alexander Bokovoy wrote: >>On Mon, 23 Sep 2013, Alexander Bokovoy wrote: >>>On Mon, 23 Sep 2013, Alexander Bokovoy wrote: On Mon, 23 Sep 2013, Alexander Bokovoy wrote: >On Mon, 23 Sep 2013, Martin Kosek wrote: However, we don't have trust type available so it needs to discovered every time. This doesn't play well with the framework, it is simply not expecting dynamic containers. >>> >>>This doesn't sound like a big obstacle to me. Right now the trust_type lookup >>>is done in trust_show.execute() for some reason, which is not the best place to >>>do it IMHO. Doing it in trust.get_dn() instead should simplify things enough to >>>make parent_object work. >> >>Yup, get_dn() is the method where object DN lookup should be done. See for >>example host.py plugin get_dn method, we also do a dynamic lookup for correct >>host name. >I'll see if that would work. > >>the best way to implement dynamic DN gathering is the get_dn() method. That >>way, it could be implemented in one place and all commands could take advantage >>of it instead of re-implementing it several times in pre_callback - this is >>just hackish. >I'd suggest you look into the code. The commands use pre_callback for a >different purpose than implementing dynamic DN gathering. > >>I think it would have been very useful to have a design page before sending a >>patch. It is then easier to make design decisions without having to dig into >>the patch. >The design page is there for long time: >http://www.freeipa.org/page/V3/Transitive_Trusts Ok, here is new version of the patch and updated version of my 0117 patch as Sumit noticed I've sent wrong version. >>>Ok, here is updated 0118 which fixes API.txt change for trustdomain_add >>>-- I renamed trustdomain_create to trustdomain_add but forgot to rerun >>>makeapi. >>New edition attached for all subdomain-related patches: > >I did some tests and all is working as expected. > >> >>freeipa-abbra-0117-ipaserver-dcerpc.py-populate-forest-trust-informatio-3.patch >> Use realmdomains to report name suffix routes at the time we establish trust >> >>freeipa-abbra-0118-trusts-support-subdomains-in-a-forest-3.patch >> Introduce trustdomain-* commands to fetch list of domains associated >> with a forest trust and allow filtering them off > >We talked on irc that ipaNTSupportedEncryptionTypes in the filter >for the trusted domains should be replace by a different attribute. >Because of an error in ipasam the ipaNTSupportedEncryptionTypes is only >set in recent versions and might not be present in the directory trees of >older versions. Fixed in the attached patch 0118 version 4. Also attached first attempt to implement transiting through trusted domains, as patch 0123. In this patch we grant transition only if all three realms (client, transited realm, and server realm) match any of our trusted domains and our domain. This is probably a bit wider but it worked for me bidirectionally, from a child domain to a service in IPA, and from IPA realm to a service in a child domain of a forest trust. -- / Alexander Bokovoy ... + + return (has_client_realm && has_transited_contents && has_server_realm) == false; I would prefer real krb5 error codes here. 0 and KRB5KRB_AP_ERR_ILL_CR_TKT are used in the core code which evaluates [capaths]. Fixed. Also tightened checks for our domain as it couldn't be the transited domain. -- / Alexander Bokovoy commit 16472f38f9ad7b7b86c3dee3ed6021d75880d30f Author: Alexander Bokovoy Date: Sat Sep 28 21:49:57 2013 +0200 KDC: implement transition check for trusted domains When client principal requests for a ticket for a server principal and we have to perform transition, check that all three belong to either our domain or the domains we trust through forest trusts. In case all three realms (client, transition, and server) match trusted domains and our domain, issue permission to transition from client realm to server realm. Part of https://fedorahosted.org/freeipa/ticket/3909 diff --git a/daemons/ipa-kdb/ipa_kdb.c b/daemons/ipa-kdb/ipa_kdb.c index 5e4d047..c807bbc 100644 --- a/daemons/ipa-kdb/ipa_kdb.c +++ b/daemons/ipa-kdb/ipa_kdb.c @@ -602,7 +602,7 @@ kdb_vftabl kdb_function_table = { NULL, /* decrypt_key_data */ NULL, /* encrypt_key_data */ ipadb_sign_authdata,/* sign_authdata */ -NULL, /* check_transited_realms */ +ipadb_check_transited_realms, /* check_transited_realms */ ipadb_check_policy_as, /* check_policy_as */ NULL,
Re: [Freeipa-devel] [PATCH] 0118 add support for subdomains
On Mon, 30 Sep 2013, Jan Cholasta wrote: On 28.9.2013 22:01, Alexander Bokovoy wrote: On Fri, 27 Sep 2013, Sumit Bose wrote: On Fri, Sep 27, 2013 at 03:53:08PM +0300, Alexander Bokovoy wrote: On Mon, 23 Sep 2013, Alexander Bokovoy wrote: On Mon, 23 Sep 2013, Alexander Bokovoy wrote: On Mon, 23 Sep 2013, Alexander Bokovoy wrote: On Mon, 23 Sep 2013, Martin Kosek wrote: However, we don't have trust type available so it needs to discovered every time. This doesn't play well with the framework, it is simply not expecting dynamic containers. This doesn't sound like a big obstacle to me. Right now the trust_type lookup is done in trust_show.execute() for some reason, which is not the best place to do it IMHO. Doing it in trust.get_dn() instead should simplify things enough to make parent_object work. Yup, get_dn() is the method where object DN lookup should be done. See for example host.py plugin get_dn method, we also do a dynamic lookup for correct host name. I'll see if that would work. the best way to implement dynamic DN gathering is the get_dn() method. That way, it could be implemented in one place and all commands could take advantage of it instead of re-implementing it several times in pre_callback - this is just hackish. I'd suggest you look into the code. The commands use pre_callback for a different purpose than implementing dynamic DN gathering. I think it would have been very useful to have a design page before sending a patch. It is then easier to make design decisions without having to dig into the patch. The design page is there for long time: http://www.freeipa.org/page/V3/Transitive_Trusts Ok, here is new version of the patch and updated version of my 0117 patch as Sumit noticed I've sent wrong version. Ok, here is updated 0118 which fixes API.txt change for trustdomain_add -- I renamed trustdomain_create to trustdomain_add but forgot to rerun makeapi. New edition attached for all subdomain-related patches: I did some tests and all is working as expected. freeipa-abbra-0117-ipaserver-dcerpc.py-populate-forest-trust-informatio-3.patch Use realmdomains to report name suffix routes at the time we establish trust freeipa-abbra-0118-trusts-support-subdomains-in-a-forest-3.patch Introduce trustdomain-* commands to fetch list of domains associated with a forest trust and allow filtering them off We talked on irc that ipaNTSupportedEncryptionTypes in the filter for the trusted domains should be replace by a different attribute. Because of an error in ipasam the ipaNTSupportedEncryptionTypes is only set in recent versions and might not be present in the directory trees of older versions. Fixed in the attached patch 0118 version 4. Also attached first attempt to implement transiting through trusted domains, as patch 0123. In this patch we grant transition only if all three realms (client, transited realm, and server realm) match any of our trusted domains and our domain. This is probably a bit wider but it worked for me bidirectionally, from a child domain to a service in IPA, and from IPA realm to a service in a child domain of a forest trust. +if not trust_type: +for ttype in self.trust_types: +dn=make_trust_dn(self.env, ttype, DN(*sdn)) +try: +object_exists = self.backend.get_entry(dn, ['']) +return object_exists.dn +except errors.NotFound: +pass +# if no trust object of any type exist, default to 'ad' +# this is required for *_add calls. +trust_type = u'ad' This could be optimized to do a single LDAP search, i.e. something like: if trust_type is None: ldap = self.backend filter = ldap.make_filter({'objectclass': ['ipaNTTrustedDomain'], 'cn': [keys[-1]]}) try: result = ldap.get_entries(base_dn, ldap.SCOPE_SUBTREE, filter, ['']) except errors.NotFound: trust_type = u'ad' else: if len(result) > 1: raise errors.OnlyOneValueAllowed(attr='trust_type') return result[0].dn Fixed. +# First see if the trust is already in place +# Force retrieval of the trust object by not passing trust_type +dn = self.obj.get_dn(keys[-1], {}) The "{}" does not seem right to me (you are passing it as a second key to get_dn, which is probably not what you want). Simply removed {}. (dn, attrs) = entry - + # Translate ipanttrusttype to trusttype if --raw not used No trailing whitespace please. Yep, removed. +takes_options = LDAPCreate.takes_options + (_trust_type_option, +Str('ipanttrustpartner?', +label=_('Trusted domain partner'), +), +) + +def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options): +if 'ipanttrustpartner' in op
Re: [Freeipa-devel] [PATCH] 0118 add support for subdomains
On Sat, Sep 28, 2013 at 11:01:34PM +0300, Alexander Bokovoy wrote: > On Fri, 27 Sep 2013, Sumit Bose wrote: > >On Fri, Sep 27, 2013 at 03:53:08PM +0300, Alexander Bokovoy wrote: > >>On Mon, 23 Sep 2013, Alexander Bokovoy wrote: > >>>On Mon, 23 Sep 2013, Alexander Bokovoy wrote: > On Mon, 23 Sep 2013, Alexander Bokovoy wrote: > >On Mon, 23 Sep 2013, Martin Kosek wrote: > However, we don't have trust type available so it needs to discovered > every time. This doesn't play well with the framework, it is simply > not > expecting dynamic containers. > >>> > >>>This doesn't sound like a big obstacle to me. Right now the trust_type > >>>lookup > >>>is done in trust_show.execute() for some reason, which is not the best > >>>place to > >>>do it IMHO. Doing it in trust.get_dn() instead should simplify things > >>>enough to > >>>make parent_object work. > >> > >>Yup, get_dn() is the method where object DN lookup should be done. See > >>for > >>example host.py plugin get_dn method, we also do a dynamic lookup for > >>correct > >>host name. > >I'll see if that would work. > > > >>the best way to implement dynamic DN gathering is the get_dn() method. > >>That > >>way, it could be implemented in one place and all commands could take > >>advantage > >>of it instead of re-implementing it several times in pre_callback - > >>this is > >>just hackish. > >I'd suggest you look into the code. The commands use pre_callback for a > >different purpose than implementing dynamic DN gathering. > > > >>I think it would have been very useful to have a design page before > >>sending a > >>patch. It is then easier to make design decisions without having to dig > >>into > >>the patch. > >The design page is there for long time: > >http://www.freeipa.org/page/V3/Transitive_Trusts > Ok, here is new version of the patch and updated version of my 0117 > patch as Sumit noticed I've sent wrong version. > >>>Ok, here is updated 0118 which fixes API.txt change for trustdomain_add > >>>-- I renamed trustdomain_create to trustdomain_add but forgot to rerun > >>>makeapi. > >>New edition attached for all subdomain-related patches: > > > >I did some tests and all is working as expected. > > > >> > >>freeipa-abbra-0117-ipaserver-dcerpc.py-populate-forest-trust-informatio-3.patch > >> Use realmdomains to report name suffix routes at the time we establish > >> trust > >> > >>freeipa-abbra-0118-trusts-support-subdomains-in-a-forest-3.patch > >> Introduce trustdomain-* commands to fetch list of domains associated > >> with a forest trust and allow filtering them off > > > >We talked on irc that ipaNTSupportedEncryptionTypes in the filter > >for the trusted domains should be replace by a different attribute. > >Because of an error in ipasam the ipaNTSupportedEncryptionTypes is only > >set in recent versions and might not be present in the directory trees of > >older versions. > Fixed in the attached patch 0118 version 4. > > Also attached first attempt to implement transiting through trusted > domains, as patch 0123. In this patch we grant transition only if all > three realms (client, transited realm, and server realm) match any of > our trusted domains and our domain. This is probably a bit wider but it > worked for me bidirectionally, from a child domain to a service in IPA, > and from IPA realm to a service in a child domain of a forest trust. > > -- > / Alexander Bokovoy ... > + > + return (has_client_realm && has_transited_contents && has_server_realm) > == false; I would prefer real krb5 error codes here. 0 and KRB5KRB_AP_ERR_ILL_CR_TKT are used in the core code which evaluates [capaths]. bye, Sumit > +} > -- > 1.8.3.1 > ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0118 add support for subdomains
On 28.9.2013 22:01, Alexander Bokovoy wrote: On Fri, 27 Sep 2013, Sumit Bose wrote: On Fri, Sep 27, 2013 at 03:53:08PM +0300, Alexander Bokovoy wrote: On Mon, 23 Sep 2013, Alexander Bokovoy wrote: >On Mon, 23 Sep 2013, Alexander Bokovoy wrote: >>On Mon, 23 Sep 2013, Alexander Bokovoy wrote: >>>On Mon, 23 Sep 2013, Martin Kosek wrote: >>However, we don't have trust type available so it needs to discovered >>every time. This doesn't play well with the framework, it is simply not >>expecting dynamic containers. > >This doesn't sound like a big obstacle to me. Right now the trust_type lookup >is done in trust_show.execute() for some reason, which is not the best place to >do it IMHO. Doing it in trust.get_dn() instead should simplify things enough to >make parent_object work. Yup, get_dn() is the method where object DN lookup should be done. See for example host.py plugin get_dn method, we also do a dynamic lookup for correct host name. >>>I'll see if that would work. >>> the best way to implement dynamic DN gathering is the get_dn() method. That way, it could be implemented in one place and all commands could take advantage of it instead of re-implementing it several times in pre_callback - this is just hackish. >>>I'd suggest you look into the code. The commands use pre_callback for a >>>different purpose than implementing dynamic DN gathering. >>> I think it would have been very useful to have a design page before sending a patch. It is then easier to make design decisions without having to dig into the patch. >>>The design page is there for long time: >>>http://www.freeipa.org/page/V3/Transitive_Trusts >>Ok, here is new version of the patch and updated version of my 0117 >>patch as Sumit noticed I've sent wrong version. >Ok, here is updated 0118 which fixes API.txt change for trustdomain_add >-- I renamed trustdomain_create to trustdomain_add but forgot to rerun >makeapi. New edition attached for all subdomain-related patches: I did some tests and all is working as expected. freeipa-abbra-0117-ipaserver-dcerpc.py-populate-forest-trust-informatio-3.patch Use realmdomains to report name suffix routes at the time we establish trust freeipa-abbra-0118-trusts-support-subdomains-in-a-forest-3.patch Introduce trustdomain-* commands to fetch list of domains associated with a forest trust and allow filtering them off We talked on irc that ipaNTSupportedEncryptionTypes in the filter for the trusted domains should be replace by a different attribute. Because of an error in ipasam the ipaNTSupportedEncryptionTypes is only set in recent versions and might not be present in the directory trees of older versions. Fixed in the attached patch 0118 version 4. Also attached first attempt to implement transiting through trusted domains, as patch 0123. In this patch we grant transition only if all three realms (client, transited realm, and server realm) match any of our trusted domains and our domain. This is probably a bit wider but it worked for me bidirectionally, from a child domain to a service in IPA, and from IPA realm to a service in a child domain of a forest trust. +if not trust_type: +for ttype in self.trust_types: +dn=make_trust_dn(self.env, ttype, DN(*sdn)) +try: +object_exists = self.backend.get_entry(dn, ['']) +return object_exists.dn +except errors.NotFound: +pass +# if no trust object of any type exist, default to 'ad' +# this is required for *_add calls. +trust_type = u'ad' This could be optimized to do a single LDAP search, i.e. something like: if trust_type is None: ldap = self.backend filter = ldap.make_filter({'objectclass': ['ipaNTTrustedDomain'], 'cn': [keys[-1]]}) try: result = ldap.get_entries(base_dn, ldap.SCOPE_SUBTREE, filter, ['']) except errors.NotFound: trust_type = u'ad' else: if len(result) > 1: raise errors.OnlyOneValueAllowed(attr='trust_type') return result[0].dn +# First see if the trust is already in place +# Force retrieval of the trust object by not passing trust_type +dn = self.obj.get_dn(keys[-1], {}) The "{}" does not seem right to me (you are passing it as a second key to get_dn, which is probably not what you want). (dn, attrs) = entry - + # Translate ipanttrusttype to trusttype if --raw not used No trailing whitespace please. +takes_options = LDAPCreate.takes_options + (_trust_type_option, +Str('ipanttrustpartner?', +label=_('Trusted domain partner'), +), +) + +def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options): +if 'ipanttrustpartne
Re: [Freeipa-devel] [PATCH] 0118 add support for subdomains
On Fri, 27 Sep 2013, Sumit Bose wrote: On Fri, Sep 27, 2013 at 03:53:08PM +0300, Alexander Bokovoy wrote: On Mon, 23 Sep 2013, Alexander Bokovoy wrote: >On Mon, 23 Sep 2013, Alexander Bokovoy wrote: >>On Mon, 23 Sep 2013, Alexander Bokovoy wrote: >>>On Mon, 23 Sep 2013, Martin Kosek wrote: >>However, we don't have trust type available so it needs to discovered >>every time. This doesn't play well with the framework, it is simply not >>expecting dynamic containers. > >This doesn't sound like a big obstacle to me. Right now the trust_type lookup >is done in trust_show.execute() for some reason, which is not the best place to >do it IMHO. Doing it in trust.get_dn() instead should simplify things enough to >make parent_object work. Yup, get_dn() is the method where object DN lookup should be done. See for example host.py plugin get_dn method, we also do a dynamic lookup for correct host name. >>>I'll see if that would work. >>> the best way to implement dynamic DN gathering is the get_dn() method. That way, it could be implemented in one place and all commands could take advantage of it instead of re-implementing it several times in pre_callback - this is just hackish. >>>I'd suggest you look into the code. The commands use pre_callback for a >>>different purpose than implementing dynamic DN gathering. >>> I think it would have been very useful to have a design page before sending a patch. It is then easier to make design decisions without having to dig into the patch. >>>The design page is there for long time: >>>http://www.freeipa.org/page/V3/Transitive_Trusts >>Ok, here is new version of the patch and updated version of my 0117 >>patch as Sumit noticed I've sent wrong version. >Ok, here is updated 0118 which fixes API.txt change for trustdomain_add >-- I renamed trustdomain_create to trustdomain_add but forgot to rerun >makeapi. New edition attached for all subdomain-related patches: I did some tests and all is working as expected. freeipa-abbra-0117-ipaserver-dcerpc.py-populate-forest-trust-informatio-3.patch Use realmdomains to report name suffix routes at the time we establish trust freeipa-abbra-0118-trusts-support-subdomains-in-a-forest-3.patch Introduce trustdomain-* commands to fetch list of domains associated with a forest trust and allow filtering them off We talked on irc that ipaNTSupportedEncryptionTypes in the filter for the trusted domains should be replace by a different attribute. Because of an error in ipasam the ipaNTSupportedEncryptionTypes is only set in recent versions and might not be present in the directory trees of older versions. Fixed in the attached patch 0118 version 4. Also attached first attempt to implement transiting through trusted domains, as patch 0123. In this patch we grant transition only if all three realms (client, transited realm, and server realm) match any of our trusted domains and our domain. This is probably a bit wider but it worked for me bidirectionally, from a child domain to a service in IPA, and from IPA realm to a service in a child domain of a forest trust. -- / Alexander Bokovoy >From cc18f9a3a55c431c70231b83d1d4a0e567bcd64b Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Wed, 18 Sep 2013 17:04:19 +0200 Subject: [PATCH 2/7] trusts: support subdomains in a forest Add IPA CLI to manage trust domains. ipa trustdomain-fetch-- fetch list of subdomains from AD side and add new ones to IPA ipa trustdomain-find -- show all available domains ipa trustdomain-del -- remove domain from IPA view about 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 --- API.txt | 73 ipalib/plugins/trust.py | 296 +++- ipaserver/dcerpc.py | 54 + 3 files changed, 371 insertions(+), 52 deletions(-) diff --git a/API.txt b/API.txt index 761d1d1..674ff6c 100644 --- a/API.txt +++ b/API.txt @@ -3497,6 +3497,79 @@ option: Str('version?', exclude='webui') output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) output: Output('summary', (, ), None) output: Output('value', , None) +command: trustdomain_add +args: 2,9,3 +arg: Str('trustcn', cli_name='trust', query=True, required=True) +arg: Str('cn', cli_name='domain') +option: Str('addattr*', cli_name='addattr', exclude='webui') +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('ipantflatname', attribute=True, cli_name='flat_name', multivalue=False, required=False) +option: Str('ipanttrusteddomainsid', attribute=True, cli_name='s
Re: [Freeipa-devel] [PATCH] 0118 add support for subdomains
On Fri, Sep 27, 2013 at 03:53:08PM +0300, Alexander Bokovoy wrote: > On Mon, 23 Sep 2013, Alexander Bokovoy wrote: > >On Mon, 23 Sep 2013, Alexander Bokovoy wrote: > >>On Mon, 23 Sep 2013, Alexander Bokovoy wrote: > >>>On Mon, 23 Sep 2013, Martin Kosek wrote: > >>However, we don't have trust type available so it needs to discovered > >>every time. This doesn't play well with the framework, it is simply not > >>expecting dynamic containers. > > > >This doesn't sound like a big obstacle to me. Right now the trust_type > >lookup > >is done in trust_show.execute() for some reason, which is not the best > >place to > >do it IMHO. Doing it in trust.get_dn() instead should simplify things > >enough to > >make parent_object work. > > Yup, get_dn() is the method where object DN lookup should be done. See for > example host.py plugin get_dn method, we also do a dynamic lookup for > correct > host name. > >>>I'll see if that would work. > >>> > the best way to implement dynamic DN gathering is the get_dn() method. > That > way, it could be implemented in one place and all commands could take > advantage > of it instead of re-implementing it several times in pre_callback - this > is > just hackish. > >>>I'd suggest you look into the code. The commands use pre_callback for a > >>>different purpose than implementing dynamic DN gathering. > >>> > I think it would have been very useful to have a design page before > sending a > patch. It is then easier to make design decisions without having to dig > into > the patch. > >>>The design page is there for long time: > >>>http://www.freeipa.org/page/V3/Transitive_Trusts > >>Ok, here is new version of the patch and updated version of my 0117 > >>patch as Sumit noticed I've sent wrong version. > >Ok, here is updated 0118 which fixes API.txt change for trustdomain_add > >-- I renamed trustdomain_create to trustdomain_add but forgot to rerun > >makeapi. > New edition attached for all subdomain-related patches: I did some tests and all is working as expected. > > freeipa-abbra-0117-ipaserver-dcerpc.py-populate-forest-trust-informatio-3.patch > Use realmdomains to report name suffix routes at the time we establish trust > > freeipa-abbra-0118-trusts-support-subdomains-in-a-forest-3.patch > Introduce trustdomain-* commands to fetch list of domains associated > with a forest trust and allow filtering them off We talked on irc that ipaNTSupportedEncryptionTypes in the filter for the trusted domains should be replace by a different attribute. Because of an error in ipasam the ipaNTSupportedEncryptionTypes is only set in recent versions and might not be present in the directory trees of older versions. bye, Sumit > > freeipa-abbra-0119-frontend-report-arguments-errors-with-better-detail.patch > Small fix to error reporting in parameters validation to show what > command produced an error and what was the context for it > > freeipa-abbra-0120-ipaserver-dcerpc-remove-use-of-trust-account-authent.patch > Removal of trust account password use. We don't need it anymore as > KDC is now capable to produce MS-PAC for HTTP/ipa.master principal > > freeipa-abbra-0121-trust-integrate-subdomains-support-into-trust-add.patch > Add automation for trust subdomains -- discover them at the time of > establishing trust and add ranges for non-POSIX case. In POSIX > attributes case no ranges are needed as trust idrange is used > instead. > > freeipa-abbra-0122-ipasam-for-subdomains-pick-up-defaults-for-missing-v.patch > Make sure to fill in missing details for subdomains. Subdomains are > stored in the LDAP tree without information about trust type, direction, > and attributes as they are the same for subdomains and the trust root > domain. > > > -- > / Alexander Bokovoy > >From 5d0c5e8c4373fcfc92b4fa5113a554debb435073 Mon Sep 17 00:00:00 2001 > From: Alexander Bokovoy > Date: Wed, 11 Sep 2013 21:34:55 +0300 > Subject: [PATCH 1/7] ipaserver/dcerpc.py: populate forest trust information > using realmdomains > > Use realmdomains information to prepopulate forest trust info. As result, > all additional domains should now be enabled from the beginning, unless they > really conflict with existing DNS domains on AD side. > > https://fedorahosted.org/freeipa/ticket/3919 > --- > ipaserver/dcerpc.py | 113 > +++- > 1 file changed, 95 insertions(+), 18 deletions(-) > > diff --git a/ipaserver/dcerpc.py b/ipaserver/dcerpc.py > index bd8f5aa..c24230b 100644 > --- a/ipaserver/dcerpc.py > +++ b/ipaserver/dcerpc.py > @@ -39,7 +39,7 @@ import uuid > from samba import param > from samba import credentials > from samba.dcerpc import security, lsa, drsblobs, nbt, netlogon > -from samba.ndr import ndr_pack > +from samba.ndr import ndr_pack, ndr_print > from samba import net > import samba > import random >
Re: [Freeipa-devel] [PATCH] 0118 add support for subdomains
On Fri, 27 Sep 2013, Sumit Bose wrote: On Mon, Sep 23, 2013 at 06:04:22PM +0300, Alexander Bokovoy wrote: On Mon, 23 Sep 2013, Alexander Bokovoy wrote: >On Mon, 23 Sep 2013, Alexander Bokovoy wrote: >>On Mon, 23 Sep 2013, Martin Kosek wrote: >However, we don't have trust type available so it needs to discovered >every time. This doesn't play well with the framework, it is simply not >expecting dynamic containers. This doesn't sound like a big obstacle to me. Right now the trust_type lookup is done in trust_show.execute() for some reason, which is not the best place to do it IMHO. Doing it in trust.get_dn() instead should simplify things enough to make parent_object work. >>> >>>Yup, get_dn() is the method where object DN lookup should be done. See for >>>example host.py plugin get_dn method, we also do a dynamic lookup for correct >>>host name. >>I'll see if that would work. >> >>>the best way to implement dynamic DN gathering is the get_dn() method. That >>>way, it could be implemented in one place and all commands could take advantage >>>of it instead of re-implementing it several times in pre_callback - this is >>>just hackish. >>I'd suggest you look into the code. The commands use pre_callback for a >>different purpose than implementing dynamic DN gathering. >> >>>I think it would have been very useful to have a design page before sending a >>>patch. It is then easier to make design decisions without having to dig into >>>the patch. >>The design page is there for long time: >>http://www.freeipa.org/page/V3/Transitive_Trusts >Ok, here is new version of the patch and updated version of my 0117 >patch as Sumit noticed I've sent wrong version. Ok, here is updated 0118 which fixes API.txt change for trustdomain_add -- I renamed trustdomain_create to trustdomain_add but forgot to rerun makeapi. I haven't see any issue during build or using the latest version of 0117 (please note the latest version of 0117 is 2 emails earlier in this thread) and 0118. So it is an ACK from me for the functional part. But since there were some discussion about the usage of the internal Python API it would be nice if someone can check the python side as well. I've rewrote the patches to follow what we discussed. New patchset is sent separately, includes patches 0117-0122. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0118 add support for subdomains
On Mon, 23 Sep 2013, Alexander Bokovoy wrote: On Mon, 23 Sep 2013, Alexander Bokovoy wrote: On Mon, 23 Sep 2013, Alexander Bokovoy wrote: On Mon, 23 Sep 2013, Martin Kosek wrote: However, we don't have trust type available so it needs to discovered every time. This doesn't play well with the framework, it is simply not expecting dynamic containers. This doesn't sound like a big obstacle to me. Right now the trust_type lookup is done in trust_show.execute() for some reason, which is not the best place to do it IMHO. Doing it in trust.get_dn() instead should simplify things enough to make parent_object work. Yup, get_dn() is the method where object DN lookup should be done. See for example host.py plugin get_dn method, we also do a dynamic lookup for correct host name. I'll see if that would work. the best way to implement dynamic DN gathering is the get_dn() method. That way, it could be implemented in one place and all commands could take advantage of it instead of re-implementing it several times in pre_callback - this is just hackish. I'd suggest you look into the code. The commands use pre_callback for a different purpose than implementing dynamic DN gathering. I think it would have been very useful to have a design page before sending a patch. It is then easier to make design decisions without having to dig into the patch. The design page is there for long time: http://www.freeipa.org/page/V3/Transitive_Trusts Ok, here is new version of the patch and updated version of my 0117 patch as Sumit noticed I've sent wrong version. Ok, here is updated 0118 which fixes API.txt change for trustdomain_add -- I renamed trustdomain_create to trustdomain_add but forgot to rerun makeapi. New edition attached for all subdomain-related patches: freeipa-abbra-0117-ipaserver-dcerpc.py-populate-forest-trust-informatio-3.patch Use realmdomains to report name suffix routes at the time we establish trust freeipa-abbra-0118-trusts-support-subdomains-in-a-forest-3.patch Introduce trustdomain-* commands to fetch list of domains associated with a forest trust and allow filtering them off freeipa-abbra-0119-frontend-report-arguments-errors-with-better-detail.patch Small fix to error reporting in parameters validation to show what command produced an error and what was the context for it freeipa-abbra-0120-ipaserver-dcerpc-remove-use-of-trust-account-authent.patch Removal of trust account password use. We don't need it anymore as KDC is now capable to produce MS-PAC for HTTP/ipa.master principal freeipa-abbra-0121-trust-integrate-subdomains-support-into-trust-add.patch Add automation for trust subdomains -- discover them at the time of establishing trust and add ranges for non-POSIX case. In POSIX attributes case no ranges are needed as trust idrange is used instead. freeipa-abbra-0122-ipasam-for-subdomains-pick-up-defaults-for-missing-v.patch Make sure to fill in missing details for subdomains. Subdomains are stored in the LDAP tree without information about trust type, direction, and attributes as they are the same for subdomains and the trust root domain. -- / Alexander Bokovoy >From 5d0c5e8c4373fcfc92b4fa5113a554debb435073 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Wed, 11 Sep 2013 21:34:55 +0300 Subject: [PATCH 1/7] ipaserver/dcerpc.py: populate forest trust information using realmdomains Use realmdomains information to prepopulate forest trust info. As result, all additional domains should now be enabled from the beginning, unless they really conflict with existing DNS domains on AD side. https://fedorahosted.org/freeipa/ticket/3919 --- ipaserver/dcerpc.py | 113 +++- 1 file changed, 95 insertions(+), 18 deletions(-) diff --git a/ipaserver/dcerpc.py b/ipaserver/dcerpc.py index bd8f5aa..c24230b 100644 --- a/ipaserver/dcerpc.py +++ b/ipaserver/dcerpc.py @@ -39,7 +39,7 @@ import uuid from samba import param from samba import credentials from samba.dcerpc import security, lsa, drsblobs, nbt, netlogon -from samba.ndr import ndr_pack +from samba.ndr import ndr_pack, ndr_print from samba import net import samba import random @@ -684,6 +684,12 @@ class DomainValidator(object): self._info[domain] = info return info +def string_to_array(what): +blob = [0] * len(what) + +for i in range(len(what)): +blob[i] = ord(what[i]) +return blob class TrustDomainInstance(object): @@ -698,6 +704,7 @@ class TrustDomainInstance(object): self._pipe = None self._policy_handle = None self.read_only = False +self.ftinfo_records = None def __gen_lsa_connection(self, binding): if self.creds is None: @@ -827,12 +834,6 @@ class TrustDomainInstance(object): def arcfour_encrypt(key, data): c = RC4.RC4(key) return c.update(data) -def string_to_array(what): -blob = [0] * len(what) - -
Re: [Freeipa-devel] [PATCH] 0118 add support for subdomains
On Mon, Sep 23, 2013 at 06:04:22PM +0300, Alexander Bokovoy wrote: > On Mon, 23 Sep 2013, Alexander Bokovoy wrote: > >On Mon, 23 Sep 2013, Alexander Bokovoy wrote: > >>On Mon, 23 Sep 2013, Martin Kosek wrote: > >However, we don't have trust type available so it needs to discovered > >every time. This doesn't play well with the framework, it is simply not > >expecting dynamic containers. > > This doesn't sound like a big obstacle to me. Right now the trust_type > lookup > is done in trust_show.execute() for some reason, which is not the best > place to > do it IMHO. Doing it in trust.get_dn() instead should simplify things > enough to > make parent_object work. > >>> > >>>Yup, get_dn() is the method where object DN lookup should be done. See for > >>>example host.py plugin get_dn method, we also do a dynamic lookup for > >>>correct > >>>host name. > >>I'll see if that would work. > >> > >>>the best way to implement dynamic DN gathering is the get_dn() method. That > >>>way, it could be implemented in one place and all commands could take > >>>advantage > >>>of it instead of re-implementing it several times in pre_callback - this is > >>>just hackish. > >>I'd suggest you look into the code. The commands use pre_callback for a > >>different purpose than implementing dynamic DN gathering. > >> > >>>I think it would have been very useful to have a design page before > >>>sending a > >>>patch. It is then easier to make design decisions without having to dig > >>>into > >>>the patch. > >>The design page is there for long time: > >>http://www.freeipa.org/page/V3/Transitive_Trusts > >Ok, here is new version of the patch and updated version of my 0117 > >patch as Sumit noticed I've sent wrong version. > Ok, here is updated 0118 which fixes API.txt change for trustdomain_add > -- I renamed trustdomain_create to trustdomain_add but forgot to rerun > makeapi. I haven't see any issue during build or using the latest version of 0117 (please note the latest version of 0117 is 2 emails earlier in this thread) and 0118. So it is an ACK from me for the functional part. But since there were some discussion about the usage of the internal Python API it would be nice if someone can check the python side as well. bye, Sumit > > -- > / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0118 add support for subdomains
On Mon, 23 Sep 2013, Alexander Bokovoy wrote: On Mon, 23 Sep 2013, Alexander Bokovoy wrote: On Mon, 23 Sep 2013, Martin Kosek wrote: However, we don't have trust type available so it needs to discovered every time. This doesn't play well with the framework, it is simply not expecting dynamic containers. This doesn't sound like a big obstacle to me. Right now the trust_type lookup is done in trust_show.execute() for some reason, which is not the best place to do it IMHO. Doing it in trust.get_dn() instead should simplify things enough to make parent_object work. Yup, get_dn() is the method where object DN lookup should be done. See for example host.py plugin get_dn method, we also do a dynamic lookup for correct host name. I'll see if that would work. the best way to implement dynamic DN gathering is the get_dn() method. That way, it could be implemented in one place and all commands could take advantage of it instead of re-implementing it several times in pre_callback - this is just hackish. I'd suggest you look into the code. The commands use pre_callback for a different purpose than implementing dynamic DN gathering. I think it would have been very useful to have a design page before sending a patch. It is then easier to make design decisions without having to dig into the patch. The design page is there for long time: http://www.freeipa.org/page/V3/Transitive_Trusts Ok, here is new version of the patch and updated version of my 0117 patch as Sumit noticed I've sent wrong version. Ok, here is updated 0118 which fixes API.txt change for trustdomain_add -- I renamed trustdomain_create to trustdomain_add but forgot to rerun makeapi. -- / Alexander Bokovoy >From 2bec4dd4709a31d6dfbfc76c5b747ad4a290d742 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Wed, 18 Sep 2013 17:04:19 +0200 Subject: [PATCH 2/2] trusts: support subdomains in a forest Add IPA CLI to manage trust domains. ipa trustdomain-fetch-- fetch list of subdomains from AD side and add new ones to IPA ipa trustdomain-find -- show all available domains ipa trustdomain-del -- remove domain from IPA view about 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 --- API.txt | 72 ++ ipalib/plugins/trust.py | 248 ++-- ipaserver/dcerpc.py | 54 +++ 3 files changed, 323 insertions(+), 51 deletions(-) diff --git a/API.txt b/API.txt index 761d1d1..3239f53 100644 --- a/API.txt +++ b/API.txt @@ -3497,6 +3497,78 @@ option: Str('version?', exclude='webui') output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) output: Output('summary', (, ), None) output: Output('value', , None) +command: trustdomain_add +args: 3,9,3 +arg: Str('trustcn', cli_name='trust', query=True, required=True) +arg: Str('trust?') +arg: Str('cn?', cli_name='domain', primary_key=True) +option: Str('addattr*', cli_name='addattr', exclude='webui') +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('ipantflatname', attribute=True, cli_name='flat_name', multivalue=False, required=False) +option: Str('ipanttrusteddomainsid', attribute=True, cli_name='sid', multivalue=False, required=False) +option: Str('ipanttrustpartner?') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('setattr*', cli_name='setattr', exclude='webui') +option: StrEnum('trust_type', autofill=True, cli_name='type', default=u'ad', values=(u'ad',)) +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: Output('value', , None) +command: trustdomain_del +args: 3,2,3 +arg: Str('trustcn', cli_name='trust', query=True, required=True) +arg: Str('trust?') +arg: Str('cn?', cli_name='domain', primary_key=True) +option: Flag('continue', autofill=True, cli_name='continue', default=False) +option: Str('version?', exclude='webui') +output: Output('result', , None) +output: Output('summary', (, ), None) +output: Output('value', , None) +command: trustdomain_fetch +args: 2,4,2 +arg: Str('trustcn', cli_name='trust', query=True, required=True) +arg: Str('trust?') +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Str('version?', exclude='webui') +output: ListOfEntries('result', (, ), Gettext('A list of LDAP entries', domain='ipa', localedir=None)) +out
Re: [Freeipa-devel] [PATCH] 0118 add support for subdomains
On Mon, 23 Sep 2013, Alexander Bokovoy wrote: On Mon, 23 Sep 2013, Martin Kosek wrote: However, we don't have trust type available so it needs to discovered every time. This doesn't play well with the framework, it is simply not expecting dynamic containers. This doesn't sound like a big obstacle to me. Right now the trust_type lookup is done in trust_show.execute() for some reason, which is not the best place to do it IMHO. Doing it in trust.get_dn() instead should simplify things enough to make parent_object work. Yup, get_dn() is the method where object DN lookup should be done. See for example host.py plugin get_dn method, we also do a dynamic lookup for correct host name. I'll see if that would work. the best way to implement dynamic DN gathering is the get_dn() method. That way, it could be implemented in one place and all commands could take advantage of it instead of re-implementing it several times in pre_callback - this is just hackish. I'd suggest you look into the code. The commands use pre_callback for a different purpose than implementing dynamic DN gathering. I think it would have been very useful to have a design page before sending a patch. It is then easier to make design decisions without having to dig into the patch. The design page is there for long time: http://www.freeipa.org/page/V3/Transitive_Trusts Ok, here is new version of the patch and updated version of my 0117 patch as Sumit noticed I've sent wrong version. -- / Alexander Bokovoy >From e2b43dae3b413fed303e7bde08e7868a9487ccbe Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Wed, 11 Sep 2013 21:34:55 +0300 Subject: [PATCH 1/2] ipaserver/dcerpc.py: populate forest trust information using realmdomains Use realmdomains information to prepopulate forest trust info. As result, all additional domains should now be enabled from the beginning, unless they really conflict with existing DNS domains on AD side. https://fedorahosted.org/freeipa/ticket/3919 --- ipaserver/dcerpc.py | 113 +++- 1 file changed, 95 insertions(+), 18 deletions(-) diff --git a/ipaserver/dcerpc.py b/ipaserver/dcerpc.py index bd8f5aa..c24230b 100644 --- a/ipaserver/dcerpc.py +++ b/ipaserver/dcerpc.py @@ -39,7 +39,7 @@ import uuid from samba import param from samba import credentials from samba.dcerpc import security, lsa, drsblobs, nbt, netlogon -from samba.ndr import ndr_pack +from samba.ndr import ndr_pack, ndr_print from samba import net import samba import random @@ -684,6 +684,12 @@ class DomainValidator(object): self._info[domain] = info return info +def string_to_array(what): +blob = [0] * len(what) + +for i in range(len(what)): +blob[i] = ord(what[i]) +return blob class TrustDomainInstance(object): @@ -698,6 +704,7 @@ class TrustDomainInstance(object): self._pipe = None self._policy_handle = None self.read_only = False +self.ftinfo_records = None def __gen_lsa_connection(self, binding): if self.creds is None: @@ -827,12 +834,6 @@ class TrustDomainInstance(object): def arcfour_encrypt(key, data): c = RC4.RC4(key) return c.update(data) -def string_to_array(what): -blob = [0] * len(what) - -for i in range(len(what)): -blob[i] = ord(what[i]) -return blob password_blob = string_to_array(trustdom_secret.encode('utf-16-le')) @@ -876,6 +877,53 @@ class TrustDomainInstance(object): self.auth_info = auth_info +def generate_ftinfo(self, another_domain): +""" +Generates TrustDomainInfoFullInfo2Internal structure +This structure allows to pass information about all domains associated +with the another domain's realm. + +Only top level name and top level name exclusions are handled here. +""" +if not another_domain.ftinfo_records: +return + +ftinfo_records = [] +info = lsa.ForestTrustInformation() + +for rec in another_domain.ftinfo_records: +record = lsa.ForestTrustRecord() +record.flags = 0 +record.time = rec['rec_time'] +record.type = rec['rec_type'] +record.forest_trust_data.string = rec['rec_name'] +ftinfo_records.append(record) + +info.count = len(ftinfo_records) +info.entries = ftinfo_records +return info + +def update_ftinfo(self, another_domain): +""" +Updates forest trust information in this forest corresponding +to the another domain's information. +""" +try: +if another_domain.ftinfo_records: +ftinfo = self.generate_ftinfo(another_domain) +# Set forest trust information -- we do it only against AD DC as +# smbd already has the information about itself +ldn
Re: [Freeipa-devel] [PATCH] 0118 add support for subdomains
On Mon, 23 Sep 2013, Martin Kosek wrote: However, we don't have trust type available so it needs to discovered every time. This doesn't play well with the framework, it is simply not expecting dynamic containers. This doesn't sound like a big obstacle to me. Right now the trust_type lookup is done in trust_show.execute() for some reason, which is not the best place to do it IMHO. Doing it in trust.get_dn() instead should simplify things enough to make parent_object work. Yup, get_dn() is the method where object DN lookup should be done. See for example host.py plugin get_dn method, we also do a dynamic lookup for correct host name. I'll see if that would work. the best way to implement dynamic DN gathering is the get_dn() method. That way, it could be implemented in one place and all commands could take advantage of it instead of re-implementing it several times in pre_callback - this is just hackish. I'd suggest you look into the code. The commands use pre_callback for a different purpose than implementing dynamic DN gathering. I think it would have been very useful to have a design page before sending a patch. It is then easier to make design decisions without having to dig into the patch. The design page is there for long time: http://www.freeipa.org/page/V3/Transitive_Trusts -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0118 add support for subdomains
On 09/20/2013 01:59 PM, Jan Cholasta wrote: > On 20.9.2013 12:55, Alexander Bokovoy wrote: > 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. subdomains as objects are not visible to users. Users cannot operate on subdomains themselves. I do not want to give you impression we are having separate trust and domains. Instead, we deal with trusts and subdomains are simply internal components of it. >>> >>> They are part of the API, whether they are visible to users or not, >>> and they should follow the same convention as the rest of the API. >>> >>> From the framework perspective, subdomains are child objects of >>> trusts, no different to how DNS records are child objects of DNS >>> zones, except they are internal and not visible to users. You even >>> implemented them this way in the patch, I just don't like how hackily >>> it is done. >> The difference is that with DNS records and zones you have explicit >> mapping -- record is under zone and zone is under dns container. The DN >> is explicitly defined by input under static DNS container DN. >> >> With trusts there are few possible containers and input does not define >> the DN fully. We have trust type which means whenever trust is created, >> type is either default or explicitly set, yet for any other operation on >> the trust its type is not specified and has to be looked up. >> >> With subdomains under trusts we get another level of indirection. Had >> subdomains and trusts be based on a static DN, it could have worked. >> However, we don't have trust type available so it needs to discovered >> every time. This doesn't play well with the framework, it is simply not >> expecting dynamic containers. > > This doesn't sound like a big obstacle to me. Right now the trust_type lookup > is done in trust_show.execute() for some reason, which is not the best place > to > do it IMHO. Doing it in trust.get_dn() instead should simplify things enough > to > make parent_object work. Yup, get_dn() is the method where object DN lookup should be done. See for example host.py plugin get_dn method, we also do a dynamic lookup for correct host name. > >> The fact that you currently see these commands in 'ipa trust-*' family reflects the situation. -mod command is intended to be internal as well, it will not be visible in CLI in the end. The only command available to users will be 'ipa trust-domain-fetch'. >>> >>> All the more reason for following the usual convention. >> I don't follow you here. With a single visible command added to the >> trust family why it should be 'ipa trustdomain-fetch' instead of 'ipa >> trust-domain-fetch'? What is the reason for inconsistency. > > Sorry, I should have been more specific - trust-domain-fetch is OK and the > rest > of the commands are not visible in the CLI, so naming them trustdomain-* will > not confuse anyone. +1 for being consistent with the rest of the system, even if the commands are internal (for now), we should keep the naming conventions that are present in the rest of the system. Since we are operating on trust domain objects, the API should be: trustdomain-add trustdomain-del trustdomain-find trustdomain-mod + the visible commands on Trust. I did not dig into code, but as Honza said, the best way to implement dynamic DN gathering is the get_dn() method. That way, it could be implemented in one place and all commands could take advantage of it instead of re-implementing it several times in pre_callback - this is just hackish. Alexander, can you please work with Honza in case the get_dn function does not work for you? He may prepare a patch for you if he has an idea how to do it better. > >> >> Current way framework lays down object-verb system is due to >> implementation convenience, not because this is a really required from >> CLI point of view. I believe I have reasonable arguments to not fall >> into trap of having multiple objects visible to CLI. CLI should be >> simple to use, it should not expose too much of internal complexity >> where not required. > > I agree with this. As I said above, I am not suggesting making the trust > domain > objects visible to users. As above, even if the commands are internal, let's make them consistent with rest of the framework. It would be very hard to change API later if we for example find we want to expose the API. > 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. It does not work in this case properly. Feel free to try to implement it, really. I have spent good deal of last
Re: [Freeipa-devel] [PATCH] 0118 add support for subdomains
On Thu, Sep 19, 2013 at 10:08:37PM +0300, Alexander Bokovoy wrote: > Hi! > > Attached patch adds IPA CLI to manage trust subdomains. > > ipa trust-domain-fetch-- fetch list of subdomains from AD side and > add new ones to IPA > ipa trust-domain-find -- show all available subdomains > ipa trust-domain-del -- remove subdomain from IPA > view about > ipa trust-domain-mod -- 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. I just want to let you know that I successfully tested you patch with sssd in a setup with the hierarchical case, i.e. the DNS name of the subdomain is a child of the DNS name of the forest root. I also didn't need to change the realm-domain mapping (https://fedorahosted.org/sssd/ticket/2080) in this case. I will test again with a non-hierarchical setup. bye, Sumit > > part of https://fedorahosted.org/freeipa/ticket/3909 > > The patch implements some dark magic to get around IPA framework > limitations: > > -- CLI commands belong to 'trust' family but operate on 'subdomain' object > -- 'subdomain' objects are stored under trust container, thus making > container_dn dependent on a particular trust: > cn=,cn=,cn=ad,cn=trusts,$SUFFIX > > 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. > > -- > / Alexander Bokovoy > >From bf6145368cd517557f9839586cae32160291964e Mon Sep 17 00:00:00 2001 > From: Alexander Bokovoy > Date: Wed, 18 Sep 2013 17:04:19 +0200 > Subject: [PATCH 5/5] trusts: support subdomains in a forest > > Add IPA CLI to manage trust subdomains. > > ipa trust-domain-fetch-- fetch list of subdomains from AD side and > add new ones to IPA > ipa trust-domain-find -- show all available subdomains > ipa trust-domain-del -- remove subdomain from IPA view about > > ipa trust-domain-mod -- 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 > --- > API.txt | 67 ++ > ipalib/plugins/trust.py | 176 > +++- > ipaserver/dcerpc.py | 54 +++ > 3 files changed, 295 insertions(+), 2 deletions(-) > > diff --git a/API.txt b/API.txt > index 761d1d1..a7c97e0 100644 > --- a/API.txt > +++ b/API.txt > @@ -3423,6 +3423,73 @@ option: Str('version?', exclude='webui') > output: Output('result', , None) > output: Output('summary', (, ), None) > output: Output('value', , None) > +command: trust_domain_create > +args: 2,9,3 > +arg: Str('trust?') > +arg: Str('cn?', cli_name='domain', primary_key=True) > +option: Str('addattr*', cli_name='addattr', exclude='webui') > +option: Flag('all', autofill=True, cli_name='all', default=False, > exclude='webui') > +option: Str('ipantflatname', attribute=True, cli_name='flat_name', > multivalue=False, required=False) > +option: Str('ipanttrusteddomainsid', attribute=True, cli_name='sid', > multivalue=False, required=False) > +option: Str('ipanttrustpartner?') > +option: Flag('raw', autofill=True, cli_name='raw', default=False, > exclude='webui') > +option: Str('setattr*', cli_name='setattr', exclude='webui') > +option: StrEnum('trust_type', autofill=True, cli_name='type', default=u'ad', > values=(u'ad',)) > +option: Str('version?', exclude='webui') > +output: Entry('result', , Gettext('A dictionary representing an > LDAP entry', domain='ipa', localedir=None)) > +output: Output('summary', (, ), None) > +output: Output('value', , None) > +command: trust_domain_del > +args: 2,2,3 > +arg: Str('trust?') > +arg: Str('cn?', cli_name='domain', primary_key=True) > +option: Flag('continue', autofill=True, cli_name='continue', default=False) > +option: Str('version?', exclude='webui') > +output: Output('result', , None) > +output: Output('summary', (, ), None) > +output: Output('value', , None) > +command: trust_domain_fetch > +args: 1,4,2 > +arg: Str('trust?') > +option: Flag('all', autofill=True, cli_name='all', default=False, > exclude='webui') > +option: Flag('raw', autofill=True, cli_name='raw', default=False, > exclude='webui') > +option: Flag('rights', autofill=True, default=False) > +option: Str('version?', exclude='webui') > +output: ListOfEntries('result', (, )
Re: [Freeipa-devel] [PATCH] 0118 add support for subdomains
On 20.9.2013 12:55, Alexander Bokovoy wrote: 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. subdomains as objects are not visible to users. Users cannot operate on subdomains themselves. I do not want to give you impression we are having separate trust and domains. Instead, we deal with trusts and subdomains are simply internal components of it. They are part of the API, whether they are visible to users or not, and they should follow the same convention as the rest of the API. From the framework perspective, subdomains are child objects of trusts, no different to how DNS records are child objects of DNS zones, except they are internal and not visible to users. You even implemented them this way in the patch, I just don't like how hackily it is done. The difference is that with DNS records and zones you have explicit mapping -- record is under zone and zone is under dns container. The DN is explicitly defined by input under static DNS container DN. With trusts there are few possible containers and input does not define the DN fully. We have trust type which means whenever trust is created, type is either default or explicitly set, yet for any other operation on the trust its type is not specified and has to be looked up. With subdomains under trusts we get another level of indirection. Had subdomains and trusts be based on a static DN, it could have worked. However, we don't have trust type available so it needs to discovered every time. This doesn't play well with the framework, it is simply not expecting dynamic containers. This doesn't sound like a big obstacle to me. Right now the trust_type lookup is done in trust_show.execute() for some reason, which is not the best place to do it IMHO. Doing it in trust.get_dn() instead should simplify things enough to make parent_object work. The fact that you currently see these commands in 'ipa trust-*' family reflects the situation. -mod command is intended to be internal as well, it will not be visible in CLI in the end. The only command available to users will be 'ipa trust-domain-fetch'. All the more reason for following the usual convention. I don't follow you here. With a single visible command added to the trust family why it should be 'ipa trustdomain-fetch' instead of 'ipa trust-domain-fetch'? What is the reason for inconsistency. Sorry, I should have been more specific - trust-domain-fetch is OK and the rest of the commands are not visible in the CLI, so naming them trustdomain-* will not confuse anyone. Current way framework lays down object-verb system is due to implementation convenience, not because this is a really required from CLI point of view. I believe I have reasonable arguments to not fall into trap of having multiple objects visible to CLI. CLI should be simple to use, it should not expose too much of internal complexity where not required. I agree with this. As I said above, I am not suggesting making the trust domain objects visible to users. 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. It does not work in this case properly. Feel free to try to implement it, really. I have spent good deal of last two weeks trying all options possible. Why does it not work? The functionality of parent_object is pretty straightforward, so I can't imagine what might go wrong. See above. It is not designed for the use case of dynamic container DNs which involves components not derived from the input. Honza -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0118 add support for subdomains
On Fri, 20 Sep 2013, Jan Cholasta wrote: part of https://fedorahosted.org/freeipa/ticket/3909 The patch implements some dark magic to get around IPA framework limitations: -- CLI commands belong to 'trust' family but operate on 'subdomain' object -- 'subdomain' objects are stored under trust container, thus making container_dn dependent on a particular trust: cn=,cn=,cn=ad,cn=trusts,$SUFFIX 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: Have you read the reasoning first? Yes. 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. subdomains as objects are not visible to users. Users cannot operate on subdomains themselves. I do not want to give you impression we are having separate trust and domains. Instead, we deal with trusts and subdomains are simply internal components of it. They are part of the API, whether they are visible to users or not, and they should follow the same convention as the rest of the API. From the framework perspective, subdomains are child objects of trusts, no different to how DNS records are child objects of DNS zones, except they are internal and not visible to users. You even implemented them this way in the patch, I just don't like how hackily it is done. The difference is that with DNS records and zones you have explicit mapping -- record is under zone and zone is under dns container. The DN is explicitly defined by input under static DNS container DN. With trusts there are few possible containers and input does not define the DN fully. We have trust type which means whenever trust is created, type is either default or explicitly set, yet for any other operation on the trust its type is not specified and has to be looked up. With subdomains under trusts we get another level of indirection. Had subdomains and trusts be based on a static DN, it could have worked. However, we don't have trust type available so it needs to discovered every time. This doesn't play well with the framework, it is simply not expecting dynamic containers. The fact that you currently see these commands in 'ipa trust-*' family reflects the situation. -mod command is intended to be internal as well, it will not be visible in CLI in the end. The only command available to users will be 'ipa trust-domain-fetch'. All the more reason for following the usual convention. I don't follow you here. With a single visible command added to the trust family why it should be 'ipa trustdomain-fetch' instead of 'ipa trust-domain-fetch'? What is the reason for inconsistency. Current way framework lays down object-verb system is due to implementation convenience, not because this is a really required from CLI point of view. I believe I have reasonable arguments to not fall into trap of having multiple objects visible to CLI. CLI should be simple to use, it should not expose too much of internal complexity where not required. 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. It does not work in this case properly. Feel free to try to implement it, really. I have spent good deal of last two weeks trying all options possible. Why does it not work? The functionality of parent_object is pretty straightforward, so I can't imagine what might go wrong. See above. It is not designed for the use case of dynamic container DNs which involves components not derived from the input. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0118 add support for subdomains
On 20.9.2013 09:36, Alexander Bokovoy wrote: On Fri, 20 Sep 2013, Jan Cholasta wrote: On 19.9.2013 21:08, Alexander Bokovoy wrote: Hi! Attached patch adds IPA CLI to manage trust subdomains. ipa trust-domain-fetch-- fetch list of subdomains from AD side and add new ones to IPA ipa trust-domain-find -- show all available subdomains ipa trust-domain-del -- remove subdomain from IPA view about ipa trust-domain-mod -- 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 limitations: -- CLI commands belong to 'trust' family but operate on 'subdomain' object -- 'subdomain' objects are stored under trust container, thus making container_dn dependent on a particular trust: cn=,cn=,cn=ad,cn=trusts,$SUFFIX 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: Have you read the reasoning first? Yes. 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. subdomains as objects are not visible to users. Users cannot operate on subdomains themselves. I do not want to give you impression we are having separate trust and domains. Instead, we deal with trusts and subdomains are simply internal components of it. They are part of the API, whether they are visible to users or not, and they should follow the same convention as the rest of the API. From the framework perspective, subdomains are child objects of trusts, no different to how DNS records are child objects of DNS zones, except they are internal and not visible to users. You even implemented them this way in the patch, I just don't like how hackily it is done. The fact that you currently see these commands in 'ipa trust-*' family reflects the situation. -mod command is intended to be internal as well, it will not be visible in CLI in the end. The only command available to users will be 'ipa trust-domain-fetch'. All the more reason for following the usual convention. 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. It does not work in this case properly. Feel free to try to implement it, really. I have spent good deal of last two weeks trying all options possible. Why does it not work? The functionality of parent_object is pretty straightforward, so I can't imagine what might go wrong. 3) Create commands are usually named "*_add", not "*_create". The command is internal, see NO_CLI there. I'm not tied to particular naming but it is not visible to users. 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. It operates on the trust. We don't have 'trust domains' at all. We have trusts and always had only trusts. Subdomains represent internal structure of the trust which is only visible to user for diagnostic purposes but practically users will not be able to modify them, only reference them for idranges. Again, it doesn't matter whether it's internal or not, it should still follow the usual convention, for consistency, maintainability and code readability. If trust_domain_fetch is the only one visible to users, I guess there's no harm in keeping the name. Honza -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0118 add support for subdomains
On Fri, 20 Sep 2013, Jan Cholasta wrote: On 19.9.2013 21:08, Alexander Bokovoy wrote: Hi! Attached patch adds IPA CLI to manage trust subdomains. ipa trust-domain-fetch-- fetch list of subdomains from AD side and add new ones to IPA ipa trust-domain-find -- show all available subdomains ipa trust-domain-del -- remove subdomain from IPA view about ipa trust-domain-mod -- 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 limitations: -- CLI commands belong to 'trust' family but operate on 'subdomain' object -- 'subdomain' objects are stored under trust container, thus making container_dn dependent on a particular trust: cn=,cn=,cn=ad,cn=trusts,$SUFFIX 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: Have you read the reasoning first? 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. subdomains as objects are not visible to users. Users cannot operate on subdomains themselves. I do not want to give you impression we are having separate trust and domains. Instead, we deal with trusts and subdomains are simply internal components of it. The fact that you currently see these commands in 'ipa trust-*' family reflects the situation. -mod command is intended to be internal as well, it will not be visible in CLI in the end. The only command available to users will be 'ipa trust-domain-fetch'. 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. It does not work in this case properly. Feel free to try to implement it, really. I have spent good deal of last two weeks trying all options possible. 3) Create commands are usually named "*_add", not "*_create". The command is internal, see NO_CLI there. I'm not tied to particular naming but it is not visible to users. 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. It operates on the trust. We don't have 'trust domains' at all. We have trusts and always had only trusts. Subdomains represent internal structure of the trust which is only visible to user for diagnostic purposes but practically users will not be able to modify them, only reference them for idranges. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0118 add support for subdomains
On 19.9.2013 21:08, Alexander Bokovoy wrote: Hi! Attached patch adds IPA CLI to manage trust subdomains. ipa trust-domain-fetch-- fetch list of subdomains from AD side and add new ones to IPA ipa trust-domain-find -- show all available subdomains ipa trust-domain-del -- remove subdomain from IPA view about ipa trust-domain-mod -- 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 limitations: -- CLI commands belong to 'trust' family but operate on 'subdomain' object -- 'subdomain' objects are stored under trust container, thus making container_dn dependent on a particular trust: cn=,cn=,cn=ad,cn=trusts,$SUFFIX 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. Honza -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 0118 add support for subdomains
Hi! Attached patch adds IPA CLI to manage trust subdomains. ipa trust-domain-fetch-- fetch list of subdomains from AD side and add new ones to IPA ipa trust-domain-find -- show all available subdomains ipa trust-domain-del -- remove subdomain from IPA view about ipa trust-domain-mod -- 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 limitations: -- CLI commands belong to 'trust' family but operate on 'subdomain' object -- 'subdomain' objects are stored under trust container, thus making container_dn dependent on a particular trust: cn=,cn=,cn=ad,cn=trusts,$SUFFIX 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. -- / Alexander Bokovoy >From bf6145368cd517557f9839586cae32160291964e Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Wed, 18 Sep 2013 17:04:19 +0200 Subject: [PATCH 5/5] trusts: support subdomains in a forest Add IPA CLI to manage trust subdomains. ipa trust-domain-fetch-- fetch list of subdomains from AD side and add new ones to IPA ipa trust-domain-find -- show all available subdomains ipa trust-domain-del -- remove subdomain from IPA view about ipa trust-domain-mod -- 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 --- API.txt | 67 ++ ipalib/plugins/trust.py | 176 +++- ipaserver/dcerpc.py | 54 +++ 3 files changed, 295 insertions(+), 2 deletions(-) diff --git a/API.txt b/API.txt index 761d1d1..a7c97e0 100644 --- a/API.txt +++ b/API.txt @@ -3423,6 +3423,73 @@ option: Str('version?', exclude='webui') output: Output('result', , None) output: Output('summary', (, ), None) output: Output('value', , None) +command: trust_domain_create +args: 2,9,3 +arg: Str('trust?') +arg: Str('cn?', cli_name='domain', primary_key=True) +option: Str('addattr*', cli_name='addattr', exclude='webui') +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('ipantflatname', attribute=True, cli_name='flat_name', multivalue=False, required=False) +option: Str('ipanttrusteddomainsid', attribute=True, cli_name='sid', multivalue=False, required=False) +option: Str('ipanttrustpartner?') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('setattr*', cli_name='setattr', exclude='webui') +option: StrEnum('trust_type', autofill=True, cli_name='type', default=u'ad', values=(u'ad',)) +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: Output('value', , None) +command: trust_domain_del +args: 2,2,3 +arg: Str('trust?') +arg: Str('cn?', cli_name='domain', primary_key=True) +option: Flag('continue', autofill=True, cli_name='continue', default=False) +option: Str('version?', exclude='webui') +output: Output('result', , None) +output: Output('summary', (, ), None) +output: Output('value', , None) +command: trust_domain_fetch +args: 1,4,2 +arg: Str('trust?') +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Str('version?', exclude='webui') +output: ListOfEntries('result', (, ), Gettext('A list of LDAP entries', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +command: trust_domain_find +args: 2,8,4 +arg: Str('criteria?', noextrawhitespace=False) +arg: Str('trust?') +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('cn?', cli_name='domain', primary_key=True) +option: Str('ipantflatname', attribute=True, autofill=False, cli_name='flat_name', multivalue=False, query=True, required=False) +option: Str('ipanttrusteddomainsid', attribute=True, autofill=False, cli_name='sid', multivalue=False, query=True, required=False) +option: Flag('raw', autofill=True, cli_name