Re: [Freeipa-devel] Kerberos over HTTPS (KDC proxy)
On Fri, 2015-05-29 at 17:23 -0400, Adam Young wrote: On 05/28/2015 01: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. Depends on if you consider it a different service from Kerberos. It is just a different protocol, and in the HTTP world would have been handled by a content type. That said, I could see the argument that the proxy is designed primarily to run in the DMZ, not where the IPA server is normally deployed, and the setup of the proxy really should be considered an architectual design decision. Deploying it on the same host as the IPA server doesn't really serve the main use case. It really depends on how you define the main use case which is really dependent on the deployment. For example, in some deployments MS-KKDCP can be used as a privacy enhancing tool and always used instead of TCP/UDP as the HTTPS channel will prevent an observer from seeing fields that are normally plain text in the raw kerberos protocol, like principal names. So I wouldn't characterize this transport as DMZ-only, and wouldn't assume there is only one use case. 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 05/28/2015 01: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. Depends on if you consider it a different service from Kerberos. It is just a different protocol, and in the HTTP world would have been handled by a content type. That said, I could see the argument that the proxy is designed primarily to run in the DMZ, not where the IPA server is normally deployed, and the setup of the proxy really should be considered an architectual design decision. Deploying it on the same host as the IPA server doesn't really serve the main use case. -- 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] Kerberos over HTTPS (KDC proxy)
On 26.5.2015 17:56, Christian Heimes wrote: On 2015-05-26 17:11, Nathaniel McCallum wrote: I don't want to add code that: 1. is half-baked 2. we aren't committed to supporting. I'd rather land per-replica switches as a separate commit with everything polished and supportable. Well then ... I'm going to remove the code for per-replica config and go back to the global switch. Since I'm now familiar with the code, it's easy for me to add it back, in case we need it again. :) I do not see a *need* for the user interface to the per-replica switch. We do not have such switch for any other optional component, like DNS. IMHO it is perfectly fine to have only per-replica switch as we do for all other components - and do not have user interface to the switch as we do not have it for any other component. It would be consistent, easy, and future proof. -- 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-27 11:59, Martin Kosek wrote: On 05/27/2015 11:53 AM, Alexander Bokovoy wrote: On Wed, 27 May 2015, Martin Kosek wrote: On 05/26/2015 05:40 PM, Jan Cholasta wrote: Dne 22.5.2015 v 12:24 Christian Heimes napsal(a): ... Finally I haven't figured out the best way to configure the instance. An admin should be able to enable / disable KDC proxy. Should I write a script or a ipa plugin for the job? A script, ipa-kdcproxy-install, if you want to be consistent with what's already there. I thought we wanted to install it by default and only switch it on/off via configuration in LDAP. In that case, no ipa-*-install should be needed. As with any other feature which requires configuration of other components, if it wasn't installed before, you need to make sure you are able to configure it over upgraded instance. Not providing ipa-kdcproxy-install would mean you are not supporting an upgrade case. I do not disagree with the approach for optional components. But as I wrote above, this was supposed to be configured everywhere by default - both on new and upgraded installations. AFAIK, it is mostly just one config for Apache and wsgi script. Yes, it is really just one boolean switch (service enabled/disabled). The state of the switch is read when Apache is started or reloaded. In the default state KDC Proxy is enabled. When the service is disabled, the WSGI script replies with 404 instead. All remaining settings like kdc, kadmin and kpasswd server(s) are read from /etc/krb5.conf. I had both the per-replica and the global switch implemented. After I discussion with Nathaniel and Martin, it's now a global switch only. Nathaniel argued, that a global switch is easier to implement as well as sufficient for now. The state of the switch is controlled with ipa config-mod: ipa config-mod --enable-kdcproxy=TRUE ipa config-mod --enable-kdcproxy=FALSE The schema changes for the new attribute are handled by ipa-server-upgrade. The Apache config file is created ipa-server-install, ipa-replica-install and ipa-server-upgrade. 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] Kerberos over HTTPS (KDC proxy)
On 05/26/2015 05:40 PM, Jan Cholasta wrote: Dne 22.5.2015 v 12:24 Christian Heimes napsal(a): ... Finally I haven't figured out the best way to configure the instance. An admin should be able to enable / disable KDC proxy. Should I write a script or a ipa plugin for the job? A script, ipa-kdcproxy-install, if you want to be consistent with what's already there. I thought we wanted to install it by default and only switch it on/off via configuration in LDAP. In that case, no ipa-*-install should be needed. -- 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/27/2015 11:53 AM, Alexander Bokovoy wrote: On Wed, 27 May 2015, Martin Kosek wrote: On 05/26/2015 05:40 PM, Jan Cholasta wrote: Dne 22.5.2015 v 12:24 Christian Heimes napsal(a): ... Finally I haven't figured out the best way to configure the instance. An admin should be able to enable / disable KDC proxy. Should I write a script or a ipa plugin for the job? A script, ipa-kdcproxy-install, if you want to be consistent with what's already there. I thought we wanted to install it by default and only switch it on/off via configuration in LDAP. In that case, no ipa-*-install should be needed. As with any other feature which requires configuration of other components, if it wasn't installed before, you need to make sure you are able to configure it over upgraded instance. Not providing ipa-kdcproxy-install would mean you are not supporting an upgrade case. I do not disagree with the approach for optional components. But as I wrote above, this was supposed to be configured everywhere by default - both on new and upgraded installations. AFAIK, it is mostly just one config for Apache and wsgi script. -- 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/27/2015 01:33 PM, Christian Heimes wrote: On 2015-05-27 11:59, Martin Kosek wrote: On 05/27/2015 11:53 AM, Alexander Bokovoy wrote: On Wed, 27 May 2015, Martin Kosek wrote: On 05/26/2015 05:40 PM, Jan Cholasta wrote: Dne 22.5.2015 v 12:24 Christian Heimes napsal(a): ... Finally I haven't figured out the best way to configure the instance. An admin should be able to enable / disable KDC proxy. Should I write a script or a ipa plugin for the job? A script, ipa-kdcproxy-install, if you want to be consistent with what's already there. I thought we wanted to install it by default and only switch it on/off via configuration in LDAP. In that case, no ipa-*-install should be needed. As with any other feature which requires configuration of other components, if it wasn't installed before, you need to make sure you are able to configure it over upgraded instance. Not providing ipa-kdcproxy-install would mean you are not supporting an upgrade case. I do not disagree with the approach for optional components. But as I wrote above, this was supposed to be configured everywhere by default - both on new and upgraded installations. AFAIK, it is mostly just one config for Apache and wsgi script. Yes, it is really just one boolean switch (service enabled/disabled). The state of the switch is read when Apache is started or reloaded. In the default state KDC Proxy is enabled. When the service is disabled, the WSGI script replies with 404 instead. All remaining settings like kdc, kadmin and kpasswd server(s) are read from /etc/krb5.conf. I had both the per-replica and the global switch implemented. After I discussion with Nathaniel and Martin, it's now a global switch only. Nathaniel argued, that a global switch is easier to implement as well as sufficient for now. The state of the switch is controlled with ipa config-mod: ipa config-mod --enable-kdcproxy=TRUE ipa config-mod --enable-kdcproxy=FALSE The schema changes for the new attribute are handled by ipa-server-upgrade. The Apache config file is created ipa-server-install, ipa-replica-install and ipa-server-upgrade. Thanks. This is all we need for 4.2, IMO. 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 Wed, 27 May 2015, Martin Kosek wrote: On 05/26/2015 05:40 PM, Jan Cholasta wrote: Dne 22.5.2015 v 12:24 Christian Heimes napsal(a): ... Finally I haven't figured out the best way to configure the instance. An admin should be able to enable / disable KDC proxy. Should I write a script or a ipa plugin for the job? A script, ipa-kdcproxy-install, if you want to be consistent with what's already there. I thought we wanted to install it by default and only switch it on/off via configuration in LDAP. In that case, no ipa-*-install should be needed. As with any other feature which requires configuration of other components, if it wasn't installed before, you need to make sure you are able to configure it over upgraded instance. Not providing ipa-kdcproxy-install would mean you are not supporting an upgrade case. -- / 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 05/27/2015 03:34 PM, Christian Heimes wrote: On 2015-05-27 14:47, Petr Vobornik wrote: Install/uninstall is not the same thing as enable/disable. Installation is a set of steps which first configures and then (optionally) enables the component. E.g: 1. modify configuration file(s), ldap entries 2. run something which starts the component. E.g. `systemctl start xxx`, an ldap change which is being observed (like topology plugin). The only rationale for external tool is to do stuff which can't be done trough API. E.g. restart of httpd.service or a need of Directory Manager. But in that case the tool should be: ipa-kdcproxy-manage enable|disable Right, the restart of httpd.service isn't handled by ipa config-mod. A tool like ipa-kdcproxy-manage could handle the restart on a local machine. As far as I know it won't be able to restart httpd on all replicas, too. My current implementation needs a restart of all Apache servers on all machines, that run a kdc proxy instance. Christian It would be great to have a privileged daemon which could observed replicated configuration and perform such tasks on all servers so we would eliminate manual tasks(and errors and misconceptions which are caused by forgotten manual tasks) as much as possible. -- 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 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. 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. 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 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 -- 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-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. My patch 0001 Provide Kerberos over HTTP (MS-KKDCP) has more details. 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] Kerberos over HTTPS (KDC proxy)
On 05/27/2015 01:57 PM, Jan Cholasta wrote: Dne 27.5.2015 v 13:34 Martin Kosek napsal(a): On 05/27/2015 01:33 PM, Christian Heimes wrote: On 2015-05-27 11:59, Martin Kosek wrote: On 05/27/2015 11:53 AM, Alexander Bokovoy wrote: On Wed, 27 May 2015, Martin Kosek wrote: On 05/26/2015 05:40 PM, Jan Cholasta wrote: Dne 22.5.2015 v 12:24 Christian Heimes napsal(a): ... Finally I haven't figured out the best way to configure the instance. An admin should be able to enable / disable KDC proxy. Should I write a script or a ipa plugin for the job? A script, ipa-kdcproxy-install, if you want to be consistent with what's already there. I thought we wanted to install it by default and only switch it on/off via configuration in LDAP. In that case, no ipa-*-install should be needed. As with any other feature which requires configuration of other components, if it wasn't installed before, you need to make sure you are able to configure it over upgraded instance. Not providing ipa-kdcproxy-install would mean you are not supporting an upgrade case. I do not disagree with the approach for optional components. But as I wrote above, this was supposed to be configured everywhere by default - both on new and upgraded installations. It doesn't matter whether it's installed by default or not. This is to support disabling and enabling the component - ipa-kdcproxy-install to enable, ipa-kdcproxy-install --uninstall to disable. Install/uninstall is not the same thing as enable/disable. Installation is a set of steps which first configures and then (optionally) enables the component. E.g: 1. modify configuration file(s), ldap entries 2. run something which starts the component. E.g. `systemctl start xxx`, an ldap change which is being observed (like topology plugin). The only rationale for external tool is to do stuff which can't be done trough API. E.g. restart of httpd.service or a need of Directory Manager. But in that case the tool should be: ipa-kdcproxy-manage enable|disable AFAIK, it is mostly just one config for Apache and wsgi script. Yes, it is really just one boolean switch (service enabled/disabled). The state of the switch is read when Apache is started or reloaded. In the default state KDC Proxy is enabled. When the service is disabled, the WSGI script replies with 404 instead. All remaining settings like kdc, kadmin and kpasswd server(s) are read from /etc/krb5.conf. This is just an implementation detail. I had both the per-replica and the global switch implemented. After I discussion with Nathaniel and Martin, it's now a global switch only. Nathaniel argued, that a global switch is easier to implement as well as sufficient for now. The state of the switch is controlled with ipa config-mod: 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. Could you be more specific? Is there really *one* way? The only optional components/functions of IPA server which can be turned on and off while still being installed are probably Managed Entry plugin(controlled by ipa-managed-entries) and a Migration mode(controlled in the same fashion as current proposal). Other optional components(CA, DNS, KRA) could be just installed later if they are not installed during server installation. They cannot be disabled nor uninstalled (KRA is exception, there is also uninstallation). So they are not the same case. The schema changes for the new attribute are handled by ipa-server-upgrade. The Apache config file is created ipa-server-install, ipa-replica-install and ipa-server-upgrade. Thanks. This is all we need for 4.2, IMO. Martin -- 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 Wed, 2015-05-27 at 15:41 +0200, Petr Vobornik wrote: On 05/27/2015 03:34 PM, Christian Heimes wrote: On 2015-05-27 14:47, Petr Vobornik wrote: Install/uninstall is not the same thing as enable/disable. Installation is a set of steps which first configures and then (optionally) enables the component. E.g: 1. modify configuration file(s), ldap entries 2. run something which starts the component. E.g. `systemctl start xxx`, an ldap change which is being observed (like topology plugin). The only rationale for external tool is to do stuff which can't be done trough API. E.g. restart of httpd.service or a need of Directory Manager. But in that case the tool should be: ipa-kdcproxy-manage enable|disable Right, the restart of httpd.service isn't handled by ipa config -mod. A tool like ipa-kdcproxy-manage could handle the restart on a local machine. As far as I know it won't be able to restart httpd on all replicas, too. My current implementation needs a restart of all Apache servers on all machines, that run a kdc proxy instance. Christian It would be great to have a privileged daemon which could observed replicated configuration and perform such tasks on all servers so we would eliminate manual tasks(and errors and misconceptions which are caused by forgotten manual tasks) as much as possible. *security shiver* -- 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 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. Simo. -- 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 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 not a separate service. 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)
Dne 27.5.2015 v 13:34 Martin Kosek napsal(a): On 05/27/2015 01:33 PM, Christian Heimes wrote: On 2015-05-27 11:59, Martin Kosek wrote: On 05/27/2015 11:53 AM, Alexander Bokovoy wrote: On Wed, 27 May 2015, Martin Kosek wrote: On 05/26/2015 05:40 PM, Jan Cholasta wrote: Dne 22.5.2015 v 12:24 Christian Heimes napsal(a): ... Finally I haven't figured out the best way to configure the instance. An admin should be able to enable / disable KDC proxy. Should I write a script or a ipa plugin for the job? A script, ipa-kdcproxy-install, if you want to be consistent with what's already there. I thought we wanted to install it by default and only switch it on/off via configuration in LDAP. In that case, no ipa-*-install should be needed. As with any other feature which requires configuration of other components, if it wasn't installed before, you need to make sure you are able to configure it over upgraded instance. Not providing ipa-kdcproxy-install would mean you are not supporting an upgrade case. I do not disagree with the approach for optional components. But as I wrote above, this was supposed to be configured everywhere by default - both on new and upgraded installations. It doesn't matter whether it's installed by default or not. This is to support disabling and enabling the component - ipa-kdcproxy-install to enable, ipa-kdcproxy-install --uninstall to disable. AFAIK, it is mostly just one config for Apache and wsgi script. Yes, it is really just one boolean switch (service enabled/disabled). The state of the switch is read when Apache is started or reloaded. In the default state KDC Proxy is enabled. When the service is disabled, the WSGI script replies with 404 instead. All remaining settings like kdc, kadmin and kpasswd server(s) are read from /etc/krb5.conf. This is just an implementation detail. I had both the per-replica and the global switch implemented. After I discussion with Nathaniel and Martin, it's now a global switch only. Nathaniel argued, that a global switch is easier to implement as well as sufficient for now. The state of the switch is controlled with ipa config-mod: 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. The schema changes for the new attribute are handled by ipa-server-upgrade. The Apache config file is created ipa-server-install, ipa-replica-install and ipa-server-upgrade. Thanks. This is all we need for 4.2, IMO. Martin -- 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)
Dne 27.5.2015 v 14:47 Petr Vobornik napsal(a): On 05/27/2015 01:57 PM, Jan Cholasta wrote: Dne 27.5.2015 v 13:34 Martin Kosek napsal(a): On 05/27/2015 01:33 PM, Christian Heimes wrote: On 2015-05-27 11:59, Martin Kosek wrote: On 05/27/2015 11:53 AM, Alexander Bokovoy wrote: On Wed, 27 May 2015, Martin Kosek wrote: On 05/26/2015 05:40 PM, Jan Cholasta wrote: Dne 22.5.2015 v 12:24 Christian Heimes napsal(a): ... Finally I haven't figured out the best way to configure the instance. An admin should be able to enable / disable KDC proxy. Should I write a script or a ipa plugin for the job? A script, ipa-kdcproxy-install, if you want to be consistent with what's already there. I thought we wanted to install it by default and only switch it on/off via configuration in LDAP. In that case, no ipa-*-install should be needed. As with any other feature which requires configuration of other components, if it wasn't installed before, you need to make sure you are able to configure it over upgraded instance. Not providing ipa-kdcproxy-install would mean you are not supporting an upgrade case. I do not disagree with the approach for optional components. But as I wrote above, this was supposed to be configured everywhere by default - both on new and upgraded installations. It doesn't matter whether it's installed by default or not. This is to support disabling and enabling the component - ipa-kdcproxy-install to enable, ipa-kdcproxy-install --uninstall to disable. Install/uninstall is not the same thing as enable/disable. Installation is a set of steps which first configures and then (optionally) enables the component. The configuration steps exist for the sole purpose of making it possible to enable the component after they are done. The result of install is that the component is enabled, and the result of uninstall is that the component is disabled. So, in a way, they are the same thing. E.g: 1. modify configuration file(s), ldap entries 2. run something which starts the component. E.g. `systemctl start xxx`, an ldap change which is being observed (like topology plugin). Yes, and this boils down to: 1. enable KDC proxy in LDAP for KDC proxy. The only rationale for external tool is to do stuff which can't be done trough API. E.g. restart of httpd.service or a need of Directory Manager. But in that case the tool should be: There is no API for enabling/disabling components, so it can't be done through API. ipa-kdcproxy-manage enable|disable There is no ipa-ca-manage, ipa-dns-manage or ipa-kra-manage. AFAIK, it is mostly just one config for Apache and wsgi script. Yes, it is really just one boolean switch (service enabled/disabled). The state of the switch is read when Apache is started or reloaded. In the default state KDC Proxy is enabled. When the service is disabled, the WSGI script replies with 404 instead. All remaining settings like kdc, kadmin and kpasswd server(s) are read from /etc/krb5.conf. This is just an implementation detail. I had both the per-replica and the global switch implemented. After I discussion with Nathaniel and Martin, it's now a global switch only. Nathaniel argued, that a global switch is easier to implement as well as sufficient for now. The state of the switch is controlled with ipa config-mod: 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. Could you be more specific? Is there really *one* way? The only optional components/functions of IPA server which can be turned on and off while still being installed are probably Managed Entry plugin(controlled by ipa-managed-entries) and a Migration mode(controlled in the same fashion as current proposal). These are not components, but rather DS switches. Other optional components(CA, DNS, KRA) could be just installed later if they are not installed during server installation. They cannot be disabled nor uninstalled (KRA is exception, there is also uninstallation). So they are not the same case. They can be uninstalled, it's just not implemented yet :-) The schema changes for the new attribute are handled by ipa-server-upgrade. The Apache config file is created ipa-server-install, ipa-replica-install and ipa-server-upgrade. Thanks. This is all we need for 4.2, IMO. Martin -- 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 2015-05-27 14:47, Petr Vobornik wrote: Install/uninstall is not the same thing as enable/disable. Installation is a set of steps which first configures and then (optionally) enables the component. E.g: 1. modify configuration file(s), ldap entries 2. run something which starts the component. E.g. `systemctl start xxx`, an ldap change which is being observed (like topology plugin). The only rationale for external tool is to do stuff which can't be done trough API. E.g. restart of httpd.service or a need of Directory Manager. But in that case the tool should be: ipa-kdcproxy-manage enable|disable Right, the restart of httpd.service isn't handled by ipa config-mod. A tool like ipa-kdcproxy-manage could handle the restart on a local machine. As far as I know it won't be able to restart httpd on all replicas, too. My current implementation needs a restart of all Apache servers on all machines, that run a kdc proxy instance. 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] Kerberos over HTTPS (KDC proxy)
On Wed, 2015-05-27 at 15:41 +0200, Petr Vobornik wrote: On 05/27/2015 03:34 PM, Christian Heimes wrote: On 2015-05-27 14:47, Petr Vobornik wrote: Install/uninstall is not the same thing as enable/disable. Installation is a set of steps which first configures and then (optionally) enables the component. E.g: 1. modify configuration file(s), ldap entries 2. run something which starts the component. E.g. `systemctl start xxx`, an ldap change which is being observed (like topology plugin). The only rationale for external tool is to do stuff which can't be done trough API. E.g. restart of httpd.service or a need of Directory Manager. But in that case the tool should be: ipa-kdcproxy-manage enable|disable Right, the restart of httpd.service isn't handled by ipa config-mod. A tool like ipa-kdcproxy-manage could handle the restart on a local machine. As far as I know it won't be able to restart httpd on all replicas, too. My current implementation needs a restart of all Apache servers on all machines, that run a kdc proxy instance. Christian It would be great to have a privileged daemon which could observed replicated configuration and perform such tasks on all servers so we would eliminate manual tasks(and errors and misconceptions which are caused by forgotten manual tasks) as much as possible. Yes this is something we had a need for, for a while, we could, perhaps, turn custodia in such a service, or embed custodia in there, as they are both very privileged service that interact with LDAP to find information. Simo. -- Petr Vobornik -- 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-27 15:41, Petr Vobornik wrote: It would be great to have a privileged daemon which could observed replicated configuration and perform such tasks on all servers so we would eliminate manual tasks(and errors and misconceptions which are caused by forgotten manual tasks) as much as possible. We don't need a separate daemon, we already have an HTTP interface. A reload interface can be implemented with an additional route, e.g. GET /KdcProxy/refresh. It needs a bit of extra work in kdcproxy, kdcproxyshim.py and an ACL for the route. 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] Kerberos over HTTPS (KDC proxy)
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. -- 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)
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? My patch 0001 Provide Kerberos over HTTP (MS-KKDCP) has more details. Christian -- 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)
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.) Simo. -- 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)
Dne 22.5.2015 v 12:24 Christian Heimes napsal(a): Hello, since May 1st I'm a new Red Hat employee and developer with the FreeIPA team. Some of you may already recognize my name from my contributions to CPython core, Python security and TLS/SSL improvements, or a couple of PEPs. I'm very glad that I can now work on Open Source as a full time job. I haven't had any dealings with FreeIPA before and just rudimentary experience with LDAP and Kerberos as a developer. Over the past two weeks I have been digging through FreeIPA sources, read docs and played with its services. I'm slowly starting to grasp the building blocks. I was put in charge of MS-KKDCP integration into FreeIPA 4.2 [1]. The task is small and isolated enough for a new contributor. KKDCP stands for Kerberos KDC proxy protocol. It was developed by Microsoft to tunnel KDC requests over HTTPS. It's useful for firewalled environments where 88/TCP+UDP are blocked and only 80/TCP + 443/TCP are available. With KKDCP the client side wraps each Kerberos request in an additional ASN.1 sequence and sends it as POST request to a proxy. The proxy unpacks the request, forwards it to a KDC and returns its reply to the client. MIT krb5 supports [2] KKDCP since 1.13, Fedora has backports for 1.12. Nathaniel McCallum has written [3] a proxy server as WSGI app. I'm working on improvements and integration of the WSGI app into FreeIPA. Yesterday several bug fixes already landed in kdcproxy. The integration into FreeIPA is the tricky part for me. I'm not familiar enough with FreeIPA yet to understand possible implications, so I need your guidance. I already got some feedback from several people (Dmitri, Nathan, Nathaniel, Martin, Martin2, Petr, Alexander...). Here is what I have so far: 1) The FreeIPA webui already depends on Apache and mod_wsgi. KDC proxy will run from the same Apache HTTPD instance but it will use a different mod_wsgi daemon configuration. A second WSGI daemon is easily configured and allows us to tune the daemon for KDC proxy's needs. FreeIPA is mounted at /ipa, KDC Proxy will be available at /KdcProxy or /kdc. 2) For now we are not going to introduce a separate package freeipa-server-kdcproxy. freeipa-server will depend on python-kdcproxy and install all configuration files. Therefore the entry point /KdcProxy is always configured 3) An administrator must be able to enable/disable the new feature. The state of the switch will be read when Apache is started or reloaded. The feature must be configurable for each replica, too. A WSGI wrapper will read the setting from ipaConfigString=enabledService in cn=KDCPROXY,cn=$FQDN,cn=masters,cn=ipa,cn=etc. When the feature is disabled, it will reply with 404 Not Found error. 4) In order to read the state of the switch, the WSGI script needs to be able to connect to LDAP. I can use Apache's / FreeIPA webui's keytab to get a ticket for GSSAPI bind. However Apache has no permission to read ipaConfigStrings in the masters subtree. A new role/permission and ACI is required here. 5) python-kdcproxy can read its configuration from multiple places. For performance reasons we don't want DNS lookups. Therefore our proxy instance will only use libkrb5.so to read a list of KDCs, kpasswd and admin servers from /etc/krb5.conf. Open questions / issues --- For 3) and 4) the Apache HTTP principal must be able to read or at least compare the state of the switch. The ACIs in the masters tree forbid any access to ipaConfigString entries except for principals with 'System: Read IPA Masters' permission. Martin Basti and Petr Spacek have suggested that I introduce a new permission for the task. I haven't figured out how to configure and assign a new permission. Right now my experimental code uses this ACI: (targetfilter=(ipaConfigString=enabledService))(targetattr=ipaConfigString)(version 3.0; acl Compare enabledService access to masters; allow(search, compare) userdn = ldap:///all;;) I think a normal ACI is fine, I'm not sure if it even should be a permission, given we have no service group object in IPA for use in roles. However, access should be limited only to HTTP on IPA servers. I found ipaserver.install.service.Service and SimpleServiceInstance in the FreeIPA sources. As far as I understand the use of the classes, they are used in the installers to configure service instances. However the kdcproxy service instance is going to be special. It has no 1:1 relation to a system service. Instead it shares a system service (Apache HTTPD) with the HttpInstance for FreeIPA's webui. AFAIK no other service instance has such a relation. Go ahead, it doesn't really matter there is no 1:1 relation to a system service. I don't think the services were supposed to have a 1:1 relation to system services in the first place. Notice how none of the older service names refer to a particular system service, but rather name what kind of service is provided (HTTP, DNS, CA, ...). It was only
Re: [Freeipa-devel] Kerberos over HTTPS (KDC proxy)
On Fri, 2015-05-22 at 12:24 +0200, Christian Heimes wrote: Here is what I have so far: 1) The FreeIPA webui already depends on Apache and mod_wsgi. KDC proxy will run from the same Apache HTTPD instance but it will use a different mod_wsgi daemon configuration. A second WSGI daemon is easily configured and allows us to tune the daemon for KDC proxy's needs. FreeIPA is mounted at /ipa, KDC Proxy will be available at /KdcProxy or /kdc. /KdcProxy The URI uses the virtual directory /KdcProxy unless otherwise configured. https://msdn.microsoft.com/en-us/library/hh553891.aspx Also, the proxy should be available over both HTTP and HTTPS. 3) An administrator must be able to enable/disable the new feature. The state of the switch will be read when Apache is started or reloaded. The feature must be configurable for each replica, too. A WSGI wrapper will read the setting from ipaConfigString=enabledService in cn=KDCPROXY,cn=$FQDN,cn=masters,cn=ipa,cn=etc. When the feature is disabled, it will reply with 404 Not Found error. I prefer enabled by default unless there is some performance or security consideration. Mere proxying isn't a security consideration since we already expose the KDC by default. 4) In order to read the state of the switch, the WSGI script needs to be able to connect to LDAP. I can use Apache's / FreeIPA webui's keytab to get a ticket for GSSAPI bind. However Apache has no permission to read ipaConfigStrings in the masters subtree. A new role/permission and ACI is required here. This is, indeed, a security problem. Do we have a strong use case for per-replica control? If not, let's just do a single global control since we can easily make this globally readable. 5) python-kdcproxy can read its configuration from multiple places. For performance reasons we don't want DNS lookups. Therefore our proxy instance will only use libkrb5.so to read a list of KDCs, kpasswd and admin servers from /etc/krb5.conf. Open questions / issues --- For 3) and 4) the Apache HTTP principal must be able to read or at least compare the state of the switch. The ACIs in the masters tree forbid any access to ipaConfigString entries except for principals with 'System: Read IPA Masters' permission. Martin Basti and Petr Spacek have suggested that I introduce a new permission for the task. I haven't figured out how to configure and assign a new permission. Right now my experimental code uses this ACI: (targetfilter=(ipaConfigString=enabledService))(targetattr=ipaConf igString)(version 3.0; acl Compare enabledService access to masters; allow(search, compare) userdn = ldap:///all;;) I found ipaserver.install.service.Service and SimpleServiceInstance in the FreeIPA sources. As far as I understand the use of the classes, they are used in the installers to configure service instances. However the kdcproxy service instance is going to be special. It has no 1:1 relation to a system service. Instead it shares a system service (Apache HTTPD) with the HttpInstance for FreeIPA's webui. AFAIK no other service instance has such a relation. Finally I haven't figured out the best way to configure the instance. An admin should be able to enable / disable KDC proxy. Should I write a script or a ipa plugin for the job? IMHO, use a global switch and put the control in the ipa config plugin. We shouldn't over-engineer this. 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] Kerberos over HTTPS (KDC proxy)
On 2015-05-26 15:57, Nathaniel McCallum wrote: /KdcProxy The URI uses the virtual directory /KdcProxy unless otherwise configured. https://msdn.microsoft.com/en-us/library/hh553891.aspx Also, the proxy should be available over both HTTP and HTTPS. Easy-peasy! I'm using /KdcProxy already and the default configuration allows HTTP and HTTPS requests. I prefer enabled by default unless there is some performance or security consideration. Mere proxying isn't a security consideration since we already expose the KDC by default. My latest patch enables the proxy by default. This is, indeed, a security problem. Do we have a strong use case for per-replica control? If not, let's just do a single global control since we can easily make this globally readable. Martin and Petr both suggested per-replica configuration of the new feature. Petr has argued it is a future-proof design. It will make containerization of FreeIPA simpler as no schema change is required later. 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] Kerberos over HTTPS (KDC proxy)
On 05/26/2015 04:17 PM, Christian Heimes wrote:
On 2015-05-26 15:57, Nathaniel McCallum wrote:
/KdcProxy
The URI uses the virtual directory /KdcProxy unless otherwise
configured.
https://msdn.microsoft.com/en-us/library/hh553891.aspx
Also, the proxy should be available over both HTTP and HTTPS.
Easy-peasy! I'm using /KdcProxy already and the default configuration
allows HTTP and HTTPS requests.
Just make sure it works with the IPA might https rewrite rule:
# Redirect to the secure port if not displaying an error or retrieving
# configuration.
RewriteCond %{SERVER_PORT} !^443$$
RewriteCond %{REQUEST_URI} !^/ipa/(errors|config|crl)
RewriteCond %{REQUEST_URI}
!^/ipa/[^\?]+(\.js|\.css|\.png|\.gif|\.ico|\.woff|\.svg|\.ttf|\.eot)$$
RewriteRule ^/ipa/(.*) https://$FQDN/ipa/$$1 [L,R=301,NC]
I prefer enabled by default unless there is some performance or
security consideration. Mere proxying isn't a security consideration
since we already expose the KDC by default.
My latest patch enables the proxy by default.
This is, indeed, a security problem. Do we have a strong use case for
per-replica control? If not, let's just do a single global control
since we can easily make this globally readable.
Martin and Petr both suggested per-replica configuration of the new
feature. Petr has argued it is a future-proof design. It will make
containerization of FreeIPA simpler as no schema change is required later.
I discussed this briefly with Nathaniel, if this is sufficiently easy/doable, I
am fine with it. If not, then adding the global control may be the way for
FreeIPA 4.2 GA and implement the per-replica control later.
--
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 Tue, 2015-05-26 at 16:43 +0200, Christian Heimes wrote:
On 2015-05-26 16:24, Martin Kosek wrote:
On 05/26/2015 04:17 PM, Christian Heimes wrote:
On 2015-05-26 15:57, Nathaniel McCallum wrote:
/KdcProxy
The URI uses the virtual directory /KdcProxy unless otherwise
configured.
https://msdn.microsoft.com/en-us/library/hh553891.aspx
Also, the proxy should be available over both HTTP and HTTPS.
Easy-peasy! I'm using /KdcProxy already and the default
configuration
allows HTTP and HTTPS requests.
Just make sure it works with the IPA might https rewrite rule:
# Redirect to the secure port if not displaying an error or
retrieving
# configuration.
RewriteCond %{SERVER_PORT} !^443$$
RewriteCond %{REQUEST_URI} !^/ipa/(errors|config|crl)
RewriteCond %{REQUEST_URI}
!^/ipa/[^\?]+(\.js|\.css|\.png|\.gif|\.ico|\.woff|\.svg|\.ttf|\.eot
)$$
RewriteRule ^/ipa/(.*) https://$FQDN/ipa/$$1 [L,R=301,NC]
The KDC proxy WSGI app is mounted at /KdcProxy. The IPA rewrite rule
only affect /ipa* paths.
I discussed this briefly with Nathaniel, if this is sufficiently
easy/doable, I am fine with it. If not, then adding the global
control
may be the way for FreeIPA 4.2 GA and implement the per-replica
control
later.
I guess the per-replica configuration is a bit more work. As far as I
know FreeIPA has no command line tool to enable/disable services in
the
cn=masters,cn=ipa,cn=etc subtree. For starters Petr Vobornik has
suggested an API command to list IPA servers. His proposal doesn't
include an API to modify services of a server, though.
Right. So as I see it, we have three options:
1. Merge kdcproxy soon with a global switch.
A. Build per-replica switches later.
B. Never build per-replica switches.
2. Merge kdcproxy later with per-replica switches.
I don't think having both types of switches is bad UX. In fact, I think
it is better UX than per-replica switches alone. Since per-replica
switches are a superset of the global switch functionality, let's do 1A
and do per-replica switches later (if needed and feasible)
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] Kerberos over HTTPS (KDC proxy)
On 2015-05-26 16:24, Martin Kosek wrote:
On 05/26/2015 04:17 PM, Christian Heimes wrote:
On 2015-05-26 15:57, Nathaniel McCallum wrote:
/KdcProxy
The URI uses the virtual directory /KdcProxy unless otherwise
configured.
https://msdn.microsoft.com/en-us/library/hh553891.aspx
Also, the proxy should be available over both HTTP and HTTPS.
Easy-peasy! I'm using /KdcProxy already and the default configuration
allows HTTP and HTTPS requests.
Just make sure it works with the IPA might https rewrite rule:
# Redirect to the secure port if not displaying an error or retrieving
# configuration.
RewriteCond %{SERVER_PORT} !^443$$
RewriteCond %{REQUEST_URI} !^/ipa/(errors|config|crl)
RewriteCond %{REQUEST_URI}
!^/ipa/[^\?]+(\.js|\.css|\.png|\.gif|\.ico|\.woff|\.svg|\.ttf|\.eot)$$
RewriteRule ^/ipa/(.*) https://$FQDN/ipa/$$1 [L,R=301,NC]
The KDC proxy WSGI app is mounted at /KdcProxy. The IPA rewrite rule
only affect /ipa* paths.
I discussed this briefly with Nathaniel, if this is sufficiently
easy/doable, I am fine with it. If not, then adding the global control
may be the way for FreeIPA 4.2 GA and implement the per-replica control
later.
I guess the per-replica configuration is a bit more work. As far as I
know FreeIPA has no command line tool to enable/disable services in the
cn=masters,cn=ipa,cn=etc subtree. For starters Petr Vobornik has
suggested an API command to list IPA servers. His proposal doesn't
include an API to modify services of a server, though.
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] Kerberos over HTTPS (KDC proxy)
On 2015-05-26 16:50, Nathaniel McCallum wrote: Right. So as I see it, we have three options: 1. Merge kdcproxy soon with a global switch. A. Build per-replica switches later. B. Never build per-replica switches. 2. Merge kdcproxy later with per-replica switches. I don't think having both types of switches is bad UX. In fact, I think it is better UX than per-replica switches alone. Since per-replica switches are a superset of the global switch functionality, let's do 1A and do per-replica switches later (if needed and feasible) You know what? That was basically my second implementation. :) I had a global switch in cn=ipaConfig,cn=etc and a per-replica switch in cn=KDCPROXY,cn=$FQDN,cn=masters,cn=ipa,cn=etc. The code is still in another branch on my laptop. Since I have both variants mostly implemented, I'd like to suggest yet another option: 2. Merge kdcproxy with global and per-replica switch, but for now offer only a CLI command for the global switch. That's easy to implement. I only need an ACI for cn=masters,cn=ipa,cn=etc in order to allow compare and search for ipaConfigString=enabledService. 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] Kerberos over HTTPS (KDC proxy)
On Tue, 2015-05-26 at 17:09 +0200, Christian Heimes wrote: On 2015-05-26 16:50, Nathaniel McCallum wrote: Right. So as I see it, we have three options: 1. Merge kdcproxy soon with a global switch. A. Build per-replica switches later. B. Never build per-replica switches. 2. Merge kdcproxy later with per-replica switches. I don't think having both types of switches is bad UX. In fact, I think it is better UX than per-replica switches alone. Since per-replica switches are a superset of the global switch functionality, let's do 1A and do per-replica switches later (if needed and feasible) You know what? That was basically my second implementation. :) I had a global switch in cn=ipaConfig,cn=etc and a per-replica switch in cn=KDCPROXY,cn=$FQDN,cn=masters,cn=ipa,cn=etc. The code is still in another branch on my laptop. Since I have both variants mostly implemented, I'd like to suggest yet another option: 2. Merge kdcproxy with global and per-replica switch, but for now offer only a CLI command for the global switch. That's easy to implement. I only need an ACI for cn=masters,cn=ipa,cn=etc in order to allow compare and search for ipaConfigString=enabledService. I don't want to add code that: 1. is half-baked 2. we aren't committed to supporting. I'd rather land per-replica switches as a separate commit with everything polished and supportable. 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] Kerberos over HTTPS (KDC proxy)
On 2015-05-26 17:11, Nathaniel McCallum wrote: I don't want to add code that: 1. is half-baked 2. we aren't committed to supporting. I'd rather land per-replica switches as a separate commit with everything polished and supportable. Well then ... I'm going to remove the code for per-replica config and go back to the global switch. Since I'm now familiar with the code, it's easy for me to add it back, in case we need it again. :) 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
[Freeipa-devel] Kerberos over HTTPS (KDC proxy)
Hello, since May 1st I'm a new Red Hat employee and developer with the FreeIPA team. Some of you may already recognize my name from my contributions to CPython core, Python security and TLS/SSL improvements, or a couple of PEPs. I'm very glad that I can now work on Open Source as a full time job. I haven't had any dealings with FreeIPA before and just rudimentary experience with LDAP and Kerberos as a developer. Over the past two weeks I have been digging through FreeIPA sources, read docs and played with its services. I'm slowly starting to grasp the building blocks. I was put in charge of MS-KKDCP integration into FreeIPA 4.2 [1]. The task is small and isolated enough for a new contributor. KKDCP stands for Kerberos KDC proxy protocol. It was developed by Microsoft to tunnel KDC requests over HTTPS. It's useful for firewalled environments where 88/TCP+UDP are blocked and only 80/TCP + 443/TCP are available. With KKDCP the client side wraps each Kerberos request in an additional ASN.1 sequence and sends it as POST request to a proxy. The proxy unpacks the request, forwards it to a KDC and returns its reply to the client. MIT krb5 supports [2] KKDCP since 1.13, Fedora has backports for 1.12. Nathaniel McCallum has written [3] a proxy server as WSGI app. I'm working on improvements and integration of the WSGI app into FreeIPA. Yesterday several bug fixes already landed in kdcproxy. The integration into FreeIPA is the tricky part for me. I'm not familiar enough with FreeIPA yet to understand possible implications, so I need your guidance. I already got some feedback from several people (Dmitri, Nathan, Nathaniel, Martin, Martin2, Petr, Alexander...). Here is what I have so far: 1) The FreeIPA webui already depends on Apache and mod_wsgi. KDC proxy will run from the same Apache HTTPD instance but it will use a different mod_wsgi daemon configuration. A second WSGI daemon is easily configured and allows us to tune the daemon for KDC proxy's needs. FreeIPA is mounted at /ipa, KDC Proxy will be available at /KdcProxy or /kdc. 2) For now we are not going to introduce a separate package freeipa-server-kdcproxy. freeipa-server will depend on python-kdcproxy and install all configuration files. Therefore the entry point /KdcProxy is always configured 3) An administrator must be able to enable/disable the new feature. The state of the switch will be read when Apache is started or reloaded. The feature must be configurable for each replica, too. A WSGI wrapper will read the setting from ipaConfigString=enabledService in cn=KDCPROXY,cn=$FQDN,cn=masters,cn=ipa,cn=etc. When the feature is disabled, it will reply with 404 Not Found error. 4) In order to read the state of the switch, the WSGI script needs to be able to connect to LDAP. I can use Apache's / FreeIPA webui's keytab to get a ticket for GSSAPI bind. However Apache has no permission to read ipaConfigStrings in the masters subtree. A new role/permission and ACI is required here. 5) python-kdcproxy can read its configuration from multiple places. For performance reasons we don't want DNS lookups. Therefore our proxy instance will only use libkrb5.so to read a list of KDCs, kpasswd and admin servers from /etc/krb5.conf. Open questions / issues --- For 3) and 4) the Apache HTTP principal must be able to read or at least compare the state of the switch. The ACIs in the masters tree forbid any access to ipaConfigString entries except for principals with 'System: Read IPA Masters' permission. Martin Basti and Petr Spacek have suggested that I introduce a new permission for the task. I haven't figured out how to configure and assign a new permission. Right now my experimental code uses this ACI: (targetfilter=(ipaConfigString=enabledService))(targetattr=ipaConfigString)(version 3.0; acl Compare enabledService access to masters; allow(search, compare) userdn = ldap:///all;;) I found ipaserver.install.service.Service and SimpleServiceInstance in the FreeIPA sources. As far as I understand the use of the classes, they are used in the installers to configure service instances. However the kdcproxy service instance is going to be special. It has no 1:1 relation to a system service. Instead it shares a system service (Apache HTTPD) with the HttpInstance for FreeIPA's webui. AFAIK no other service instance has such a relation. Finally I haven't figured out the best way to configure the instance. An admin should be able to enable / disable KDC proxy. Should I write a script or a ipa plugin for the job? You can find my patch in my Github repos [4]. The installer code is mostly untested, though. Please advice :) Christian [1] https://www.freeipa.org/page/V4/KDC_Proxy [2] http://web.mit.edu/kerberos/krb5-current/doc/admin/https.html [3] https://github.com/npmccallum/kdcproxy [4] https://github.com/tiran/freeipa/compare/master...kdcproxy2 signature.asc Description: OpenPGP digital signature -- Manage your subscription for the
Re: [Freeipa-devel] Kerberos over HTTPS (KDC proxy)
On 05/22/2015 12:24 PM, Christian Heimes wrote: Hello, since May 1st I'm a new Red Hat employee and developer with the FreeIPA team. Some of you may already recognize my name from my contributions to CPython core, Python security and TLS/SSL improvements, or a couple of PEPs. I'm very glad that I can now work on Open Source as a full time job. I haven't had any dealings with FreeIPA before and just rudimentary experience with LDAP and Kerberos as a developer. Over the past two weeks I have been digging through FreeIPA sources, read docs and played with its services. I'm slowly starting to grasp the building blocks. I was put in charge of MS-KKDCP integration into FreeIPA 4.2 [1]. The task is small and isolated enough for a new contributor. KKDCP stands for Kerberos KDC proxy protocol. It was developed by Microsoft to tunnel KDC requests over HTTPS. It's useful for firewalled environments where 88/TCP+UDP are blocked and only 80/TCP + 443/TCP are available. With KKDCP the client side wraps each Kerberos request in an additional ASN.1 sequence and sends it as POST request to a proxy. The proxy unpacks the request, forwards it to a KDC and returns its reply to the client. MIT krb5 supports [2] KKDCP since 1.13, Fedora has backports for 1.12. Nathaniel McCallum has written [3] a proxy server as WSGI app. I'm working on improvements and integration of the WSGI app into FreeIPA. Yesterday several bug fixes already landed in kdcproxy. The integration into FreeIPA is the tricky part for me. I'm not familiar enough with FreeIPA yet to understand possible implications, so I need your guidance. I already got some feedback from several people (Dmitri, Nathan, Nathaniel, Martin, Martin2, Petr, Alexander...). Here is what I have so far: 1) The FreeIPA webui already depends on Apache and mod_wsgi. KDC proxy will run from the same Apache HTTPD instance but it will use a different mod_wsgi daemon configuration. A second WSGI daemon is easily configured and allows us to tune the daemon for KDC proxy's needs. FreeIPA is mounted at /ipa, KDC Proxy will be available at /KdcProxy or /kdc. Right. 2) For now we are not going to introduce a separate package freeipa-server-kdcproxy. freeipa-server will depend on python-kdcproxy and install all configuration files. Therefore the entry point /KdcProxy is always configured Right. 3) An administrator must be able to enable/disable the new feature. The state of the switch will be read when Apache is started or reloaded. The feature must be configurable for each replica, too. A WSGI wrapper will read the setting from ipaConfigString=enabledService in cn=KDCPROXY,cn=$FQDN,cn=masters,cn=ipa,cn=etc. When the feature is disabled, it will reply with 404 Not Found error. The original proposal was to do it globally in cn=config. But if it is about to be stored in the cn=masters, per-replica, this looks as the right way. What API did you plan using, for enabling/disabling service? If we go the general IPA service way, should we extend the planned service-* API that Petr Vobornik announced in http://www.redhat.com/archives/freeipa-devel/2015-May/msg00309.html and have command like serverservice-mod ipa.server kdcproxy --enabled=0? 4) In order to read the state of the switch, the WSGI script needs to be able to connect to LDAP. I can use Apache's / FreeIPA webui's keytab to get a ticket for GSSAPI bind. However Apache has no permission to read ipaConfigStrings in the masters subtree. A new role/permission and ACI is required here. There is already a permission 'System: Read IPA Masters' and privilege IPA Masters Readers defined, in ipaserver/install/plugins/update_managed_permissions.py. Can this be used? 5) python-kdcproxy can read its configuration from multiple places. For performance reasons we don't want DNS lookups. Therefore our proxy instance will only use libkrb5.so to read a list of KDCs, kpasswd and admin servers from /etc/krb5.conf. Ok. Open questions / issues --- For 3) and 4) the Apache HTTP principal must be able to read or at least compare the state of the switch. The ACIs in the masters tree forbid any access to ipaConfigString entries except for principals with 'System: Read IPA Masters' permission. Martin Basti and Petr Spacek have suggested that I introduce a new permission for the task. I haven't figured out how to configure and assign a new permission. Right now my experimental code uses this ACI: (targetfilter=(ipaConfigString=enabledService))(targetattr=ipaConfigString)(version 3.0; acl Compare enabledService access to masters; allow(search, compare) userdn = ldap:///all;;) I found ipaserver.install.service.Service and SimpleServiceInstance in the FreeIPA sources. As far as I understand the use of the classes, they are used in the installers to configure service instances. However the kdcproxy service instance is going to be special. It has no 1:1 relation to a system service. Instead it shares a system
Re: [Freeipa-devel] Kerberos over HTTPS (KDC proxy)
On 2015-05-22 13:02, Martin Kosek wrote: The original proposal was to do it globally in cn=config. But if it is about to be stored in the cn=masters, per-replica, this looks as the right way. My first proposal used cn=ipaConfig,cn=etc because it was the first place I found. It took me a bit to find and understand the other subtrees in cn=etc. Other developers have pointed me to the cn=masters subtree. What API did you plan using, for enabling/disabling service? If we go the general IPA service way, should we extend the planned service-* API that Petr Vobornik announced in http://www.redhat.com/archives/freeipa-devel/2015-May/msg00309.html and have command like serverservice-mod ipa.server kdcproxy --enabled=0? I don't have concrete plans for an enabling/disabling API yet. It's one of the questions I have raised at the end of my mail. I'm going to study Petr Vobornik's mail now. In order to disable or enable KDC proxy, the switch in LDAP must be switched and Apache must be reloaded or restarted. The WSGI wrapper does NOT poll the state of the switch. 4) In order to read the state of the switch, the WSGI script needs to be able to connect to LDAP. I can use Apache's / FreeIPA webui's keytab to get a ticket for GSSAPI bind. However Apache has no permission to read ipaConfigStrings in the masters subtree. A new role/permission and ACI is required here. There is already a permission 'System: Read IPA Masters' and privilege IPA Masters Readers defined, in ipaserver/install/plugins/update_managed_permissions.py. Can this be used? The permission sounds too broad to me. There is probably a reason why all ipaConfigStrings entries are read-protected. I really just need search (and maybe compare) for ipaConfigString=enabledService. Thanks for your feedback, 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] Kerberos over HTTPS (KDC proxy)
On 05/22/2015 01:17 PM, Christian Heimes wrote: On 2015-05-22 13:02, Martin Kosek wrote: The original proposal was to do it globally in cn=config. But if it is about to be stored in the cn=masters, per-replica, this looks as the right way. My first proposal used cn=ipaConfig,cn=etc because it was the first place I found. It took me a bit to find and understand the other subtrees in cn=etc. Other developers have pointed me to the cn=masters subtree. What API did you plan using, for enabling/disabling service? If we go the general IPA service way, should we extend the planned service-* API that Petr Vobornik announced in http://www.redhat.com/archives/freeipa-devel/2015-May/msg00309.html and have command like serverservice-mod ipa.server kdcproxy --enabled=0? I don't have concrete plans for an enabling/disabling API yet. It's one of the questions I have raised at the end of my mail. I'm going to study Petr Vobornik's mail now. In order to disable or enable KDC proxy, the switch in LDAP must be switched and Apache must be reloaded or restarted. The WSGI wrapper does NOT poll the state of the switch. Actually the service part of IPA servers is not covered in the proposal. The proposal just says that it can be added later. There will be question if it should even be called services. Maybe capabilities would be better term given that KDC Proxy is not a standalone service. 4) In order to read the state of the switch, the WSGI script needs to be able to connect to LDAP. I can use Apache's / FreeIPA webui's keytab to get a ticket for GSSAPI bind. However Apache has no permission to read ipaConfigStrings in the masters subtree. A new role/permission and ACI is required here. There is already a permission 'System: Read IPA Masters' and privilege IPA Masters Readers defined, in ipaserver/install/plugins/update_managed_permissions.py. Can this be used? The permission sounds too broad to me. There is probably a reason why all ipaConfigStrings entries are read-protected. I really just need search (and maybe compare) for ipaConfigString=enabledService. Thanks for your feedback, Christian -- 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 22/05/15 13:02, Martin Kosek wrote: On 05/22/2015 12:24 PM, Christian Heimes wrote: Hello, since May 1st I'm a new Red Hat employee and developer with the FreeIPA team. Some of you may already recognize my name from my contributions to CPython core, Python security and TLS/SSL improvements, or a couple of PEPs. I'm very glad that I can now work on Open Source as a full time job. I haven't had any dealings with FreeIPA before and just rudimentary experience with LDAP and Kerberos as a developer. Over the past two weeks I have been digging through FreeIPA sources, read docs and played with its services. I'm slowly starting to grasp the building blocks. I was put in charge of MS-KKDCP integration into FreeIPA 4.2 [1]. The task is small and isolated enough for a new contributor. KKDCP stands for Kerberos KDC proxy protocol. It was developed by Microsoft to tunnel KDC requests over HTTPS. It's useful for firewalled environments where 88/TCP+UDP are blocked and only 80/TCP + 443/TCP are available. With KKDCP the client side wraps each Kerberos request in an additional ASN.1 sequence and sends it as POST request to a proxy. The proxy unpacks the request, forwards it to a KDC and returns its reply to the client. MIT krb5 supports [2] KKDCP since 1.13, Fedora has backports for 1.12. Nathaniel McCallum has written [3] a proxy server as WSGI app. I'm working on improvements and integration of the WSGI app into FreeIPA. Yesterday several bug fixes already landed in kdcproxy. The integration into FreeIPA is the tricky part for me. I'm not familiar enough with FreeIPA yet to understand possible implications, so I need your guidance. I already got some feedback from several people (Dmitri, Nathan, Nathaniel, Martin, Martin2, Petr, Alexander...). Here is what I have so far: 1) The FreeIPA webui already depends on Apache and mod_wsgi. KDC proxy will run from the same Apache HTTPD instance but it will use a different mod_wsgi daemon configuration. A second WSGI daemon is easily configured and allows us to tune the daemon for KDC proxy's needs. FreeIPA is mounted at /ipa, KDC Proxy will be available at /KdcProxy or /kdc. Right. 2) For now we are not going to introduce a separate package freeipa-server-kdcproxy. freeipa-server will depend on python-kdcproxy and install all configuration files. Therefore the entry point /KdcProxy is always configured Right. 3) An administrator must be able to enable/disable the new feature. The state of the switch will be read when Apache is started or reloaded. The feature must be configurable for each replica, too. A WSGI wrapper will read the setting from ipaConfigString=enabledService in cn=KDCPROXY,cn=$FQDN,cn=masters,cn=ipa,cn=etc. When the feature is disabled, it will reply with 404 Not Found error. The original proposal was to do it globally in cn=config. But if it is about to be stored in the cn=masters, per-replica, this looks as the right way. What API did you plan using, for enabling/disabling service? If we go the general IPA service way, should we extend the planned service-* API that Petr Vobornik announced in http://www.redhat.com/archives/freeipa-devel/2015-May/msg00309.html and have command like serverservice-mod ipa.server kdcproxy --enabled=0? 4) In order to read the state of the switch, the WSGI script needs to be able to connect to LDAP. I can use Apache's / FreeIPA webui's keytab to get a ticket for GSSAPI bind. However Apache has no permission to read ipaConfigStrings in the masters subtree. A new role/permission and ACI is required here. There is already a permission 'System: Read IPA Masters' and privilege IPA Masters Readers defined, in ipaserver/install/plugins/update_managed_permissions.py. Can this be used? Do we want to expose which services are configured and how they are configured for apache service? IMO this may be a security issue, to give overall read access to configuration of all services on all servers. 5) python-kdcproxy can read its configuration from multiple places. For performance reasons we don't want DNS lookups. Therefore our proxy instance will only use libkrb5.so to read a list of KDCs, kpasswd and admin servers from /etc/krb5.conf. Ok. Open questions / issues --- For 3) and 4) the Apache HTTP principal must be able to read or at least compare the state of the switch. The ACIs in the masters tree forbid any access to ipaConfigString entries except for principals with 'System: Read IPA Masters' permission. Martin Basti and Petr Spacek have suggested that I introduce a new permission for the task. I haven't figured out how to configure and assign a new permission. Right now my experimental code uses this ACI: (targetfilter=(ipaConfigString=enabledService))(targetattr=ipaConfigString)(version 3.0; acl Compare enabledService access to masters; allow(search, compare) userdn = ldap:///all;;) I found ipaserver.install.service.Service and SimpleServiceInstance in the
Re: [Freeipa-devel] Kerberos over HTTPS (KDC proxy)
On 2015-05-22 14:02, Petr Vobornik wrote: Actually the service part of IPA servers is not covered in the proposal. The proposal just says that it can be added later. There will be question if it should even be called services. Maybe capabilities would be better term given that KDC Proxy is not a standalone service. It's an implementation detail. KDC Proxy shares the Apache HTTP with webui because it is the simplest way. We don't have to create another certificate and an additional principal. However in the future that may change. For high traffic sites a separation of webui and KDC proxy may make sense. The KKDCP WSGI app has different tuning requirements than webui. 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
