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

Reply via email to