Re: [Freeipa-devel] Kerberos over HTTPS (KDC proxy)

2015-05-30 Thread Simo Sorce
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)

2015-05-29 Thread Adam Young

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)

2015-05-28 Thread Christian Heimes
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)

2015-05-28 Thread Petr Spacek
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)

2015-05-28 Thread Christian Heimes
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)

2015-05-28 Thread Jan Cholasta

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)

2015-05-28 Thread Martin Kosek
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)

2015-05-28 Thread Martin Kosek
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)

2015-05-28 Thread Jan Cholasta

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)

2015-05-28 Thread Alexander Bokovoy

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)

2015-05-28 Thread Martin Basti

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)

2015-05-28 Thread Martin Kosek
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)

2015-05-28 Thread Petr Spacek
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)

2015-05-28 Thread Alexander Bokovoy

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)

2015-05-28 Thread Petr Spacek
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)

2015-05-28 Thread Jan Cholasta

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)

2015-05-28 Thread Martin Basti

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)

2015-05-28 Thread Martin Kosek
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)

2015-05-28 Thread Simo Sorce
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)

2015-05-28 Thread Christian Heimes
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)

2015-05-28 Thread Christian Heimes
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)

2015-05-27 Thread Petr Spacek
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)

2015-05-27 Thread Christian Heimes
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)

2015-05-27 Thread Martin Kosek
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)

2015-05-27 Thread Martin Kosek
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)

2015-05-27 Thread Martin Kosek
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)

2015-05-27 Thread Alexander Bokovoy

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)

2015-05-27 Thread Petr Vobornik

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)

2015-05-27 Thread Simo Sorce
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)

2015-05-27 Thread Nathaniel McCallum
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)

2015-05-27 Thread Christian Heimes
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)

2015-05-27 Thread Petr Vobornik

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)

2015-05-27 Thread Nathaniel McCallum
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)

2015-05-27 Thread Jan Cholasta

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)

2015-05-27 Thread Simo Sorce
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)

2015-05-27 Thread Jan Cholasta

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)

2015-05-27 Thread Jan Cholasta

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)

2015-05-27 Thread Christian Heimes
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)

2015-05-27 Thread Simo Sorce
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)

2015-05-27 Thread Christian Heimes
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)

2015-05-27 Thread Jan Cholasta

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)

2015-05-27 Thread Jan Cholasta

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)

2015-05-27 Thread Jan Cholasta

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)

2015-05-26 Thread Jan Cholasta

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)

2015-05-26 Thread Nathaniel McCallum
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)

2015-05-26 Thread Christian Heimes
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)

2015-05-26 Thread Martin Kosek

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)

2015-05-26 Thread Nathaniel McCallum
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)

2015-05-26 Thread Christian Heimes
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)

2015-05-26 Thread Christian Heimes
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)

2015-05-26 Thread Nathaniel McCallum
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)

2015-05-26 Thread Christian Heimes
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

Re: [Freeipa-devel] Kerberos over HTTPS (KDC proxy)

2015-05-22 Thread Martin Kosek

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)

2015-05-22 Thread Christian Heimes
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)

2015-05-22 Thread Petr Vobornik

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)

2015-05-22 Thread Martin Basti

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)

2015-05-22 Thread Christian Heimes
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