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
