Re: [Freeipa-devel] [PROPOSAL] Kerberos flags
On Sat, 2013-03-16 at 16:46 -0400, Dmitri Pal wrote: On 03/12/2013 02:02 PM, Simo Sorce wrote: On Tue, 2013-03-12 at 18:31 +0100, Jan Cholasta wrote: On 12.3.2013 18:01, Simo Sorce wrote: On Tue, 2013-03-12 at 17:31 +0100, Jan Cholasta wrote: On 12.3.2013 17:24, Simo Sorce wrote: On Tue, 2013-03-12 at 17:02 +0100, Jan Cholasta wrote: Why can't we set the bitfield (krbTicketFlags) directly? (There is an ACI preventing that, I'm just wondering what is the reason for this.) If you tell me who 'we' is (as in what user would set it) I can tell you why it is/isn't possible. Why no IPA user (including admins) can set the attribute? I guess admins should be allowed to. Users can't, as ticket flags change the behavior of the principal in ways only admins should allowed to. (preauth required or not, AS requests disabled or not, etc...) Thanks. For normal users it's obvious, but it seemed a little bit strange to disallow admins to set the flags. So, can the krbTicketFlags attribute be used internally in IPA plugins to set/unset the flags, given that the ACI is changed to allow admins to modify the attribute? The problem is determining if all the flags can be set by the same set of admins or if we need to be able to delegate some of them. In the second case we have only 2 options: 1) break the flags out in multiple attributes so we can set separate ACIs 2) create a plugin that can intercept and filter modifications to the attribute so only the allowed flags are changed The first option has the problem that we are going to change the schema. The second option has the problem that the check will be less flexible than with regular ACIs (unless we use some sort of virtual ACI) and duplicates access control points. Anyway we need to find out if we really need fine grained access control per flags or not before wrapping our heads. Simo. Do we have a decision on this? Have we determined that the flags actually have to be delegated and have different access privileges? Can we start with allowing admins to change them all and reconsider when anyone actually asks for a finer grain access control? We decided there is no flag that should ever be delegated to less powerful admins. So we can proceed with allowing the admins group access to this whole attribute w/o need to break it down into parts. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PROPOSAL] Kerberos flags
On 03/12/2013 02:02 PM, Simo Sorce wrote: On Tue, 2013-03-12 at 18:31 +0100, Jan Cholasta wrote: On 12.3.2013 18:01, Simo Sorce wrote: On Tue, 2013-03-12 at 17:31 +0100, Jan Cholasta wrote: On 12.3.2013 17:24, Simo Sorce wrote: On Tue, 2013-03-12 at 17:02 +0100, Jan Cholasta wrote: Why can't we set the bitfield (krbTicketFlags) directly? (There is an ACI preventing that, I'm just wondering what is the reason for this.) If you tell me who 'we' is (as in what user would set it) I can tell you why it is/isn't possible. Why no IPA user (including admins) can set the attribute? I guess admins should be allowed to. Users can't, as ticket flags change the behavior of the principal in ways only admins should allowed to. (preauth required or not, AS requests disabled or not, etc...) Thanks. For normal users it's obvious, but it seemed a little bit strange to disallow admins to set the flags. So, can the krbTicketFlags attribute be used internally in IPA plugins to set/unset the flags, given that the ACI is changed to allow admins to modify the attribute? The problem is determining if all the flags can be set by the same set of admins or if we need to be able to delegate some of them. In the second case we have only 2 options: 1) break the flags out in multiple attributes so we can set separate ACIs 2) create a plugin that can intercept and filter modifications to the attribute so only the allowed flags are changed The first option has the problem that we are going to change the schema. The second option has the problem that the check will be less flexible than with regular ACIs (unless we use some sort of virtual ACI) and duplicates access control points. Anyway we need to find out if we really need fine grained access control per flags or not before wrapping our heads. Simo. Do we have a decision on this? Have we determined that the flags actually have to be delegated and have different access privileges? Can we start with allowing admins to change them all and reconsider when anyone actually asks for a finer grain access control? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PROPOSAL] Kerberos flags
On 8.3.2013 20:09, Rob Crittenden wrote: Petr Spacek wrote: On 8.3.2013 16:45, Rob Crittenden wrote: One would need to pass in the object type they are dealing with: ipa krbflags --type=user --ok-as-delegate=false sbose ipa krbflags --type=service --ok-as-delegate=true HTTP/ipa.example.com We *could* avoid type potentially but it would expand our search base and could slow things down with lots of entries. Correct me if I'm wrong, but our KDC driver usually does sub-tree search with base dc=example,dc=com. (Except some special cases.) Or not? :-) Yes but when we do that search we've got a full principal. Consider the host plugin. If we are given a non-fully-qualified hostname we add the IPA domain by default when looking for things. It is not uncommon for people to name their laptop after themselves. So if we are told to add a flag to the pspacek principal, which one is it? The user pspacek or the host pspacek.example.com? Or we could require that hostnames are fully-qualified, it would just be a difference from other plugins. We could search on the accounts container using (objectclass=ipaKrbPrincipal) and (|(uid=CRITERIA)(fqdn=CRITERIA)(krbprincipalname=CRITERIA)) or something like that. I think I'd prefer specifying a type to avoid the case where someone has a hostname the same as a uid (we typically allow specifying non-fqdn when managing hosts). Would it be possible define some reasonable default value for --type? I don't like typing --service all the time ... Maybe, if we can assume what type of principal is most likely to be updated. Remember that the host/ principal is stored in a host, not a service record. Then again, I don't know how often one is going to be adding flags to principals, so perhaps a required switch wouldn't be too onerous. Since the plugin would be used to manage Kerberos specifics, I think it is fair to require a valid principal as the argument. So it's either user or host/fqdn (or service/fqdn), there's no ambiguity in that and no --type option is required. If you insist on using arbitrary names, I think we better do this in user/host/service plugins, as suggested originally. Setting PAC type is done in the usual place in service plugin after all, even when it is Kerberos-specific. rob Honza -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PROPOSAL] Kerberos flags
On 8.3.2013 14:41, Simo Sorce wrote: On Fri, 2013-03-08 at 10:31 +0100, Jan Cholasta wrote: Hi, On 7.3.2013 21:15, Rob Crittenden wrote: Based on a comment from Sumit in ticket https://fedorahosted.org/freeipa/ticket/3329 here is a bare outline of how one might do it: http://freeipa.org/page/V3/Kerberos_Flags Can we have one multi-valued attribute which contains names of flags to set instead of one attribute per flag? It might make adding new flags easier. if you are cramming everything in one attribute then we can keep using krbExtraData, no ? I'm not sure if that can be done from Python. Can we use krbTicketFlags for this? Support for this attribute is already in ipa-kdb and I have checked that setting it to the right value results in tickets with OK_AS_DELEGATE set. Would it make sense to add a global configuration option to turn flags on or off for all services of a given type? We might, but how do you check for the global value ? An additional search for every KDC operation is simply not going to happen. Can we do that extra search only when the KDC is initialized and when configuration is refreshed? I don't think the default values would change too often, so this might be OK. Simo. Honza -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PROPOSAL] Kerberos flags
Jan Cholasta wrote: On 8.3.2013 20:09, Rob Crittenden wrote: Petr Spacek wrote: On 8.3.2013 16:45, Rob Crittenden wrote: One would need to pass in the object type they are dealing with: ipa krbflags --type=user --ok-as-delegate=false sbose ipa krbflags --type=service --ok-as-delegate=true HTTP/ipa.example.com We *could* avoid type potentially but it would expand our search base and could slow things down with lots of entries. Correct me if I'm wrong, but our KDC driver usually does sub-tree search with base dc=example,dc=com. (Except some special cases.) Or not? :-) Yes but when we do that search we've got a full principal. Consider the host plugin. If we are given a non-fully-qualified hostname we add the IPA domain by default when looking for things. It is not uncommon for people to name their laptop after themselves. So if we are told to add a flag to the pspacek principal, which one is it? The user pspacek or the host pspacek.example.com? Or we could require that hostnames are fully-qualified, it would just be a difference from other plugins. We could search on the accounts container using (objectclass=ipaKrbPrincipal) and (|(uid=CRITERIA)(fqdn=CRITERIA)(krbprincipalname=CRITERIA)) or something like that. I think I'd prefer specifying a type to avoid the case where someone has a hostname the same as a uid (we typically allow specifying non-fqdn when managing hosts). Would it be possible define some reasonable default value for --type? I don't like typing --service all the time ... Maybe, if we can assume what type of principal is most likely to be updated. Remember that the host/ principal is stored in a host, not a service record. Then again, I don't know how often one is going to be adding flags to principals, so perhaps a required switch wouldn't be too onerous. Since the plugin would be used to manage Kerberos specifics, I think it is fair to require a valid principal as the argument. So it's either user or host/fqdn (or service/fqdn), there's no ambiguity in that and no --type option is required. If you insist on using arbitrary names, I think we better do this in user/host/service plugins, as suggested originally. Setting PAC type is done in the usual place in service plugin after all, even when it is Kerberos-specific. I cam to the same conclusion and updated the proposal yesterday this way. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PROPOSAL] Kerberos flags
On Tue, 2013-03-12 at 10:23 +0100, Jan Cholasta wrote: On 8.3.2013 14:41, Simo Sorce wrote: On Fri, 2013-03-08 at 10:31 +0100, Jan Cholasta wrote: Hi, On 7.3.2013 21:15, Rob Crittenden wrote: Based on a comment from Sumit in ticket https://fedorahosted.org/freeipa/ticket/3329 here is a bare outline of how one might do it: http://freeipa.org/page/V3/Kerberos_Flags Can we have one multi-valued attribute which contains names of flags to set instead of one attribute per flag? It might make adding new flags easier. if you are cramming everything in one attribute then we can keep using krbExtraData, no ? I'm not sure if that can be done from Python. Can we use krbTicketFlags for this? Support for this attribute is already in ipa-kdb and I have checked that setting it to the right value results in tickets with OK_AS_DELEGATE set. Would it make sense to add a global configuration option to turn flags on or off for all services of a given type? We might, but how do you check for the global value ? An additional search for every KDC operation is simply not going to happen. Can we do that extra search only when the KDC is initialized and when configuration is refreshed? I don't think the default values would change too often, so this might be OK. How do you know when the configuration changes ? Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PROPOSAL] Kerberos flags
On 12.3.2013 13:34, Simo Sorce wrote: We might, but how do you check for the global value ? An additional search for every KDC operation is simply not going to happen. Can we do that extra search only when the KDC is initialized and when configuration is refreshed? I don't think the default values would change too often, so this might be OK. How do you know when the configuration changes ? Persistent search? -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PROPOSAL] Kerberos flags
Petr Spacek wrote: On 12.3.2013 13:34, Simo Sorce wrote: We might, but how do you check for the global value ? An additional search for every KDC operation is simply not going to happen. Can we do that extra search only when the KDC is initialized and when configuration is refreshed? I don't think the default values would change too often, so this might be OK. How do you know when the configuration changes ? Persistent search? Well, this is where we might do well with a 389-ds plugin that monitors flag changes so we can catch changes made directly by kadmin.local as well. This would be similar to the password plugin in keeping several attributes in sync. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PROPOSAL] Kerberos flags
On 12.3.2013 15:39, Rob Crittenden wrote: Petr Spacek wrote: On 12.3.2013 13:34, Simo Sorce wrote: We might, but how do you check for the global value ? An additional search for every KDC operation is simply not going to happen. Can we do that extra search only when the KDC is initialized and when configuration is refreshed? I don't think the default values would change too often, so this might be OK. How do you know when the configuration changes ? Persistent search? Well, this is where we might do well with a 389-ds plugin that monitors flag changes so we can catch changes made directly by kadmin.local as well. This would be similar to the password plugin in keeping several attributes in sync. I didn't understand your note about DS plugin. kadmin.local does all changes in LDAP, or not? All changes in LDAP DB are sent via persistent search (if the persistent search was issued with appropriate parameters). -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PROPOSAL] Kerberos flags
Petr Spacek wrote: On 12.3.2013 15:39, Rob Crittenden wrote: Petr Spacek wrote: On 12.3.2013 13:34, Simo Sorce wrote: We might, but how do you check for the global value ? An additional search for every KDC operation is simply not going to happen. Can we do that extra search only when the KDC is initialized and when configuration is refreshed? I don't think the default values would change too often, so this might be OK. How do you know when the configuration changes ? Persistent search? Well, this is where we might do well with a 389-ds plugin that monitors flag changes so we can catch changes made directly by kadmin.local as well. This would be similar to the password plugin in keeping several attributes in sync. I didn't understand your note about DS plugin. kadmin.local does all changes in LDAP, or not? All changes in LDAP DB are sent via persistent search (if the persistent search was issued with appropriate parameters). Let me step back and say I know next to nothing about how the KDB backend works. What would be nice is one place to notice changes to these proposed flags and the flag bitfield. Whether that is best done in the backend or via a 389-ds plugin I don't know. So whatever we do, we need one place to notice changes in either the flag(s) or bitfield and keep the values in sync. kadmin.local changes things in LDAP because we use our own backend driver. It doesn't speak LDAP natively. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PROPOSAL] Kerberos flags
On Tue, Mar 12, 2013 at 08:34:33AM -0400, Simo Sorce wrote: On Tue, 2013-03-12 at 10:23 +0100, Jan Cholasta wrote: On 8.3.2013 14:41, Simo Sorce wrote: On Fri, 2013-03-08 at 10:31 +0100, Jan Cholasta wrote: Hi, On 7.3.2013 21:15, Rob Crittenden wrote: Based on a comment from Sumit in ticket https://fedorahosted.org/freeipa/ticket/3329 here is a bare outline of how one might do it: http://freeipa.org/page/V3/Kerberos_Flags Can we have one multi-valued attribute which contains names of flags to set instead of one attribute per flag? It might make adding new flags easier. if you are cramming everything in one attribute then we can keep using krbExtraData, no ? I'm not sure if that can be done from Python. Can we use krbTicketFlags for this? Support for this attribute is already in ipa-kdb and I have checked that setting it to the right value results in tickets with OK_AS_DELEGATE set. Would it make sense to add a global configuration option to turn flags on or off for all services of a given type? We might, but how do you check for the global value ? An additional search for every KDC operation is simply not going to happen. Can we do that extra search only when the KDC is initialized and when configuration is refreshed? I don't think the default values would change too often, so this might be OK. How do you know when the configuration changes ? iirc Martin introduced a reload of the configuration if it is older than a certain time with the SID blacklist work. bye, Sumit Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PROPOSAL] Kerberos flags
On 12.3.2013 16:00, Rob Crittenden wrote: Petr Spacek wrote: On 12.3.2013 15:39, Rob Crittenden wrote: Petr Spacek wrote: On 12.3.2013 13:34, Simo Sorce wrote: We might, but how do you check for the global value ? An additional search for every KDC operation is simply not going to happen. Can we do that extra search only when the KDC is initialized and when configuration is refreshed? I don't think the default values would change too often, so this might be OK. How do you know when the configuration changes ? Persistent search? Well, this is where we might do well with a 389-ds plugin that monitors flag changes so we can catch changes made directly by kadmin.local as well. This would be similar to the password plugin in keeping several attributes in sync. I didn't understand your note about DS plugin. kadmin.local does all changes in LDAP, or not? All changes in LDAP DB are sent via persistent search (if the persistent search was issued with appropriate parameters). Let me step back and say I know next to nothing about how the KDB backend works. What would be nice is one place to notice changes to these proposed flags and the flag bitfield. Whether that is best done in the backend or via a 389-ds plugin I don't know. So whatever we do, we need one place to notice changes in either the flag(s) or bitfield and keep the values in sync. Why can't we set the bitfield (krbTicketFlags) directly? (There is an ACI preventing that, I'm just wondering what is the reason for this.) kadmin.local changes things in LDAP because we use our own backend driver. It doesn't speak LDAP natively. rob -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PROPOSAL] Kerberos flags
On Tue, 2013-03-12 at 15:31 +0100, Petr Spacek wrote: On 12.3.2013 13:34, Simo Sorce wrote: We might, but how do you check for the global value ? An additional search for every KDC operation is simply not going to happen. Can we do that extra search only when the KDC is initialized and when configuration is refreshed? I don't think the default values would change too often, so this might be OK. How do you know when the configuration changes ? Persistent search? No for 3 reasons. 1. Persistent searches are expensive for the server. 2. The KDC is not threaded so it has no way to react to data being sent down the pipe. It may accumulate for hours and then the KDC would be swamped processing all that data on the first request it gets from a client. 3. The KDC is configured to spawn multiple processes on multi-CPU machines, and that would mean tons of duplication with one persistent search per process, and the associated heavy load on DS would increase even more. We might have a dirty way to do something like this with inotify and a common file we agree upon to 'touch' from DS plugins. The the KDC would be able to reload the configuration only when inotify signals there is a change in the underlying file. It's not really elegant and will probably also require changes to the selinux policy but it would be less heavy weight. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PROPOSAL] Kerberos flags
On Tue, 2013-03-12 at 17:02 +0100, Jan Cholasta wrote: On 12.3.2013 16:00, Rob Crittenden wrote: Petr Spacek wrote: On 12.3.2013 15:39, Rob Crittenden wrote: Petr Spacek wrote: On 12.3.2013 13:34, Simo Sorce wrote: We might, but how do you check for the global value ? An additional search for every KDC operation is simply not going to happen. Can we do that extra search only when the KDC is initialized and when configuration is refreshed? I don't think the default values would change too often, so this might be OK. How do you know when the configuration changes ? Persistent search? Well, this is where we might do well with a 389-ds plugin that monitors flag changes so we can catch changes made directly by kadmin.local as well. This would be similar to the password plugin in keeping several attributes in sync. I didn't understand your note about DS plugin. kadmin.local does all changes in LDAP, or not? All changes in LDAP DB are sent via persistent search (if the persistent search was issued with appropriate parameters). Let me step back and say I know next to nothing about how the KDB backend works. What would be nice is one place to notice changes to these proposed flags and the flag bitfield. Whether that is best done in the backend or via a 389-ds plugin I don't know. So whatever we do, we need one place to notice changes in either the flag(s) or bitfield and keep the values in sync. Why can't we set the bitfield (krbTicketFlags) directly? (There is an ACI preventing that, I'm just wondering what is the reason for this.) If you tell me who 'we' is (as in what user would set it) I can tell you why it is/isn't possible. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PROPOSAL] Kerberos flags
On 12.3.2013 17:24, Simo Sorce wrote: On Tue, 2013-03-12 at 17:02 +0100, Jan Cholasta wrote: Why can't we set the bitfield (krbTicketFlags) directly? (There is an ACI preventing that, I'm just wondering what is the reason for this.) If you tell me who 'we' is (as in what user would set it) I can tell you why it is/isn't possible. Why no IPA user (including admins) can set the attribute? Simo. -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PROPOSAL] Kerberos flags
On 12.3.2013 18:01, Simo Sorce wrote: On Tue, 2013-03-12 at 17:31 +0100, Jan Cholasta wrote: On 12.3.2013 17:24, Simo Sorce wrote: On Tue, 2013-03-12 at 17:02 +0100, Jan Cholasta wrote: Why can't we set the bitfield (krbTicketFlags) directly? (There is an ACI preventing that, I'm just wondering what is the reason for this.) If you tell me who 'we' is (as in what user would set it) I can tell you why it is/isn't possible. Why no IPA user (including admins) can set the attribute? I guess admins should be allowed to. Users can't, as ticket flags change the behavior of the principal in ways only admins should allowed to. (preauth required or not, AS requests disabled or not, etc...) Thanks. For normal users it's obvious, but it seemed a little bit strange to disallow admins to set the flags. So, can the krbTicketFlags attribute be used internally in IPA plugins to set/unset the flags, given that the ACI is changed to allow admins to modify the attribute? Honza -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PROPOSAL] Kerberos flags
On Tue, 2013-03-12 at 18:31 +0100, Jan Cholasta wrote: On 12.3.2013 18:01, Simo Sorce wrote: On Tue, 2013-03-12 at 17:31 +0100, Jan Cholasta wrote: On 12.3.2013 17:24, Simo Sorce wrote: On Tue, 2013-03-12 at 17:02 +0100, Jan Cholasta wrote: Why can't we set the bitfield (krbTicketFlags) directly? (There is an ACI preventing that, I'm just wondering what is the reason for this.) If you tell me who 'we' is (as in what user would set it) I can tell you why it is/isn't possible. Why no IPA user (including admins) can set the attribute? I guess admins should be allowed to. Users can't, as ticket flags change the behavior of the principal in ways only admins should allowed to. (preauth required or not, AS requests disabled or not, etc...) Thanks. For normal users it's obvious, but it seemed a little bit strange to disallow admins to set the flags. So, can the krbTicketFlags attribute be used internally in IPA plugins to set/unset the flags, given that the ACI is changed to allow admins to modify the attribute? The problem is determining if all the flags can be set by the same set of admins or if we need to be able to delegate some of them. In the second case we have only 2 options: 1) break the flags out in multiple attributes so we can set separate ACIs 2) create a plugin that can intercept and filter modifications to the attribute so only the allowed flags are changed The first option has the problem that we are going to change the schema. The second option has the problem that the check will be less flexible than with regular ACIs (unless we use some sort of virtual ACI) and duplicates access control points. Anyway we need to find out if we really need fine grained access control per flags or not before wrapping our heads. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PROPOSAL] Kerberos flags
On Thu, Mar 07, 2013 at 03:15:18PM -0500, Rob Crittenden wrote: Based on a comment from Sumit in ticket https://fedorahosted.org/freeipa/ticket/3329 here is a bare outline of how one might do it: http://freeipa.org/page/V3/Kerberos_Flags There is a bit of hand waving going on around how the flags are actually set inside the KDB plugin since I'm not at all familiar with that code but I don't expect it to be too big a deal. I'm not necessarily volunteering to do this work, just trying to keep the ball moving forward. Thank you for setting up the design page. I would like to suggest that we should try to include all currently available flags in one run, because: - some flags related to OTP would be needed as well - it is only a minor increase the development effort - it is only a minor increase in the QE effort. Instead of doing * set/unset flag in CLI/WebUI * check with kdamin.local if the flag is in the expected state for a single attribute it has to be done for a list of attributes (maybe the steps can be added to a new 'How to test' section on the design page) - it will help to find a good solution how to handle the flags in the CLI/WebUI I think the last point is important because the flags are needed for all Kerberos principals, i.e. users, hosts and services. Instead of adding a list of new options/check boxes to each of the CLI commands/WebUI pages it might be more helpful to handle the flags separately. The CLI can get a new command class, e.g. krbflags. In the WebUI the Kerberos flags can be shown and modified in a separate tab, I hope this will allow to use a common template to users, hosts and services. These are only rough ideas and suggestions, my point is that if we not only add a single flag but about 15 it might be easier to find a good and usable interface to modify them. bye, Sumit rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PROPOSAL] Kerberos flags
Hi, On 7.3.2013 21:15, Rob Crittenden wrote: Based on a comment from Sumit in ticket https://fedorahosted.org/freeipa/ticket/3329 here is a bare outline of how one might do it: http://freeipa.org/page/V3/Kerberos_Flags Can we have one multi-valued attribute which contains names of flags to set instead of one attribute per flag? It might make adding new flags easier. Would it make sense to add a global configuration option to turn flags on or off for all services of a given type? There is a bit of hand waving going on around how the flags are actually set inside the KDB plugin since I'm not at all familiar with that code but I don't expect it to be too big a deal. I'm not necessarily volunteering to do this work, just trying to keep the ball moving forward. rob Honza -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PROPOSAL] Kerberos flags
On Fri, Mar 08, 2013 at 10:31:58AM +0100, Jan Cholasta wrote: Hi, On 7.3.2013 21:15, Rob Crittenden wrote: Based on a comment from Sumit in ticket https://fedorahosted.org/freeipa/ticket/3329 here is a bare outline of how one might do it: http://freeipa.org/page/V3/Kerberos_Flags Can we have one multi-valued attribute which contains names of flags to set instead of one attribute per flag? It might make adding new flags easier. Yes, as said I think it makes sense to just add support for all flags to find a good/scalable design. This way it would be a bit harder for external applications which access the LDAP server directly to see which flags are supported, but it will keep the schema much cleaner. Would it make sense to add a global configuration option to turn flags on or off for all services of a given type? In general yes, I'm just wondering if this should be handled here or tracked by a separate ticket/design because different LDAP objects will be used to manage the defaults. Additionally we might want to think a bit longer about how global defaults and individual flags will be merged. I think it is not as easy as with the authorization date (PAC type) where we said that individual setting replaces the defaults because iirc the REQUIRES_PRE_AUTH is currently always set. Please note also that tis is not only about services but hosts and users as well. bye, Sumit There is a bit of hand waving going on around how the flags are actually set inside the KDB plugin since I'm not at all familiar with that code but I don't expect it to be too big a deal. I'm not necessarily volunteering to do this work, just trying to keep the ball moving forward. rob Honza -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PROPOSAL] Kerberos flags
On Thu, 2013-03-07 at 15:15 -0500, Rob Crittenden wrote: Based on a comment from Sumit in ticket https://fedorahosted.org/freeipa/ticket/3329 here is a bare outline of how one might do it: http://freeipa.org/page/V3/Kerberos_Flags There is a bit of hand waving going on around how the flags are actually set inside the KDB plugin since I'm not at all familiar with that code but I don't expect it to be too big a deal. I'm not necessarily volunteering to do this work, just trying to keep the ball moving forward. How is upgrade performed ? What happens during upgrade when mixed old/new servers are around ? Please add explicitly the process in the Design page, this is crucial to decide if this design is acceptable or not. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PROPOSAL] Kerberos flags
Sumit Bose wrote: On Thu, Mar 07, 2013 at 03:15:18PM -0500, Rob Crittenden wrote: Based on a comment from Sumit in ticket https://fedorahosted.org/freeipa/ticket/3329 here is a bare outline of how one might do it: http://freeipa.org/page/V3/Kerberos_Flags There is a bit of hand waving going on around how the flags are actually set inside the KDB plugin since I'm not at all familiar with that code but I don't expect it to be too big a deal. I'm not necessarily volunteering to do this work, just trying to keep the ball moving forward. Thank you for setting up the design page. I would like to suggest that we should try to include all currently available flags in one run, because: - some flags related to OTP would be needed as well - it is only a minor increase the development effort - it is only a minor increase in the QE effort. Instead of doing * set/unset flag in CLI/WebUI * check with kdamin.local if the flag is in the expected state for a single attribute it has to be done for a list of attributes (maybe the steps can be added to a new 'How to test' section on the design page) - it will help to find a good solution how to handle the flags in the CLI/WebUI I think the last point is important because the flags are needed for all Kerberos principals, i.e. users, hosts and services. Instead of adding a list of new options/check boxes to each of the CLI commands/WebUI pages it might be more helpful to handle the flags separately. The CLI can get a new command class, e.g. krbflags. In the WebUI the Kerberos flags can be shown and modified in a separate tab, I hope this will allow to use a common template to users, hosts and services. These are only rough ideas and suggestions, my point is that if we not only add a single flag but about 15 it might be easier to find a good and usable interface to modify them. I'll update the page with these comments as well, eventually... Ok, a new plugin makes sense, so we don't have to pollute all the other plugins with these flags. One would need to pass in the object type they are dealing with: ipa krbflags --type=user --ok-as-delegate=false sbose ipa krbflags --type=service --ok-as-delegate=true HTTP/ipa.example.com We *could* avoid type potentially but it would expand our search base and could slow things down with lots of entries. We could search on the accounts container using (objectclass=ipaKrbPrincipal) and (|(uid=CRITERIA)(fqdn=CRITERIA)(krbprincipalname=CRITERIA)) or something like that. I think I'd prefer specifying a type to avoid the case where someone has a hostname the same as a uid (we typically allow specifying non-fqdn when managing hosts). As for setting all these flags, is this going to introduce oddball support issues if people start experimenting with turning somethings on and off? I really don't know. They can do it now using kadmin.local I suppose, and we aren't hearing any complaints. Simo asked about upgrades. An interesting question. So we'd have to sift through all the krbextradata to see if any of the flags we want to set are actually set and update LDAP. We may end up requiring a C tool to do this. Mixing old and new backends could be supported during a transition period by setting the value both in the attribute and within krbextradata but we lack a way to do that in python AFAIK. Doing this in a 398-ds plugin might be an easy way to support forwards and backwards compatibility, and it'd be C so we'd avoid all the python issues. Adding the new schema and plugin should be the easy part. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PROPOSAL] Kerberos flags
On Fri, 2013-03-08 at 10:27 +0100, Sumit Bose wrote: On Thu, Mar 07, 2013 at 03:15:18PM -0500, Rob Crittenden wrote: Based on a comment from Sumit in ticket https://fedorahosted.org/freeipa/ticket/3329 here is a bare outline of how one might do it: http://freeipa.org/page/V3/Kerberos_Flags There is a bit of hand waving going on around how the flags are actually set inside the KDB plugin since I'm not at all familiar with that code but I don't expect it to be too big a deal. I'm not necessarily volunteering to do this work, just trying to keep the ball moving forward. Thank you for setting up the design page. I would like to suggest that we should try to include all currently available flags in one run, because: - some flags related to OTP would be needed as well I'm not aware of any. Are you? I may very well be missing something obvious. Nathaniel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PROPOSAL] Kerberos flags
On 8.3.2013 16:45, Rob Crittenden wrote: One would need to pass in the object type they are dealing with: ipa krbflags --type=user --ok-as-delegate=false sbose ipa krbflags --type=service --ok-as-delegate=true HTTP/ipa.example.com We *could* avoid type potentially but it would expand our search base and could slow things down with lots of entries. Correct me if I'm wrong, but our KDC driver usually does sub-tree search with base dc=example,dc=com. (Except some special cases.) Or not? :-) We could search on the accounts container using (objectclass=ipaKrbPrincipal) and (|(uid=CRITERIA)(fqdn=CRITERIA)(krbprincipalname=CRITERIA)) or something like that. I think I'd prefer specifying a type to avoid the case where someone has a hostname the same as a uid (we typically allow specifying non-fqdn when managing hosts). Would it be possible define some reasonable default value for --type? I don't like typing --service all the time ... -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PROPOSAL] Kerberos flags
On Fri, Mar 08, 2013 at 12:28:03PM -0500, Nathaniel McCallum wrote: On Fri, 2013-03-08 at 10:27 +0100, Sumit Bose wrote: On Thu, Mar 07, 2013 at 03:15:18PM -0500, Rob Crittenden wrote: Based on a comment from Sumit in ticket https://fedorahosted.org/freeipa/ticket/3329 here is a bare outline of how one might do it: http://freeipa.org/page/V3/Kerberos_Flags There is a bit of hand waving going on around how the flags are actually set inside the KDB plugin since I'm not at all familiar with that code but I don't expect it to be too big a deal. I'm not necessarily volunteering to do this work, just trying to keep the ball moving forward. Thank you for setting up the design page. I would like to suggest that we should try to include all currently available flags in one run, because: - some flags related to OTP would be needed as well I'm not aware of any. Are you? I may very well be missing something obvious. iirc you once mentioned that requires_hwauth is used to signal the client that an OTP is needed. But I haven't checked your recent code if the flag is added behind the scenes or if it needs to be set for the principal. bye, Sumit Nathaniel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PROPOSAL] Kerberos flags
On Fri, 2013-03-08 at 18:53 +0100, Sumit Bose wrote: On Fri, Mar 08, 2013 at 12:28:03PM -0500, Nathaniel McCallum wrote: On Fri, 2013-03-08 at 10:27 +0100, Sumit Bose wrote: On Thu, Mar 07, 2013 at 03:15:18PM -0500, Rob Crittenden wrote: Based on a comment from Sumit in ticket https://fedorahosted.org/freeipa/ticket/3329 here is a bare outline of how one might do it: http://freeipa.org/page/V3/Kerberos_Flags There is a bit of hand waving going on around how the flags are actually set inside the KDB plugin since I'm not at all familiar with that code but I don't expect it to be too big a deal. I'm not necessarily volunteering to do this work, just trying to keep the ball moving forward. Thank you for setting up the design page. I would like to suggest that we should try to include all currently available flags in one run, because: - some flags related to OTP would be needed as well I'm not aware of any. Are you? I may very well be missing something obvious. iirc you once mentioned that requires_hwauth is used to signal the client that an OTP is needed. But I haven't checked your recent code if the flag is added behind the scenes or if it needs to be set for the principal. We chose to abandon this since this flag is passed to the recipients of the ticket and since OTP doesn't necessarily provide hardware guarantee. Note that requires_hwauth is an RFC defined flag and admins may wish to use it, so support for it should probably be present. However, it is unrelated to OTP at this point. Nathaniel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PROPOSAL] Kerberos flags
Petr Spacek wrote: On 8.3.2013 16:45, Rob Crittenden wrote: One would need to pass in the object type they are dealing with: ipa krbflags --type=user --ok-as-delegate=false sbose ipa krbflags --type=service --ok-as-delegate=true HTTP/ipa.example.com We *could* avoid type potentially but it would expand our search base and could slow things down with lots of entries. Correct me if I'm wrong, but our KDC driver usually does sub-tree search with base dc=example,dc=com. (Except some special cases.) Or not? :-) Yes but when we do that search we've got a full principal. Consider the host plugin. If we are given a non-fully-qualified hostname we add the IPA domain by default when looking for things. It is not uncommon for people to name their laptop after themselves. So if we are told to add a flag to the pspacek principal, which one is it? The user pspacek or the host pspacek.example.com? Or we could require that hostnames are fully-qualified, it would just be a difference from other plugins. We could search on the accounts container using (objectclass=ipaKrbPrincipal) and (|(uid=CRITERIA)(fqdn=CRITERIA)(krbprincipalname=CRITERIA)) or something like that. I think I'd prefer specifying a type to avoid the case where someone has a hostname the same as a uid (we typically allow specifying non-fqdn when managing hosts). Would it be possible define some reasonable default value for --type? I don't like typing --service all the time ... Maybe, if we can assume what type of principal is most likely to be updated. Remember that the host/ principal is stored in a host, not a service record. Then again, I don't know how often one is going to be adding flags to principals, so perhaps a required switch wouldn't be too onerous. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
