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 FreeIPA sources. As far as I understand the use of the classes, they
are used in the installers to configure service instances. However the
kdcproxy service instance is going to be special. It has no 1:1 relation
to a system service. Instead it shares a system service (Apache HTTPD)
with the HttpInstance for FreeIPA's webui. AFAIK no other service
instance has such a relation.
Finally I haven't figured out the best way to configure the instance. An
admin should be able to enable / disable KDC proxy. Should I write a
script or a ipa plugin for the job?
You can find my patch in my Github repos [4]. The installer code is
mostly untested, though.
Please advice :)
Christian
[1] https://www.freeipa.org/page/V4/KDC_Proxy
[2] http://web.mit.edu/kerberos/krb5-current/doc/admin/https.html
[3] https://github.com/npmccallum/kdcproxy
[4] https://github.com/tiran/freeipa/compare/master...kdcproxy2
--
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
