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 trust -- fetch list of subdomains from AD side and add new ones to IPA ipa trust-domain-find trust-- show all available subdomains ipa trust-domain-del trust domain -- remove subdomain from IPA view about trust ipa trust-domain-mod trust domain -- modify subdomain parameters (work in progress) IPA KDC needs also information for authentication paths to subdomains in case they are not hierarchical under AD forest trust root. This information is managed via capaths section in krb5.conf. SSSD should be able to generate it once ticket https://fedorahosted.org/sssd/ticket/2093 is resolved. part of https://fedorahosted.org/freeipa/ticket/3909 The patch implements some dark magic to get around IPA framework 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=subdomain,cn=trust,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
Re: [Freeipa-devel] [PATCH] 0114 ipa-sam: fix setting encryption type for trust object already created
On 09/11/2013 09:12 PM, Alexander Bokovoy wrote: On Wed, 11 Sep 2013, Simo Sorce wrote: On Tue, 2013-09-10 at 19:31 +0300, Alexander Bokovoy wrote: On Sat, 07 Sep 2013, Simo Sorce wrote: On Sat, 2013-09-07 at 21:32 +0300, Alexander Bokovoy wrote: On Sat, 07 Sep 2013, Simo Sorce wrote: On Sat, 2013-09-07 at 21:01 +0300, Alexander Bokovoy wrote: On Sat, 07 Sep 2013, Simo Sorce wrote: On Thu, 2013-09-05 at 17:44 +0300, Alexander Bokovoy wrote: + enctypes = KERB_ENCTYPE_DES_CBC_CRC | + KERB_ENCTYPE_DES_CBC_MD5 | + KERB_ENCTYPE_RC4_HMAC_MD5 | + KERB_ENCTYPE_AES128_CTS_HMAC_SHA1_96 | + KERB_ENCTYPE_AES256_CTS_HMAC_SHA1_96; Why are we hardcoding support for *DES* enctype, we disable DES by default and also Windows never uses it by default. This is actually a copy of the same statement from fill_pdb_trusted_domain(). Should I remove it? Yes please remove DES types, is there any chance we can make this list configurable ? (not a hard requirement, only if ti is something easy to do, maybe as a further enhancement down the road). If you can point me to some place in cn=config or $SUFFIX that could be read by cifs/fqdn on ipa-sam module init, I can look in fetching that. But I suspect it is much harder to deduce exact list of supported types. Look in: cn=REALM.NAME,cn=kerberos,$SUFFIX there we have 2 lists: krbDefaultEncSaltTypes - use this krbSupportedEncSaltTypes in util/ipa_krb5.c we have then the funciton parse_bval_key_sal_tuples() that can covert strings to enctypes. RC4 enctype will be the only one available for Windows 2003 trusts then... It's the only one 2003 enables by default anyway and the only one that we can use as DES is disabled on FreeIPA. Since admin could enable DES on FreeIPA manually, right now ipa-sam would allow using DES to Windows 2003. If we remove DES enctypes unconditionally, it would not be possible. If you look at the attributes I pointed you at above, then you have a way to support DES by simply changing the defaults and restarting FreeIPA. DES is dead anyway and not sufficiently secure for cross-realm keys anymore, even if we do not support it at all I think we are just fine. Ok, attached three patches 0114-0116 is a new revision that implements also fetching encryption types from the Kerberos configuration container. The patches depend on each other in that order. I think you should explictly add cn=REALM.NAME to the filter when seraching the kerberos container in the 3rd patch. But beyond that the patches look sane to me (I haven't tested them though). I'm already searching on cn=REALM.NAME,cn=kerberos,$SUFFIX with a base scope so this is pretty tight, no need to expand the filter. (Simo agreed to this argument on IRC) ACK -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org ___ 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 trust -- fetch list of subdomains from AD side and add new ones to IPA ipa trust-domain-find trust-- show all available subdomains ipa trust-domain-del trust domain -- remove subdomain from IPA view about trust ipa trust-domain-mod trust domain -- modify subdomain parameters (work in progress) IPA KDC needs also information for authentication paths to subdomains in case they are not hierarchical under AD forest trust root. This information is managed via capaths section in krb5.conf. SSSD should be able to generate it once ticket https://fedorahosted.org/sssd/ticket/2093 is resolved. part of https://fedorahosted.org/freeipa/ticket/3909 The patch implements some dark magic to get around IPA framework 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=subdomain,cn=trust,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 109] Use getent admin@domain for nss check in, ipa-client-install
On 09/19/2013 04:41 PM, Ana Krivokapic wrote: On 09/19/2013 04:33 PM, Tomas Babej wrote: On 09/19/2013 11:59 AM, Tomas Babej wrote: Hi, Use 'getent admin@domain' rather than 'getent admin@REALM' to check if nss is working properly since admin@REALM check fails in case the domain and the realm name does not match. https://fedorahosted.org/freeipa/ticket/3906 Thanks to Ana for telling me I basically copied Stephen's patch: https://www.redhat.com/archives/freeipa-devel/2013-September/msg00085.html And I did the same mistake. Fixed patched attached. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ACK Pushed to: master: 316a9c215982527814089dc02be95fe14e635006 ipa-3-3: b0b7335cbaf104ba582c12b49e908c280d332cf6 -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0114 ipa-sam: fix setting encryption type for trust object already created
On 09/20/2013 09:23 AM, Tomas Babej wrote: On 09/11/2013 09:12 PM, Alexander Bokovoy wrote: On Wed, 11 Sep 2013, Simo Sorce wrote: On Tue, 2013-09-10 at 19:31 +0300, Alexander Bokovoy wrote: On Sat, 07 Sep 2013, Simo Sorce wrote: On Sat, 2013-09-07 at 21:32 +0300, Alexander Bokovoy wrote: On Sat, 07 Sep 2013, Simo Sorce wrote: On Sat, 2013-09-07 at 21:01 +0300, Alexander Bokovoy wrote: On Sat, 07 Sep 2013, Simo Sorce wrote: On Thu, 2013-09-05 at 17:44 +0300, Alexander Bokovoy wrote: + enctypes = KERB_ENCTYPE_DES_CBC_CRC | + KERB_ENCTYPE_DES_CBC_MD5 | + KERB_ENCTYPE_RC4_HMAC_MD5 | + KERB_ENCTYPE_AES128_CTS_HMAC_SHA1_96 | + KERB_ENCTYPE_AES256_CTS_HMAC_SHA1_96; Why are we hardcoding support for *DES* enctype, we disable DES by default and also Windows never uses it by default. This is actually a copy of the same statement from fill_pdb_trusted_domain(). Should I remove it? Yes please remove DES types, is there any chance we can make this list configurable ? (not a hard requirement, only if ti is something easy to do, maybe as a further enhancement down the road). If you can point me to some place in cn=config or $SUFFIX that could be read by cifs/fqdn on ipa-sam module init, I can look in fetching that. But I suspect it is much harder to deduce exact list of supported types. Look in: cn=REALM.NAME,cn=kerberos,$SUFFIX there we have 2 lists: krbDefaultEncSaltTypes - use this krbSupportedEncSaltTypes in util/ipa_krb5.c we have then the funciton parse_bval_key_sal_tuples() that can covert strings to enctypes. RC4 enctype will be the only one available for Windows 2003 trusts then... It's the only one 2003 enables by default anyway and the only one that we can use as DES is disabled on FreeIPA. Since admin could enable DES on FreeIPA manually, right now ipa-sam would allow using DES to Windows 2003. If we remove DES enctypes unconditionally, it would not be possible. If you look at the attributes I pointed you at above, then you have a way to support DES by simply changing the defaults and restarting FreeIPA. DES is dead anyway and not sufficiently secure for cross-realm keys anymore, even if we do not support it at all I think we are just fine. Ok, attached three patches 0114-0116 is a new revision that implements also fetching encryption types from the Kerberos configuration container. The patches depend on each other in that order. I think you should explictly add cn=REALM.NAME to the filter when seraching the kerberos container in the 3rd patch. But beyond that the patches look sane to me (I haven't tested them though). I'm already searching on cn=REALM.NAME,cn=kerberos,$SUFFIX with a base scope so this is pretty tight, no need to expand the filter. (Simo agreed to this argument on IRC) ACK Pushed to: master: a9843d6918f73c2236d0083b1e8adf54ca34eb0d ipa-3-3: de5ec4fbd916c52e7474f1e4dae3b69c80eb497a -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFE] Support for automember rebuild membership
On 09/19/2013 07:34 PM, JR Aquino wrote: Does the rebuild support the notion of members belonging to multiple groups via automember rules? Yes, all memberships are rebuilt. You cannot hope to secure that which you do not first understand ~ Jr Aquino | Sr. Information Security Specialist GXPN | GIAC Exploit Researcher and Advanced Penetration Tester GCIH | GIAC Certified Incident Handler GWAPT | GIAC WebApp Penetration Tester Citrix Online | 7408 Hollister Avenue | Goleta, CA 93117x-apple-data-detectors://0/0 T: +1 805.690.3478tel:+1%C2%A0805.690.3478 C: +1 805.717.0365tel:+1%20805.717.0365 jr.aqu...@citrix.commailto:jr.aqu...@citrixonline.com http://www.citrixonline.comhttp://www.citrixonline.com/ On Sep 19, 2013, at 6:43 AM, Ana Krivokapic akriv...@redhat.commailto:akriv...@redhat.com wrote: On 09/19/2013 03:26 PM, Jan Cholasta wrote: Hi, On 12.9.2013 19:59, Ana Krivokapic wrote: Hello, The design document for $SUBJECT can be found at: http://www.freeipa.org/page/V3/Automember_rebuild_membership Related tickets: https://fedorahosted.org/freeipa/ticket/3752 https://fedorahosted.org/freeipa/ticket/3928 Thoughts, comments, questions welcome. I don't think naming the commands user-automember-rebuild and host-automember-rebuild commands is correct. The names imply they are methods of user/host, but they don't directly do anything to user/host objects. I would prefer if they were kept in the automember namespace where they logically belong (automember-rebuild-user and automember-rebuild-host perhaps?) Honza That makes sense... I don't have a strong preference one way or other. So if other agree with this suggestion, I will change it. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.commailto:Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. ___ 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 trust -- fetch list of subdomains from AD side and add new ones to IPA ipa trust-domain-find trust-- show all available subdomains ipa trust-domain-del trust domain -- remove subdomain from IPA view about trust ipa trust-domain-mod trust domain -- modify subdomain parameters (work in progress) IPA KDC needs also information for authentication paths to subdomains in case they are not hierarchical under AD forest trust root. This information is managed via capaths section in krb5.conf. SSSD should be able to generate it once ticket https://fedorahosted.org/sssd/ticket/2093 is resolved. part of https://fedorahosted.org/freeipa/ticket/3909 The patch implements some dark magic to get around IPA framework 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=subdomain,cn=trust,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: 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=subdomain,cn=trust,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 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] [RFE] Support for automember rebuild membership
On 09/20/2013 04:25 PM, JR Aquino wrote: Great work on this. I've longed to revisit my code and provide a way to refresh/update. I think it got left off with rich and Nathan as something that should be a 389 plugin mod. Thanks for working on this! You cannot hope to secure that which you do not understand ~ Jr Aquino Sr. Information Security Specialist, Technical Operations Sans: GXPN, GCIH, GWAPT T: +1 805 690 3478 | M: +1 805 717 0365 | F: +1 805 403 9399 jr.aqu...@citrix.com Powering mobile workstyles and cloud services On Sep 20, 2013, at 3:37 AM, Ana Krivokapic akriv...@redhat.com wrote: On 09/19/2013 07:34 PM, JR Aquino wrote: Does the rebuild support the notion of members belonging to multiple groups via automember rules? Yes, all memberships are rebuilt. You cannot hope to secure that which you do not first understand ~ Jr Aquino | Sr. Information Security Specialist GXPN | GIAC Exploit Researcher and Advanced Penetration Tester GCIH | GIAC Certified Incident Handler GWAPT | GIAC WebApp Penetration Tester Citrix Online | 7408 Hollister Avenue | Goleta, CA 93117x-apple-data-detectors://0/0 T: +1 805.690.3478tel:+1%C2%A0805.690.3478 C: +1 805.717.0365tel:+1%20805.717.0365 jr.aqu...@citrix.commailto:jr.aqu...@citrixonline.com http://www.citrixonline.comhttp://www.citrixonline.com/ On Sep 19, 2013, at 6:43 AM, Ana Krivokapic akriv...@redhat.commailto:akriv...@redhat.com wrote: On 09/19/2013 03:26 PM, Jan Cholasta wrote: Hi, On 12.9.2013 19:59, Ana Krivokapic wrote: Hello, The design document for $SUBJECT can be found at: http://www.freeipa.org/page/V3/Automember_rebuild_membership Related tickets: https://fedorahosted.org/freeipa/ticket/3752 https://fedorahosted.org/freeipa/ticket/3928 Thoughts, comments, questions welcome. I don't think naming the commands user-automember-rebuild and host-automember-rebuild commands is correct. The names imply they are methods of user/host, but they don't directly do anything to user/host objects. I would prefer if they were kept in the automember namespace where they logically belong (automember-rebuild-user and automember-rebuild-host perhaps?) Honza That makes sense... I don't have a strong preference one way or other. So if other agree with this suggestion, I will change it. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.commailto:Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. You are welcome, I'm glad you find it useful! :) BTW, patches are already on the list (minus the web UI part - coming soon), you can check them out if you want: https://www.redhat.com/archives/freeipa-devel/2013-September/msg00295.html -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. ___ 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, 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 trust -- fetch list of subdomains from AD side and
add new ones to IPA
ipa trust-domain-find trust-- show all available subdomains
ipa trust-domain-del trust domain -- remove subdomain from IPA
view about trust
ipa trust-domain-mod trust domain -- modify subdomain parameters (work in
progress)
IPA KDC needs also information for authentication paths to subdomains in
case they are not hierarchical under AD forest trust root. This
information is managed via capaths section in krb5.conf. SSSD should be
able to generate it once ticket https://fedorahosted.org/sssd/ticket/2093 is
resolved.
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=subdomain,cn=trust,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 aboko...@redhat.com
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 trust -- fetch list of subdomains from AD side and
add new ones to IPA
ipa trust-domain-find trust-- show all available subdomains
ipa trust-domain-del trust domain -- remove subdomain from IPA view about
trust
ipa trust-domain-mod trust domain -- modify subdomain parameters (work in
progress)
IPA KDC needs also information for authentication paths to subdomains in case
they
are not hierarchical under AD forest trust root. This information is managed
via capaths
section in krb5.conf. SSSD should be able to generate it once
ticket https://fedorahosted.org/sssd/ticket/2093 is resolved.
part of https://fedorahosted.org/freeipa/ticket/3909
---
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', type 'dict', None)
output: Output('summary', (type 'unicode', type 'NoneType'), None)
output: Output('value', type 'unicode', 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', type 'dict', Gettext('A dictionary representing an
LDAP entry', domain='ipa', localedir=None))
+output: Output('summary', (type 'unicode', type 'NoneType'), None)
+output: Output('value', type 'unicode', 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', type 'dict', None)
+output: Output('summary', (type 'unicode', type 'NoneType'), None)
+output: Output('value', type 'unicode', 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,
Re: [Freeipa-devel] [DOC] 0005 Updated chapter 4 - login into web UI
On 09/20/2013 04:06 PM, Martin Basti wrote: Logging into web UI and configuring web browser sections were outdated Thanks for the path. Here are my comments (some for existing issues): 1. There are whitespace warnings when applying this patch. 2. PDF output is bad. Images are too big - right half is not displayed. Several times there is image A with list item for image B below (image B is on the next page with list item for image C). I saw some 'missing image constraints warnings' during build - maybe that's the cause. 3. Section 4.3.5: Don't know why it's called 'Simple authentication'. Usually it's referred to as 'forms based authentication'. 3a. Following sentence is misleading: the error first says to renew the Kerberos credentials or to configure the browser to support Kerberos authentication. IIRC the previous dialog had different wording. The new one gives user two options but it doesn't encourage user to 'renew Kerberos credentials'. Also, you have deleted the first instruction but left a second: Then simply supply the UID and password for a configured FreeIPA user. without any context. IMO it should be reworded. 4. I think the entire section '4.3.6. Using the UI with Proxy Servers' is incorrect. Using Web UI with proxy is not an easy thing to do. http://www.redhat.com/archives/freeipa-users/2013-August/msg00065.html 5. Old unused images should be deleted. 6. Section 4.4.1 (not sure if it's related to this patch) says: randomly selects up to 20 entries that's not true. There is no randomness. It selects: First record: ($PAGE_NUM * 20 +1), up to Last: (($PAGE_NUM + 1) *20). When first index is 1. 6a. LDAP search limit: the option name is --pkey-only not --pkey. -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0016] Add RADIUS proxy support to ipalib CLI
On Thu, 2013-09-12 at 16:48 -0400, Nathaniel McCallum wrote:
On Thu, 2013-09-05 at 00:06 -0400, Nathaniel McCallum wrote:
patch attached
Update for ./makeapi attached.
Version 3. This should fix all the current review issues, including the
use of the referential integrity plugin. I had to make one schema change
in order to make the referential integrity modification work. Note also
that the command name prefix is changed from radius to radiusproxy.
Nathaniel
From ddcdef7f62fe364c1081eecd9f254e8e1c0c6ee6 Mon Sep 17 00:00:00 2001
From: Nathaniel McCallum npmccal...@redhat.com
Date: Wed, 4 Sep 2013 23:45:00 -0400
Subject: [PATCH] Add RADIUS proxy support to ipalib CLI
https://fedorahosted.org/freeipa/ticket/3368
---
API.txt| 95 +++--
install/share/70ipaotp.ldif| 2 +-
install/share/indices.ldif | 10 +++
install/share/referint-conf.ldif | 3 +
install/updates/10-70ipaotp.update | 2 +-
install/updates/20-indices.update | 7 ++
install/updates/25-referint.update | 1 +
install/updates/40-otp.update | 5 ++
ipalib/constants.py| 1 +
ipalib/plugins/config.py | 2 +-
ipalib/plugins/radiusproxy.py | 138 +
ipalib/plugins/user.py | 44 +++-
12 files changed, 297 insertions(+), 13 deletions(-)
create mode 100644 ipalib/plugins/radiusproxy.py
diff --git a/API.txt b/API.txt
index b49493f33af0f7d0192df8318bda12df94c9567b..e662cc53e84cc3cb66e78c444e12e615bf7e3a7f 100644
--- a/API.txt
+++ b/API.txt
@@ -514,7 +514,7 @@ option: Int('ipasearchrecordslimit', attribute=True, autofill=False, cli_name='s
option: Int('ipasearchtimelimit', attribute=True, autofill=False, cli_name='searchtimelimit', minvalue=-1, multivalue=False, required=False)
option: Str('ipaselinuxusermapdefault', attribute=True, autofill=False, cli_name='ipaselinuxusermapdefault', multivalue=False, required=False)
option: Str('ipaselinuxusermaporder', attribute=True, autofill=False, cli_name='ipaselinuxusermaporder', multivalue=False, required=False)
-option: StrEnum('ipauserauthtype', attribute=True, autofill=False, cli_name='user_auth_type', csv=True, multivalue=True, required=False, values=(u'password',))
+option: StrEnum('ipauserauthtype', attribute=True, autofill=False, cli_name='user_auth_type', csv=True, multivalue=True, required=False, values=(u'password', u'radius'))
option: Str('ipauserobjectclasses', attribute=True, autofill=False, cli_name='userobjectclasses', csv=True, multivalue=True, required=False)
option: IA5Str('ipausersearchfields', attribute=True, autofill=False, cli_name='usersearch', multivalue=False, required=False)
option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui')
@@ -2542,6 +2542,81 @@ option: Str('version?', exclude='webui')
output: Entry('result', type 'dict', Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None))
output: Output('summary', (type 'unicode', type 'NoneType'), None)
output: Output('value', type 'unicode', None)
+command: radiusproxy_add
+args: 1,11,3
+arg: Str('cn', attribute=True, cli_name='name', multivalue=False, primary_key=True, required=True)
+option: Str('addattr*', cli_name='addattr', exclude='webui')
+option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui')
+option: Str('description', attribute=True, cli_name='desc', multivalue=False, required=False)
+option: Int('ipatokenradiusretries', attribute=True, cli_name='retries', maxvalue=10, minvalue=0, multivalue=False, required=False)
+option: Password('ipatokenradiussecret', attribute=True, cli_name='secret', confirm=True, multivalue=False, required=True)
+option: Str('ipatokenradiusserver', attribute=True, cli_name='server', multivalue=True, required=True)
+option: Int('ipatokenradiustimeout', attribute=True, cli_name='timeout', minvalue=1, multivalue=False, required=False)
+option: Str('ipatokenusermapattribute', attribute=True, cli_name='userattr', multivalue=False, required=False)
+option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui')
+option: Str('setattr*', cli_name='setattr', exclude='webui')
+option: Str('version?', exclude='webui')
+output: Entry('result', type 'dict', Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None))
+output: Output('summary', (type 'unicode', type 'NoneType'), None)
+output: Output('value', type 'unicode', None)
+command: radiusproxy_del
+args: 1,2,3
+arg: Str('cn', attribute=True, cli_name='name', multivalue=True, primary_key=True, query=True, required=True)
+option: Flag('continue', autofill=True, cli_name='continue', default=False)
+option: Str('version?', exclude='webui')
+output: Output('result', type 'dict', None)
+output: Output('summary', (type 'unicode', type 'NoneType'), None)
+output: Output('value', type 'unicode', None)
+command: radiusproxy_find
+args: 1,13,4
+arg:
