Re: [Freeipa-devel] Testing Migration
Drew Erny wrote: Hi, freeipa-devel, More newbie questions. I have what I believe to be a fix for Ticket #2547 (https://fedorahosted.org/freeipa/ticket/2547) written, but I need to test this fix. I need to migrate an LDAP database that is in the previously expected for (all users and groups under 1 level) and migrate an LDAP database that is in a nested form where there might be many sub-ou's to search for users and groups. I need to make sure the outcome of both migrations is the same. What would be the best way to go about this, more specifically than set up two LDAP server and migrate them. Like, what tools are available to help me get this set up? Also, how can I preserve my work so that next time we have to modify migration code, it can be easily tested? Should I spin up VMs and save the images? Also, I can just send a patch if someone feels so utterly confident in the codebase that they can tell if the thing I've done is right or wrong just by looking at it. I'm pretty sure the 389-ds team has scripts to generate test users and groups in ldif format. I'd ask them for it. I'd use this to seed an openldap server install, then migrate from that. You can learn how to setup openldap at https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/ch-Directory_Servers.html#s1-OpenLDAP I believe migration testing is something that is missing in the in-tree tests (ipatests). Perhaps a test could be made that fires up an openldap server on an unprivileged port and either generates a bunch of users/groups and imports it or uses a pre-canned ldif (one is slow but more random, the other faster but runs the risk of missign things). rob -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Sudorules user validation help
On Thu, 28 May 2015, Martin Kosek wrote: On 05/28/2015 04:27 PM, Drew Erny wrote: In the ticket, however, it's stated that if the user wants to use any combination of weird characters, they should be able to. Would it be better to just define a function like def validate_username(username, ignore_pattern=False): and have it ignore all username validation? Tough question. FreeIPA in general tries to sanitize user input and does not allow everything user wants and try to advise the best practices, as we see it. In your case, if we allow only the 2 mentioned user login formats, it should work for AD use case just fine and add some level of sanity check of the user name. BTW, given we run an LDAP search later on this user name, isn't there a possibility of LDAP injection if we choose to allow all characters, including ( and )? :-) In any case, if we choose to ignore the pattern, we do not need the extra validator function at all. We would just skip validation in the pre callback if a user is being added. I still think we should run the validator exactly for the reasons outlined above. There are few limiting factors for Active Directory and Linux environments -- while user and group objects names are specified in 'cn' attirbute in Active Directory, in POSIX environment we get the real name from sAMAccountName attribute for users: * Certain characters in the Relative Distinguished Names of objects must be escaped using the backslash, \, escape character. The characters that must be escaped are: , \ # + ; = In addition, any leading or trailing spaces in the RDN must be escaped. * The following characters are not allowed in sAMAccountName values: [ ] : ; | = + * ? / \ , * In Windows Server 2003 domains and above, if you do not assign a value for sAMAccountName, the system will create a semi-random value for your. This value will be similar to: $KJK000-H4GJL6AQOV1I * The schema allows 256 characters in sAMAccountName values. However, the system limits sAMAccountName to 20 characters for user and group objects and 16 characters for computer objects. As you can see, group names may have ( and ), also ! and few more characters which you have to escape properly before making them part of the LDAP filter. Additionally, we actually have to allow UTF-8 characters, not just ASCII as syntax for DirectoryString (OID 1.3.6.1.4.1.1466.115.121.1.15) requires that. On 05/28/2015 09:40 AM, Drew Erny wrote: OK, I see now what you mean by that. That is a simpler solution. I'll do it that way. On 05/28/2015 04:44 AM, Martin Kosek wrote: On 05/27/2015 08:41 PM, Drew Erny wrote: Hey, Freeipa-devel, I'm working on ticket #3226 (https://fedorahosted.org/freeipa/ticket/3226) I've identified the problem. The sudorules add user command adds the user validations at the end of it's pre-callback using add_external_pre_callback. However, the user plugin pattern-matches a string for the uid param, because it only allows certain characters. I've been picking through the codebase and I think I have enough understanding to ask this: What if we changed the user uid validation to a standalone rule function (you can do that, right? pass in a function as a validation rule?) that would normally just assert that the pattern matches, but could have that pattern matching validation overridden in some cases. I think that's the easiest, cleanest way to change user so that sudorules and other plugins can ignore this validation if necessary (I'm trying to figure out exactly how to implement this without changing any APIs). Am I understanding the plugin params API correctly, and can I do this? Is this the best way to do this? The only other solution I see is to write sudorules-specific code in some plugin-related (either user.py or baseldap.py module, which would create unwanted coupling. Most specifically, this would be a change to the object instantiated at ipalib/plugins/user.py line 467 Thoughts and suggestions? I think it would make sense to follow the example with validate_hostname and prepare a function validate_username(username, upn=False, netbios_name=False) [1]. where upn would allow using @. on top of current validator (i.e. u...@domain.test) and netbios_name would allow the DOMAIN\user style. I would just suggest making sure the standard user validation error message is still the same to avoid unnecessary QE fail positives. In add_external_pre_callback you could then just simply call validate_username(user, True, True) just like it is already done with hostname. My 2 cents. Martin [1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa380525(v=vs.85).aspx -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-devel mailing list:
Re: [Freeipa-devel] Domain level for topology plugin = 2
On 05/28/2015 05:53 PM, Ludwig Krispenz wrote: On 05/28/2015 05:35 PM, Simo Sorce wrote: On Thu, 2015-05-28 at 17:18 +0200, Ludwig Krispenz wrote: On 05/28/2015 05:03 PM, Martin Kosek wrote: On 05/28/2015 04:59 PM, Ludwig Krispenz wrote: On 05/28/2015 04:46 PM, Simo Sorce wrote: On Thu, 2015-05-28 at 15:54 +0200, Ludwig Krispenz wrote: On 05/28/2015 03:26 PM, Simo Sorce wrote: On Thu, 2015-05-28 at 14:11 +0200, Petr Spacek wrote: On 28.5.2015 10:49, Martin Kosek wrote: On 05/28/2015 09:05 AM, Petr Spacek wrote: On 28.5.2015 08:55, Jan Cholasta wrote: Dne 26.5.2015 v 16:32 Petr Spacek napsal(a): On 26.5.2015 16:16, Martin Kosek wrote: On 05/26/2015 04:13 PM, thierry bordaz wrote: On 05/26/2015 02:12 PM, Petr Spacek wrote: Hello, it came to my mind that domain level for topology plugin should actually be number 2, not 1. We already used number 1 for incompatible changes in DNS tree and I believe that it is not a good idea to have two places which say 'version 1' but and actually mean two different things. (DNS tree version 1 + domain level 1) Patch is attached. Hello, The fix looks good but that seems strange to have to set the initial version of the topology plugin to 2.0. (IIUC That is the version that will be written in dse.ldif) I would rather expects that topology plugin 1.0, would activate itself if the DomainLevel is 2.0 or more. If topology plugin 1.0 sets an internal DomainLevel_trigger=2.0 then activate itself if DomainLevel = DomainLevel_trigger. Let's wait for Ludwig feedback. thanks thierry My personal opinion on this is to start with Domain Level 1 regardless. We already solved the DNS forwarders otherwise, with docs, async updates etc. I do not think we will be returning to implementing proper Domain Level support for that anyway. So I rather think that all the Domain Level starts with 0, 1 is unused, 2 is the top one will cause unforeseen issues I would rather like to avoid. I'm more worried about confusion in future. To to me it simply seems easier to bump one integer now than to document and explain (to users new developers) why we have two ones which mean something else. Code-wise it is just an integer. Also, it can simplify logic in future when we decide to do another incompatible change in DNS tree because we will have only one integer to test (instead of checking two separate version attribute in DNS tree domain level). +1, but I think the minimum supported domain level should be 1, not 0, because 0 means the server uses the old DNS schema, which we do not support anymore, right? Good point! It may be a good point, but it does not make the situation easier. You still have RHEL/CentOS 6.x IPA out there, where some of them already support the new DNS forwarders and some don't - and neither of them support Domain Levels - i.e. have Domain Level 0. As I said, I still see more complications with this proposals than benefits... I would argue that it actually helps. If domain level = 1 then we can be *sure* that all replicas support the new DNS semantics. If domain level = 0 then we know nothing (because of patched RHEL 6) and it is a warning sign for diagnostic tools and also us when it comes to debugging. First of all a domain level is something we change *RARELY*, and it is a whole number and it is an all or nothing thing. I do not understand why plugin versions matter at all, plugin version have nothing to do with domain levels. Each plugin *whatever* the version MUST always support at least 2 levels, because every domain you have will have to go through a domain_level transition when a new domain level comes out. Finally no single developer should be allowed to decide on anew domain level, this must be a well ponder team decision as all plugins that need to change behavior based on domain level will be affected so a thorough review of what changes are needed across all plugins must be done every time someone propose a change that requires a domain level bump. Last but not least we should consider domain levels as something that changes *very* slowly, because otherwise you'll have to support many domain levels within any plugins that have to change behavior according to the domain level. I would say that the domain level should not change more frequently than once a year or so. It would be too much code churn to do otherwise. So for now domain_level should be set to 0. And the topology plugin will be enabled only when we turn it to 1. However we shouldn't turn it to 1 until we have the replica promotion code at least, because only then we can make full use of the topology plugins. The DNS mess is unfixable, unless Petr you volunteer to backport code to change the behavior of the DNS based on the domain level, if that's the case then you can tie old behavior to level 0 and new behavior to level = 1, but I do not think you want to do that given we already have level 0 servers that sport the new code and changed the data in the directory,
[Freeipa-devel] Testing Migration
Hi, freeipa-devel, More newbie questions. I have what I believe to be a fix for Ticket #2547 (https://fedorahosted.org/freeipa/ticket/2547) written, but I need to test this fix. I need to migrate an LDAP database that is in the previously expected for (all users and groups under 1 level) and migrate an LDAP database that is in a nested form where there might be many sub-ou's to search for users and groups. I need to make sure the outcome of both migrations is the same. What would be the best way to go about this, more specifically than set up two LDAP server and migrate them. Like, what tools are available to help me get this set up? Also, how can I preserve my work so that next time we have to modify migration code, it can be easily tested? Should I spin up VMs and save the images? Also, I can just send a patch if someone feels so utterly confident in the codebase that they can tell if the thing I've done is right or wrong just by looking at it. Thanks, Drew Erny de...@redhat.com -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Sudorules user validation help
Ok, so should I write a regex that matches that broader pattern, and only allow sudorules users to be added that follow those broader restrictions? On 05/28/2015 02:09 PM, Alexander Bokovoy wrote: On Thu, 28 May 2015, Martin Kosek wrote: On 05/28/2015 04:27 PM, Drew Erny wrote: In the ticket, however, it's stated that if the user wants to use any combination of weird characters, they should be able to. Would it be better to just define a function like def validate_username(username, ignore_pattern=False): and have it ignore all username validation? Tough question. FreeIPA in general tries to sanitize user input and does not allow everything user wants and try to advise the best practices, as we see it. In your case, if we allow only the 2 mentioned user login formats, it should work for AD use case just fine and add some level of sanity check of the user name. BTW, given we run an LDAP search later on this user name, isn't there a possibility of LDAP injection if we choose to allow all characters, including ( and )? :-) In any case, if we choose to ignore the pattern, we do not need the extra validator function at all. We would just skip validation in the pre callback if a user is being added. I still think we should run the validator exactly for the reasons outlined above. There are few limiting factors for Active Directory and Linux environments -- while user and group objects names are specified in 'cn' attirbute in Active Directory, in POSIX environment we get the real name from sAMAccountName attribute for users: * Certain characters in the Relative Distinguished Names of objects must be escaped using the backslash, \, escape character. The characters that must be escaped are: , \ # + ; = In addition, any leading or trailing spaces in the RDN must be escaped. * The following characters are not allowed in sAMAccountName values: [ ] : ; | = + * ? / \ , * In Windows Server 2003 domains and above, if you do not assign a value for sAMAccountName, the system will create a semi-random value for your. This value will be similar to: $KJK000-H4GJL6AQOV1I * The schema allows 256 characters in sAMAccountName values. However, the system limits sAMAccountName to 20 characters for user and group objects and 16 characters for computer objects. As you can see, group names may have ( and ), also ! and few more characters which you have to escape properly before making them part of the LDAP filter. Additionally, we actually have to allow UTF-8 characters, not just ASCII as syntax for DirectoryString (OID 1.3.6.1.4.1.1466.115.121.1.15) requires that. On 05/28/2015 09:40 AM, Drew Erny wrote: OK, I see now what you mean by that. That is a simpler solution. I'll do it that way. On 05/28/2015 04:44 AM, Martin Kosek wrote: On 05/27/2015 08:41 PM, Drew Erny wrote: Hey, Freeipa-devel, I'm working on ticket #3226 (https://fedorahosted.org/freeipa/ticket/3226) I've identified the problem. The sudorules add user command adds the user validations at the end of it's pre-callback using add_external_pre_callback. However, the user plugin pattern-matches a string for the uid param, because it only allows certain characters. I've been picking through the codebase and I think I have enough understanding to ask this: What if we changed the user uid validation to a standalone rule function (you can do that, right? pass in a function as a validation rule?) that would normally just assert that the pattern matches, but could have that pattern matching validation overridden in some cases. I think that's the easiest, cleanest way to change user so that sudorules and other plugins can ignore this validation if necessary (I'm trying to figure out exactly how to implement this without changing any APIs). Am I understanding the plugin params API correctly, and can I do this? Is this the best way to do this? The only other solution I see is to write sudorules-specific code in some plugin-related (either user.py or baseldap.py module, which would create unwanted coupling. Most specifically, this would be a change to the object instantiated at ipalib/plugins/user.py line 467 Thoughts and suggestions? I think it would make sense to follow the example with validate_hostname and prepare a function validate_username(username, upn=False, netbios_name=False) [1]. where upn would allow using @. on top of current validator (i.e. u...@domain.test) and netbios_name would allow the DOMAIN\user style. I would just suggest making sure the standard user validation error message is still the same to avoid unnecessary QE fail positives. In add_external_pre_callback you could then just simply call validate_username(user, True, True) just like it is already done with hostname. My 2 cents. Martin [1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa380525(v=vs.85).aspx -- Manage your subscription for the Freeipa-devel mailing list:
Re: [Freeipa-devel] [PATCHES 0001-0013 v5] Profiles and CA ACLs
On Thu, May 28, 2015 at 02:42:53PM +0200, Martin Basti wrote: On 28/05/15 11:48, Martin Basti wrote: On 27/05/15 16:04, Fraser Tweedale wrote: Hello all, Fresh certificate management patchset; Changelog: - Now depends on patch freeipa-ftweedal-0014 for correct cert-request behaviour with host and service principals. - Updated Dogtag dependency to 10.2.4-1. Should should be in f22 soon, but for f22 right now or for f21, please grab from my copr: https://copr.fedoraproject.org/coprs/ftweedal/freeipa/ Martin^1 could you please add to the quasi-official freeipa copr? SRPM lives at https://frase.id.au/pki-core-10.2.4-1.fc21.src.rpm. - cert-request now verifies that for user principals, CSR CN matches uid and, DN emailAddress and SAN rfc822Name match user's email address, if either of those is present. - Fixed one or two other sneaky little bugs. On Wed, May 27, 2015 at 01:59:30AM +1000, Fraser Tweedale wrote: Hi all, Please find attached the latest certificate management patchset, which introduces the `caacl' plugin and various fixes and improvement to earlier patches. One important change to earlier patches is reverting the name of the default profile to 'caIPAserviceCert' and using the existing instance of this profile on upgrade (but not install) in case it has been modified. Other notes: - Still have changes in ipa-server-install (fewer lines now, though) - Still have the ugly import hack. It is not a high priority for me, i.e. I think it should wait until after alpha - Still need to update 'service' and 'host' plugins to support multiple certificates. (The userCertificate attribute schema itself is multi-valued, so there are no schema issues here) - The TODOs in [1]; mostly certprofile CLI conveniences and supporting multiple profiles for hosts and services (which requires changes to framework only, not schema). [1]: http://idm.etherpad.corp.redhat.com/rhel72-cert-mgmt-progress Happy reviewing! I am pleased with the initial cut of the caacl plugin but I'm sure you will find some things to be fixed :) Cheers, Fraser [root@vm-093 ~]# ipa-replica-prepare vm-094.example.com --ip-address 10.34.78.94 Directory Manager (existing master) password: Preparing replica for vm-094.example.com from vm-093.example.com Creating SSL certificate for the Directory Server not well-formed (invalid token): line 2, column 14 I cannot create replica file. It work on the upgraded server, but it doesn't work on the newly installed server. I'm not sure if this causes your patches which modifies the ca-installer, or the newer version of dogtag. Or if there was any other changes in master, I will continue to investigate with new RPM from master branch. Martin^2 ipa-replica-prepare works for: * master branch * master branch + pki-ca 10.2.4-1 So something in your patches is breaking it Martin^2 Martin, master + my patches with pki 10.2.4-1 is working for me on f21 and f22. Can you provide ipa-replica-prepare --debug output and Dogtag debug log? ( /var/log/pki/pki-tomcat/ca/debug ) Thanks, Fraser -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0014] Support multiple user and host certificates
On Wed, May 27, 2015 at 06:12:50PM +0200, Martin Basti wrote:
On 27/05/15 15:53, Fraser Tweedale wrote:
This patch adds supports for multiple user / host certificates. No
schema change is needed ('usercertificate' attribute is already
multi-value). The revoke-previous-cert behaviour of host-mod and
user-mod has been removed but revocation behaviour of -del and
-disable is preserved.
The latest profiles/caacl patchset (0001..0013 v5) depends on this
patch for correct cert-request behaviour.
There is one design question (or maybe more, let me know): the
`--out=FILENAME' option to {host,service} show saves ONE certificate
to the named file. I propose to either:
a) write all certs, suffixing suggested filename with either a
sequential numerical index, e.g. cert.pem becomes
cert.pem.1, cert.pem.2, and so on; or
b) as above, but suffix with serial number and, if there are
different issues, some issuer-identifying information.
Let me know your thoughts.
Thanks,
Fraser
Is there a possible way how to store certificates into one file?
I read about possibilities to have multiple certs in one .pem file, but I'm
not cert guru :)
I personally vote for serial number in case there are multiple certificates,
if ^ is no possible.
Actually, yeah, we can just write the PEMs to a single file,
sequentially. I don't know why I didn't think of that... ¯\_(ツ)_/¯
1)
+if len(certs) 0:
please use only,
if certs:
I have strong feels about this. ``if len(certs) 0:`` admits fewer
bugs than ``if certs:`` , e.g. if 'certs' were bound to a
non-length-able object by mistake. Even though we have already
iterated ``certs`` at this point in the function, this failure mode
is still possible, e.g. if ``certs`` is a generator. Using ``if
certs:`` will not fail for a generator, but it will be a silent bug!
PEP-8 is wrong on this one. It is better to use the construction
that admits fewer errors. Unless it causes lint failure (on f21 it
does not) I prefer not to change it.
2)
You need to re-generate API/ACI.txt in this patch
Good pickup, thanks.
3)
syntax error:
+for dercert in certs_der
Geez... dunno how I let that one past -_- My bad.
4)
command
ipa user-mod ca_user --certificate=ceritifcate
removes the current certificate from the LDAP, by design.
Should be the old certificate(s) revoked? You removed that part in the code.
only the --addattr='usercertificate=cert' appends new value there
Yeah... I was a bit confused about how --addattr=... interacts with
options. I understand it now, and yes I think we should revoke
certificates that get removed this way.
cert-request will use addattr= so no existing certificates will get
removed (or revoked). New patch addressing this and other points
will arrive on list today.
Thanks for reviewing!
Fraser
--
Martin Basti
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Kerberos over HTTPS (KDC proxy)
On 2015-05-28 10:02, Jan Cholasta wrote: The python-kdcproxy package is a new dependency for the freeipa-server package. It will always get installed with the server. Why? None of the IPA core functionality depends on it, so it should be optional. Also the overall trend in IPA is to have everything in subpackages. We discussed the idea on the internal IPA and Samba team list (KDC proxy for FreeIPA 4.2 on 2015-05-15). My initial design suggested a separate freeipa-server-kdcproxy package. Nathaniel, Nathan and Dmitri were in favor of a new dependency instead of a new subpackage. Christian signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Domain level for topology plugin = 2
On 05/27/2015 01:04 PM, Martin Kosek wrote: On 05/26/2015 04:32 PM, Petr Spacek wrote: On 26.5.2015 16:16, Martin Kosek wrote: ... If you really want to avoid unforeseen issues rather go and get rid of major.minor logic we have in the topology plugin right now :-) Ludwig, I thought we agreed to avoid using major.minor format in the topology plugin Domain Level implementation, to both avoid confusion of users and to not ship unused code - right? The user does not see major/minor, so no confusion. All the plugin versions have the format 1.0 or alike and I converted the single integer domain level internally to compare to the plugin version Thanks, Martin -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Kerberos over HTTPS (KDC proxy)
On 28.5.2015 07:42, Jan Cholasta wrote: Dne 27.5.2015 v 15:54 Simo Sorce napsal(a): On Wed, 2015-05-27 at 15:47 +0200, Jan Cholasta wrote: Dne 27.5.2015 v 15:43 Simo Sorce napsal(a): On Wed, 2015-05-27 at 13:57 +0200, Jan Cholasta wrote: ipa config-mod --enable-kdcproxy=TRUE ipa config-mod --enable-kdcproxy=FALSE I don't like this approach, as it is completely inconsistent with every other optional component. There should be *one* way to handle them and there already is one, no need to reinvent the wheel. Sorry Jan, but this is really the correct approach. I don't think so. We want a boolean in LDAP to control whether the IPA Domain allows proxying or not, the code is embedded in the overall framework and has no need for explicit install/uninstall unlike the CA or DNS components. There is a boolean for every other component/service as well. If you want to add new API to manipulate the boolean, fine, but it should be done in a generic way that works for other components as well. This is the same as: ipa config-mod --enable-migration=TRUE Why is it a problem ? This is a switch to enable the migrate-ds plugin. I think it's hardly fair to compare it to a whole new component which provides a new service to the outside world. This is not a separate service. How is it not a separate service? If it's installed, MS-KKDCP is provided to the outside world, and if it's not installed MS-KKDCP is not provided to the outside world. How is this different from, say, DNS? (Besides implementation details, such as what protocols or how many daemons it uses - think about IPA as a black box for a moment.) I very much agree with Honza - we have per-replica boolean for every service so there is no reason not to have one for kdc proxy, especially when we consider future containerization of services. -- Petr^2 Spacek -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] 1112 Add service constraint delegation plugin
On 05/27/2015 08:17 PM, Martin Basti wrote:
On 27/05/15 19:27, Rob Crittenden wrote:
Martin Basti wrote:
Thank you.
I haven't finished review yet, but I have few notes in case you will
modify the patch.
Please fix following issues:
3)
There are many PEP8 errors, can you fix some of them,?
Is PEP8 a concern? What kinds of errors do we fix? For example, the
current model for defining options generates a slew of indention errors.
In old modules it's preferred to keep the old indentation style for
options(not to mix 2 styles). New modules should use following pep8
compliant style:
Str(
'cn',
cli_name='name',
primary_key=True,
label=_('Server name'),
doc=_('IPA server hostname'),
),
We try to keep PEP8 in new code, mainly indentation, blank lines, too
long lines.
Yes in test definitions and option definitions, is better to keep the
same style, but other parts of code should be PEP8.
For example these should be fixed
./ipatests/test_xmlrpc/test_serviceconstraint_plugin.py:37:13: E225
missing whitespace around operator
./ipatests/test_xmlrpc/test_serviceconstraint_plugin.py:39:1: E302
expected 2 blank lines, found 1
./ipatests/test_xmlrpc/test_serviceconstraint_plugin.py:42:1: E302
expected 2 blank lines, found 1
I'll wait and see what falls out of the API review before making any
real changes.
rob
Martin^2
--
Petr Vobornik
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Domain level for topology plugin = 2
Dne 26.5.2015 v 16:32 Petr Spacek napsal(a): On 26.5.2015 16:16, Martin Kosek wrote: On 05/26/2015 04:13 PM, thierry bordaz wrote: On 05/26/2015 02:12 PM, Petr Spacek wrote: Hello, it came to my mind that domain level for topology plugin should actually be number 2, not 1. We already used number 1 for incompatible changes in DNS tree and I believe that it is not a good idea to have two places which say 'version 1' but and actually mean two different things. (DNS tree version 1 + domain level 1) Patch is attached. Hello, The fix looks good but that seems strange to have to set the initial version of the topology plugin to 2.0. (IIUC That is the version that will be written in dse.ldif) I would rather expects that topology plugin 1.0, would activate itself if the DomainLevel is 2.0 or more. If topology plugin 1.0 sets an internal DomainLevel_trigger=2.0 then activate itself if DomainLevel = DomainLevel_trigger. Let's wait for Ludwig feedback. thanks thierry My personal opinion on this is to start with Domain Level 1 regardless. We already solved the DNS forwarders otherwise, with docs, async updates etc. I do not think we will be returning to implementing proper Domain Level support for that anyway. So I rather think that all the Domain Level starts with 0, 1 is unused, 2 is the top one will cause unforeseen issues I would rather like to avoid. I'm more worried about confusion in future. To to me it simply seems easier to bump one integer now than to document and explain (to users new developers) why we have two ones which mean something else. Code-wise it is just an integer. Also, it can simplify logic in future when we decide to do another incompatible change in DNS tree because we will have only one integer to test (instead of checking two separate version attribute in DNS tree domain level). +1, but I think the minimum supported domain level should be 1, not 0, because 0 means the server uses the old DNS schema, which we do not support anymore, right? If you really want to avoid unforeseen issues rather go and get rid of major.minor logic we have in the topology plugin right now :-) -- Jan Cholasta -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Domain level for topology plugin = 2
On 28.5.2015 08:55, Jan Cholasta wrote: Dne 26.5.2015 v 16:32 Petr Spacek napsal(a): On 26.5.2015 16:16, Martin Kosek wrote: On 05/26/2015 04:13 PM, thierry bordaz wrote: On 05/26/2015 02:12 PM, Petr Spacek wrote: Hello, it came to my mind that domain level for topology plugin should actually be number 2, not 1. We already used number 1 for incompatible changes in DNS tree and I believe that it is not a good idea to have two places which say 'version 1' but and actually mean two different things. (DNS tree version 1 + domain level 1) Patch is attached. Hello, The fix looks good but that seems strange to have to set the initial version of the topology plugin to 2.0. (IIUC That is the version that will be written in dse.ldif) I would rather expects that topology plugin 1.0, would activate itself if the DomainLevel is 2.0 or more. If topology plugin 1.0 sets an internal DomainLevel_trigger=2.0 then activate itself if DomainLevel = DomainLevel_trigger. Let's wait for Ludwig feedback. thanks thierry My personal opinion on this is to start with Domain Level 1 regardless. We already solved the DNS forwarders otherwise, with docs, async updates etc. I do not think we will be returning to implementing proper Domain Level support for that anyway. So I rather think that all the Domain Level starts with 0, 1 is unused, 2 is the top one will cause unforeseen issues I would rather like to avoid. I'm more worried about confusion in future. To to me it simply seems easier to bump one integer now than to document and explain (to users new developers) why we have two ones which mean something else. Code-wise it is just an integer. Also, it can simplify logic in future when we decide to do another incompatible change in DNS tree because we will have only one integer to test (instead of checking two separate version attribute in DNS tree domain level). +1, but I think the minimum supported domain level should be 1, not 0, because 0 means the server uses the old DNS schema, which we do not support anymore, right? Good point! -- Petr^2 Spacek -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Kerberos over HTTPS (KDC proxy)
On 2015-05-28 07:32, Jan Cholasta wrote: Dne 27.5.2015 v 16:01 Christian Heimes napsal(a): On 2015-05-27 15:51, Nathaniel McCallum wrote: As I understand the problem, there is an assumption that an optional component has a distinct service to start and stop. That is not the case here. This is just new config for apache. More details: The KDC Proxy uses the same Apache instance as FreeIPAs Web GUI and Tomcat. There is no extra service involved. The switch just decides if https://ipa.example.org/KdcProxy acts as a MS-KKDCP end point or returns a 404 error. FYI Tomcat does not use the same Apache instance, the Apache instance is configured to proxy requests to Tomcat. If the IPA KDC proxy package is not installed on a replica, then going to /KdcProxy will return 404, right? Why is an additional switch necessary then? The python-kdcproxy package is a new dependency for the freeipa-server package. It will always get installed with the server. signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0014] Support multiple user and host certificates
On 05/27/2015 06:12 PM, Martin Basti wrote:
On 27/05/15 15:53, Fraser Tweedale wrote:
This patch adds supports for multiple user / host certificates. No
schema change is needed ('usercertificate' attribute is already
multi-value). The revoke-previous-cert behaviour of host-mod and
user-mod has been removed but revocation behaviour of -del and
-disable is preserved.
The latest profiles/caacl patchset (0001..0013 v5) depends on this
patch for correct cert-request behaviour.
There is one design question (or maybe more, let me know): the
`--out=FILENAME' option to {host,service} show saves ONE certificate
to the named file. I propose to either:
a) write all certs, suffixing suggested filename with either a
sequential numerical index, e.g. cert.pem becomes
cert.pem.1, cert.pem.2, and so on; or
b) as above, but suffix with serial number and, if there are
different issues, some issuer-identifying information.
Let me know your thoughts.
Thanks,
Fraser
Is there a possible way how to store certificates into one file?
I read about possibilities to have multiple certs in one .pem file, but I'm
not
cert guru :)
I personally vote for serial number in case there are multiple certificates,
if
^ is no possible.
1)
+if len(certs) 0:
please use only,
if certs:
2)
You need to re-generate API/ACI.txt in this patch
3)
syntax error:
+for dercert in certs_der
4)
command
ipa user-mod ca_user --certificate=ceritifcate
removes the current certificate from the LDAP, by design.
Should be the old certificate(s) revoked? You removed that part in the code.
Good question. I think the suggestion was to have a global switch in IPA global
config that would configure the policy - whether the certificates removed by
this command or by host-del or host-disable are revoked or if they are just
removed (my motivation is to avoid behavior regression in case somebody
depended on this behavior).
only the --addattr='usercertificate=cert' appends new value there
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Kerberos over HTTPS (KDC proxy)
Dne 28.5.2015 v 09:45 Christian Heimes napsal(a): On 2015-05-28 07:32, Jan Cholasta wrote: Dne 27.5.2015 v 16:01 Christian Heimes napsal(a): On 2015-05-27 15:51, Nathaniel McCallum wrote: As I understand the problem, there is an assumption that an optional component has a distinct service to start and stop. That is not the case here. This is just new config for apache. More details: The KDC Proxy uses the same Apache instance as FreeIPAs Web GUI and Tomcat. There is no extra service involved. The switch just decides if https://ipa.example.org/KdcProxy acts as a MS-KKDCP end point or returns a 404 error. FYI Tomcat does not use the same Apache instance, the Apache instance is configured to proxy requests to Tomcat. If the IPA KDC proxy package is not installed on a replica, then going to /KdcProxy will return 404, right? Why is an additional switch necessary then? The python-kdcproxy package is a new dependency for the freeipa-server package. It will always get installed with the server. Why? None of the IPA core functionality depends on it, so it should be optional. Also the overall trend in IPA is to have everything in subpackages. -- Jan Cholasta -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Kerberos over HTTPS (KDC proxy)
On 05/28/2015 07:29 AM, Jan Cholasta wrote: Dne 27.5.2015 v 15:51 Nathaniel McCallum napsal(a): On Wed, 2015-05-27 at 15:47 +0200, Jan Cholasta wrote: Dne 27.5.2015 v 15:43 Simo Sorce napsal(a): On Wed, 2015-05-27 at 13:57 +0200, Jan Cholasta wrote: ipa config-mod --enable-kdcproxy=TRUE ipa config-mod --enable-kdcproxy=FALSE I don't like this approach, as it is completely inconsistent with every other optional component. There should be *one* way to handle them and there already is one, no need to reinvent the wheel. Sorry Jan, but this is really the correct approach. I don't think so. We want a boolean in LDAP to control whether the IPA Domain allows proxying or not, the code is embedded in the overall framework and has no need for explicit install/uninstall unlike the CA or DNS components. There is a boolean for every other component/service as well. If you want to add new API to manipulate the boolean, fine, but it should be done in a generic way that works for other components as well. As I understand the problem, there is an assumption that an optional component has a distinct service to start and stop. That is not the case here. This is just new config for apache. Nathaniel I say that's a wrong assumption. It should not matter whether the service is provided by an actual daemon, or a set of daemons or no daemon, as that is an implementation detail. By installing KDC proxy on IPA server an actual new service is provided to the outside world, which is conceptually the same as adding DNS or CA, so I don't see why it should be handled differently. It is not another new service, like DNS or CA. It is another transport for Kerberos, on top of TCP/UDP. Can we please stop bikeshedding here? -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Kerberos over HTTPS (KDC proxy)
On 05/28/2015 10:02 AM, Jan Cholasta wrote: Dne 28.5.2015 v 09:45 Christian Heimes napsal(a): On 2015-05-28 07:32, Jan Cholasta wrote: Dne 27.5.2015 v 16:01 Christian Heimes napsal(a): On 2015-05-27 15:51, Nathaniel McCallum wrote: As I understand the problem, there is an assumption that an optional component has a distinct service to start and stop. That is not the case here. This is just new config for apache. More details: The KDC Proxy uses the same Apache instance as FreeIPAs Web GUI and Tomcat. There is no extra service involved. The switch just decides if https://ipa.example.org/KdcProxy acts as a MS-KKDCP end point or returns a 404 error. FYI Tomcat does not use the same Apache instance, the Apache instance is configured to proxy requests to Tomcat. If the IPA KDC proxy package is not installed on a replica, then going to /KdcProxy will return 404, right? Why is an additional switch necessary then? The python-kdcproxy package is a new dependency for the freeipa-server package. It will always get installed with the server. Why? None of the IPA core functionality depends on it, so it should be optional. Also the overall trend in IPA is to have everything in subpackages. Do not look at it as a separate component. It is mostly just a new transport for Kerberos. FreeIPA already provides Kerberos via TCP and UDP. This is a third transport - HTTP. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] New replica installation and topology - we need stable base
On 05/27/2015 05:05 PM, Oleg Fayans wrote: On 05/27/2015 04:59 PM, Martin Kosek wrote: Hello all, As FreeIPA 4.2 deadlines are approaching us slowly, there is a concern that not all of the new replica install way (replication-package-less) based on Custodia would be done and finished in time. There will be certainly a lot of integration hurdles, in making sure that the installed replica can ask for all needed secrets and that the server can provide them and ensure proper encryption. My question is - if we postpone new replica promotion wayCustodia, what is needed to make FreeIPA 4.2 replica installation and topology management GA-ready and finished? This is the status of related functions, as I see it: Domain Levels - Done, committed - Defaults to Level 1, i.e. Topology plugin powered infra enabled Topology plugin - We have the base plugin and it's installation pushed - There is a critical bug that needs to be solved - #5035 Which actually blocks the testing of the feature. Once it is resolved, we need several days to properly test the plugin. I anticipate at least a week, if there will be no other blockers. This does not include WebUI part of the plugin. Right. I would suggest this bug to be now the top priority for Ludwig. - APIUI is in works (Petr Vobornik). We already committed the new server-* commands used there. Overall, AFAIU the API should be mostly functionally complete - Plugin is enabled during installation, but we still use the simple auth with DM password during replica creation process. I think we planned to use GSSAPI, no? Is anything else needed in the replica creation process, except fixing #5035? Given this summary, if we forget about the Custodia parts for a moment, it seems to me that the new Topology is almost functionally complete and we only miss the management API. Is that correct or we miss some bigger piece? I am for example not sure if the IPA masters hostgroup is needed for Topology work without Custodia, I think Ludwig used some other group for authorization purposes in Topology. Thanks. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] 1112 Add service constraint delegation plugin
Dne 27.5.2015 v 19:38 Rob Crittenden napsal(a):
Petr Vobornik wrote:
On 05/27/2015 05:46 PM, Alexander Bokovoy wrote:
On Wed, 27 May 2015, Rob Crittenden wrote:
Petr Vobornik wrote:
On 05/20/2015 06:02 PM, Rob Crittenden wrote:
Rob Crittenden wrote:
Rob Crittenden wrote:
Add a plugin to manage service delegations, like the one allowing
the
HTTP service to obtain an ldap service ticket on behalf of the
user.
This does not include impersonation targets, so one cannot yet
limit by
user what tickets can be obtained.
There is also no referential integrity for the memberPrincipal
attribute
since it is a string and not a DN. I don't see a way around this
that
isn't either clunky or requires a 389-ds plugin, both of which are
overkill in this case IMHO.
If you wonder why all the overrides it's because all of this is
stored
in the same container, and membership-like functions are used for a
non-DN attribute (memberPrincipal).
I used Alexander's patch in the ticket as a jumping off point.
Removed a couple of hardcoded domain/realm elements in the tests.
I must be getting rustly. Forgot to include ACIs. Added now.
rob
Thanks for the design[1] and patches.
First some high level questions before any unnecessary changes are
made.
From API point of view wouldn't it be better to distinguish rules and
targets by object name so we could avoid usage of the --type option.
I.e., why expose internal schema limitations in the API?
Type could be implied by the object name and commands can do what they
do now. They could even have a common base class if needed.
E.g.:
servicedelegationrule-add MYRULE
servicedelegationrule-find
servicedelegationrule-del MYRULE
servicedelegationrule-add_member MYRULE --targets={MYTARGET,MYTARGET2}
--principals={..,..}
servicedelegationrule-remove_member MYRULE
--targets={MYTARGET,MYTARGET2} --principals={..,..}
servicedelegationtarget-add MYTARGET
servicedelegationtarget-find
servicedelegationtarget-del MYTARGET
servicedelegationtarget-add_member MYTARGET --principals={..,..}
servicedelegationtarget-remove_member MYTARGET --principals={..,..}
+1, but I would split servicedelegationrule-{add,remove}-member into
separate commands:
servicedelegationrule-add-member --principals=
servicedelegationrule-remove-member --principals=
servicedelegationrule-add-target --targets=
servicedelegationrule-remove-target --targets=
because one means services which can delegate and the other services
to which can be delegated.
Yes, I used delegation instead of constraint. What is the rationale
behind 'constraint'? To me 'constraint' specifies what kind of
delegation we want to set but a goal of S4U2 proxy is to allow
something
which is not allowed by default not to create a new constraint.
[1] http://www.freeipa.org/page/V4/Service_Constraint_Delegation
I considered that but we already have this precedent in automember so
I went with it. This is complex enough with the fake memberPrincipal
stuff, I don't want to explode it with a baseclass and two subclasses
as well, plus doubling the number of new API commands.
It could tolerated in automember given that hostgroup and group rules
have exactly the same schema and purpose. The only difference is a
different target.
On the other hand, here, the purpose of both types is different. One is
a rule, second a target. Separation of the names would tell it to the
users.
+1
Number of API commands is a topic for different discussion. In short, it
could be handled better in CLI and future doc.
I don't want to discuss implementation details(complexity) yet. Issue
with API is that we are stuck with it and can't change it(much).
I very much agree.
Technically this is called constrained delegation. I was trying to
keep the name short and still descriptive. There is already aci
delegation which is a completely separate thing.
I understand that. The existing delegation might be misleading and
should be distinguished from s4u2. But imagine that somebody told you
that he created a new service constraint rule of service A to service
B. Since there is no mention of word delegation nor S4U I wouldn't know
that it's related to ticket delegation. I would think the *opposite*.
That he constrained service A to do something with service B. But a
service delegation rule, constrained delegation rule or ticket
delegation rule says what it is actually about.
Rather than avoiding descriptive commands we should improve a speed bash
completion.
Perhaps, but it still possible to be excessive.
A feeble attempt to remove service from the object name:
A question: Even thought the kerberos feature is called S4U (service for
user), is it limited to service principals? Services are of course the
primary target but in theory they don't have to be, right?
What is the user case for non-services? Sure, you could probably use
this to allow paul to get an ldap ticket for dave, but why would you? It
would be nice for delegating calendar entries for a
Re: [Freeipa-devel] [PATCH 0014] Support multiple user and host certificates
On Thu, May 28, 2015 at 10:40:22AM +0200, Martin Basti wrote:
On 28/05/15 10:13, Fraser Tweedale wrote:
On Wed, May 27, 2015 at 06:12:50PM +0200, Martin Basti wrote:
On 27/05/15 15:53, Fraser Tweedale wrote:
This patch adds supports for multiple user / host certificates. No
schema change is needed ('usercertificate' attribute is already
multi-value). The revoke-previous-cert behaviour of host-mod and
user-mod has been removed but revocation behaviour of -del and
-disable is preserved.
The latest profiles/caacl patchset (0001..0013 v5) depends on this
patch for correct cert-request behaviour.
There is one design question (or maybe more, let me know): the
`--out=FILENAME' option to {host,service} show saves ONE certificate
to the named file. I propose to either:
a) write all certs, suffixing suggested filename with either a
sequential numerical index, e.g. cert.pem becomes
cert.pem.1, cert.pem.2, and so on; or
b) as above, but suffix with serial number and, if there are
different issues, some issuer-identifying information.
Let me know your thoughts.
Thanks,
Fraser
Is there a possible way how to store certificates into one file?
I read about possibilities to have multiple certs in one .pem file, but I'm
not cert guru :)
I personally vote for serial number in case there are multiple certificates,
if ^ is no possible.
Actually, yeah, we can just write the PEMs to a single file,
sequentially. I don't know why I didn't think of that... ¯\_(ツ)_/¯
1)
+if len(certs) 0:
please use only,
if certs:
I have strong feels about this. ``if len(certs) 0:`` admits fewer
bugs than ``if certs:`` , e.g. if 'certs' were bound to a
non-length-able object by mistake. Even though we have already
iterated ``certs`` at this point in the function, this failure mode
is still possible, e.g. if ``certs`` is a generator. Using ``if
certs:`` will not fail for a generator, but it will be a silent bug!
PEP-8 is wrong on this one. It is better to use the construction
that admits fewer errors. Unless it causes lint failure (on f21 it
does not) I prefer not to change it.
I still think it should be in PEP8 style.
We should avoid these mistakes, not create the code which will detect it.
How do you know if you made a mistake? This is not just about me
making this change now. If someone in the future comes along and
for whatever reasons changes the list to a generator, the diff in
isolation may look like a good change, and the reviewer might not
notice that the change leads to undesired behaviour elsewhere
(outside the diff context).
If you have good test coverage, tests might catch the bug. If not,
hopefully QE notices the incorrect behaviour before a customer does.
The best tool is a type system so you don't get a program if you
make a mistake like this. Well, Python doesn't give us that tool
but let us not ignore what it *can* do to help us for the sake of
adhereing to PEP-8 or saving a few characters.
And, I forgot to write, please use
except Exception as e: instead except Exception, e
to be compatible with python3
Sure, no problem.
2)
You need to re-generate API/ACI.txt in this patch
Good pickup, thanks.
3)
syntax error:
+for dercert in certs_der
Geez... dunno how I let that one past -_- My bad.
4)
command
ipa user-mod ca_user --certificate=ceritifcate
removes the current certificate from the LDAP, by design.
Should be the old certificate(s) revoked? You removed that part in the code.
only the --addattr='usercertificate=cert' appends new value there
Yeah... I was a bit confused about how --addattr=... interacts with
options. I understand it now, and yes I think we should revoke
certificates that get removed this way.
cert-request will use addattr= so no existing certificates will get
removed (or revoked). New patch addressing this and other points
will arrive on list today.
Thanks for reviewing!
Fraser
--
Martin Basti
--
Martin Basti
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0014] Support multiple user and host certificates
On 28/05/15 10:46, Martin Kosek wrote:
On 05/27/2015 06:12 PM, Martin Basti wrote:
On 27/05/15 15:53, Fraser Tweedale wrote:
This patch adds supports for multiple user / host certificates. No
schema change is needed ('usercertificate' attribute is already
multi-value). The revoke-previous-cert behaviour of host-mod and
user-mod has been removed but revocation behaviour of -del and
-disable is preserved.
The latest profiles/caacl patchset (0001..0013 v5) depends on this
patch for correct cert-request behaviour.
There is one design question (or maybe more, let me know): the
`--out=FILENAME' option to {host,service} show saves ONE certificate
to the named file. I propose to either:
a) write all certs, suffixing suggested filename with either a
sequential numerical index, e.g. cert.pem becomes
cert.pem.1, cert.pem.2, and so on; or
b) as above, but suffix with serial number and, if there are
different issues, some issuer-identifying information.
Let me know your thoughts.
Thanks,
Fraser
Is there a possible way how to store certificates into one file?
I read about possibilities to have multiple certs in one .pem file, but I'm not
cert guru :)
I personally vote for serial number in case there are multiple certificates, if
^ is no possible.
1)
+if len(certs) 0:
please use only,
if certs:
2)
You need to re-generate API/ACI.txt in this patch
3)
syntax error:
+for dercert in certs_der
4)
command
ipa user-mod ca_user --certificate=ceritifcate
removes the current certificate from the LDAP, by design.
Should be the old certificate(s) revoked? You removed that part in the code.
Good question. I think the suggestion was to have a global switch in IPA global
config that would configure the policy - whether the certificates removed by
this command or by host-del or host-disable are revoked or if they are just
removed (my motivation is to avoid behavior regression in case somebody
depended on this behavior).
I would prefer to keep the current behavior: revoke the certificate if
it was replaced or removed, instead of adding an extra configuration option.
This behavior is not regression.
only the --addattr='usercertificate=cert' appends new value there
--
Martin Basti
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0014] Support multiple user and host certificates
On 28/05/15 11:17, Fraser Tweedale wrote:
On Thu, May 28, 2015 at 10:40:22AM +0200, Martin Basti wrote:
On 28/05/15 10:13, Fraser Tweedale wrote:
On Wed, May 27, 2015 at 06:12:50PM +0200, Martin Basti wrote:
On 27/05/15 15:53, Fraser Tweedale wrote:
This patch adds supports for multiple user / host certificates. No
schema change is needed ('usercertificate' attribute is already
multi-value). The revoke-previous-cert behaviour of host-mod and
user-mod has been removed but revocation behaviour of -del and
-disable is preserved.
The latest profiles/caacl patchset (0001..0013 v5) depends on this
patch for correct cert-request behaviour.
There is one design question (or maybe more, let me know): the
`--out=FILENAME' option to {host,service} show saves ONE certificate
to the named file. I propose to either:
a) write all certs, suffixing suggested filename with either a
sequential numerical index, e.g. cert.pem becomes
cert.pem.1, cert.pem.2, and so on; or
b) as above, but suffix with serial number and, if there are
different issues, some issuer-identifying information.
Let me know your thoughts.
Thanks,
Fraser
Is there a possible way how to store certificates into one file?
I read about possibilities to have multiple certs in one .pem file, but I'm
not cert guru :)
I personally vote for serial number in case there are multiple certificates,
if ^ is no possible.
Actually, yeah, we can just write the PEMs to a single file,
sequentially. I don't know why I didn't think of that... ¯\_(ツ)_/¯
1)
+if len(certs) 0:
please use only,
if certs:
I have strong feels about this. ``if len(certs) 0:`` admits fewer
bugs than ``if certs:`` , e.g. if 'certs' were bound to a
non-length-able object by mistake. Even though we have already
iterated ``certs`` at this point in the function, this failure mode
is still possible, e.g. if ``certs`` is a generator. Using ``if
certs:`` will not fail for a generator, but it will be a silent bug!
PEP-8 is wrong on this one. It is better to use the construction
that admits fewer errors. Unless it causes lint failure (on f21 it
does not) I prefer not to change it.
I still think it should be in PEP8 style.
We should avoid these mistakes, not create the code which will detect it.
How do you know if you made a mistake? This is not just about me
making this change now. If someone in the future comes along and
for whatever reasons changes the list to a generator, the diff in
isolation may look like a good change, and the reviewer might not
notice that the change leads to undesired behaviour elsewhere
(outside the diff context).
If you have good test coverage, tests might catch the bug. If not,
hopefully QE notices the incorrect behaviour before a customer does.
The best tool is a type system so you don't get a program if you
make a mistake like this. Well, Python doesn't give us that tool
but let us not ignore what it *can* do to help us for the sake of
adhereing to PEP-8 or saving a few characters.
Ok then, leave there len() 0
but to catch these kind of mistakes, we should have asserts everywhere
to verify type.
And, I forgot to write, please use
except Exception as e: instead except Exception, e
to be compatible with python3
Sure, no problem.
2)
You need to re-generate API/ACI.txt in this patch
Good pickup, thanks.
3)
syntax error:
+for dercert in certs_der
Geez... dunno how I let that one past -_- My bad.
4)
command
ipa user-mod ca_user --certificate=ceritifcate
removes the current certificate from the LDAP, by design.
Should be the old certificate(s) revoked? You removed that part in the code.
only the --addattr='usercertificate=cert' appends new value there
Yeah... I was a bit confused about how --addattr=... interacts with
options. I understand it now, and yes I think we should revoke
certificates that get removed this way.
cert-request will use addattr= so no existing certificates will get
removed (or revoked). New patch addressing this and other points
will arrive on list today.
Thanks for reviewing!
Fraser
--
Martin Basti
--
Martin Basti
--
Martin Basti
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Kerberos over HTTPS (KDC proxy)
Dne 28.5.2015 v 12:53 Christian Heimes napsal(a): On 2015-05-28 12:46, Martin Kosek wrote: I am fine with this too. So if there is not another major disagreement, let us start with enabling KDCPROXY by default during upgrade/install, the new ACI and the per-replica standard configuration. API CLI/UI can come later (4.2.x or 4.3). LGTM, too. How should the new ACI work? I see two possible ways: 1) Allow compare/search for ipaConfigString=enabledService for everybody: (targetfilter=(ipaConfigString=enabledService))(targetattr=ipaConfigString)(version 3.0; acl Compare enabledService access to masters; allow(search, compare) userdn = ldap:///all;;) 2) Create a new permission, assign it to all HTTP principals and allow read, compare and search for all ipaConfigString attributes. For the second way I need somebody to walk me through the permission and role system of FreeIPA. Christian So, will it be a separate component with its own freeipa-server-kdcproxy subpackage and installer or will it be a sub-component of KDC (as Martin suggested) and part of the core freeipa-server package? -- Jan Cholasta -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCHES 0001-0013 v5] Profiles and CA ACLs
On 05/28/2015 11:48 AM, Martin Basti wrote: On 27/05/15 16:04, Fraser Tweedale wrote: Hello all, Fresh certificate management patchset; Changelog: - Now depends on patch freeipa-ftweedal-0014 for correct cert-request behaviour with host and service principals. - Updated Dogtag dependency to 10.2.4-1. Should should be in f22 soon, but for f22 right now or for f21, please grab from my copr: https://copr.fedoraproject.org/coprs/ftweedal/freeipa/ Martin^1 could you please add to the quasi-official freeipa copr? SRPM lives at https://frase.id.au/pki-core-10.2.4-1.fc21.src.rpm. I've added it to mkosek/freeipa-master The build was successful on f22 but failed on f21. Should it be successful on f21? https://copr.fedoraproject.org/coprs/mkosek/freeipa-master/build/94540/ -- Petr Vobornik -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Kerberos over HTTPS (KDC proxy)
On Thu, 28 May 2015, Petr Spacek wrote: On 28.5.2015 07:42, Jan Cholasta wrote: Dne 27.5.2015 v 15:54 Simo Sorce napsal(a): On Wed, 2015-05-27 at 15:47 +0200, Jan Cholasta wrote: Dne 27.5.2015 v 15:43 Simo Sorce napsal(a): On Wed, 2015-05-27 at 13:57 +0200, Jan Cholasta wrote: ipa config-mod --enable-kdcproxy=TRUE ipa config-mod --enable-kdcproxy=FALSE I don't like this approach, as it is completely inconsistent with every other optional component. There should be *one* way to handle them and there already is one, no need to reinvent the wheel. Sorry Jan, but this is really the correct approach. I don't think so. We want a boolean in LDAP to control whether the IPA Domain allows proxying or not, the code is embedded in the overall framework and has no need for explicit install/uninstall unlike the CA or DNS components. There is a boolean for every other component/service as well. If you want to add new API to manipulate the boolean, fine, but it should be done in a generic way that works for other components as well. This is the same as: ipa config-mod --enable-migration=TRUE Why is it a problem ? This is a switch to enable the migrate-ds plugin. I think it's hardly fair to compare it to a whole new component which provides a new service to the outside world. This is not a separate service. How is it not a separate service? If it's installed, MS-KKDCP is provided to the outside world, and if it's not installed MS-KKDCP is not provided to the outside world. How is this different from, say, DNS? (Besides implementation details, such as what protocols or how many daemons it uses - think about IPA as a black box for a moment.) I very much agree with Honza - we have per-replica boolean for every service so there is no reason not to have one for kdc proxy, especially when we consider future containerization of services. A mere 'me too' here. Note that once updates to RFC 4120 as outlined in https://tools.ietf.org/html/draft-mccallum-kitten-krb-service-discovery-00 would be accepted, clients will not be assuming all of replicas serve MS-KKDCP proxies so there will not be need to run them everywhere. Rather, only the servers on a network boundary will need to be advertised. This means we'll eventually get per-replica need as well. It is fine to assume right now that all of them are going to run MS-KKDCP proxy but configuration isn't really going to be global. Additionally, ipa-kdcproxy-manage would need to manipulate _kerberos.$DOMAIN URI DNS records too, so there is more than just switching the boolean here. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0014] Support multiple user and host certificates
On 05/28/2015 11:17 AM, Martin Basti wrote:
On 28/05/15 10:46, Martin Kosek wrote:
On 05/27/2015 06:12 PM, Martin Basti wrote:
On 27/05/15 15:53, Fraser Tweedale wrote:
This patch adds supports for multiple user / host certificates. No
schema change is needed ('usercertificate' attribute is already
multi-value). The revoke-previous-cert behaviour of host-mod and
user-mod has been removed but revocation behaviour of -del and
-disable is preserved.
The latest profiles/caacl patchset (0001..0013 v5) depends on this
patch for correct cert-request behaviour.
There is one design question (or maybe more, let me know): the
`--out=FILENAME' option to {host,service} show saves ONE certificate
to the named file. I propose to either:
a) write all certs, suffixing suggested filename with either a
sequential numerical index, e.g. cert.pem becomes
cert.pem.1, cert.pem.2, and so on; or
b) as above, but suffix with serial number and, if there are
different issues, some issuer-identifying information.
Let me know your thoughts.
Thanks,
Fraser
Is there a possible way how to store certificates into one file?
I read about possibilities to have multiple certs in one .pem file, but I'm
not
cert guru :)
I personally vote for serial number in case there are multiple
certificates, if
^ is no possible.
1)
+if len(certs) 0:
please use only,
if certs:
2)
You need to re-generate API/ACI.txt in this patch
3)
syntax error:
+for dercert in certs_der
4)
command
ipa user-mod ca_user --certificate=ceritifcate
removes the current certificate from the LDAP, by design.
Should be the old certificate(s) revoked? You removed that part in the code.
Good question. I think the suggestion was to have a global switch in IPA
global
config that would configure the policy - whether the certificates removed by
this command or by host-del or host-disable are revoked or if they are just
removed (my motivation is to avoid behavior regression in case somebody
depended on this behavior).
I would prefer to keep the current behavior: revoke the certificate if it was
replaced or removed, instead of adding an extra configuration option.
This behavior is not regression.
It is not. However, it is not an ideal behavior also. In FreeIPA 4.2, we are
now adding support of certificate profiles, multiple certificates and even
certificates for user.
With that change, there may be much more certificates in play than now. If we
keep revoking all such certificates, it may cause rapid growth of CRLs. This is
something I am trying to avoid with this proposal and default to not revoking
certificates automatically (which mostly only makes sense if there is a risk
that the key is compromised), but have some option to keep the old behavior.
Does this make sense?
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [PATCHES 326-328] ID Views improvements
Hi,
this couple of patches improves ID Views and ID overrides handling. See
commit messages for details.
Tomas
From 8acc50c10d9886668a0147b46f311f9aa83294bb Mon Sep 17 00:00:00 2001
From: Tomas Babej tba...@redhat.com
Date: Wed, 27 May 2015 14:31:13 +0200
Subject: [PATCH] idviews: Set dcerpc detection flag properly
The availability of dcerpc bindings is being checked on the client
side as well, hence we need to define it properly.
https://fedorahosted.org/freeipa/ticket/5025
---
ipalib/plugins/idviews.py | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/ipalib/plugins/idviews.py b/ipalib/plugins/idviews.py
index 57f0cce1549edb4e582df225f7831916d96c216b..a7b1e0a78e57fcd2864d258c7968393c359499f2 100644
--- a/ipalib/plugins/idviews.py
+++ b/ipalib/plugins/idviews.py
@@ -30,12 +30,14 @@ from ipalib.util import (normalize_sshpubkey, validate_sshpubkey,
from ipapython.dn import DN
+_dcerpc_bindings_installed = False
+
if api.env.in_server and api.env.context in ['lite', 'server']:
try:
import ipaserver.dcerpc
_dcerpc_bindings_installed = True
except ImportError:
-_dcerpc_bindings_installed = False
+pass
__doc__ = _(
ID Views
--
2.1.0
From 41f158cd2b18ee7007e5b1d9ee2e1e02e37512c5 Mon Sep 17 00:00:00 2001
From: Tomas Babej tba...@redhat.com
Date: Wed, 27 May 2015 15:06:15 +0200
Subject: [PATCH] idviews: Allow users specify the raw anchor directly as
identifier
For various reasons, it can happen that the users or groups that
have overrides defined in a given ID view are no longer resolvable.
Since user and group names are used to specify the ID override objects
too by leveraging the respective user's or group's ipaUniqueID,
we need to provide a fallback in case these user or group entries
no longer exist.
https://fedorahosted.org/freeipa/ticket/5026
---
ipalib/plugins/idviews.py | 42 +++---
1 file changed, 31 insertions(+), 11 deletions(-)
diff --git a/ipalib/plugins/idviews.py b/ipalib/plugins/idviews.py
index a7b1e0a78e57fcd2864d258c7968393c359499f2..2c843462a859ae397ab1ef8e183f21dc1ac796a6 100644
--- a/ipalib/plugins/idviews.py
+++ b/ipalib/plugins/idviews.py
@@ -17,6 +17,7 @@
#
# You should have received a copy of the GNU General Public License
# along with this program. If not, see http://www.gnu.org/licenses/.
+import re
from ipalib.plugins.baseldap import (LDAPQuery, LDAPObject, LDAPCreate,
LDAPDelete, LDAPUpdate, LDAPSearch,
@@ -57,6 +58,12 @@ protected_default_trust_view_error = errors.ProtectedEntryError(
DEFAULT_TRUST_VIEW_NAME = default trust view
+ANCHOR_REGEX = re.compile(
+r':IPA:.*:[a-f0-9]{8}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{12}'
+r'|'
+r':SID:S-[0-9\-]+'
+)
+
@register()
class idview(LDAPObject):
@@ -559,11 +566,19 @@ class baseidoverride(LDAPObject):
override_object = None
def get_dn(self, *keys, **options):
-anchor = resolve_object_to_anchor(
-self.backend,
-self.override_object,
-keys[-1]
-)
+# If user passed raw anchor, do not try
+# to translate it.
+if ANCHOR_REGEX.match(keys[-1]):
+anchor = keys[-1]
+
+# Otherwise, translate object into a
+# legitimate object anchor.
+else:
+anchor = resolve_object_to_anchor(
+self.backend,
+self.override_object,
+keys[-1]
+)
keys = keys[:-1] + (anchor, )
return super(baseidoverride, self).get_dn(*keys, **options)
@@ -578,12 +593,17 @@ class baseidoverride(LDAPObject):
anchor = entry_attrs.single_value['ipaanchoruuid']
if anchor:
-object_name = resolve_anchor_to_object_name(
-self.backend,
-self.override_object,
-anchor
-)
-entry_attrs.single_value['ipaanchoruuid'] = object_name
+try:
+object_name = resolve_anchor_to_object_name(
+self.backend,
+self.override_object,
+anchor
+)
+entry_attrs.single_value['ipaanchoruuid'] = object_name
+except errors.NotFound:
+# If we were unable to resolve the anchor,
+# keep it in the raw form
+pass
def prohibit_ipa_users_in_default_view(self, dn, entry_attrs):
# Check if parent object is Default Trust View, if so, prohibit
--
2.1.0
From c4ad3ba829ab2816c6ddb64da8d5c6ceb8789340 Mon Sep 17 00:00:00 2001
From: Tomas Babej tba...@redhat.com
Date: Wed, 27 May 2015 16:30:48 +0200
Subject: [PATCH] idviews: Remove ID overrides for permanently removed users
and groups
For IPA users and groups we are able to trigger a removal of
any relevant
Re: [Freeipa-devel] Kerberos over HTTPS (KDC proxy)
On 28/05/15 12:53, Christian Heimes wrote: On 2015-05-28 12:46, Martin Kosek wrote: I am fine with this too. So if there is not another major disagreement, let us start with enabling KDCPROXY by default during upgrade/install, the new ACI and the per-replica standard configuration. API CLI/UI can come later (4.2.x or 4.3). LGTM, too. How should the new ACI work? I see two possible ways: 1) Allow compare/search for ipaConfigString=enabledService for everybody: (targetfilter=(ipaConfigString=enabledService))(targetattr=ipaConfigString)(version 3.0; acl Compare enabledService access to masters; allow(search, compare) userdn = ldap:///all;;) 2) Create a new permission, assign it to all HTTP principals and allow read, compare and search for all ipaConfigString attributes. For the second way I need somebody to walk me through the permission and role system of FreeIPA. 3) Or we can create a new keytab for KDC proxy, and add permission only for this service Christian -- Martin Basti -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCHES 0001-0013 v5] Profiles and CA ACLs
On 27/05/15 16:04, Fraser Tweedale wrote: Hello all, Fresh certificate management patchset; Changelog: - Now depends on patch freeipa-ftweedal-0014 for correct cert-request behaviour with host and service principals. - Updated Dogtag dependency to 10.2.4-1. Should should be in f22 soon, but for f22 right now or for f21, please grab from my copr: https://copr.fedoraproject.org/coprs/ftweedal/freeipa/ Martin^1 could you please add to the quasi-official freeipa copr? SRPM lives at https://frase.id.au/pki-core-10.2.4-1.fc21.src.rpm. - cert-request now verifies that for user principals, CSR CN matches uid and, DN emailAddress and SAN rfc822Name match user's email address, if either of those is present. - Fixed one or two other sneaky little bugs. On Wed, May 27, 2015 at 01:59:30AM +1000, Fraser Tweedale wrote: Hi all, Please find attached the latest certificate management patchset, which introduces the `caacl' plugin and various fixes and improvement to earlier patches. One important change to earlier patches is reverting the name of the default profile to 'caIPAserviceCert' and using the existing instance of this profile on upgrade (but not install) in case it has been modified. Other notes: - Still have changes in ipa-server-install (fewer lines now, though) - Still have the ugly import hack. It is not a high priority for me, i.e. I think it should wait until after alpha - Still need to update 'service' and 'host' plugins to support multiple certificates. (The userCertificate attribute schema itself is multi-valued, so there are no schema issues here) - The TODOs in [1]; mostly certprofile CLI conveniences and supporting multiple profiles for hosts and services (which requires changes to framework only, not schema). [1]: http://idm.etherpad.corp.redhat.com/rhel72-cert-mgmt-progress Happy reviewing! I am pleased with the initial cut of the caacl plugin but I'm sure you will find some things to be fixed :) Cheers, Fraser [root@vm-093 ~]# ipa-replica-prepare vm-094.example.com --ip-address 10.34.78.94 Directory Manager (existing master) password: Preparing replica for vm-094.example.com from vm-093.example.com Creating SSL certificate for the Directory Server not well-formed (invalid token): line 2, column 14 I cannot create replica file. It work on the upgraded server, but it doesn't work on the newly installed server. I'm not sure if this causes your patches which modifies the ca-installer, or the newer version of dogtag. Or if there was any other changes in master, I will continue to investigate with new RPM from master branch. Martin^2 -- Martin Basti -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Kerberos over HTTPS (KDC proxy)
On 05/28/2015 12:27 PM, Alexander Bokovoy wrote: On Thu, 28 May 2015, Christian Heimes wrote: On 2015-05-28 12:10, Petr Spacek wrote: I see. My question is - if we go this way, what is then the reasonable subset configuration functionality realistic for FreeIPA 4.2 GA? (As we want this feature in for 4.2). Is ipa-kdcproxy-manage doable? What is the proposed API here? ipa-kdcproxy-manage list ipa-kdcproxy-manage enable server ipa-kdcproxy-manage disable server I believe that for 4.2 it is perfectly enough to have per-replica switch in LDAP (enabled by default) and to provide ldapmodify command in docs. User interface can be polished later if we get the design right. For Petr proposal to work we only need an additional ACI and maybe an additional permission. I'm using Apache's keytab for LDAP bin. The principal has no permission to read or search ipaConfigString attributes in the cn=masters tree. A ipa-kdcproxy-manage is more work. I'd have to write the script and implement a HTTP interface to reload all settings. I'm fine with that for 4.2. We can always add an example of enable/disable via ipa-ldap-updater tool which should be simplest one for admins as it includes template values for domain and IPA master hosts. See https://vda.li/en/posts/2015/01/02/playing-with-freeipa-ipa-ldap-updater/ for examples, this one would be similar to how weak enctypes are enabled: # 20-kdcproxy-enable-on-this-master.update dn: cn=KDCPROXY,cn=$FQDN,cn=masters,cn=ipa,cn=etc,$SUFFIX add:ipaConfigString:enabledService # 20-kdcproxy-disable-on-this-master.update dn: cn=KDCPROXY,cn=$FQDN,cn=masters,cn=ipa,cn=etc,$SUFFIX remove:ipaConfigString:enabledService I am fine with this too. So if there is not another major disagreement, let us start with enabling KDCPROXY by default during upgrade/install, the new ACI and the per-replica standard configuration. API CLI/UI can come later (4.2.x or 4.3). -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Kerberos over HTTPS (KDC proxy)
On 28.5.2015 11:59, Martin Kosek wrote: On 05/28/2015 11:12 AM, Alexander Bokovoy wrote: On Thu, 28 May 2015, Petr Spacek wrote: On 28.5.2015 07:42, Jan Cholasta wrote: Dne 27.5.2015 v 15:54 Simo Sorce napsal(a): On Wed, 2015-05-27 at 15:47 +0200, Jan Cholasta wrote: Dne 27.5.2015 v 15:43 Simo Sorce napsal(a): On Wed, 2015-05-27 at 13:57 +0200, Jan Cholasta wrote: ipa config-mod --enable-kdcproxy=TRUE ipa config-mod --enable-kdcproxy=FALSE I don't like this approach, as it is completely inconsistent with every other optional component. There should be *one* way to handle them and there already is one, no need to reinvent the wheel. Sorry Jan, but this is really the correct approach. I don't think so. We want a boolean in LDAP to control whether the IPA Domain allows proxying or not, the code is embedded in the overall framework and has no need for explicit install/uninstall unlike the CA or DNS components. There is a boolean for every other component/service as well. If you want to add new API to manipulate the boolean, fine, but it should be done in a generic way that works for other components as well. This is the same as: ipa config-mod --enable-migration=TRUE Why is it a problem ? This is a switch to enable the migrate-ds plugin. I think it's hardly fair to compare it to a whole new component which provides a new service to the outside world. This is not a separate service. How is it not a separate service? If it's installed, MS-KKDCP is provided to the outside world, and if it's not installed MS-KKDCP is not provided to the outside world. How is this different from, say, DNS? (Besides implementation details, such as what protocols or how many daemons it uses - think about IPA as a black box for a moment.) I very much agree with Honza - we have per-replica boolean for every service so there is no reason not to have one for kdc proxy, especially when we consider future containerization of services. A mere 'me too' here. Note that once updates to RFC 4120 as outlined in https://tools.ietf.org/html/draft-mccallum-kitten-krb-service-discovery-00 would be accepted, clients will not be assuming all of replicas serve MS-KKDCP proxies so there will not be need to run them everywhere. Rather, only the servers on a network boundary will need to be advertised. This means we'll eventually get per-replica need as well. It is fine to assume right now that all of them are going to run MS-KKDCP proxy but configuration isn't really going to be global. Additionally, ipa-kdcproxy-manage would need to manipulate _kerberos.$DOMAIN URI DNS records too, so there is more than just switching the boolean here. I see. My question is - if we go this way, what is then the reasonable subset configuration functionality realistic for FreeIPA 4.2 GA? (As we want this feature in for 4.2). Is ipa-kdcproxy-manage doable? What is the proposed API here? ipa-kdcproxy-manage list ipa-kdcproxy-manage enable server ipa-kdcproxy-manage disable server I believe that for 4.2 it is perfectly enough to have per-replica switch in LDAP (enabled by default) and to provide ldapmodify command in docs. User interface can be polished later if we get the design right. -- Petr^2 Spacek -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Kerberos over HTTPS (KDC proxy)
On Thu, 28 May 2015, Christian Heimes wrote: On 2015-05-28 12:10, Petr Spacek wrote: I see. My question is - if we go this way, what is then the reasonable subset configuration functionality realistic for FreeIPA 4.2 GA? (As we want this feature in for 4.2). Is ipa-kdcproxy-manage doable? What is the proposed API here? ipa-kdcproxy-manage list ipa-kdcproxy-manage enable server ipa-kdcproxy-manage disable server I believe that for 4.2 it is perfectly enough to have per-replica switch in LDAP (enabled by default) and to provide ldapmodify command in docs. User interface can be polished later if we get the design right. For Petr proposal to work we only need an additional ACI and maybe an additional permission. I'm using Apache's keytab for LDAP bin. The principal has no permission to read or search ipaConfigString attributes in the cn=masters tree. A ipa-kdcproxy-manage is more work. I'd have to write the script and implement a HTTP interface to reload all settings. I'm fine with that for 4.2. We can always add an example of enable/disable via ipa-ldap-updater tool which should be simplest one for admins as it includes template values for domain and IPA master hosts. See https://vda.li/en/posts/2015/01/02/playing-with-freeipa-ipa-ldap-updater/ for examples, this one would be similar to how weak enctypes are enabled: # 20-kdcproxy-enable-on-this-master.update dn: cn=KDCPROXY,cn=$FQDN,cn=masters,cn=ipa,cn=etc,$SUFFIX add:ipaConfigString:enabledService # 20-kdcproxy-disable-on-this-master.update dn: cn=KDCPROXY,cn=$FQDN,cn=masters,cn=ipa,cn=etc,$SUFFIX remove:ipaConfigString:enabledService -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Kerberos over HTTPS (KDC proxy)
On 28.5.2015 12:53, Christian Heimes wrote: On 2015-05-28 12:46, Martin Kosek wrote: I am fine with this too. So if there is not another major disagreement, let us start with enabling KDCPROXY by default during upgrade/install, the new ACI and the per-replica standard configuration. API CLI/UI can come later (4.2.x or 4.3). LGTM, too. How should the new ACI work? I see two possible ways: 1) Allow compare/search for ipaConfigString=enabledService for everybody: (targetfilter=(ipaConfigString=enabledService))(targetattr=ipaConfigString)(version 3.0; acl Compare enabledService access to masters; allow(search, compare) userdn = ldap:///all;;) 2) Create a new permission, assign it to all HTTP principals and allow read, compare and search for all ipaConfigString attributes. I like option 2 - a new permission like Read configuration of IPA services. For the second way I need somebody to walk me through the permission and role system of FreeIPA. Unfortunately I did not use the new system myself so I do not have particular steps to share. Please see design pages here: http://www.freeipa.org/page/V3/Permissions_V2 http://www.freeipa.org/page/V3/Permissions_V2/tests ... and contact Petr Viktorin pvikt...@redhat.com. The new permission system is his child :-) I hope this helps. -- Petr^2 Spacek -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Kerberos over HTTPS (KDC proxy)
Dne 28.5.2015 v 13:56 Christian Heimes napsal(a): On 2015-05-28 13:30, Jan Cholasta wrote: Dne 28.5.2015 v 12:53 Christian Heimes napsal(a): On 2015-05-28 12:46, Martin Kosek wrote: I am fine with this too. So if there is not another major disagreement, let us start with enabling KDCPROXY by default during upgrade/install, the new ACI and the per-replica standard configuration. API CLI/UI can come later (4.2.x or 4.3). LGTM, too. How should the new ACI work? I see two possible ways: 1) Allow compare/search for ipaConfigString=enabledService for everybody: (targetfilter=(ipaConfigString=enabledService))(targetattr=ipaConfigString)(version 3.0; acl Compare enabledService access to masters; allow(search, compare) userdn = ldap:///all;;) 2) Create a new permission, assign it to all HTTP principals and allow read, compare and search for all ipaConfigString attributes. For the second way I need somebody to walk me through the permission and role system of FreeIPA. Christian So, will it be a separate component with its own freeipa-server-kdcproxy subpackage and installer or will it be a sub-component of KDC (as Martin suggested) and part of the core freeipa-server package? For now I'm in favor of a sub-component as part of the freeipa-server package. OK, then I'm fine with ipa-kdcproxy-manage, but instead of adding a new service entry for KDC proxy, you can just add a flag to the KDC service entry, like ipaConfigString=kdcProxyEnabled. -- Jan Cholasta -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Kerberos over HTTPS (KDC proxy)
On 28/05/15 14:06, Christian Heimes wrote: On 2015-05-28 13:29, Martin Basti wrote: On 28/05/15 12:53, Christian Heimes wrote: On 2015-05-28 12:46, Martin Kosek wrote: I am fine with this too. So if there is not another major disagreement, let us start with enabling KDCPROXY by default during upgrade/install, the new ACI and the per-replica standard configuration. API CLI/UI can come later (4.2.x or 4.3). LGTM, too. How should the new ACI work? I see two possible ways: 1) Allow compare/search for ipaConfigString=enabledService for everybody: (targetfilter=(ipaConfigString=enabledService))(targetattr=ipaConfigString)(version 3.0; acl Compare enabledService access to masters; allow(search, compare) userdn = ldap:///all;;) 2) Create a new permission, assign it to all HTTP principals and allow read, compare and search for all ipaConfigString attributes. For the second way I need somebody to walk me through the permission and role system of FreeIPA. 3) Or we can create a new keytab for KDC proxy, and add permission only for this service The new keytab must be readable by the Apache process.Therefore a new keytab doesn't give us extra security. It separates the kdcproxy service from the IPA webgui. Is that your goal? Christian OK, then nevermind :-) Martin^2 -- Martin Basti -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0039] ipa-kdb: common function to get key encodings/salt types
On Thu, 2015-05-28 at 14:43 +0200, Martin Babinsky wrote: A small improvement upon simo's fix for https://fedorahosted.org/freeipa/ticket/4914 -- Martin^3 Babinsky LGTM. Simo. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Kerberos over HTTPS (KDC proxy)
On 05/28/2015 03:06 PM, Simo Sorce wrote: On Thu, 2015-05-28 at 07:42 +0200, Jan Cholasta wrote: Dne 27.5.2015 v 15:54 Simo Sorce napsal(a): On Wed, 2015-05-27 at 15:47 +0200, Jan Cholasta wrote: Dne 27.5.2015 v 15:43 Simo Sorce napsal(a): On Wed, 2015-05-27 at 13:57 +0200, Jan Cholasta wrote: ipa config-mod --enable-kdcproxy=TRUE ipa config-mod --enable-kdcproxy=FALSE I don't like this approach, as it is completely inconsistent with every other optional component. There should be *one* way to handle them and there already is one, no need to reinvent the wheel. Sorry Jan, but this is really the correct approach. I don't think so. We want a boolean in LDAP to control whether the IPA Domain allows proxying or not, the code is embedded in the overall framework and has no need for explicit install/uninstall unlike the CA or DNS components. There is a boolean for every other component/service as well. If you want to add new API to manipulate the boolean, fine, but it should be done in a generic way that works for other components as well. This is the same as: ipa config-mod --enable-migration=TRUE Why is it a problem ? This is a switch to enable the migrate-ds plugin. I think it's hardly fair to compare it to a whole new component which provides a new service to the outside world. Well, this is the problem, I guess there is a perception issue. The KDC Proxy is basically nothing more than adding a new protocol to the KDC. It doesn't really do anything special but getting packets on HTTPS and sending them to the KDC over TCP. SO I think that for this specific case the KDC Proxy really is comparable to migration mode (actually simpler than migration). This is not a separate service. How is it not a separate service? If it's installed, MS-KKDCP is provided to the outside world, and if it's not installed MS-KKDCP is not provided to the outside world. If the migration plugin is installed the service is provided, if it is not installed it is not provided, it is conceptually the same. Yes there is code involved, but we plan to have the proxy always provided. There is no plan to have it as a removable component, you can only enable or disable it, like for migration. How is this different from, say, DNS? (Besides implementation details, such as what protocols or how many daemons it uses - think about IPA as a black box for a moment.) It is completely different in size and scope, the KDCProxy really is just an enabler to reach the KDC over a different protocol, it is not a whole new protocol and service. In the end it is a matter of perspective, I think most of the people that have been dealing with it think it is much like migration and not an entire new service like DNS. In the end, Alexander had a good point that there will be some needed associated configuration changes in DNS, when the KdcProxy is enabled/disabled: http://www.redhat.com/archives/freeipa-devel/2015-May/msg00522.html In which case, we may want to end up with more complicated API/CLI (ipa-kdcproxy-manage) than just config-mod command. We now mostly settled to per replica configuration, postponing powerful API/CLI for later: http://www.redhat.com/archives/freeipa-devel/2015-May/msg00535.html Martin -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Kerberos over HTTPS (KDC proxy)
On Thu, 2015-05-28 at 12:14 +0300, Alexander Bokovoy wrote: On Thu, 28 May 2015, Martin Kosek wrote: On 05/28/2015 10:02 AM, Jan Cholasta wrote: Dne 28.5.2015 v 09:45 Christian Heimes napsal(a): On 2015-05-28 07:32, Jan Cholasta wrote: Dne 27.5.2015 v 16:01 Christian Heimes napsal(a): On 2015-05-27 15:51, Nathaniel McCallum wrote: As I understand the problem, there is an assumption that an optional component has a distinct service to start and stop. That is not the case here. This is just new config for apache. More details: The KDC Proxy uses the same Apache instance as FreeIPAs Web GUI and Tomcat. There is no extra service involved. The switch just decides if https://ipa.example.org/KdcProxy acts as a MS-KKDCP end point or returns a 404 error. FYI Tomcat does not use the same Apache instance, the Apache instance is configured to proxy requests to Tomcat. If the IPA KDC proxy package is not installed on a replica, then going to /KdcProxy will return 404, right? Why is an additional switch necessary then? The python-kdcproxy package is a new dependency for the freeipa-server package. It will always get installed with the server. Why? None of the IPA core functionality depends on it, so it should be optional. Also the overall trend in IPA is to have everything in subpackages. Do not look at it as a separate component. It is mostly just a new transport for Kerberos. FreeIPA already provides Kerberos via TCP and UDP. This is a third transport - HTTP. See my other response. With changes in https://tools.ietf.org/html/draft-mccallum-kitten-krb-service-discovery-00 we'll need to manage _kerberos.$DOMAIN URI DNS record (not just TXT one like now) to explicitly report where the proxies are located. This goes beyond just global switch in LDAP and requires ipa-kdcproxy-manage tool. Not really, we'll use the enable/disable switch to find out which DNS records to publish, like we do for SRV records now, not special tool is needed for now. Simo. -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Kerberos over HTTPS (KDC proxy)
On 2015-05-28 13:30, Jan Cholasta wrote: Dne 28.5.2015 v 12:53 Christian Heimes napsal(a): On 2015-05-28 12:46, Martin Kosek wrote: I am fine with this too. So if there is not another major disagreement, let us start with enabling KDCPROXY by default during upgrade/install, the new ACI and the per-replica standard configuration. API CLI/UI can come later (4.2.x or 4.3). LGTM, too. How should the new ACI work? I see two possible ways: 1) Allow compare/search for ipaConfigString=enabledService for everybody: (targetfilter=(ipaConfigString=enabledService))(targetattr=ipaConfigString)(version 3.0; acl Compare enabledService access to masters; allow(search, compare) userdn = ldap:///all;;) 2) Create a new permission, assign it to all HTTP principals and allow read, compare and search for all ipaConfigString attributes. For the second way I need somebody to walk me through the permission and role system of FreeIPA. Christian So, will it be a separate component with its own freeipa-server-kdcproxy subpackage and installer or will it be a sub-component of KDC (as Martin suggested) and part of the core freeipa-server package? For now I'm in favor of a sub-component as part of the freeipa-server package. Christian signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0014] Support multiple user and host certificates
On 28/05/15 14:29, Petr Spacek wrote:
On 28.5.2015 12:06, Fraser Tweedale wrote:
On Thu, May 28, 2015 at 11:52:25AM +0200, Martin Kosek wrote:
On 05/28/2015 11:17 AM, Martin Basti wrote:
On 28/05/15 10:46, Martin Kosek wrote:
On 05/27/2015 06:12 PM, Martin Basti wrote:
On 27/05/15 15:53, Fraser Tweedale wrote:
This patch adds supports for multiple user / host certificates. No
schema change is needed ('usercertificate' attribute is already
multi-value). The revoke-previous-cert behaviour of host-mod and
user-mod has been removed but revocation behaviour of -del and
-disable is preserved.
The latest profiles/caacl patchset (0001..0013 v5) depends on this
patch for correct cert-request behaviour.
There is one design question (or maybe more, let me know): the
`--out=FILENAME' option to {host,service} show saves ONE certificate
to the named file. I propose to either:
a) write all certs, suffixing suggested filename with either a
sequential numerical index, e.g. cert.pem becomes
cert.pem.1, cert.pem.2, and so on; or
b) as above, but suffix with serial number and, if there are
different issues, some issuer-identifying information.
Let me know your thoughts.
Thanks,
Fraser
Is there a possible way how to store certificates into one file?
I read about possibilities to have multiple certs in one .pem file, but I'm not
cert guru :)
I personally vote for serial number in case there are multiple certificates, if
^ is no possible.
1)
+if len(certs) 0:
please use only,
if certs:
2)
You need to re-generate API/ACI.txt in this patch
3)
syntax error:
+for dercert in certs_der
4)
command
ipa user-mod ca_user --certificate=ceritifcate
removes the current certificate from the LDAP, by design.
Should be the old certificate(s) revoked? You removed that part in the code.
Good question. I think the suggestion was to have a global switch in IPA global
config that would configure the policy - whether the certificates removed by
this command or by host-del or host-disable are revoked or if they are just
removed (my motivation is to avoid behavior regression in case somebody
depended on this behavior).
I would prefer to keep the current behavior: revoke the certificate if it was
replaced or removed, instead of adding an extra configuration option.
This behavior is not regression.
It is not. However, it is not an ideal behavior also. In FreeIPA 4.2, we are
now adding support of certificate profiles, multiple certificates and even
certificates for user.
With that change, there may be much more certificates in play than now. If we
keep revoking all such certificates, it may cause rapid growth of CRLs. This is
something I am trying to avoid with this proposal and default to not revoking
certificates automatically (which mostly only makes sense if there is a risk
that the key is compromised), but have some option to keep the old behavior.
Does this make sense?
I would like to see some data to support the decision not to revoke certs by
default. Are there some facts to base the decision on? Or just hand-wavy
reasoning?
Sure, huge CRL may be bad, but not revoking certs may be even worse. E.g. when
older backup files are stolen (in the information sense, i.e. copied without
anyone noticing it) - attacker might get valid certs despite the fact that the
old cert is never used (because it was rotated right after the backup).
IMHO this behavior should be configurable and default to 'revoke'. We should
ship FreeIPA with secure defaults and let users to lower the standards if they
wish/need.
Petr^2 Spacek
+1
would be enought to have just option in the command --revoke-cert=true,
with true as default, instead of global configuration?
Martin^2
It does make senes.
In regards to *this* patch, I will make -mod behave the same as -del
and -disable; i.e. the current behaviour i.e. revoke whenever we
forget a certificate.
Any config knobs, command options, etc to govern whether to revoke
shall be added in a subsequent patch.
--
Martin Basti
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Domain level for topology plugin = 2
On Thu, 2015-05-28 at 14:11 +0200, Petr Spacek wrote: On 28.5.2015 10:49, Martin Kosek wrote: On 05/28/2015 09:05 AM, Petr Spacek wrote: On 28.5.2015 08:55, Jan Cholasta wrote: Dne 26.5.2015 v 16:32 Petr Spacek napsal(a): On 26.5.2015 16:16, Martin Kosek wrote: On 05/26/2015 04:13 PM, thierry bordaz wrote: On 05/26/2015 02:12 PM, Petr Spacek wrote: Hello, it came to my mind that domain level for topology plugin should actually be number 2, not 1. We already used number 1 for incompatible changes in DNS tree and I believe that it is not a good idea to have two places which say 'version 1' but and actually mean two different things. (DNS tree version 1 + domain level 1) Patch is attached. Hello, The fix looks good but that seems strange to have to set the initial version of the topology plugin to 2.0. (IIUC That is the version that will be written in dse.ldif) I would rather expects that topology plugin 1.0, would activate itself if the DomainLevel is 2.0 or more. If topology plugin 1.0 sets an internal DomainLevel_trigger=2.0 then activate itself if DomainLevel = DomainLevel_trigger. Let's wait for Ludwig feedback. thanks thierry My personal opinion on this is to start with Domain Level 1 regardless. We already solved the DNS forwarders otherwise, with docs, async updates etc. I do not think we will be returning to implementing proper Domain Level support for that anyway. So I rather think that all the Domain Level starts with 0, 1 is unused, 2 is the top one will cause unforeseen issues I would rather like to avoid. I'm more worried about confusion in future. To to me it simply seems easier to bump one integer now than to document and explain (to users new developers) why we have two ones which mean something else. Code-wise it is just an integer. Also, it can simplify logic in future when we decide to do another incompatible change in DNS tree because we will have only one integer to test (instead of checking two separate version attribute in DNS tree domain level). +1, but I think the minimum supported domain level should be 1, not 0, because 0 means the server uses the old DNS schema, which we do not support anymore, right? Good point! It may be a good point, but it does not make the situation easier. You still have RHEL/CentOS 6.x IPA out there, where some of them already support the new DNS forwarders and some don't - and neither of them support Domain Levels - i.e. have Domain Level 0. As I said, I still see more complications with this proposals than benefits... I would argue that it actually helps. If domain level = 1 then we can be *sure* that all replicas support the new DNS semantics. If domain level = 0 then we know nothing (because of patched RHEL 6) and it is a warning sign for diagnostic tools and also us when it comes to debugging. First of all a domain level is something we change *RARELY*, and it is a whole number and it is an all or nothing thing. I do not understand why plugin versions matter at all, plugin version have nothing to do with domain levels. Each plugin *whatever* the version MUST always support at least 2 levels, because every domain you have will have to go through a domain_level transition when a new domain level comes out. Finally no single developer should be allowed to decide on anew domain level, this must be a well ponder team decision as all plugins that need to change behavior based on domain level will be affected so a thorough review of what changes are needed across all plugins must be done every time someone propose a change that requires a domain level bump. Last but not least we should consider domain levels as something that changes *very* slowly, because otherwise you'll have to support many domain levels within any plugins that have to change behavior according to the domain level. I would say that the domain level should not change more frequently than once a year or so. It would be too much code churn to do otherwise. So for now domain_level should be set to 0. And the topology plugin will be enabled only when we turn it to 1. However we shouldn't turn it to 1 until we have the replica promotion code at least, because only then we can make full use of the topology plugins. The DNS mess is unfixable, unless Petr you volunteer to backport code to change the behavior of the DNS based on the domain level, if that's the case then you can tie old behavior to level 0 and new behavior to level = 1, but I do not think you want to do that given we already have level 0 servers that sport the new code and changed the data in the directory, so let's just ignore DNS for the purpose of this discussion, except for nothing that once we finally switch to level 1 then all servers must be running with the newer DNS schema and older is not supported. Ah, I almost
Re: [Freeipa-devel] Domain level for topology plugin = 2
On 05/28/2015 03:52 PM, Simo Sorce wrote: On Thu, 2015-05-28 at 15:39 +0200, Oleg Fayans wrote: On 05/28/2015 03:26 PM, Simo Sorce wrote: On Thu, 2015-05-28 at 14:11 +0200, Petr Spacek wrote: On 28.5.2015 10:49, Martin Kosek wrote: On 05/28/2015 09:05 AM, Petr Spacek wrote: On 28.5.2015 08:55, Jan Cholasta wrote: Dne 26.5.2015 v 16:32 Petr Spacek napsal(a): On 26.5.2015 16:16, Martin Kosek wrote: On 05/26/2015 04:13 PM, thierry bordaz wrote: On 05/26/2015 02:12 PM, Petr Spacek wrote: Hello, it came to my mind that domain level for topology plugin should actually be number 2, not 1. We already used number 1 for incompatible changes in DNS tree and I believe that it is not a good idea to have two places which say 'version 1' but and actually mean two different things. (DNS tree version 1 + domain level 1) Patch is attached. Hello, The fix looks good but that seems strange to have to set the initial version of the topology plugin to 2.0. (IIUC That is the version that will be written in dse.ldif) I would rather expects that topology plugin 1.0, would activate itself if the DomainLevel is 2.0 or more. If topology plugin 1.0 sets an internal DomainLevel_trigger=2.0 then activate itself if DomainLevel = DomainLevel_trigger. Let's wait for Ludwig feedback. thanks thierry My personal opinion on this is to start with Domain Level 1 regardless. We already solved the DNS forwarders otherwise, with docs, async updates etc. I do not think we will be returning to implementing proper Domain Level support for that anyway. So I rather think that all the Domain Level starts with 0, 1 is unused, 2 is the top one will cause unforeseen issues I would rather like to avoid. I'm more worried about confusion in future. To to me it simply seems easier to bump one integer now than to document and explain (to users new developers) why we have two ones which mean something else. Code-wise it is just an integer. Also, it can simplify logic in future when we decide to do another incompatible change in DNS tree because we will have only one integer to test (instead of checking two separate version attribute in DNS tree domain level). +1, but I think the minimum supported domain level should be 1, not 0, because 0 means the server uses the old DNS schema, which we do not support anymore, right? Good point! It may be a good point, but it does not make the situation easier. You still have RHEL/CentOS 6.x IPA out there, where some of them already support the new DNS forwarders and some don't - and neither of them support Domain Levels - i.e. have Domain Level 0. As I said, I still see more complications with this proposals than benefits... I would argue that it actually helps. If domain level = 1 then we can be *sure* that all replicas support the new DNS semantics. If domain level = 0 then we know nothing (because of patched RHEL 6) and it is a warning sign for diagnostic tools and also us when it comes to debugging. First of all a domain level is something we change *RARELY*, and it is a whole number and it is an all or nothing thing. I do not understand why plugin versions matter at all, plugin version have nothing to do with domain levels. Each plugin *whatever* the version MUST always support at least 2 levels, because every domain you have will have to go through a domain_level transition when a new domain level comes out. Finally no single developer should be allowed to decide on anew domain level, this must be a well ponder team decision as all plugins that need to change behavior based on domain level will be affected so a thorough review of what changes are needed across all plugins must be done every time someone propose a change that requires a domain level bump. Last but not least we should consider domain levels as something that changes *very* slowly, because otherwise you'll have to support many domain levels within any plugins that have to change behavior according to the domain level. I would say that the domain level should not change more frequently than once a year or so. It would be too much code churn to do otherwise. So for now domain_level should be set to 0. And the topology plugin will be enabled only when we turn it to 1. However we shouldn't turn it to 1 until we have the replica promotion code at least, because only then we can make full use of the topology plugins. Does that mean, that by default domain level must be set to 0 and only raised manually by the identity admin? Yes, the domain level is established by the first server you install, and CANNOT be raise automatically by a replica, it must be always manually raised by the admin. yes, for the first time it is raised, but if you install a new replica it will be initialized from an existing replica in the domain and teh domain level is in the shared tree, so the new replica will have it automatically Moreover the code that raises *MUST* check that all server are capable of handling the new domain level or
Re: [Freeipa-devel] New replica installation and topology - we need stable base
On Thu, 2015-05-28 at 16:04 +0200, Martin Kosek wrote: On 05/28/2015 04:04 PM, Ludwig Krispenz wrote: On 05/28/2015 04:00 PM, Martin Kosek wrote: On 05/28/2015 03:57 PM, Ludwig Krispenz wrote: On 05/28/2015 03:47 PM, Martin Kosek wrote: On 05/27/2015 04:59 PM, Martin Kosek wrote: ... Domain Levels - Done, committed - Defaults to Level 1, i.e. Topology plugin powered infra enabled With respect to related Simo's response in http://www.redhat.com/archives/freeipa-devel/2015-May/msg00553.html Would we want to enable Topology (i.e. Domain Level 1) even if Replica promotion is not done? who is we ? I thought there is an api to set the domain-level and the admin decides if, or do you mean to have it by default during installation ? The question here is if Topology plugin (i.e. Domain Level 1) shall be enabled during new FreeIPA 4.2 installation or if would be still disabled and only enabled by domain-level-set request. I'm with Simo, this shoul be a deliberate action by an admin, based upon the info that all servers support this domain level Guys, I am really talking about *new* FreeIPA server installation, not upgrades. If you are installing FreeIPA 4.2 server, you already know that *all* servers support Topology as we do not allow installing replica with older version than a server. What do I miss here? I think the only thing that may be missing is that the current installer still does the dance of using SSL and then later transitioning to GSSAPI, I am not sure the topology plugin copes with that. Ludwig, can you comment ? Simo. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Domain level for topology plugin = 2
Hi Simo, On 05/28/2015 03:52 PM, Simo Sorce wrote: On Thu, 2015-05-28 at 15:39 +0200, Oleg Fayans wrote: On 05/28/2015 03:26 PM, Simo Sorce wrote: On Thu, 2015-05-28 at 14:11 +0200, Petr Spacek wrote: On 28.5.2015 10:49, Martin Kosek wrote: On 05/28/2015 09:05 AM, Petr Spacek wrote: On 28.5.2015 08:55, Jan Cholasta wrote: Dne 26.5.2015 v 16:32 Petr Spacek napsal(a): On 26.5.2015 16:16, Martin Kosek wrote: On 05/26/2015 04:13 PM, thierry bordaz wrote: On 05/26/2015 02:12 PM, Petr Spacek wrote: Hello, it came to my mind that domain level for topology plugin should actually be number 2, not 1. We already used number 1 for incompatible changes in DNS tree and I believe that it is not a good idea to have two places which say 'version 1' but and actually mean two different things. (DNS tree version 1 + domain level 1) Patch is attached. Hello, The fix looks good but that seems strange to have to set the initial version of the topology plugin to 2.0. (IIUC That is the version that will be written in dse.ldif) I would rather expects that topology plugin 1.0, would activate itself if the DomainLevel is 2.0 or more. If topology plugin 1.0 sets an internal DomainLevel_trigger=2.0 then activate itself if DomainLevel = DomainLevel_trigger. Let's wait for Ludwig feedback. thanks thierry My personal opinion on this is to start with Domain Level 1 regardless. We already solved the DNS forwarders otherwise, with docs, async updates etc. I do not think we will be returning to implementing proper Domain Level support for that anyway. So I rather think that all the Domain Level starts with 0, 1 is unused, 2 is the top one will cause unforeseen issues I would rather like to avoid. I'm more worried about confusion in future. To to me it simply seems easier to bump one integer now than to document and explain (to users new developers) why we have two ones which mean something else. Code-wise it is just an integer. Also, it can simplify logic in future when we decide to do another incompatible change in DNS tree because we will have only one integer to test (instead of checking two separate version attribute in DNS tree domain level). +1, but I think the minimum supported domain level should be 1, not 0, because 0 means the server uses the old DNS schema, which we do not support anymore, right? Good point! It may be a good point, but it does not make the situation easier. You still have RHEL/CentOS 6.x IPA out there, where some of them already support the new DNS forwarders and some don't - and neither of them support Domain Levels - i.e. have Domain Level 0. As I said, I still see more complications with this proposals than benefits... I would argue that it actually helps. If domain level = 1 then we can be *sure* that all replicas support the new DNS semantics. If domain level = 0 then we know nothing (because of patched RHEL 6) and it is a warning sign for diagnostic tools and also us when it comes to debugging. First of all a domain level is something we change *RARELY*, and it is a whole number and it is an all or nothing thing. I do not understand why plugin versions matter at all, plugin version have nothing to do with domain levels. Each plugin *whatever* the version MUST always support at least 2 levels, because every domain you have will have to go through a domain_level transition when a new domain level comes out. Finally no single developer should be allowed to decide on anew domain level, this must be a well ponder team decision as all plugins that need to change behavior based on domain level will be affected so a thorough review of what changes are needed across all plugins must be done every time someone propose a change that requires a domain level bump. Last but not least we should consider domain levels as something that changes *very* slowly, because otherwise you'll have to support many domain levels within any plugins that have to change behavior according to the domain level. I would say that the domain level should not change more frequently than once a year or so. It would be too much code churn to do otherwise. So for now domain_level should be set to 0. And the topology plugin will be enabled only when we turn it to 1. However we shouldn't turn it to 1 until we have the replica promotion code at least, because only then we can make full use of the topology plugins. Does that mean, that by default domain level must be set to 0 and only raised manually by the identity admin? Yes, the domain level is established by the first server you install, and CANNOT be raise automatically by a replica, it must be always manually raised by the admin. Moreover the code that raises *MUST* check that all server are capable of handling the new domain level or refuse to raise the level. This means all servers must publish the range of domain levels they support, a
[Freeipa-devel] KDC proxy implementation specs
Hello, thanks you for your input. The former thread has 58 messages in total. Since last Friday we have came to an agreement in most points. I like to some up our decisions and focus on some minor details. decisions - python-kdcproxy will be installed as a dependency of freeipa-server. There won't be a separate freeipa-server-kdcproxy package. That may or may not change in the future. The decision is out of scope for 4.2.0. [1] KDC proxy support will be enabled by default. The config files and LDAP settings will be created by ipa-server-install, ipa-server-upgrade and ipa-replica-install. The enabled/disabled switch will be stored per-replica in the cn=masters,cn=ipa,cn=etc tree. An API and CLI tool for management is postponed. [2] For now we settle for some doc examples that use the ipa-ldap-updater as suggested by Alex. [3] open for discussion --- Jan has suggested to ipaConfigString=kdcProxyEnabled in cn=KDC,cn=$FQDN,cn=masters,cn=ipa,cn=etc instead of ipaConfigString=enabledService in cn=KDCPROXY,cn=$FQDN,cn=masters,cn=ipa,cn=etc. It makes sense to me. After all MS-KKDCP is just another transport for the KDC. [4] Martin Basti suggested a different keytab and principal for kdcproxy. [5] The keytab is only required for GSSAPI bind to lookup the state of the enabled/disabled switch. The current patch uses the same keytab as webgui. A new principal separates kdcproxy more cleanly and allows for fine-grained ACIs. It is also more future proof. In the future we may want to move kdcproxy from an Apache WSGI app to a separate service. A dedicated Twisted or asyncio daemon could handle more load. A separate keytab is easy to implement, too. I looked at the code in HTTPInstance.__create_http_keytab(). For the ACI I plan to add a new permission 'System: Read IPA Config String' and make the principal a direct memberOf of it. We don't have service roles yet. cn=roles,cn=accounts look like end user roles to me. The new ACI in cn=masters,cn=ipa,cn=etc will grant read, search and compare permission: (targetfilter = (objectClass=nsContainer))(targetattr = cn || objectClass || ipaConfigString)(version 3.0; acl Read IPA Config String; allow (read, search, compare) groupdn = ldap:///cn=System: Read IPA Config String,cn=permissions,cn=pbac,dc=ipa,dc=example;) I should be able to modify and test my patch in a matter of a couple of hours. Christian [1] http://www.redhat.com/archives/freeipa-devel/2015-May/msg00535.html [2] http://www.redhat.com/archives/freeipa-devel/2015-May/msg00555.html [3] http://www.redhat.com/archives/freeipa-devel/2015-May/msg00533.html [4] http://www.redhat.com/archives/freeipa-devel/2015-May/msg00543.html [5] http://www.redhat.com/archives/freeipa-devel/2015-May/msg00539.html signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] New replica installation and topology - we need stable base
On 05/28/2015 04:07 PM, Simo Sorce wrote: On Thu, 2015-05-28 at 16:02 +0200, Martin Kosek wrote: On 05/28/2015 04:00 PM, Simo Sorce wrote: On Thu, 2015-05-28 at 15:47 +0200, Martin Kosek wrote: On 05/27/2015 04:59 PM, Martin Kosek wrote: ... Domain Levels - Done, committed - Defaults to Level 1, i.e. Topology plugin powered infra enabled With respect to related Simo's response in http://www.redhat.com/archives/freeipa-devel/2015-May/msg00553.html Would we want to enable Topology (i.e. Domain Level 1) even if Replica promotion is not done? I thought we do as I see those as orthogonal features. Replica promotion would take advantage of the Topology plugin, but it does not mean you cannot benefit from Topology plugin without it. You can still use the API to see/manage the topology and set replication settings with it. You do not need Replica Promotion for that... You cannot move for domain level 0 to 1 automatically anyway. So this is a moot point to some degree. In general we need to have the code that checks for the domain level version to be able to change the level, so we need new code in replicas to publish the supported domain level version and code in the install patchs to check that we can actually join a domain given its current domain level status. These checks are absolutely a critical blocker to enable the whole domain-level feature. All the functionality you describe and the checks should be already there. I was really only asking about the default domain level for *new* installations Old/upgraded FreeIPA will be on the Domain Level 0 of course. I think new installation should be on 1 but only if we have decided and finalized what level 1 is. Simo. In my mind, Domain Level 1 means: - Topology plugins is activated for all replicas and manages the agreements - All changes to topology can be only made via topology-* commands - ipa-replica-manage connect|disconnect are not allowed Martin -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] New replica installation and topology - we need stable base
On Thu, 2015-05-28 at 16:02 +0200, Jan Cholasta wrote: f3010498af2a4b98512d219b8e09101176c172fe. This is perfect! Thanks a lot. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Domain level for topology plugin = 2
On Thu, 2015-05-28 at 16:23 +0200, Oleg Fayans wrote: Hi Simo, On 05/28/2015 03:52 PM, Simo Sorce wrote: On Thu, 2015-05-28 at 15:39 +0200, Oleg Fayans wrote: On 05/28/2015 03:26 PM, Simo Sorce wrote: On Thu, 2015-05-28 at 14:11 +0200, Petr Spacek wrote: On 28.5.2015 10:49, Martin Kosek wrote: On 05/28/2015 09:05 AM, Petr Spacek wrote: On 28.5.2015 08:55, Jan Cholasta wrote: Dne 26.5.2015 v 16:32 Petr Spacek napsal(a): On 26.5.2015 16:16, Martin Kosek wrote: On 05/26/2015 04:13 PM, thierry bordaz wrote: On 05/26/2015 02:12 PM, Petr Spacek wrote: Hello, it came to my mind that domain level for topology plugin should actually be number 2, not 1. We already used number 1 for incompatible changes in DNS tree and I believe that it is not a good idea to have two places which say 'version 1' but and actually mean two different things. (DNS tree version 1 + domain level 1) Patch is attached. Hello, The fix looks good but that seems strange to have to set the initial version of the topology plugin to 2.0. (IIUC That is the version that will be written in dse.ldif) I would rather expects that topology plugin 1.0, would activate itself if the DomainLevel is 2.0 or more. If topology plugin 1.0 sets an internal DomainLevel_trigger=2.0 then activate itself if DomainLevel = DomainLevel_trigger. Let's wait for Ludwig feedback. thanks thierry My personal opinion on this is to start with Domain Level 1 regardless. We already solved the DNS forwarders otherwise, with docs, async updates etc. I do not think we will be returning to implementing proper Domain Level support for that anyway. So I rather think that all the Domain Level starts with 0, 1 is unused, 2 is the top one will cause unforeseen issues I would rather like to avoid. I'm more worried about confusion in future. To to me it simply seems easier to bump one integer now than to document and explain (to users new developers) why we have two ones which mean something else. Code-wise it is just an integer. Also, it can simplify logic in future when we decide to do another incompatible change in DNS tree because we will have only one integer to test (instead of checking two separate version attribute in DNS tree domain level). +1, but I think the minimum supported domain level should be 1, not 0, because 0 means the server uses the old DNS schema, which we do not support anymore, right? Good point! It may be a good point, but it does not make the situation easier. You still have RHEL/CentOS 6.x IPA out there, where some of them already support the new DNS forwarders and some don't - and neither of them support Domain Levels - i.e. have Domain Level 0. As I said, I still see more complications with this proposals than benefits... I would argue that it actually helps. If domain level = 1 then we can be *sure* that all replicas support the new DNS semantics. If domain level = 0 then we know nothing (because of patched RHEL 6) and it is a warning sign for diagnostic tools and also us when it comes to debugging. First of all a domain level is something we change *RARELY*, and it is a whole number and it is an all or nothing thing. I do not understand why plugin versions matter at all, plugin version have nothing to do with domain levels. Each plugin *whatever* the version MUST always support at least 2 levels, because every domain you have will have to go through a domain_level transition when a new domain level comes out. Finally no single developer should be allowed to decide on anew domain level, this must be a well ponder team decision as all plugins that need to change behavior based on domain level will be affected so a thorough review of what changes are needed across all plugins must be done every time someone propose a change that requires a domain level bump. Last but not least we should consider domain levels as something that changes *very* slowly, because otherwise you'll have to support many domain levels within any plugins that have to change behavior according to the domain level. I would say that the domain level should not change more frequently than once a year or so. It would be too much code churn to do otherwise. So for now domain_level should be set to 0. And the topology plugin will be enabled only when we turn it to 1. However we shouldn't turn it to 1 until we have the replica promotion code at least, because only then we can make full use of the topology plugins. Does that mean, that by default domain level must be set to 0 and only raised manually by the identity admin? Yes, the domain level is established by the first server you install, and CANNOT be raise automatically by a replica, it must be always manually raised by the admin. Moreover the code that
Re: [Freeipa-devel] Sudorules user validation help
OK, I see now what you mean by that. That is a simpler solution. I'll do it that way. On 05/28/2015 04:44 AM, Martin Kosek wrote: On 05/27/2015 08:41 PM, Drew Erny wrote: Hey, Freeipa-devel, I'm working on ticket #3226 (https://fedorahosted.org/freeipa/ticket/3226) I've identified the problem. The sudorules add user command adds the user validations at the end of it's pre-callback using add_external_pre_callback. However, the user plugin pattern-matches a string for the uid param, because it only allows certain characters. I've been picking through the codebase and I think I have enough understanding to ask this: What if we changed the user uid validation to a standalone rule function (you can do that, right? pass in a function as a validation rule?) that would normally just assert that the pattern matches, but could have that pattern matching validation overridden in some cases. I think that's the easiest, cleanest way to change user so that sudorules and other plugins can ignore this validation if necessary (I'm trying to figure out exactly how to implement this without changing any APIs). Am I understanding the plugin params API correctly, and can I do this? Is this the best way to do this? The only other solution I see is to write sudorules-specific code in some plugin-related (either user.py or baseldap.py module, which would create unwanted coupling. Most specifically, this would be a change to the object instantiated at ipalib/plugins/user.py line 467 Thoughts and suggestions? I think it would make sense to follow the example with validate_hostname and prepare a function validate_username(username, upn=False, netbios_name=False) [1]. where upn would allow using @. on top of current validator (i.e. u...@domain.test) and netbios_name would allow the DOMAIN\user style. I would just suggest making sure the standard user validation error message is still the same to avoid unnecessary QE fail positives. In add_external_pre_callback you could then just simply call validate_username(user, True, True) just like it is already done with hostname. My 2 cents. Martin [1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa380525(v=vs.85).aspx -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0014] Support multiple user and host certificates
On 05/28/2015 02:29 PM, Petr Spacek wrote:
On 28.5.2015 12:06, Fraser Tweedale wrote:
On Thu, May 28, 2015 at 11:52:25AM +0200, Martin Kosek wrote:
On 05/28/2015 11:17 AM, Martin Basti wrote:
On 28/05/15 10:46, Martin Kosek wrote:
On 05/27/2015 06:12 PM, Martin Basti wrote:
On 27/05/15 15:53, Fraser Tweedale wrote:
This patch adds supports for multiple user / host certificates. No
schema change is needed ('usercertificate' attribute is already
multi-value). The revoke-previous-cert behaviour of host-mod and
user-mod has been removed but revocation behaviour of -del and
-disable is preserved.
The latest profiles/caacl patchset (0001..0013 v5) depends on this
patch for correct cert-request behaviour.
There is one design question (or maybe more, let me know): the
`--out=FILENAME' option to {host,service} show saves ONE certificate
to the named file. I propose to either:
a) write all certs, suffixing suggested filename with either a
sequential numerical index, e.g. cert.pem becomes
cert.pem.1, cert.pem.2, and so on; or
b) as above, but suffix with serial number and, if there are
different issues, some issuer-identifying information.
Let me know your thoughts.
Thanks,
Fraser
Is there a possible way how to store certificates into one file?
I read about possibilities to have multiple certs in one .pem file, but
I'm not
cert guru :)
I personally vote for serial number in case there are multiple
certificates, if
^ is no possible.
1)
+if len(certs) 0:
please use only,
if certs:
2)
You need to re-generate API/ACI.txt in this patch
3)
syntax error:
+for dercert in certs_der
4)
command
ipa user-mod ca_user --certificate=ceritifcate
removes the current certificate from the LDAP, by design.
Should be the old certificate(s) revoked? You removed that part in the
code.
Good question. I think the suggestion was to have a global switch in IPA
global
config that would configure the policy - whether the certificates removed
by
this command or by host-del or host-disable are revoked or if they are
just
removed (my motivation is to avoid behavior regression in case somebody
depended on this behavior).
I would prefer to keep the current behavior: revoke the certificate if it
was
replaced or removed, instead of adding an extra configuration option.
This behavior is not regression.
It is not. However, it is not an ideal behavior also. In FreeIPA 4.2, we are
now adding support of certificate profiles, multiple certificates and even
certificates for user.
With that change, there may be much more certificates in play than now. If
we
keep revoking all such certificates, it may cause rapid growth of CRLs.
This is
something I am trying to avoid with this proposal and default to not
revoking
certificates automatically (which mostly only makes sense if there is a risk
that the key is compromised), but have some option to keep the old behavior.
Does this make sense?
I would like to see some data to support the decision not to revoke certs by
default. Are there some facts to base the decision on? Or just hand-wavy
reasoning?
What facts would you like to hear? If we are speaking from bugs, we already
know that large CRL lists caused lot of grief to deployments with bug
host/service turnaround. I do not have more data than this, besides my
expectation that there may be much more certificates tracked by FreeIPA than in
the past and we need to deal with it.
Sure, huge CRL may be bad, but not revoking certs may be even worse. E.g. when
older backup files are stolen (in the information sense, i.e. copied without
anyone noticing it) - attacker might get valid certs despite the fact that the
old cert is never used (because it was rotated right after the backup).
I am not convinced that this is a valid point. We cannot assume that FreeIPA
administrator leaks certificate keys and try to magically fix that by this
policy. Such fault backup can leak even when the host/service still exists.
This is about what makes most sense for certificate handling, what is the
secure behavior and a behavior that most administrators would expect (thus the
default). Are you sure revoking all deleted certificates is the expected
behavior? In my mind, certificates are being revoked from more serious reasons
- when employee leaves a company, machine (or it's backup) is compromised,
etc. But in that case admin would use cert-revoke command.
Let me also CC Rob - do we know why FreeIPA was implemented to revoke all
service/host certificates by default on deletion/disable?
IMHO this behavior should be configurable and default to 'revoke'. We should
ship FreeIPA with secure defaults and let users to lower the standards if they
wish/need.
Petr^2 Spacek
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA:
Re: [Freeipa-devel] New replica installation and topology - we need stable base
On 05/28/2015 04:00 PM, Simo Sorce wrote: On Thu, 2015-05-28 at 15:47 +0200, Martin Kosek wrote: On 05/27/2015 04:59 PM, Martin Kosek wrote: ... Domain Levels - Done, committed - Defaults to Level 1, i.e. Topology plugin powered infra enabled With respect to related Simo's response in http://www.redhat.com/archives/freeipa-devel/2015-May/msg00553.html Would we want to enable Topology (i.e. Domain Level 1) even if Replica promotion is not done? I thought we do as I see those as orthogonal features. Replica promotion would take advantage of the Topology plugin, but it does not mean you cannot benefit from Topology plugin without it. You can still use the API to see/manage the topology and set replication settings with it. You do not need Replica Promotion for that... You cannot move for domain level 0 to 1 automatically anyway. So this is a moot point to some degree. In general we need to have the code that checks for the domain level version to be able to change the level, so we need new code in replicas to publish the supported domain level version and code in the install patchs to check that we can actually join a domain given its current domain level status. These checks are absolutely a critical blocker to enable the whole domain-level feature. All the functionality you describe and the checks should be already there. I was really only asking about the default domain level for *new* installations Old/upgraded FreeIPA will be on the Domain Level 0 of course. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] New replica installation and topology - we need stable base
Dne 28.5.2015 v 16:00 Simo Sorce napsal(a): On Thu, 2015-05-28 at 15:47 +0200, Martin Kosek wrote: On 05/27/2015 04:59 PM, Martin Kosek wrote: ... Domain Levels - Done, committed - Defaults to Level 1, i.e. Topology plugin powered infra enabled With respect to related Simo's response in http://www.redhat.com/archives/freeipa-devel/2015-May/msg00553.html Would we want to enable Topology (i.e. Domain Level 1) even if Replica promotion is not done? I thought we do as I see those as orthogonal features. Replica promotion would take advantage of the Topology plugin, but it does not mean you cannot benefit from Topology plugin without it. You can still use the API to see/manage the topology and set replication settings with it. You do not need Replica Promotion for that... You cannot move for domain level 0 to 1 automatically anyway. So this is a moot point to some degree. In general we need to have the code that checks for the domain level version to be able to change the level, so we need new code in replicas to publish the supported domain level version and code in the install patchs to check that we can actually join a domain given its current domain level status. These checks are absolutely a critical blocker to enable the whole domain-level feature. IIUC this is already done, see commit f3010498af2a4b98512d219b8e09101176c172fe. -- Jan Cholasta -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] New replica installation and topology - we need stable base
On 05/28/2015 04:04 PM, Martin Kosek wrote: On 05/28/2015 04:04 PM, Ludwig Krispenz wrote: On 05/28/2015 04:00 PM, Martin Kosek wrote: On 05/28/2015 03:57 PM, Ludwig Krispenz wrote: On 05/28/2015 03:47 PM, Martin Kosek wrote: On 05/27/2015 04:59 PM, Martin Kosek wrote: ... Domain Levels - Done, committed - Defaults to Level 1, i.e. Topology plugin powered infra enabled With respect to related Simo's response in http://www.redhat.com/archives/freeipa-devel/2015-May/msg00553.html Would we want to enable Topology (i.e. Domain Level 1) even if Replica promotion is not done? who is we ? I thought there is an api to set the domain-level and the admin decides if, or do you mean to have it by default during installation ? The question here is if Topology plugin (i.e. Domain Level 1) shall be enabled during new FreeIPA 4.2 installation or if would be still disabled and only enabled by domain-level-set request. I'm with Simo, this shoul be a deliberate action by an admin, based upon the info that all servers support this domain level Guys, I am really talking about *new* FreeIPA server installation, not upgrades. If you are installing FreeIPA 4.2 server, you already know that *all* servers support Topology as we do not allow installing replica with older version than a server. What do I miss here? well, I was not sure where in the install process you would set the domain level. If you create a 4.2 replica from a 4.1 server and in the instance creation of the 4.2 replica you set the domain level automatically, it depends on when it is done what side effects it will have. but maybe I miss that this already is handled I thought we do as I see those as orthogonal features. Replica promotion would take advantage of the Topology plugin, but it does not mean you cannot benefit from Topology plugin without it. You can still use the API to see/manage the topology and set replication settings with it. You do not need Replica Promotion for that... well, it is not just for viewing, you restrict management to use the ipa-toplogy commands Right. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] New replica installation and topology - we need stable base
On 05/28/2015 04:17 PM, Simo Sorce wrote: On Thu, 2015-05-28 at 16:04 +0200, Martin Kosek wrote: On 05/28/2015 04:04 PM, Ludwig Krispenz wrote: On 05/28/2015 04:00 PM, Martin Kosek wrote: On 05/28/2015 03:57 PM, Ludwig Krispenz wrote: On 05/28/2015 03:47 PM, Martin Kosek wrote: On 05/27/2015 04:59 PM, Martin Kosek wrote: ... Domain Levels - Done, committed - Defaults to Level 1, i.e. Topology plugin powered infra enabled With respect to related Simo's response in http://www.redhat.com/archives/freeipa-devel/2015-May/msg00553.html Would we want to enable Topology (i.e. Domain Level 1) even if Replica promotion is not done? who is we ? I thought there is an api to set the domain-level and the admin decides if, or do you mean to have it by default during installation ? The question here is if Topology plugin (i.e. Domain Level 1) shall be enabled during new FreeIPA 4.2 installation or if would be still disabled and only enabled by domain-level-set request. I'm with Simo, this shoul be a deliberate action by an admin, based upon the info that all servers support this domain level Guys, I am really talking about *new* FreeIPA server installation, not upgrades. If you are installing FreeIPA 4.2 server, you already know that *all* servers support Topology as we do not allow installing replica with older version than a server. What do I miss here? I think the only thing that may be missing is that the current installer still does the dance of using SSL and then later transitioning to GSSAPI, I am not sure the topology plugin copes with that. yes, it works with the current installer (except for bugs) Ludwig, can you comment ? Simo. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0014] Support multiple user and host certificates
On Thu, 2015-05-28 at 15:43 +0200, Martin Kosek wrote:
On 05/28/2015 02:29 PM, Petr Spacek wrote:
On 28.5.2015 12:06, Fraser Tweedale wrote:
On Thu, May 28, 2015 at 11:52:25AM +0200, Martin Kosek wrote:
On 05/28/2015 11:17 AM, Martin Basti wrote:
On 28/05/15 10:46, Martin Kosek wrote:
On 05/27/2015 06:12 PM, Martin Basti wrote:
On 27/05/15 15:53, Fraser Tweedale wrote:
This patch adds supports for multiple user / host certificates. No
schema change is needed ('usercertificate' attribute is already
multi-value). The revoke-previous-cert behaviour of host-mod and
user-mod has been removed but revocation behaviour of -del and
-disable is preserved.
The latest profiles/caacl patchset (0001..0013 v5) depends on this
patch for correct cert-request behaviour.
There is one design question (or maybe more, let me know): the
`--out=FILENAME' option to {host,service} show saves ONE certificate
to the named file. I propose to either:
a) write all certs, suffixing suggested filename with either a
sequential numerical index, e.g. cert.pem becomes
cert.pem.1, cert.pem.2, and so on; or
b) as above, but suffix with serial number and, if there are
different issues, some issuer-identifying information.
Let me know your thoughts.
Thanks,
Fraser
Is there a possible way how to store certificates into one file?
I read about possibilities to have multiple certs in one .pem file,
but I'm not
cert guru :)
I personally vote for serial number in case there are multiple
certificates, if
^ is no possible.
1)
+if len(certs) 0:
please use only,
if certs:
2)
You need to re-generate API/ACI.txt in this patch
3)
syntax error:
+for dercert in certs_der
4)
command
ipa user-mod ca_user --certificate=ceritifcate
removes the current certificate from the LDAP, by design.
Should be the old certificate(s) revoked? You removed that part in the
code.
Good question. I think the suggestion was to have a global switch in
IPA global
config that would configure the policy - whether the certificates
removed by
this command or by host-del or host-disable are revoked or if they are
just
removed (my motivation is to avoid behavior regression in case somebody
depended on this behavior).
I would prefer to keep the current behavior: revoke the certificate if
it was
replaced or removed, instead of adding an extra configuration option.
This behavior is not regression.
It is not. However, it is not an ideal behavior also. In FreeIPA 4.2, we
are
now adding support of certificate profiles, multiple certificates and even
certificates for user.
With that change, there may be much more certificates in play than now.
If we
keep revoking all such certificates, it may cause rapid growth of CRLs.
This is
something I am trying to avoid with this proposal and default to not
revoking
certificates automatically (which mostly only makes sense if there is a
risk
that the key is compromised), but have some option to keep the old
behavior.
Does this make sense?
I would like to see some data to support the decision not to revoke certs by
default. Are there some facts to base the decision on? Or just hand-wavy
reasoning?
What facts would you like to hear? If we are speaking from bugs, we already
know that large CRL lists caused lot of grief to deployments with bug
host/service turnaround. I do not have more data than this, besides my
expectation that there may be much more certificates tracked by FreeIPA than
in
the past and we need to deal with it.
Sure, huge CRL may be bad, but not revoking certs may be even worse. E.g.
when
older backup files are stolen (in the information sense, i.e. copied without
anyone noticing it) - attacker might get valid certs despite the fact that
the
old cert is never used (because it was rotated right after the backup).
I am not convinced that this is a valid point. We cannot assume that FreeIPA
administrator leaks certificate keys and try to magically fix that by this
policy. Such fault backup can leak even when the host/service still exists.
This is about what makes most sense for certificate handling, what is the
secure behavior and a behavior that most administrators would expect (thus the
default). Are you sure revoking all deleted certificates is the expected
behavior? In my mind, certificates are being revoked from more serious reasons
- when employee leaves a company, machine (or it's backup) is compromised,
etc. But in that case admin would use cert-revoke command.
Let me also CC Rob - do we know why FreeIPA was implemented to revoke all
service/host certificates by default on deletion/disable?
+1 Martin, by default you assume minimally competent admins that do not
leak private key. If you cannot assume that then you have already lost,
revoking certs will
Re: [Freeipa-devel] New replica installation and topology - we need stable base
On 05/28/2015 03:47 PM, Martin Kosek wrote: On 05/27/2015 04:59 PM, Martin Kosek wrote: ... Domain Levels - Done, committed - Defaults to Level 1, i.e. Topology plugin powered infra enabled With respect to related Simo's response in http://www.redhat.com/archives/freeipa-devel/2015-May/msg00553.html Would we want to enable Topology (i.e. Domain Level 1) even if Replica promotion is not done? who is we ? I thought there is an api to set the domain-level and the admin decides if, or do you mean to have it by default during installation ? I thought we do as I see those as orthogonal features. Replica promotion would take advantage of the Topology plugin, but it does not mean you cannot benefit from Topology plugin without it. You can still use the API to see/manage the topology and set replication settings with it. You do not need Replica Promotion for that... well, it is not just for viewing, you restrict management to use the ipa-toplogy commands -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0014] Support multiple user and host certificates
On 28.5.2015 15:43, Martin Kosek wrote:
On 05/28/2015 02:29 PM, Petr Spacek wrote:
On 28.5.2015 12:06, Fraser Tweedale wrote:
On Thu, May 28, 2015 at 11:52:25AM +0200, Martin Kosek wrote:
On 05/28/2015 11:17 AM, Martin Basti wrote:
On 28/05/15 10:46, Martin Kosek wrote:
On 05/27/2015 06:12 PM, Martin Basti wrote:
On 27/05/15 15:53, Fraser Tweedale wrote:
This patch adds supports for multiple user / host certificates. No
schema change is needed ('usercertificate' attribute is already
multi-value). The revoke-previous-cert behaviour of host-mod and
user-mod has been removed but revocation behaviour of -del and
-disable is preserved.
The latest profiles/caacl patchset (0001..0013 v5) depends on this
patch for correct cert-request behaviour.
There is one design question (or maybe more, let me know): the
`--out=FILENAME' option to {host,service} show saves ONE certificate
to the named file. I propose to either:
a) write all certs, suffixing suggested filename with either a
sequential numerical index, e.g. cert.pem becomes
cert.pem.1, cert.pem.2, and so on; or
b) as above, but suffix with serial number and, if there are
different issues, some issuer-identifying information.
Let me know your thoughts.
Thanks,
Fraser
Is there a possible way how to store certificates into one file?
I read about possibilities to have multiple certs in one .pem file, but
I'm not
cert guru :)
I personally vote for serial number in case there are multiple
certificates, if
^ is no possible.
1)
+if len(certs) 0:
please use only,
if certs:
2)
You need to re-generate API/ACI.txt in this patch
3)
syntax error:
+for dercert in certs_der
4)
command
ipa user-mod ca_user --certificate=ceritifcate
removes the current certificate from the LDAP, by design.
Should be the old certificate(s) revoked? You removed that part in the
code.
Good question. I think the suggestion was to have a global switch in IPA
global
config that would configure the policy - whether the certificates
removed by
this command or by host-del or host-disable are revoked or if they are
just
removed (my motivation is to avoid behavior regression in case somebody
depended on this behavior).
I would prefer to keep the current behavior: revoke the certificate if it
was
replaced or removed, instead of adding an extra configuration option.
This behavior is not regression.
It is not. However, it is not an ideal behavior also. In FreeIPA 4.2, we
are
now adding support of certificate profiles, multiple certificates and even
certificates for user.
With that change, there may be much more certificates in play than now. If
we
keep revoking all such certificates, it may cause rapid growth of CRLs.
This is
something I am trying to avoid with this proposal and default to not
revoking
certificates automatically (which mostly only makes sense if there is a
risk
that the key is compromised), but have some option to keep the old
behavior.
Does this make sense?
I would like to see some data to support the decision not to revoke certs by
default. Are there some facts to base the decision on? Or just hand-wavy
reasoning?
What facts would you like to hear? If we are speaking from bugs, we already
know that large CRL lists caused lot of grief to deployments with bug
host/service turnaround.
We had bugs about big CRLs is good enough. I wanted to be sure that this is
not a premature optimization.
I do not have more data than this, besides my
expectation that there may be much more certificates tracked by FreeIPA than
in
the past and we need to deal with it.
Sure, huge CRL may be bad, but not revoking certs may be even worse. E.g.
when
older backup files are stolen (in the information sense, i.e. copied without
anyone noticing it) - attacker might get valid certs despite the fact that
the
old cert is never used (because it was rotated right after the backup).
I am not convinced that this is a valid point. We cannot assume that FreeIPA
administrator leaks certificate keys and try to magically fix that by this
policy. Such fault backup can leak even when the host/service still exists.
This is about what makes most sense for certificate handling, what is the
secure behavior and a behavior that most administrators would expect (thus the
default). Are you sure revoking all deleted certificates is the expected
behavior? In my mind, certificates are being revoked from more serious reasons
- when employee leaves a company, machine (or it's backup) is compromised,
etc. But in that case admin would use cert-revoke command.
Let me also CC Rob - do we know why FreeIPA was implemented to revoke all
service/host certificates by default on deletion/disable?
I'm curious too. My expectation is that if admin deletes a user then the user
cannot use his password for authentication anymore, even if admin did not use
user-lock command
Re: [Freeipa-devel] New replica installation and topology - we need stable base
On Thu, 2015-05-28 at 15:47 +0200, Martin Kosek wrote: On 05/27/2015 04:59 PM, Martin Kosek wrote: ... Domain Levels - Done, committed - Defaults to Level 1, i.e. Topology plugin powered infra enabled With respect to related Simo's response in http://www.redhat.com/archives/freeipa-devel/2015-May/msg00553.html Would we want to enable Topology (i.e. Domain Level 1) even if Replica promotion is not done? I thought we do as I see those as orthogonal features. Replica promotion would take advantage of the Topology plugin, but it does not mean you cannot benefit from Topology plugin without it. You can still use the API to see/manage the topology and set replication settings with it. You do not need Replica Promotion for that... You cannot move for domain level 0 to 1 automatically anyway. So this is a moot point to some degree. In general we need to have the code that checks for the domain level version to be able to change the level, so we need new code in replicas to publish the supported domain level version and code in the install patchs to check that we can actually join a domain given its current domain level status. These checks are absolutely a critical blocker to enable the whole domain-level feature. Simo. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] New replica installation and topology - we need stable base
On 05/28/2015 03:57 PM, Ludwig Krispenz wrote: On 05/28/2015 03:47 PM, Martin Kosek wrote: On 05/27/2015 04:59 PM, Martin Kosek wrote: ... Domain Levels - Done, committed - Defaults to Level 1, i.e. Topology plugin powered infra enabled With respect to related Simo's response in http://www.redhat.com/archives/freeipa-devel/2015-May/msg00553.html Would we want to enable Topology (i.e. Domain Level 1) even if Replica promotion is not done? who is we ? I thought there is an api to set the domain-level and the admin decides if, or do you mean to have it by default during installation ? The question here is if Topology plugin (i.e. Domain Level 1) shall be enabled during new FreeIPA 4.2 installation or if would be still disabled and only enabled by domain-level-set request. I thought we do as I see those as orthogonal features. Replica promotion would take advantage of the Topology plugin, but it does not mean you cannot benefit from Topology plugin without it. You can still use the API to see/manage the topology and set replication settings with it. You do not need Replica Promotion for that... well, it is not just for viewing, you restrict management to use the ipa-toplogy commands Right. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] New replica installation and topology - we need stable base
On Thu, 2015-05-28 at 16:02 +0200, Martin Kosek wrote: On 05/28/2015 04:00 PM, Simo Sorce wrote: On Thu, 2015-05-28 at 15:47 +0200, Martin Kosek wrote: On 05/27/2015 04:59 PM, Martin Kosek wrote: ... Domain Levels - Done, committed - Defaults to Level 1, i.e. Topology plugin powered infra enabled With respect to related Simo's response in http://www.redhat.com/archives/freeipa-devel/2015-May/msg00553.html Would we want to enable Topology (i.e. Domain Level 1) even if Replica promotion is not done? I thought we do as I see those as orthogonal features. Replica promotion would take advantage of the Topology plugin, but it does not mean you cannot benefit from Topology plugin without it. You can still use the API to see/manage the topology and set replication settings with it. You do not need Replica Promotion for that... You cannot move for domain level 0 to 1 automatically anyway. So this is a moot point to some degree. In general we need to have the code that checks for the domain level version to be able to change the level, so we need new code in replicas to publish the supported domain level version and code in the install patchs to check that we can actually join a domain given its current domain level status. These checks are absolutely a critical blocker to enable the whole domain-level feature. All the functionality you describe and the checks should be already there. I was really only asking about the default domain level for *new* installations Old/upgraded FreeIPA will be on the Domain Level 0 of course. I think new installation should be on 1 but only if we have decided and finalized what level 1 is. Simo. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Domain level for topology plugin = 2
On 28/05/15 16:29, Simo Sorce wrote: On Thu, 2015-05-28 at 16:23 +0200, Oleg Fayans wrote: Hi Simo, On 05/28/2015 03:52 PM, Simo Sorce wrote: On Thu, 2015-05-28 at 15:39 +0200, Oleg Fayans wrote: On 05/28/2015 03:26 PM, Simo Sorce wrote: On Thu, 2015-05-28 at 14:11 +0200, Petr Spacek wrote: On 28.5.2015 10:49, Martin Kosek wrote: On 05/28/2015 09:05 AM, Petr Spacek wrote: On 28.5.2015 08:55, Jan Cholasta wrote: Dne 26.5.2015 v 16:32 Petr Spacek napsal(a): On 26.5.2015 16:16, Martin Kosek wrote: On 05/26/2015 04:13 PM, thierry bordaz wrote: On 05/26/2015 02:12 PM, Petr Spacek wrote: Hello, it came to my mind that domain level for topology plugin should actually be number 2, not 1. We already used number 1 for incompatible changes in DNS tree and I believe that it is not a good idea to have two places which say 'version 1' but and actually mean two different things. (DNS tree version 1 + domain level 1) Patch is attached. Hello, The fix looks good but that seems strange to have to set the initial version of the topology plugin to 2.0. (IIUC That is the version that will be written in dse.ldif) I would rather expects that topology plugin 1.0, would activate itself if the DomainLevel is 2.0 or more. If topology plugin 1.0 sets an internal DomainLevel_trigger=2.0 then activate itself if DomainLevel = DomainLevel_trigger. Let's wait for Ludwig feedback. thanks thierry My personal opinion on this is to start with Domain Level 1 regardless. We already solved the DNS forwarders otherwise, with docs, async updates etc. I do not think we will be returning to implementing proper Domain Level support for that anyway. So I rather think that all the Domain Level starts with 0, 1 is unused, 2 is the top one will cause unforeseen issues I would rather like to avoid. I'm more worried about confusion in future. To to me it simply seems easier to bump one integer now than to document and explain (to users new developers) why we have two ones which mean something else. Code-wise it is just an integer. Also, it can simplify logic in future when we decide to do another incompatible change in DNS tree because we will have only one integer to test (instead of checking two separate version attribute in DNS tree domain level). +1, but I think the minimum supported domain level should be 1, not 0, because 0 means the server uses the old DNS schema, which we do not support anymore, right? Good point! It may be a good point, but it does not make the situation easier. You still have RHEL/CentOS 6.x IPA out there, where some of them already support the new DNS forwarders and some don't - and neither of them support Domain Levels - i.e. have Domain Level 0. As I said, I still see more complications with this proposals than benefits... I would argue that it actually helps. If domain level = 1 then we can be *sure* that all replicas support the new DNS semantics. If domain level = 0 then we know nothing (because of patched RHEL 6) and it is a warning sign for diagnostic tools and also us when it comes to debugging. First of all a domain level is something we change *RARELY*, and it is a whole number and it is an all or nothing thing. I do not understand why plugin versions matter at all, plugin version have nothing to do with domain levels. Each plugin *whatever* the version MUST always support at least 2 levels, because every domain you have will have to go through a domain_level transition when a new domain level comes out. Finally no single developer should be allowed to decide on anew domain level, this must be a well ponder team decision as all plugins that need to change behavior based on domain level will be affected so a thorough review of what changes are needed across all plugins must be done every time someone propose a change that requires a domain level bump. Last but not least we should consider domain levels as something that changes *very* slowly, because otherwise you'll have to support many domain levels within any plugins that have to change behavior according to the domain level. I would say that the domain level should not change more frequently than once a year or so. It would be too much code churn to do otherwise. So for now domain_level should be set to 0. And the topology plugin will be enabled only when we turn it to 1. However we shouldn't turn it to 1 until we have the replica promotion code at least, because only then we can make full use of the topology plugins. Does that mean, that by default domain level must be set to 0 and only raised manually by the identity admin? Yes, the domain level is established by the first server you install, and CANNOT be raise automatically by a replica, it must be always manually raised by the admin. Moreover the code that raises *MUST* check that all server are capable of handling the new domain level or refuse to raise the level. This means all servers must publish the range of domain levels they support, a missing range means
Re: [Freeipa-devel] Domain level for topology plugin = 2
On Thu, 2015-05-28 at 15:54 +0200, Ludwig Krispenz wrote: On 05/28/2015 03:26 PM, Simo Sorce wrote: On Thu, 2015-05-28 at 14:11 +0200, Petr Spacek wrote: On 28.5.2015 10:49, Martin Kosek wrote: On 05/28/2015 09:05 AM, Petr Spacek wrote: On 28.5.2015 08:55, Jan Cholasta wrote: Dne 26.5.2015 v 16:32 Petr Spacek napsal(a): On 26.5.2015 16:16, Martin Kosek wrote: On 05/26/2015 04:13 PM, thierry bordaz wrote: On 05/26/2015 02:12 PM, Petr Spacek wrote: Hello, it came to my mind that domain level for topology plugin should actually be number 2, not 1. We already used number 1 for incompatible changes in DNS tree and I believe that it is not a good idea to have two places which say 'version 1' but and actually mean two different things. (DNS tree version 1 + domain level 1) Patch is attached. Hello, The fix looks good but that seems strange to have to set the initial version of the topology plugin to 2.0. (IIUC That is the version that will be written in dse.ldif) I would rather expects that topology plugin 1.0, would activate itself if the DomainLevel is 2.0 or more. If topology plugin 1.0 sets an internal DomainLevel_trigger=2.0 then activate itself if DomainLevel = DomainLevel_trigger. Let's wait for Ludwig feedback. thanks thierry My personal opinion on this is to start with Domain Level 1 regardless. We already solved the DNS forwarders otherwise, with docs, async updates etc. I do not think we will be returning to implementing proper Domain Level support for that anyway. So I rather think that all the Domain Level starts with 0, 1 is unused, 2 is the top one will cause unforeseen issues I would rather like to avoid. I'm more worried about confusion in future. To to me it simply seems easier to bump one integer now than to document and explain (to users new developers) why we have two ones which mean something else. Code-wise it is just an integer. Also, it can simplify logic in future when we decide to do another incompatible change in DNS tree because we will have only one integer to test (instead of checking two separate version attribute in DNS tree domain level). +1, but I think the minimum supported domain level should be 1, not 0, because 0 means the server uses the old DNS schema, which we do not support anymore, right? Good point! It may be a good point, but it does not make the situation easier. You still have RHEL/CentOS 6.x IPA out there, where some of them already support the new DNS forwarders and some don't - and neither of them support Domain Levels - i.e. have Domain Level 0. As I said, I still see more complications with this proposals than benefits... I would argue that it actually helps. If domain level = 1 then we can be *sure* that all replicas support the new DNS semantics. If domain level = 0 then we know nothing (because of patched RHEL 6) and it is a warning sign for diagnostic tools and also us when it comes to debugging. First of all a domain level is something we change *RARELY*, and it is a whole number and it is an all or nothing thing. I do not understand why plugin versions matter at all, plugin version have nothing to do with domain levels. Each plugin *whatever* the version MUST always support at least 2 levels, because every domain you have will have to go through a domain_level transition when a new domain level comes out. Finally no single developer should be allowed to decide on anew domain level, this must be a well ponder team decision as all plugins that need to change behavior based on domain level will be affected so a thorough review of what changes are needed across all plugins must be done every time someone propose a change that requires a domain level bump. Last but not least we should consider domain levels as something that changes *very* slowly, because otherwise you'll have to support many domain levels within any plugins that have to change behavior according to the domain level. I would say that the domain level should not change more frequently than once a year or so. It would be too much code churn to do otherwise. So for now domain_level should be set to 0. And the topology plugin will be enabled only when we turn it to 1. However we shouldn't turn it to 1 until we have the replica promotion code at least, because only then we can make full use of the topology plugins. The DNS mess is unfixable, unless Petr you volunteer to backport code to change the behavior of the DNS based on the domain level, if that's the case then you can tie old behavior to level 0 and new behavior to level = 1, but I do not think you want to do that given we already have level 0 servers that sport the new code and changed the data in the directory, so let's just ignore DNS for the purpose of this
Re: [Freeipa-devel] KDC proxy implementation specs
On Thu, 2015-05-28 at 10:48 -0400, Nathaniel McCallum wrote: On Thu, 2015-05-28 at 16:34 +0200, Christian Heimes wrote: Hello, thanks you for your input. The former thread has 58 messages in total. Since last Friday we have came to an agreement in most points. I like to some up our decisions and focus on some minor details. decisions - python-kdcproxy will be installed as a dependency of freeipa-server. There won't be a separate freeipa-server-kdcproxy package. That may or may not change in the future. The decision is out of scope for 4.2.0. [1] KDC proxy support will be enabled by default. The config files and LDAP settings will be created by ipa-server-install, ipa-server-upgrade and ipa-replica-install. The enabled/disabled switch will be stored per-replica in the cn=masters,cn=ipa,cn=etc tree. An API and CLI tool for management is postponed. [2] For now we settle for some doc examples that use the ipa-ldap-updater as suggested by Alex. [3] open for discussion --- Jan has suggested to ipaConfigString=kdcProxyEnabled in cn=KDC,cn=$FQDN,cn=masters,cn=ipa,cn=etc instead of ipaConfigString=enabledService in cn=KDCPROXY,cn=$FQDN,cn=masters,cn=ipa,cn=etc. It makes sense to me. After all MS-KKDCP is just another transport for the KDC. [4] There may be a security concern here if we aren't careful. I think I'm in favor of KDCPROXY since it is a different application. Martin Basti suggested a different keytab and principal for kdcproxy. [5] The keytab is only required for GSSAPI bind to lookup the state of the enabled/disabled switch. The current patch uses the same keytab as webgui. A new principal separates kdcproxy more cleanly and allows for fine-grained ACIs. It is also more future proof. It may also have auditing benefits now that we are beginning to think about the A in FreeIPA. We can't have 2 different keytabs with the same principal name. If we need privilege separation we'll have to work on integrating GSS-Proxy and give the keytab only to GSS-Proxy leaving it off the hands of both the framework, the proxy, and apache itself. Although to be honest I do not see why the proxy need access to the keytab at all, can we simply run it as a wsgi application under a different user and prevent it from accessing the apache keytab at all ? In the future we may want to move kdcproxy from an Apache WSGI app to a separate service. A dedicated Twisted or asyncio daemon could handle more load. A separate keytab is easy to implement, too. I looked at the code in HTTPInstance.__create_http_keytab(). An apache module would also provide similar benefits. I'm not sure I necessarily want to stick with python here if we're optimizing for performance. Another option would be to add it to the KDC itself and proxy through Apache like we do for Tomcat. MIT might like that option. What do we need the keytab for ? Is it just in order to authenticate and read if the service is enabled ? Can we make that information available anonymously ? For the ACI I plan to add a new permission 'System: Read IPA Config String' and make the principal a direct memberOf of it. We don't have service roles yet. cn=roles,cn=accounts look like end user roles to me. The new ACI in cn=masters,cn=ipa,cn=etc will grant read, search and compare permission: (targetfilter = (objectClass=nsContainer))(targetattr = cn || objectClass || ipaConfigString)(version 3.0; acl Read IPA Config String; allow (read, search, compare) groupdn = ldap:///cn=System: Read IPA Config String,cn=permissions,cn=pbac,dc=ipa,dc=example;) I should be able to modify and test my patch in a matter of a couple of hours. Christian [1] http://www.redhat.com/archives/freeipa-devel/2015-May/msg00535.html [2] http://www.redhat.com/archives/freeipa-devel/2015-May/msg00555.html [3] http://www.redhat.com/archives/freeipa-devel/2015-May/msg00533.html [4] http://www.redhat.com/archives/freeipa-devel/2015-May/msg00543.html [5] http://www.redhat.com/archives/freeipa-devel/2015-May/msg00539.html -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Domain level for topology plugin = 2
On Thu, 2015-05-28 at 10:46 -0400, Simo Sorce wrote: On Thu, 2015-05-28 at 15:54 +0200, Ludwig Krispenz wrote: On 05/28/2015 03:26 PM, Simo Sorce wrote: On Thu, 2015-05-28 at 14:11 +0200, Petr Spacek wrote: On 28.5.2015 10:49, Martin Kosek wrote: On 05/28/2015 09:05 AM, Petr Spacek wrote: On 28.5.2015 08:55, Jan Cholasta wrote: Dne 26.5.2015 v 16:32 Petr Spacek napsal(a): On 26.5.2015 16:16, Martin Kosek wrote: On 05/26/2015 04:13 PM, thierry bordaz wrote: On 05/26/2015 02:12 PM, Petr Spacek wrote: Hello, it came to my mind that domain level for topology plugin should actually be number 2, not 1. We already used number 1 for incompatible changes in DNS tree and I believe that it is not a good idea to have two places which say 'version 1' but and actually mean two different things. (DNS tree version 1 + domain level 1) Patch is attached. Hello, The fix looks good but that seems strange to have to set the initial version of the topology plugin to 2.0. (IIUC That is the version that will be written in dse.ldif) I would rather expects that topology plugin 1.0, would activate itself if the DomainLevel is 2.0 or more. If topology plugin 1.0 sets an internal DomainLevel_trigger=2.0 then activate itself if DomainLevel = DomainLevel_trigger. Let's wait for Ludwig feedback. thanks thierry My personal opinion on this is to start with Domain Level 1 regardless. We already solved the DNS forwarders otherwise, with docs, async updates etc. I do not think we will be returning to implementing proper Domain Level support for that anyway. So I rather think that all the Domain Level starts with 0, 1 is unused, 2 is the top one will cause unforeseen issues I would rather like to avoid. I'm more worried about confusion in future. To to me it simply seems easier to bump one integer now than to document and explain (to users new developers) why we have two ones which mean something else. Code-wise it is just an integer. Also, it can simplify logic in future when we decide to do another incompatible change in DNS tree because we will have only one integer to test (instead of checking two separate version attribute in DNS tree domain level). +1, but I think the minimum supported domain level should be 1, not 0, because 0 means the server uses the old DNS schema, which we do not support anymore, right? Good point! It may be a good point, but it does not make the situation easier. You still have RHEL/CentOS 6.x IPA out there, where some of them already support the new DNS forwarders and some don't - and neither of them support Domain Levels - i.e. have Domain Level 0. As I said, I still see more complications with this proposals than benefits... I would argue that it actually helps. If domain level = 1 then we can be *sure* that all replicas support the new DNS semantics. If domain level = 0 then we know nothing (because of patched RHEL 6) and it is a warning sign for diagnostic tools and also us when it comes to debugging. First of all a domain level is something we change *RARELY*, and it is a whole number and it is an all or nothing thing. I do not understand why plugin versions matter at all, plugin version have nothing to do with domain levels. Each plugin *whatever* the version MUST always support at least 2 levels, because every domain you have will have to go through a domain_level transition when a new domain level comes out. Finally no single developer should be allowed to decide on anew domain level, this must be a well ponder team decision as all plugins that need to change behavior based on domain level will be affected so a thorough review of what changes are needed across all plugins must be done every time someone propose a change that requires a domain level bump. Last but not least we should consider domain levels as something that changes *very* slowly, because otherwise you'll have to support many domain levels within any plugins that have to change behavior according to the domain level. I would say that the domain level should not change more frequently than once a year or so. It would be too much code churn to do otherwise. So for now domain_level should be set to 0. And the topology plugin will be enabled only when we turn it to 1. However we shouldn't turn it to 1 until we have the replica promotion code at least, because only then we can make full use of the topology plugins. The DNS mess is unfixable, unless Petr you volunteer to backport code to change the behavior of the DNS based on the domain level, if that's the case then you can tie old behavior to level 0 and new behavior to level = 1, but I
Re: [Freeipa-devel] New replica installation and topology - we need stable base
On Thu, 2015-05-28 at 16:14 +0200, Martin Kosek wrote: On 05/28/2015 04:07 PM, Simo Sorce wrote: On Thu, 2015-05-28 at 16:02 +0200, Martin Kosek wrote: On 05/28/2015 04:00 PM, Simo Sorce wrote: On Thu, 2015-05-28 at 15:47 +0200, Martin Kosek wrote: On 05/27/2015 04:59 PM, Martin Kosek wrote: ... Domain Levels - Done, committed - Defaults to Level 1, i.e. Topology plugin powered infra enabled With respect to related Simo's response in http://www.redhat.com/archives/freeipa-devel/2015-May/msg00553.html Would we want to enable Topology (i.e. Domain Level 1) even if Replica promotion is not done? I thought we do as I see those as orthogonal features. Replica promotion would take advantage of the Topology plugin, but it does not mean you cannot benefit from Topology plugin without it. You can still use the API to see/manage the topology and set replication settings with it. You do not need Replica Promotion for that... You cannot move for domain level 0 to 1 automatically anyway. So this is a moot point to some degree. In general we need to have the code that checks for the domain level version to be able to change the level, so we need new code in replicas to publish the supported domain level version and code in the install patchs to check that we can actually join a domain given its current domain level status. These checks are absolutely a critical blocker to enable the whole domain-level feature. All the functionality you describe and the checks should be already there. I was really only asking about the default domain level for *new* installations Old/upgraded FreeIPA will be on the Domain Level 0 of course. I think new installation should be on 1 but only if we have decided and finalized what level 1 is. Simo. In my mind, Domain Level 1 means: - Topology plugins is activated for all replicas and manages the agreements - All changes to topology can be only made via topology-* commands - ipa-replica-manage connect|disconnect are not allowed Ok, if we want to restrict it to this then fine. In my original plan level 1 also meant the KISS/Custodia service is available on all master. If not then we cannot depend on it and we cannot fully finish the work on replica promotion w/o requiring the replica package anymore. Simo. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] KDC proxy implementation specs
On 2015-05-28 16:53, Simo Sorce wrote: We can't have 2 different keytabs with the same principal name. If we need privilege separation we'll have to work on integrating GSS-Proxy and give the keytab only to GSS-Proxy leaving it off the hands of both the framework, the proxy, and apache itself. I had a different principal like KDCPROXY/fqdn@realm in mind. Although to be honest I do not see why the proxy need access to the keytab at all, can we simply run it as a wsgi application under a different user and prevent it from accessing the apache keytab at all ? Yes, mod_wsgi is able to run a WSGI app as a different user: https://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIDaemonProcess A different user needs another location for the ccache and perhaps additional SELinux rules. What do we need the keytab for ? Is it just in order to authenticate and read if the service is enabled ? Can we make that information available anonymously ? Yes, the information is not available for anon bind. It doesn't feel right to disclose the settings to the public. Christian signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Domain level for topology plugin = 2
On 05/28/2015 04:46 PM, Simo Sorce wrote: On Thu, 2015-05-28 at 15:54 +0200, Ludwig Krispenz wrote: On 05/28/2015 03:26 PM, Simo Sorce wrote: On Thu, 2015-05-28 at 14:11 +0200, Petr Spacek wrote: On 28.5.2015 10:49, Martin Kosek wrote: On 05/28/2015 09:05 AM, Petr Spacek wrote: On 28.5.2015 08:55, Jan Cholasta wrote: Dne 26.5.2015 v 16:32 Petr Spacek napsal(a): On 26.5.2015 16:16, Martin Kosek wrote: On 05/26/2015 04:13 PM, thierry bordaz wrote: On 05/26/2015 02:12 PM, Petr Spacek wrote: Hello, it came to my mind that domain level for topology plugin should actually be number 2, not 1. We already used number 1 for incompatible changes in DNS tree and I believe that it is not a good idea to have two places which say 'version 1' but and actually mean two different things. (DNS tree version 1 + domain level 1) Patch is attached. Hello, The fix looks good but that seems strange to have to set the initial version of the topology plugin to 2.0. (IIUC That is the version that will be written in dse.ldif) I would rather expects that topology plugin 1.0, would activate itself if the DomainLevel is 2.0 or more. If topology plugin 1.0 sets an internal DomainLevel_trigger=2.0 then activate itself if DomainLevel = DomainLevel_trigger. Let's wait for Ludwig feedback. thanks thierry My personal opinion on this is to start with Domain Level 1 regardless. We already solved the DNS forwarders otherwise, with docs, async updates etc. I do not think we will be returning to implementing proper Domain Level support for that anyway. So I rather think that all the Domain Level starts with 0, 1 is unused, 2 is the top one will cause unforeseen issues I would rather like to avoid. I'm more worried about confusion in future. To to me it simply seems easier to bump one integer now than to document and explain (to users new developers) why we have two ones which mean something else. Code-wise it is just an integer. Also, it can simplify logic in future when we decide to do another incompatible change in DNS tree because we will have only one integer to test (instead of checking two separate version attribute in DNS tree domain level). +1, but I think the minimum supported domain level should be 1, not 0, because 0 means the server uses the old DNS schema, which we do not support anymore, right? Good point! It may be a good point, but it does not make the situation easier. You still have RHEL/CentOS 6.x IPA out there, where some of them already support the new DNS forwarders and some don't - and neither of them support Domain Levels - i.e. have Domain Level 0. As I said, I still see more complications with this proposals than benefits... I would argue that it actually helps. If domain level = 1 then we can be *sure* that all replicas support the new DNS semantics. If domain level = 0 then we know nothing (because of patched RHEL 6) and it is a warning sign for diagnostic tools and also us when it comes to debugging. First of all a domain level is something we change *RARELY*, and it is a whole number and it is an all or nothing thing. I do not understand why plugin versions matter at all, plugin version have nothing to do with domain levels. Each plugin *whatever* the version MUST always support at least 2 levels, because every domain you have will have to go through a domain_level transition when a new domain level comes out. Finally no single developer should be allowed to decide on anew domain level, this must be a well ponder team decision as all plugins that need to change behavior based on domain level will be affected so a thorough review of what changes are needed across all plugins must be done every time someone propose a change that requires a domain level bump. Last but not least we should consider domain levels as something that changes *very* slowly, because otherwise you'll have to support many domain levels within any plugins that have to change behavior according to the domain level. I would say that the domain level should not change more frequently than once a year or so. It would be too much code churn to do otherwise. So for now domain_level should be set to 0. And the topology plugin will be enabled only when we turn it to 1. However we shouldn't turn it to 1 until we have the replica promotion code at least, because only then we can make full use of the topology plugins. The DNS mess is unfixable, unless Petr you volunteer to backport code to change the behavior of the DNS based on the domain level, if that's the case then you can tie old behavior to level 0 and new behavior to level = 1, but I do not think you want to do that given we already have level 0 servers that sport the new code and changed the data in the directory, so let's just ignore DNS for the purpose of this discussion, except for nothing that once we finally switch to level 1 then all servers must be running with the newer DNS schema and older is not supported. Ah, I almost forgot, there is no
Re: [Freeipa-devel] KDC proxy implementation specs
On 2015-05-28 16:48, Nathaniel McCallum wrote: An apache module would also provide similar benefits. I'm not sure I necessarily want to stick with python here if we're optimizing for performance. Another option would be to add it to the KDC itself and proxy through Apache like we do for Tomcat. MIT might like that option. For that kind of network code Python is really fast enough. An event driven framework like asyncio or Twisted can handle lots of connections simultaneous. We aren't speaking about several GBit/sec where zero-copy is required. I'm more worried about Apache than Python. Apache is tuned for the needs of the webui, e.g. prefork MPM. Let's see how it works out in a production system. Christian signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Sudorules user validation help
On 05/28/2015 04:27 PM, Drew Erny wrote: In the ticket, however, it's stated that if the user wants to use any combination of weird characters, they should be able to. Would it be better to just define a function like def validate_username(username, ignore_pattern=False): and have it ignore all username validation? Tough question. FreeIPA in general tries to sanitize user input and does not allow everything user wants and try to advise the best practices, as we see it. In your case, if we allow only the 2 mentioned user login formats, it should work for AD use case just fine and add some level of sanity check of the user name. BTW, given we run an LDAP search later on this user name, isn't there a possibility of LDAP injection if we choose to allow all characters, including ( and )? :-) In any case, if we choose to ignore the pattern, we do not need the extra validator function at all. We would just skip validation in the pre callback if a user is being added. On 05/28/2015 09:40 AM, Drew Erny wrote: OK, I see now what you mean by that. That is a simpler solution. I'll do it that way. On 05/28/2015 04:44 AM, Martin Kosek wrote: On 05/27/2015 08:41 PM, Drew Erny wrote: Hey, Freeipa-devel, I'm working on ticket #3226 (https://fedorahosted.org/freeipa/ticket/3226) I've identified the problem. The sudorules add user command adds the user validations at the end of it's pre-callback using add_external_pre_callback. However, the user plugin pattern-matches a string for the uid param, because it only allows certain characters. I've been picking through the codebase and I think I have enough understanding to ask this: What if we changed the user uid validation to a standalone rule function (you can do that, right? pass in a function as a validation rule?) that would normally just assert that the pattern matches, but could have that pattern matching validation overridden in some cases. I think that's the easiest, cleanest way to change user so that sudorules and other plugins can ignore this validation if necessary (I'm trying to figure out exactly how to implement this without changing any APIs). Am I understanding the plugin params API correctly, and can I do this? Is this the best way to do this? The only other solution I see is to write sudorules-specific code in some plugin-related (either user.py or baseldap.py module, which would create unwanted coupling. Most specifically, this would be a change to the object instantiated at ipalib/plugins/user.py line 467 Thoughts and suggestions? I think it would make sense to follow the example with validate_hostname and prepare a function validate_username(username, upn=False, netbios_name=False) [1]. where upn would allow using @. on top of current validator (i.e. u...@domain.test) and netbios_name would allow the DOMAIN\user style. I would just suggest making sure the standard user validation error message is still the same to avoid unnecessary QE fail positives. In add_external_pre_callback you could then just simply call validate_username(user, True, True) just like it is already done with hostname. My 2 cents. Martin [1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa380525(v=vs.85).aspx -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Domain level for topology plugin = 2
On Thu, 2015-05-28 at 16:59 +0200, Ludwig Krispenz wrote: On 05/28/2015 04:46 PM, Simo Sorce wrote: On Thu, 2015-05-28 at 15:54 +0200, Ludwig Krispenz wrote: On 05/28/2015 03:26 PM, Simo Sorce wrote: On Thu, 2015-05-28 at 14:11 +0200, Petr Spacek wrote: On 28.5.2015 10:49, Martin Kosek wrote: On 05/28/2015 09:05 AM, Petr Spacek wrote: On 28.5.2015 08:55, Jan Cholasta wrote: Dne 26.5.2015 v 16:32 Petr Spacek napsal(a): On 26.5.2015 16:16, Martin Kosek wrote: On 05/26/2015 04:13 PM, thierry bordaz wrote: On 05/26/2015 02:12 PM, Petr Spacek wrote: Hello, it came to my mind that domain level for topology plugin should actually be number 2, not 1. We already used number 1 for incompatible changes in DNS tree and I believe that it is not a good idea to have two places which say 'version 1' but and actually mean two different things. (DNS tree version 1 + domain level 1) Patch is attached. Hello, The fix looks good but that seems strange to have to set the initial version of the topology plugin to 2.0. (IIUC That is the version that will be written in dse.ldif) I would rather expects that topology plugin 1.0, would activate itself if the DomainLevel is 2.0 or more. If topology plugin 1.0 sets an internal DomainLevel_trigger=2.0 then activate itself if DomainLevel = DomainLevel_trigger. Let's wait for Ludwig feedback. thanks thierry My personal opinion on this is to start with Domain Level 1 regardless. We already solved the DNS forwarders otherwise, with docs, async updates etc. I do not think we will be returning to implementing proper Domain Level support for that anyway. So I rather think that all the Domain Level starts with 0, 1 is unused, 2 is the top one will cause unforeseen issues I would rather like to avoid. I'm more worried about confusion in future. To to me it simply seems easier to bump one integer now than to document and explain (to users new developers) why we have two ones which mean something else. Code-wise it is just an integer. Also, it can simplify logic in future when we decide to do another incompatible change in DNS tree because we will have only one integer to test (instead of checking two separate version attribute in DNS tree domain level). +1, but I think the minimum supported domain level should be 1, not 0, because 0 means the server uses the old DNS schema, which we do not support anymore, right? Good point! It may be a good point, but it does not make the situation easier. You still have RHEL/CentOS 6.x IPA out there, where some of them already support the new DNS forwarders and some don't - and neither of them support Domain Levels - i.e. have Domain Level 0. As I said, I still see more complications with this proposals than benefits... I would argue that it actually helps. If domain level = 1 then we can be *sure* that all replicas support the new DNS semantics. If domain level = 0 then we know nothing (because of patched RHEL 6) and it is a warning sign for diagnostic tools and also us when it comes to debugging. First of all a domain level is something we change *RARELY*, and it is a whole number and it is an all or nothing thing. I do not understand why plugin versions matter at all, plugin version have nothing to do with domain levels. Each plugin *whatever* the version MUST always support at least 2 levels, because every domain you have will have to go through a domain_level transition when a new domain level comes out. Finally no single developer should be allowed to decide on anew domain level, this must be a well ponder team decision as all plugins that need to change behavior based on domain level will be affected so a thorough review of what changes are needed across all plugins must be done every time someone propose a change that requires a domain level bump. Last but not least we should consider domain levels as something that changes *very* slowly, because otherwise you'll have to support many domain levels within any plugins that have to change behavior according to the domain level. I would say that the domain level should not change more frequently than once a year or so. It would be too much code churn to do otherwise. So for now domain_level should be set to 0. And the topology plugin will be enabled only when we turn it to 1. However we shouldn't turn it to 1 until we have the replica promotion code at least, because only then we can make full use of the topology plugins. The DNS mess is unfixable, unless Petr you volunteer to backport code to change the behavior of the DNS based on the domain level, if that's the case then you can tie old behavior to level 0 and new behavior to level = 1, but I do not think you want to do that given we already have level 0 servers that
Re: [Freeipa-devel] Domain level for topology plugin = 2
On 05/28/2015 05:03 PM, Martin Kosek wrote: On 05/28/2015 04:59 PM, Ludwig Krispenz wrote: On 05/28/2015 04:46 PM, Simo Sorce wrote: On Thu, 2015-05-28 at 15:54 +0200, Ludwig Krispenz wrote: On 05/28/2015 03:26 PM, Simo Sorce wrote: On Thu, 2015-05-28 at 14:11 +0200, Petr Spacek wrote: On 28.5.2015 10:49, Martin Kosek wrote: On 05/28/2015 09:05 AM, Petr Spacek wrote: On 28.5.2015 08:55, Jan Cholasta wrote: Dne 26.5.2015 v 16:32 Petr Spacek napsal(a): On 26.5.2015 16:16, Martin Kosek wrote: On 05/26/2015 04:13 PM, thierry bordaz wrote: On 05/26/2015 02:12 PM, Petr Spacek wrote: Hello, it came to my mind that domain level for topology plugin should actually be number 2, not 1. We already used number 1 for incompatible changes in DNS tree and I believe that it is not a good idea to have two places which say 'version 1' but and actually mean two different things. (DNS tree version 1 + domain level 1) Patch is attached. Hello, The fix looks good but that seems strange to have to set the initial version of the topology plugin to 2.0. (IIUC That is the version that will be written in dse.ldif) I would rather expects that topology plugin 1.0, would activate itself if the DomainLevel is 2.0 or more. If topology plugin 1.0 sets an internal DomainLevel_trigger=2.0 then activate itself if DomainLevel = DomainLevel_trigger. Let's wait for Ludwig feedback. thanks thierry My personal opinion on this is to start with Domain Level 1 regardless. We already solved the DNS forwarders otherwise, with docs, async updates etc. I do not think we will be returning to implementing proper Domain Level support for that anyway. So I rather think that all the Domain Level starts with 0, 1 is unused, 2 is the top one will cause unforeseen issues I would rather like to avoid. I'm more worried about confusion in future. To to me it simply seems easier to bump one integer now than to document and explain (to users new developers) why we have two ones which mean something else. Code-wise it is just an integer. Also, it can simplify logic in future when we decide to do another incompatible change in DNS tree because we will have only one integer to test (instead of checking two separate version attribute in DNS tree domain level). +1, but I think the minimum supported domain level should be 1, not 0, because 0 means the server uses the old DNS schema, which we do not support anymore, right? Good point! It may be a good point, but it does not make the situation easier. You still have RHEL/CentOS 6.x IPA out there, where some of them already support the new DNS forwarders and some don't - and neither of them support Domain Levels - i.e. have Domain Level 0. As I said, I still see more complications with this proposals than benefits... I would argue that it actually helps. If domain level = 1 then we can be *sure* that all replicas support the new DNS semantics. If domain level = 0 then we know nothing (because of patched RHEL 6) and it is a warning sign for diagnostic tools and also us when it comes to debugging. First of all a domain level is something we change *RARELY*, and it is a whole number and it is an all or nothing thing. I do not understand why plugin versions matter at all, plugin version have nothing to do with domain levels. Each plugin *whatever* the version MUST always support at least 2 levels, because every domain you have will have to go through a domain_level transition when a new domain level comes out. Finally no single developer should be allowed to decide on anew domain level, this must be a well ponder team decision as all plugins that need to change behavior based on domain level will be affected so a thorough review of what changes are needed across all plugins must be done every time someone propose a change that requires a domain level bump. Last but not least we should consider domain levels as something that changes *very* slowly, because otherwise you'll have to support many domain levels within any plugins that have to change behavior according to the domain level. I would say that the domain level should not change more frequently than once a year or so. It would be too much code churn to do otherwise. So for now domain_level should be set to 0. And the topology plugin will be enabled only when we turn it to 1. However we shouldn't turn it to 1 until we have the replica promotion code at least, because only then we can make full use of the topology plugins. The DNS mess is unfixable, unless Petr you volunteer to backport code to change the behavior of the DNS based on the domain level, if that's the case then you can tie old behavior to level 0 and new behavior to level = 1, but I do not think you want to do that given we already have level 0 servers that sport the new code and changed the data in the directory, so let's just ignore DNS for the purpose of this discussion, except for nothing that once we finally switch to level 1 then all servers must be running
Re: [Freeipa-devel] New replica installation and topology - we need stable base
On 05/28/2015 04:57 PM, Simo Sorce wrote: On Thu, 2015-05-28 at 16:14 +0200, Martin Kosek wrote: On 05/28/2015 04:07 PM, Simo Sorce wrote: On Thu, 2015-05-28 at 16:02 +0200, Martin Kosek wrote: On 05/28/2015 04:00 PM, Simo Sorce wrote: On Thu, 2015-05-28 at 15:47 +0200, Martin Kosek wrote: On 05/27/2015 04:59 PM, Martin Kosek wrote: ... Domain Levels - Done, committed - Defaults to Level 1, i.e. Topology plugin powered infra enabled With respect to related Simo's response in http://www.redhat.com/archives/freeipa-devel/2015-May/msg00553.html Would we want to enable Topology (i.e. Domain Level 1) even if Replica promotion is not done? I thought we do as I see those as orthogonal features. Replica promotion would take advantage of the Topology plugin, but it does not mean you cannot benefit from Topology plugin without it. You can still use the API to see/manage the topology and set replication settings with it. You do not need Replica Promotion for that... You cannot move for domain level 0 to 1 automatically anyway. So this is a moot point to some degree. In general we need to have the code that checks for the domain level version to be able to change the level, so we need new code in replicas to publish the supported domain level version and code in the install patchs to check that we can actually join a domain given its current domain level status. These checks are absolutely a critical blocker to enable the whole domain-level feature. All the functionality you describe and the checks should be already there. I was really only asking about the default domain level for *new* installations Old/upgraded FreeIPA will be on the Domain Level 0 of course. I think new installation should be on 1 but only if we have decided and finalized what level 1 is. Simo. In my mind, Domain Level 1 means: - Topology plugins is activated for all replicas and manages the agreements - All changes to topology can be only made via topology-* commands - ipa-replica-manage connect|disconnect are not allowed Ok, if we want to restrict it to this then fine. In my original plan level 1 also meant the KISS/Custodia service is available on all master. If not then we cannot depend on it and we cannot fully finish the work on replica promotion w/o requiring the replica package anymore. The Custodia/Replica promotion will depend on Topology plugin to be there, but I do not think we necessarily need to make it a new Domain Level just for it. During ipa-replica-install, the installer can simply check if Custodia is accessible on remote server and bail out if it is not accessible and it does not have the replica file. Martin -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Domain level for topology plugin = 2
On 05/28/2015 04:59 PM, Ludwig Krispenz wrote: On 05/28/2015 04:46 PM, Simo Sorce wrote: On Thu, 2015-05-28 at 15:54 +0200, Ludwig Krispenz wrote: On 05/28/2015 03:26 PM, Simo Sorce wrote: On Thu, 2015-05-28 at 14:11 +0200, Petr Spacek wrote: On 28.5.2015 10:49, Martin Kosek wrote: On 05/28/2015 09:05 AM, Petr Spacek wrote: On 28.5.2015 08:55, Jan Cholasta wrote: Dne 26.5.2015 v 16:32 Petr Spacek napsal(a): On 26.5.2015 16:16, Martin Kosek wrote: On 05/26/2015 04:13 PM, thierry bordaz wrote: On 05/26/2015 02:12 PM, Petr Spacek wrote: Hello, it came to my mind that domain level for topology plugin should actually be number 2, not 1. We already used number 1 for incompatible changes in DNS tree and I believe that it is not a good idea to have two places which say 'version 1' but and actually mean two different things. (DNS tree version 1 + domain level 1) Patch is attached. Hello, The fix looks good but that seems strange to have to set the initial version of the topology plugin to 2.0. (IIUC That is the version that will be written in dse.ldif) I would rather expects that topology plugin 1.0, would activate itself if the DomainLevel is 2.0 or more. If topology plugin 1.0 sets an internal DomainLevel_trigger=2.0 then activate itself if DomainLevel = DomainLevel_trigger. Let's wait for Ludwig feedback. thanks thierry My personal opinion on this is to start with Domain Level 1 regardless. We already solved the DNS forwarders otherwise, with docs, async updates etc. I do not think we will be returning to implementing proper Domain Level support for that anyway. So I rather think that all the Domain Level starts with 0, 1 is unused, 2 is the top one will cause unforeseen issues I would rather like to avoid. I'm more worried about confusion in future. To to me it simply seems easier to bump one integer now than to document and explain (to users new developers) why we have two ones which mean something else. Code-wise it is just an integer. Also, it can simplify logic in future when we decide to do another incompatible change in DNS tree because we will have only one integer to test (instead of checking two separate version attribute in DNS tree domain level). +1, but I think the minimum supported domain level should be 1, not 0, because 0 means the server uses the old DNS schema, which we do not support anymore, right? Good point! It may be a good point, but it does not make the situation easier. You still have RHEL/CentOS 6.x IPA out there, where some of them already support the new DNS forwarders and some don't - and neither of them support Domain Levels - i.e. have Domain Level 0. As I said, I still see more complications with this proposals than benefits... I would argue that it actually helps. If domain level = 1 then we can be *sure* that all replicas support the new DNS semantics. If domain level = 0 then we know nothing (because of patched RHEL 6) and it is a warning sign for diagnostic tools and also us when it comes to debugging. First of all a domain level is something we change *RARELY*, and it is a whole number and it is an all or nothing thing. I do not understand why plugin versions matter at all, plugin version have nothing to do with domain levels. Each plugin *whatever* the version MUST always support at least 2 levels, because every domain you have will have to go through a domain_level transition when a new domain level comes out. Finally no single developer should be allowed to decide on anew domain level, this must be a well ponder team decision as all plugins that need to change behavior based on domain level will be affected so a thorough review of what changes are needed across all plugins must be done every time someone propose a change that requires a domain level bump. Last but not least we should consider domain levels as something that changes *very* slowly, because otherwise you'll have to support many domain levels within any plugins that have to change behavior according to the domain level. I would say that the domain level should not change more frequently than once a year or so. It would be too much code churn to do otherwise. So for now domain_level should be set to 0. And the topology plugin will be enabled only when we turn it to 1. However we shouldn't turn it to 1 until we have the replica promotion code at least, because only then we can make full use of the topology plugins. The DNS mess is unfixable, unless Petr you volunteer to backport code to change the behavior of the DNS based on the domain level, if that's the case then you can tie old behavior to level 0 and new behavior to level = 1, but I do not think you want to do that given we already have level 0 servers that sport the new code and changed the data in the directory, so let's just ignore DNS for the purpose of this discussion, except for nothing that once we finally
Re: [Freeipa-devel] KDC proxy implementation specs
On Thu, 2015-05-28 at 16:34 +0200, Christian Heimes wrote: Hello, thanks you for your input. The former thread has 58 messages in total. Since last Friday we have came to an agreement in most points. I like to some up our decisions and focus on some minor details. decisions - python-kdcproxy will be installed as a dependency of freeipa-server. There won't be a separate freeipa-server-kdcproxy package. That may or may not change in the future. The decision is out of scope for 4.2.0. [1] KDC proxy support will be enabled by default. The config files and LDAP settings will be created by ipa-server-install, ipa-server-upgrade and ipa-replica-install. The enabled/disabled switch will be stored per-replica in the cn=masters,cn=ipa,cn=etc tree. An API and CLI tool for management is postponed. [2] For now we settle for some doc examples that use the ipa-ldap-updater as suggested by Alex. [3] open for discussion --- Jan has suggested to ipaConfigString=kdcProxyEnabled in cn=KDC,cn=$FQDN,cn=masters,cn=ipa,cn=etc instead of ipaConfigString=enabledService in cn=KDCPROXY,cn=$FQDN,cn=masters,cn=ipa,cn=etc. It makes sense to me. After all MS-KKDCP is just another transport for the KDC. [4] There may be a security concern here if we aren't careful. I think I'm in favor of KDCPROXY since it is a different application. Martin Basti suggested a different keytab and principal for kdcproxy. [5] The keytab is only required for GSSAPI bind to lookup the state of the enabled/disabled switch. The current patch uses the same keytab as webgui. A new principal separates kdcproxy more cleanly and allows for fine-grained ACIs. It is also more future proof. It may also have auditing benefits now that we are beginning to think about the A in FreeIPA. In the future we may want to move kdcproxy from an Apache WSGI app to a separate service. A dedicated Twisted or asyncio daemon could handle more load. A separate keytab is easy to implement, too. I looked at the code in HTTPInstance.__create_http_keytab(). An apache module would also provide similar benefits. I'm not sure I necessarily want to stick with python here if we're optimizing for performance. Another option would be to add it to the KDC itself and proxy through Apache like we do for Tomcat. MIT might like that option. For the ACI I plan to add a new permission 'System: Read IPA Config String' and make the principal a direct memberOf of it. We don't have service roles yet. cn=roles,cn=accounts look like end user roles to me. The new ACI in cn=masters,cn=ipa,cn=etc will grant read, search and compare permission: (targetfilter = (objectClass=nsContainer))(targetattr = cn || objectClass || ipaConfigString)(version 3.0; acl Read IPA Config String; allow (read, search, compare) groupdn = ldap:///cn=System: Read IPA Config String,cn=permissions,cn=pbac,dc=ipa,dc=example;) I should be able to modify and test my patch in a matter of a couple of hours. Christian [1] http://www.redhat.com/archives/freeipa-devel/2015-May/msg00535.html [2] http://www.redhat.com/archives/freeipa-devel/2015-May/msg00555.html [3] http://www.redhat.com/archives/freeipa-devel/2015-May/msg00533.html [4] http://www.redhat.com/archives/freeipa-devel/2015-May/msg00543.html [5] http://www.redhat.com/archives/freeipa-devel/2015-May/msg00539.html -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] KDC proxy implementation specs
On Thu, 2015-05-28 at 17:07 +0200, Christian Heimes wrote: On 2015-05-28 16:48, Nathaniel McCallum wrote: An apache module would also provide similar benefits. I'm not sure I necessarily want to stick with python here if we're optimizing for performance. Another option would be to add it to the KDC itself and proxy through Apache like we do for Tomcat. MIT might like that option. For that kind of network code Python is really fast enough. An event driven framework like asyncio or Twisted can handle lots of connections simultaneous. We aren't speaking about several GBit/sec where zero -copy is required. I'm more worried about Apache than Python. Apache is tuned for the needs of the webui, e.g. prefork MPM. Let's see how it works out in a production system. Right. And the KDC could just parse the messages directly. I agree. Let's wait and see. Nathaniel -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] KDC proxy implementation specs
On Thu, 2015-05-28 at 17:00 +0200, Christian Heimes wrote: On 2015-05-28 16:53, Simo Sorce wrote: We can't have 2 different keytabs with the same principal name. If we need privilege separation we'll have to work on integrating GSS-Proxy and give the keytab only to GSS-Proxy leaving it off the hands of both the framework, the proxy, and apache itself. I had a different principal like KDCPROXY/fqdn@realm in mind. Although to be honest I do not see why the proxy need access to the keytab at all, can we simply run it as a wsgi application under a different user and prevent it from accessing the apache keytab at all ? Yes, mod_wsgi is able to run a WSGI app as a different user: https://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIDaemonProcess A different user needs another location for the ccache and perhaps additional SELinux rules. If you are using the keytab only to acquire credentials to access ldap you could use a memory ccache and not have to deal with locations: KRB5CCNAME=MEMORY:kdcproxy_random_number What do we need the keytab for ? Is it just in order to authenticate and read if the service is enabled ? Can we make that information available anonymously ? Yes, the information is not available for anon bind. It doesn't feel right to disclose the settings to the public. Another option is to use ldapi and external auth, I forgot if we allow automatic binding for no-root users though. Rob, do you remember ? Simo. -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] KDC proxy implementation specs
On 2015-05-28 17:10, Simo Sorce wrote: On Thu, 2015-05-28 at 17:00 +0200, Christian Heimes wrote: On 2015-05-28 16:53, Simo Sorce wrote: We can't have 2 different keytabs with the same principal name. If we need privilege separation we'll have to work on integrating GSS-Proxy and give the keytab only to GSS-Proxy leaving it off the hands of both the framework, the proxy, and apache itself. I had a different principal like KDCPROXY/fqdn@realm in mind. Although to be honest I do not see why the proxy need access to the keytab at all, can we simply run it as a wsgi application under a different user and prevent it from accessing the apache keytab at all ? Yes, mod_wsgi is able to run a WSGI app as a different user: https://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIDaemonProcess A different user needs another location for the ccache and perhaps additional SELinux rules. If you are using the keytab only to acquire credentials to access ldap you could use a memory ccache and not have to deal with locations: KRB5CCNAME=MEMORY:kdcproxy_random_number Oh nice, I wasn't aware about the MEMORY scheme. Is that supported on older versions of RHEL, too? What do we need the keytab for ? Is it just in order to authenticate and read if the service is enabled ? Can we make that information available anonymously ? Yes, the information is not available for anon bind. It doesn't feel right to disclose the settings to the public. Another option is to use ldapi and external auth, I forgot if we allow automatic binding for no-root users though. No, been there, tried it, failed. It works as root but not as Apache user or my test user. Christian signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] KDC proxy implementation specs
Simo Sorce wrote: On Thu, 2015-05-28 at 17:00 +0200, Christian Heimes wrote: On 2015-05-28 16:53, Simo Sorce wrote: We can't have 2 different keytabs with the same principal name. If we need privilege separation we'll have to work on integrating GSS-Proxy and give the keytab only to GSS-Proxy leaving it off the hands of both the framework, the proxy, and apache itself. I had a different principal like KDCPROXY/fqdn@realm in mind. Although to be honest I do not see why the proxy need access to the keytab at all, can we simply run it as a wsgi application under a different user and prevent it from accessing the apache keytab at all ? Yes, mod_wsgi is able to run a WSGI app as a different user: https://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIDaemonProcess A different user needs another location for the ccache and perhaps additional SELinux rules. If you are using the keytab only to acquire credentials to access ldap you could use a memory ccache and not have to deal with locations: KRB5CCNAME=MEMORY:kdcproxy_random_number What do we need the keytab for ? Is it just in order to authenticate and read if the service is enabled ? Can we make that information available anonymously ? Yes, the information is not available for anon bind. It doesn't feel right to disclose the settings to the public. Another option is to use ldapi and external auth, I forgot if we allow automatic binding for no-root users though. Rob, do you remember ? AFAIK we have no rules other than root - DM. rob -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Kerberos over HTTPS (KDC proxy)
On 2015-05-28 13:29, Martin Basti wrote: On 28/05/15 12:53, Christian Heimes wrote: On 2015-05-28 12:46, Martin Kosek wrote: I am fine with this too. So if there is not another major disagreement, let us start with enabling KDCPROXY by default during upgrade/install, the new ACI and the per-replica standard configuration. API CLI/UI can come later (4.2.x or 4.3). LGTM, too. How should the new ACI work? I see two possible ways: 1) Allow compare/search for ipaConfigString=enabledService for everybody: (targetfilter=(ipaConfigString=enabledService))(targetattr=ipaConfigString)(version 3.0; acl Compare enabledService access to masters; allow(search, compare) userdn = ldap:///all;;) 2) Create a new permission, assign it to all HTTP principals and allow read, compare and search for all ipaConfigString attributes. For the second way I need somebody to walk me through the permission and role system of FreeIPA. 3) Or we can create a new keytab for KDC proxy, and add permission only for this service The new keytab must be readable by the Apache process.Therefore a new keytab doesn't give us extra security. It separates the kdcproxy service from the IPA webgui. Is that your goal? Christian signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0377-0382] Synchronize changes from LDAP after reconnect
Hi, functionality seems to work fine. I have not checked the code thoroughly. Kind of a test is attached (requires setting named's ldap connection appropriately). ACK Matúš Honěk - Original Message - From: Petr Spacek pspa...@redhat.com To: tho...@redhat.com, Matus Honek mho...@redhat.com Cc: freeipa-devel@redhat.com Sent: Wednesday, May 27, 2015 2:50:52 PM Subject: [PATCH 0377-0382] Synchronize changes from LDAP after reconnect Hello, https://fedorahosted.org/bind-dyndb-ldap/ticket/128 Previously records deleted when connection to LDAP server was down were not synchronized properly. It should work now. I use this command to simulate broken connections and connection re-establishment: $ socat tcp-listen:3899,reuseaddr,fork tcp-connect:localhost:389 It should be enough to add ldap://$(hostname):3899 as LDAP URI to /etc/named.conf and then simulate changes by killing and restarting socat. Let me know if you need any assistance! -- Petr^2 Spacek test-resync-on-unavailability.sh Description: application/shellscript -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Domain level for topology plugin = 2
On 05/28/2015 05:35 PM, Simo Sorce wrote: On Thu, 2015-05-28 at 17:18 +0200, Ludwig Krispenz wrote: On 05/28/2015 05:03 PM, Martin Kosek wrote: On 05/28/2015 04:59 PM, Ludwig Krispenz wrote: On 05/28/2015 04:46 PM, Simo Sorce wrote: On Thu, 2015-05-28 at 15:54 +0200, Ludwig Krispenz wrote: On 05/28/2015 03:26 PM, Simo Sorce wrote: On Thu, 2015-05-28 at 14:11 +0200, Petr Spacek wrote: On 28.5.2015 10:49, Martin Kosek wrote: On 05/28/2015 09:05 AM, Petr Spacek wrote: On 28.5.2015 08:55, Jan Cholasta wrote: Dne 26.5.2015 v 16:32 Petr Spacek napsal(a): On 26.5.2015 16:16, Martin Kosek wrote: On 05/26/2015 04:13 PM, thierry bordaz wrote: On 05/26/2015 02:12 PM, Petr Spacek wrote: Hello, it came to my mind that domain level for topology plugin should actually be number 2, not 1. We already used number 1 for incompatible changes in DNS tree and I believe that it is not a good idea to have two places which say 'version 1' but and actually mean two different things. (DNS tree version 1 + domain level 1) Patch is attached. Hello, The fix looks good but that seems strange to have to set the initial version of the topology plugin to 2.0. (IIUC That is the version that will be written in dse.ldif) I would rather expects that topology plugin 1.0, would activate itself if the DomainLevel is 2.0 or more. If topology plugin 1.0 sets an internal DomainLevel_trigger=2.0 then activate itself if DomainLevel = DomainLevel_trigger. Let's wait for Ludwig feedback. thanks thierry My personal opinion on this is to start with Domain Level 1 regardless. We already solved the DNS forwarders otherwise, with docs, async updates etc. I do not think we will be returning to implementing proper Domain Level support for that anyway. So I rather think that all the Domain Level starts with 0, 1 is unused, 2 is the top one will cause unforeseen issues I would rather like to avoid. I'm more worried about confusion in future. To to me it simply seems easier to bump one integer now than to document and explain (to users new developers) why we have two ones which mean something else. Code-wise it is just an integer. Also, it can simplify logic in future when we decide to do another incompatible change in DNS tree because we will have only one integer to test (instead of checking two separate version attribute in DNS tree domain level). +1, but I think the minimum supported domain level should be 1, not 0, because 0 means the server uses the old DNS schema, which we do not support anymore, right? Good point! It may be a good point, but it does not make the situation easier. You still have RHEL/CentOS 6.x IPA out there, where some of them already support the new DNS forwarders and some don't - and neither of them support Domain Levels - i.e. have Domain Level 0. As I said, I still see more complications with this proposals than benefits... I would argue that it actually helps. If domain level = 1 then we can be *sure* that all replicas support the new DNS semantics. If domain level = 0 then we know nothing (because of patched RHEL 6) and it is a warning sign for diagnostic tools and also us when it comes to debugging. First of all a domain level is something we change *RARELY*, and it is a whole number and it is an all or nothing thing. I do not understand why plugin versions matter at all, plugin version have nothing to do with domain levels. Each plugin *whatever* the version MUST always support at least 2 levels, because every domain you have will have to go through a domain_level transition when a new domain level comes out. Finally no single developer should be allowed to decide on anew domain level, this must be a well ponder team decision as all plugins that need to change behavior based on domain level will be affected so a thorough review of what changes are needed across all plugins must be done every time someone propose a change that requires a domain level bump. Last but not least we should consider domain levels as something that changes *very* slowly, because otherwise you'll have to support many domain levels within any plugins that have to change behavior according to the domain level. I would say that the domain level should not change more frequently than once a year or so. It would be too much code churn to do otherwise. So for now domain_level should be set to 0. And the topology plugin will be enabled only when we turn it to 1. However we shouldn't turn it to 1 until we have the replica promotion code at least, because only then we can make full use of the topology plugins. The DNS mess is unfixable, unless Petr you volunteer to backport code to change the behavior of the DNS based on the domain level, if that's the case then you can tie old behavior to level 0 and new behavior to level = 1, but I do not think you want to do that given we already have level 0 servers that sport the new code and changed the data in the directory, so let's just ignore DNS for the purpose of this
Re: [Freeipa-devel] KDC proxy implementation specs
On Thu, 2015-05-28 at 17:13 +0200, Christian Heimes wrote: On 2015-05-28 17:10, Simo Sorce wrote: On Thu, 2015-05-28 at 17:00 +0200, Christian Heimes wrote: On 2015-05-28 16:53, Simo Sorce wrote: We can't have 2 different keytabs with the same principal name. If we need privilege separation we'll have to work on integrating GSS-Proxy and give the keytab only to GSS-Proxy leaving it off the hands of both the framework, the proxy, and apache itself. I had a different principal like KDCPROXY/fqdn@realm in mind. Although to be honest I do not see why the proxy need access to the keytab at all, can we simply run it as a wsgi application under a different user and prevent it from accessing the apache keytab at all ? Yes, mod_wsgi is able to run a WSGI app as a different user: https://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIDaemonProcess A different user needs another location for the ccache and perhaps additional SELinux rules. If you are using the keytab only to acquire credentials to access ldap you could use a memory ccache and not have to deal with locations: KRB5CCNAME=MEMORY:kdcproxy_random_number Oh nice, I wasn't aware about the MEMORY scheme. Is that supported on older versions of RHEL, too? Yes, it has been there for a long while. What do we need the keytab for ? Is it just in order to authenticate and read if the service is enabled ? Can we make that information available anonymously ? Yes, the information is not available for anon bind. It doesn't feel right to disclose the settings to the public. Another option is to use ldapi and external auth, I forgot if we allow automatic binding for no-root users though. No, been there, tried it, failed. It works as root but not as Apache user or my test user. Maybe we can enable it in cn=config, need to check what's needed, but it may be worth, if all you need is to read a few entries. Simo. -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Domain level for topology plugin = 2
On Thu, 2015-05-28 at 17:18 +0200, Ludwig Krispenz wrote: On 05/28/2015 05:03 PM, Martin Kosek wrote: On 05/28/2015 04:59 PM, Ludwig Krispenz wrote: On 05/28/2015 04:46 PM, Simo Sorce wrote: On Thu, 2015-05-28 at 15:54 +0200, Ludwig Krispenz wrote: On 05/28/2015 03:26 PM, Simo Sorce wrote: On Thu, 2015-05-28 at 14:11 +0200, Petr Spacek wrote: On 28.5.2015 10:49, Martin Kosek wrote: On 05/28/2015 09:05 AM, Petr Spacek wrote: On 28.5.2015 08:55, Jan Cholasta wrote: Dne 26.5.2015 v 16:32 Petr Spacek napsal(a): On 26.5.2015 16:16, Martin Kosek wrote: On 05/26/2015 04:13 PM, thierry bordaz wrote: On 05/26/2015 02:12 PM, Petr Spacek wrote: Hello, it came to my mind that domain level for topology plugin should actually be number 2, not 1. We already used number 1 for incompatible changes in DNS tree and I believe that it is not a good idea to have two places which say 'version 1' but and actually mean two different things. (DNS tree version 1 + domain level 1) Patch is attached. Hello, The fix looks good but that seems strange to have to set the initial version of the topology plugin to 2.0. (IIUC That is the version that will be written in dse.ldif) I would rather expects that topology plugin 1.0, would activate itself if the DomainLevel is 2.0 or more. If topology plugin 1.0 sets an internal DomainLevel_trigger=2.0 then activate itself if DomainLevel = DomainLevel_trigger. Let's wait for Ludwig feedback. thanks thierry My personal opinion on this is to start with Domain Level 1 regardless. We already solved the DNS forwarders otherwise, with docs, async updates etc. I do not think we will be returning to implementing proper Domain Level support for that anyway. So I rather think that all the Domain Level starts with 0, 1 is unused, 2 is the top one will cause unforeseen issues I would rather like to avoid. I'm more worried about confusion in future. To to me it simply seems easier to bump one integer now than to document and explain (to users new developers) why we have two ones which mean something else. Code-wise it is just an integer. Also, it can simplify logic in future when we decide to do another incompatible change in DNS tree because we will have only one integer to test (instead of checking two separate version attribute in DNS tree domain level). +1, but I think the minimum supported domain level should be 1, not 0, because 0 means the server uses the old DNS schema, which we do not support anymore, right? Good point! It may be a good point, but it does not make the situation easier. You still have RHEL/CentOS 6.x IPA out there, where some of them already support the new DNS forwarders and some don't - and neither of them support Domain Levels - i.e. have Domain Level 0. As I said, I still see more complications with this proposals than benefits... I would argue that it actually helps. If domain level = 1 then we can be *sure* that all replicas support the new DNS semantics. If domain level = 0 then we know nothing (because of patched RHEL 6) and it is a warning sign for diagnostic tools and also us when it comes to debugging. First of all a domain level is something we change *RARELY*, and it is a whole number and it is an all or nothing thing. I do not understand why plugin versions matter at all, plugin version have nothing to do with domain levels. Each plugin *whatever* the version MUST always support at least 2 levels, because every domain you have will have to go through a domain_level transition when a new domain level comes out. Finally no single developer should be allowed to decide on anew domain level, this must be a well ponder team decision as all plugins that need to change behavior based on domain level will be affected so a thorough review of what changes are needed across all plugins must be done every time someone propose a change that requires a domain level bump. Last but not least we should consider domain levels as something that changes *very* slowly, because otherwise you'll have to support many domain levels within any plugins that have to change behavior according to the domain level. I would say that the domain level should not change more frequently than once a year or so. It would be too much code churn to do otherwise. So for now domain_level should be set to 0. And the topology plugin will be enabled only when we turn it to 1. However we shouldn't turn it to 1 until we have the replica promotion code at least, because only then we can make full use of the topology plugins. The DNS mess is unfixable, unless Petr you volunteer to backport code to change the behavior of the DNS based on the domain level, if that's the case then you can tie old behavior to level 0 and new
