Re: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation

[Rob Crittenden]

Simo Sorce wrote:

On Mon, 2016-07-25 at 18:05 +0300, Alexander Bokovoy wrote:

But maybe I'm not seeing the proper priorities here. Perhaps it's

more

of a problem because clients are easier to update with bugfixes than
the server? Or maybe the preference for the client is for

scalability

reasons? Could you tell me more about why you prefer a client
implementation?

Making client responsible for generating the certificate signing
request serves several purposes where privacy is one of main benefits:
access to private key stays at the client side.


I would definitely veto any scheme where the client must send the
private key to the server. I thought the server would generate the CSR,
but then it would be sent to the client for signing ?


I doubt any SSL library will let you disconnect CSR generation in this 
way (fairly certain not in NSS anyway).


rob

--
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] [Design Review Request] V4/Automatic_Certificate_Request_Generation

[Alexander Bokovoy]

On Mon, 25 Jul 2016, Simo Sorce wrote:

On Mon, 2016-07-25 at 12:13 -0400, Ben Lipton wrote:

On 07/25/2016 11:07 AM, Simo Sorce wrote:
> On Mon, 2016-07-25 at 11:04 -0400, Simo Sorce wrote:
>> On Mon, 2016-07-25 at 10:51 -0400, Ben Lipton wrote:
>>> On 07/25/2016 05:07 AM, Simo Sorce wrote:
 On Mon, 2016-07-25 at 10:50 +0200, Jan Cholasta wrote:
> Anyway, my main grudge is that the transformation rules shouldn't
> really
> be stored on and processed by the server. The server should know the
> *what* (mapping rules), but not the *how* (transformation rules). The
> *how* is an implementation detail and does not change in time, so
> there's no benefit in handling it on the server. It should be handled
> exclusively on the client, which I believe would also make the whole
> thing more robust (it would not be possible for a bug on the server
> to
> break all the clients).
 W/o entering in specific +1 as a general comment on this.
 If it can be done on the client, probably better be done there.

 Simo.

>>> My thinking was that while the CSR generation must be done on the
>>> client, the retrieval and formatting of the data for the CSR should be
>>> done on the server, so that the functionality is available to all
>>> consumers of the API (ipa command-line, certmonger, Web UI, something
>>> else?). I imagine it would be relatively easy to move the formatting
>>> stuff into the ipa CLI, but all the other clients would then need an
>>> implementation of their own, and so we'd need to worry about
>>> interpreting the templates and generating CSRs in multiple different
>>> languages. It's true that as it stands a bug on the server could break
>>> all the clients, but on the other hand there's only one implementation
>>> to maintain, rather than a different one in each client.
>>>
>>> But maybe I'm not seeing the proper priorities here. Perhaps it's more
>>> of a problem because clients are easier to update with bugfixes than the
>>> server? Or maybe the preference for the client is for scalability
>>> reasons? Could you tell me more about why you prefer a client
>>> implementation?
>>>
>>> (And yeah, everything here carries a disclaimer of "I probably can't
>>> make any large changes in the remaining 3 weeks of my internship," but I
>>> think it's still good to know and document what the limitations of the
>>> current implementation are.)
>>>
>>> Thanks,
>>> Ben
>> You do not want to have to upgrade the server because tool foobarx
>> became suddenly the most used. Client tools may change over the time as
>> well, so if you try to generate stuff on the server you may end up
>> having to support multiple version with little way of knowing which
>> version that is.
>>
>> It is true that multiple client would have to implement "something", but
>> that something could be a python library+binary that other tools/script
>> can call or pipe through as needed.
> Note, from my pov the code should be more or less the same except it
> would run on the client rather than the server. Templates would be
> delivered via the same package that delivers the tool/module and admins
> would have the option to add more locally, though I am not against
> sharing templates via the server if we think that is a good idea in
> general (but the same issue vs tools changing and rendering templates
> broken with one or another version remain).
>
> Simo.
>
Ok, I definitely see your point here about making it easier to support
the shifting versions of the helper utilities. Pulling the formatting
out into a standalone binary that could be used by different clients
seems achievable. The Web UI wouldn't be able to use it, I guess, but as
of now there's no web UI for this feature anyway. I'll make sure this is
at least documented as a desirable modification.


Note, that the same tool *could* be used server side in the UI, should
it be desirable.

That was what I commented on -- IPA server is IPA client too, so it can
make all the work locally and provide resulted bundle to download.

--
/ 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] [Design Review Request] V4/Automatic_Certificate_Request_Generation

[Alexander Bokovoy]

On Mon, 25 Jul 2016, Simo Sorce wrote:

On Mon, 2016-07-25 at 12:09 -0400, Ben Lipton wrote:

On 07/25/2016 12:03 PM, Simo Sorce wrote:
> On Mon, 2016-07-25 at 18:05 +0300, Alexander Bokovoy wrote:
>>> But maybe I'm not seeing the proper priorities here. Perhaps it's
>> more
>>> of a problem because clients are easier to update with bugfixes than
>>> the server? Or maybe the preference for the client is for
>> scalability
>>> reasons? Could you tell me more about why you prefer a client
>>> implementation?
>> Making client responsible for generating the certificate signing
>> request serves several purposes where privacy is one of main benefits:
>> access to private key stays at the client side.
> I would definitely veto any scheme where the client must send the
> private key to the server. I thought the server would generate the CSR,
> but then it would be sent to the client for signing ?
>
> Simo.
>
The server generates the data and formats it for the helper tool. The
helper runs on the client and generates the CSR, with signature. I don't
think we were considering signing anything server-side; in this thread I
was referring to whether the data should be requested and formatted on
the server or client side.


This was my understanding as well, but Alexander's comment startled me,
thanks for confirming.

Correct. I was commenting by also taking into account current Fedora
situation where your certificate is generated on the server and that it
needs to be provided as well if we want Fedora to use FreeIPA as a
replacement for some of their infrastructure. However, this has nothing
to do with CSR generation as that mode can be simulated on IPA server
locally if really needed (again, because IPA server is own client, so it
has access to all the client infra).
--
/ 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] [PATCH 0553] CI tests: improve log collecting in tests

[Martin Basti]

On 25.07.2016 18:02, Martin Babinsky wrote:

On 07/22/2016 06:13 PM, Martin Basti wrote:



On 20.07.2016 17:41, Martin Basti wrote:




On 19.07.2016 17:05, Martin Basti wrote:




On 19.07.2016 16:18, Martin Basti wrote:

Patch attached.




self-NACK, my assumptions were wrong, this doesn't work if any of log
files do not exist



updated patches attached

Please note, that in case that any logfile does not exist tar returns
exit code 2, but provides correct output anyway.



Updated patches attached.



NACK:

* Module ipatests.test_integration.tasks
ipatests/test_integration/tasks.py:68: [E1101(no-member), 
setup_server_logs_collecting] Instance of 'FedoraPathNamespace' has no 
'IPASERVER_CA_INSTALL_LOG' member)

Makefile:137: recipe for target 'lint' failed
make: *** [lint] Error 1


Ooops, I forgot to merge fix

Updated patch attached.
From 2c9e3f05d191c053e94cfeba3822830f6c8f2d0e Mon Sep 17 00:00:00 2001
From: Martin Basti 
Date: Tue, 19 Jul 2016 12:09:29 +0200
Subject: [PATCH 1/2] CI tests: improve log collecting

We should collect as much as possible relevant logs to be able do better
investigation from test automation
---
 ipaplatform/base/paths.py  |  1 +
 ipatests/test_integration/tasks.py | 59 +-
 2 files changed, 46 insertions(+), 14 deletions(-)

diff --git a/ipaplatform/base/paths.py b/ipaplatform/base/paths.py
index 1507ac36da5b40447c951ee608053a09b2db2fc3..579ea70d9f0795443aebb5f120d63c8e5289886c 100644
--- a/ipaplatform/base/paths.py
+++ b/ipaplatform/base/paths.py
@@ -300,6 +300,7 @@ class BasePathNamespace(object):
 SLAPD_INSTANCE_ACCESS_LOG_TEMPLATE = "/var/log/dirsrv/slapd-%s/access"
 SLAPD_INSTANCE_ERROR_LOG_TEMPLATE = "/var/log/dirsrv/slapd-%s/errors"
 VAR_LOG_HTTPD_DIR = "/var/log/httpd"
+VAR_LOG_HTTPD_ERROR = "/var/log/httpd/error_log"
 IPABACKUP_LOG = "/var/log/ipabackup.log"
 IPACLIENT_INSTALL_LOG = "/var/log/ipaclient-install.log"
 IPACLIENT_UNINSTALL_LOG = "/var/log/ipaclient-uninstall.log"
diff --git a/ipatests/test_integration/tasks.py b/ipatests/test_integration/tasks.py
index cee6c15ccdc260f6ebe4cdebbc2cf6ec84931f27..df5fddb4a439dcd3dc73cee8fe4902686ed7b33c 100644
--- a/ipatests/test_integration/tasks.py
+++ b/ipatests/test_integration/tasks.py
@@ -47,6 +47,48 @@ from ipalib.constants import DOMAIN_LEVEL_0
 log = log_mgr.get_logger(__name__)
 
 
+def setup_server_logs_collecting(host):
+"""
+This function setup logs to be collected on host. We should collect all
+possible logs that may be helpful to debug IPA server
+"""
+# dirsrv logs
+inst = host.domain.realm.replace('.', '-')
+host.collect_log(paths.SLAPD_INSTANCE_ERROR_LOG_TEMPLATE % inst)
+host.collect_log(paths.SLAPD_INSTANCE_ACCESS_LOG_TEMPLATE % inst)
+
+# IPA install logs
+host.collect_log(paths.IPASERVER_INSTALL_LOG)
+host.collect_log(paths.IPACLIENT_INSTALL_LOG)
+host.collect_log(paths.IPAREPLICA_INSTALL_LOG)
+host.collect_log(paths.IPAREPLICA_CONNCHECK_LOG)
+host.collect_log(paths.IPAREPLICA_CA_INSTALL_LOG)
+host.collect_log(paths.IPACLIENT_INSTALL_LOG)
+host.collect_log(paths.IPASERVER_KRA_INSTALL_LOG)
+host.collect_log(paths.IPA_CUSTODIA_AUDIT_LOG)
+
+# IPA uninstall logs
+host.collect_log(paths.IPASERVER_KRA_UNINSTALL_LOG)
+host.collect_log(paths.IPACLIENT_UNINSTALL_LOG)
+host.collect_log(paths.IPASERVER_KRA_UNINSTALL_LOG)
+
+# IPA backup and restore logs
+host.collect_log(paths.IPARESTORE_LOG)
+host.collect_log(paths.IPABACKUP_LOG)
+
+# kerberos related logs
+host.collect_log(paths.KADMIND_LOG)
+
+# httpd logs
+host.collect_log(paths.VAR_LOG_HTTPD_ERROR)
+
+# dogtag logs
+host.collect_log(os.path.join(paths.VAR_LOG_PKI_DIR))
+
+# SSSD debugging must be set after client is installed (function
+# setup_sssd_debugging)
+
+
 def check_arguments_are(slice, instanceof):
 """
 :param: slice - tuple of integers denoting the beginning and the end
@@ -234,12 +276,7 @@ def install_master(host, setup_dns=True, setup_kra=False, extra_args=(),
domain_level=None):
 if domain_level is None:
 domain_level = host.config.domain_level
-host.collect_log(paths.IPASERVER_INSTALL_LOG)
-host.collect_log(paths.IPACLIENT_INSTALL_LOG)
-inst = host.domain.realm.replace('.', '-')
-host.collect_log(paths.SLAPD_INSTANCE_ERROR_LOG_TEMPLATE % inst)
-host.collect_log(paths.SLAPD_INSTANCE_ACCESS_LOG_TEMPLATE % inst)
-
+setup_server_logs_collecting(host)
 apply_common_fixes(host)
 fix_apache_semaphores(host)
 
@@ -321,8 +358,7 @@ def install_replica(master, replica, setup_ca=True, setup_dns=False,
 if domain_level is None:
 domain_level = domainlevel(master)
 apply_common_fixes(replica)
-replica.collect_log(paths.IPAREPLICA_INSTALL_LOG)
-replica.collect_log(paths.IPAREPLICA_CONNCHECK_LOG)
+

Re: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation

[Simo Sorce]

On Mon, 2016-07-25 at 12:13 -0400, Ben Lipton wrote:
> On 07/25/2016 11:07 AM, Simo Sorce wrote:
> > On Mon, 2016-07-25 at 11:04 -0400, Simo Sorce wrote:
> >> On Mon, 2016-07-25 at 10:51 -0400, Ben Lipton wrote:
> >>> On 07/25/2016 05:07 AM, Simo Sorce wrote:
>  On Mon, 2016-07-25 at 10:50 +0200, Jan Cholasta wrote:
> > Anyway, my main grudge is that the transformation rules shouldn't
> > really
> > be stored on and processed by the server. The server should know the
> > *what* (mapping rules), but not the *how* (transformation rules). The
> > *how* is an implementation detail and does not change in time, so
> > there's no benefit in handling it on the server. It should be handled
> > exclusively on the client, which I believe would also make the whole
> > thing more robust (it would not be possible for a bug on the server
> > to
> > break all the clients).
>  W/o entering in specific +1 as a general comment on this.
>  If it can be done on the client, probably better be done there.
> 
>  Simo.
> 
> >>> My thinking was that while the CSR generation must be done on the
> >>> client, the retrieval and formatting of the data for the CSR should be
> >>> done on the server, so that the functionality is available to all
> >>> consumers of the API (ipa command-line, certmonger, Web UI, something
> >>> else?). I imagine it would be relatively easy to move the formatting
> >>> stuff into the ipa CLI, but all the other clients would then need an
> >>> implementation of their own, and so we'd need to worry about
> >>> interpreting the templates and generating CSRs in multiple different
> >>> languages. It's true that as it stands a bug on the server could break
> >>> all the clients, but on the other hand there's only one implementation
> >>> to maintain, rather than a different one in each client.
> >>>
> >>> But maybe I'm not seeing the proper priorities here. Perhaps it's more
> >>> of a problem because clients are easier to update with bugfixes than the
> >>> server? Or maybe the preference for the client is for scalability
> >>> reasons? Could you tell me more about why you prefer a client
> >>> implementation?
> >>>
> >>> (And yeah, everything here carries a disclaimer of "I probably can't
> >>> make any large changes in the remaining 3 weeks of my internship," but I
> >>> think it's still good to know and document what the limitations of the
> >>> current implementation are.)
> >>>
> >>> Thanks,
> >>> Ben
> >> You do not want to have to upgrade the server because tool foobarx
> >> became suddenly the most used. Client tools may change over the time as
> >> well, so if you try to generate stuff on the server you may end up
> >> having to support multiple version with little way of knowing which
> >> version that is.
> >>
> >> It is true that multiple client would have to implement "something", but
> >> that something could be a python library+binary that other tools/script
> >> can call or pipe through as needed.
> > Note, from my pov the code should be more or less the same except it
> > would run on the client rather than the server. Templates would be
> > delivered via the same package that delivers the tool/module and admins
> > would have the option to add more locally, though I am not against
> > sharing templates via the server if we think that is a good idea in
> > general (but the same issue vs tools changing and rendering templates
> > broken with one or another version remain).
> >
> > Simo.
> >
> Ok, I definitely see your point here about making it easier to support 
> the shifting versions of the helper utilities. Pulling the formatting 
> out into a standalone binary that could be used by different clients 
> seems achievable. The Web UI wouldn't be able to use it, I guess, but as 
> of now there's no web UI for this feature anyway. I'll make sure this is 
> at least documented as a desirable modification.

Note, that the same tool *could* be used server side in the UI, should
it be desirable.

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] [Design Review Request] V4/Automatic_Certificate_Request_Generation

[Simo Sorce]

On Mon, 2016-07-25 at 12:09 -0400, Ben Lipton wrote:
> On 07/25/2016 12:03 PM, Simo Sorce wrote:
> > On Mon, 2016-07-25 at 18:05 +0300, Alexander Bokovoy wrote:
> >>> But maybe I'm not seeing the proper priorities here. Perhaps it's
> >> more
> >>> of a problem because clients are easier to update with bugfixes than
> >>> the server? Or maybe the preference for the client is for
> >> scalability
> >>> reasons? Could you tell me more about why you prefer a client
> >>> implementation?
> >> Making client responsible for generating the certificate signing
> >> request serves several purposes where privacy is one of main benefits:
> >> access to private key stays at the client side.
> > I would definitely veto any scheme where the client must send the
> > private key to the server. I thought the server would generate the CSR,
> > but then it would be sent to the client for signing ?
> >
> > Simo.
> >
> The server generates the data and formats it for the helper tool. The 
> helper runs on the client and generates the CSR, with signature. I don't 
> think we were considering signing anything server-side; in this thread I 
> was referring to whether the data should be requested and formatted on 
> the server or client side.

This was my understanding as well, but Alexander's comment startled me,
thanks for confirming.

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] [Design Review Request] V4/Automatic_Certificate_Request_Generation

[Ben Lipton]

On 07/25/2016 11:07 AM, Simo Sorce wrote:

On Mon, 2016-07-25 at 11:04 -0400, Simo Sorce wrote:

On Mon, 2016-07-25 at 10:51 -0400, Ben Lipton wrote:

On 07/25/2016 05:07 AM, Simo Sorce wrote:

On Mon, 2016-07-25 at 10:50 +0200, Jan Cholasta wrote:

Anyway, my main grudge is that the transformation rules shouldn't
really
be stored on and processed by the server. The server should know the
*what* (mapping rules), but not the *how* (transformation rules). The
*how* is an implementation detail and does not change in time, so
there's no benefit in handling it on the server. It should be handled
exclusively on the client, which I believe would also make the whole
thing more robust (it would not be possible for a bug on the server
to
break all the clients).

W/o entering in specific +1 as a general comment on this.
If it can be done on the client, probably better be done there.

Simo.


My thinking was that while the CSR generation must be done on the
client, the retrieval and formatting of the data for the CSR should be
done on the server, so that the functionality is available to all
consumers of the API (ipa command-line, certmonger, Web UI, something
else?). I imagine it would be relatively easy to move the formatting
stuff into the ipa CLI, but all the other clients would then need an
implementation of their own, and so we'd need to worry about
interpreting the templates and generating CSRs in multiple different
languages. It's true that as it stands a bug on the server could break
all the clients, but on the other hand there's only one implementation
to maintain, rather than a different one in each client.

But maybe I'm not seeing the proper priorities here. Perhaps it's more
of a problem because clients are easier to update with bugfixes than the
server? Or maybe the preference for the client is for scalability
reasons? Could you tell me more about why you prefer a client
implementation?

(And yeah, everything here carries a disclaimer of "I probably can't
make any large changes in the remaining 3 weeks of my internship," but I
think it's still good to know and document what the limitations of the
current implementation are.)

Thanks,
Ben

You do not want to have to upgrade the server because tool foobarx
became suddenly the most used. Client tools may change over the time as
well, so if you try to generate stuff on the server you may end up
having to support multiple version with little way of knowing which
version that is.

It is true that multiple client would have to implement "something", but
that something could be a python library+binary that other tools/script
can call or pipe through as needed.

Note, from my pov the code should be more or less the same except it
would run on the client rather than the server. Templates would be
delivered via the same package that delivers the tool/module and admins
would have the option to add more locally, though I am not against
sharing templates via the server if we think that is a good idea in
general (but the same issue vs tools changing and rendering templates
broken with one or another version remain).

Simo.

Ok, I definitely see your point here about making it easier to support 
the shifting versions of the helper utilities. Pulling the formatting 
out into a standalone binary that could be used by different clients 
seems achievable. The Web UI wouldn't be able to use it, I guess, but as 
of now there's no web UI for this feature anyway. I'll make sure this is 
at least documented as a desirable modification.


--
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] [Design Review Request] V4/Automatic_Certificate_Request_Generation

[Ben Lipton]

On 07/25/2016 12:03 PM, Simo Sorce wrote:

On Mon, 2016-07-25 at 18:05 +0300, Alexander Bokovoy wrote:

But maybe I'm not seeing the proper priorities here. Perhaps it's

more

of a problem because clients are easier to update with bugfixes than
the server? Or maybe the preference for the client is for

scalability

reasons? Could you tell me more about why you prefer a client
implementation?

Making client responsible for generating the certificate signing
request serves several purposes where privacy is one of main benefits:
access to private key stays at the client side.

I would definitely veto any scheme where the client must send the
private key to the server. I thought the server would generate the CSR,
but then it would be sent to the client for signing ?

Simo.

The server generates the data and formats it for the helper tool. The 
helper runs on the client and generates the CSR, with signature. I don't 
think we were considering signing anything server-side; in this thread I 
was referring to whether the data should be requested and formatted on 
the server or client side.


--
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] [PATCH 0553] CI tests: improve log collecting in tests

[Martin Babinsky]

On 07/22/2016 06:13 PM, Martin Basti wrote:



On 20.07.2016 17:41, Martin Basti wrote:




On 19.07.2016 17:05, Martin Basti wrote:




On 19.07.2016 16:18, Martin Basti wrote:

Patch attached.




self-NACK, my assumptions were wrong, this doesn't work if any of log
files do not exist



updated patches attached

Please note, that in case that any logfile does not exist tar returns
exit code 2, but provides correct output anyway.



Updated patches attached.



NACK:

* Module ipatests.test_integration.tasks
ipatests/test_integration/tasks.py:68: [E1101(no-member), 
setup_server_logs_collecting] Instance of 'FedoraPathNamespace' has no 
'IPASERVER_CA_INSTALL_LOG' member)

Makefile:137: recipe for target 'lint' failed
make: *** [lint] Error 1

--
Martin^3 Babinsky

--
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] [Design Review Request] V4/Automatic_Certificate_Request_Generation

[Simo Sorce]

On Mon, 2016-07-25 at 18:05 +0300, Alexander Bokovoy wrote:
> >But maybe I'm not seeing the proper priorities here. Perhaps it's
> more 
> >of a problem because clients are easier to update with bugfixes than 
> >the server? Or maybe the preference for the client is for
> scalability 
> >reasons? Could you tell me more about why you prefer a client 
> >implementation?
> Making client responsible for generating the certificate signing
> request serves several purposes where privacy is one of main benefits:
> access to private key stays at the client side.

I would definitely veto any scheme where the client must send the
private key to the server. I thought the server would generate the CSR,
but then it would be sent to the client for signing ?

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] [PATCH] restrict setkeytab operation

[Simo Sorce]

On Mon, 2016-07-25 at 11:10 -0400, Rob Crittenden wrote:
> Simo Sorce wrote:
> > On Mon, 2016-07-25 at 10:55 -0400, Rob Crittenden wrote:
> >> Simo Sorce wrote:
> >>> As described in #232 start restricting the use of the setkeytab
> >>> operation to just the computers objects.
> >>>
> >>> I haven't tested this with older RHEL/CentOS machines that actully use
> >>> the setkeytab operation as I do not have such an old VM handy right now.
> >>>
> >>> Meanwhile I'd like to know if ppl agree with this approach.
> >>
> >> What about services?
> >
> > Do we automatically acquire keytab for services in the old clients ?
> >
> > Are you thinking about scripted ipa-getkytab callouts ?
> 
> You are limiting access to host keytabs, what about service keytabs? 
> Should they be or are they now similarly restricted?
> 
> Installers for something like Foreman may try to generate a service 
> keytab in its installer, probably using admin credentials. I am planning 
> to do the same in Openstack.

Ok I'll amend the patch to allow service keytabs to still use the
setkeytab control still, and restrict only users.
However note that the idea of using this method is that admin can change
this default on their own, so they can restrict more or less if they
want, to that end I need to remember how to set a default that we do not
override in the update file.

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] [PATCH] restrict setkeytab operation

[Rob Crittenden]

Simo Sorce wrote:

On Mon, 2016-07-25 at 10:55 -0400, Rob Crittenden wrote:

Simo Sorce wrote:

As described in #232 start restricting the use of the setkeytab
operation to just the computers objects.

I haven't tested this with older RHEL/CentOS machines that actully use
the setkeytab operation as I do not have such an old VM handy right now.

Meanwhile I'd like to know if ppl agree with this approach.


What about services?


Do we automatically acquire keytab for services in the old clients ?

Are you thinking about scripted ipa-getkytab callouts ?


You are limiting access to host keytabs, what about service keytabs? 
Should they be or are they now similarly restricted?


Installers for something like Foreman may try to generate a service 
keytab in its installer, probably using admin credentials. I am planning 
to do the same in Openstack.


rob

--
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] [Design Review Request] V4/Automatic_Certificate_Request_Generation

[Simo Sorce]

On Mon, 2016-07-25 at 11:04 -0400, Simo Sorce wrote:
> On Mon, 2016-07-25 at 10:51 -0400, Ben Lipton wrote:
> > On 07/25/2016 05:07 AM, Simo Sorce wrote:
> > > On Mon, 2016-07-25 at 10:50 +0200, Jan Cholasta wrote:
> > >> Anyway, my main grudge is that the transformation rules shouldn't
> > >> really
> > >> be stored on and processed by the server. The server should know the
> > >> *what* (mapping rules), but not the *how* (transformation rules). The
> > >> *how* is an implementation detail and does not change in time, so
> > >> there's no benefit in handling it on the server. It should be handled
> > >> exclusively on the client, which I believe would also make the whole
> > >> thing more robust (it would not be possible for a bug on the server
> > >> to
> > >> break all the clients).
> > > W/o entering in specific +1 as a general comment on this.
> > > If it can be done on the client, probably better be done there.
> > >
> > > Simo.
> > >
> > My thinking was that while the CSR generation must be done on the 
> > client, the retrieval and formatting of the data for the CSR should be 
> > done on the server, so that the functionality is available to all 
> > consumers of the API (ipa command-line, certmonger, Web UI, something 
> > else?). I imagine it would be relatively easy to move the formatting 
> > stuff into the ipa CLI, but all the other clients would then need an 
> > implementation of their own, and so we'd need to worry about 
> > interpreting the templates and generating CSRs in multiple different 
> > languages. It's true that as it stands a bug on the server could break 
> > all the clients, but on the other hand there's only one implementation 
> > to maintain, rather than a different one in each client.
> > 
> > But maybe I'm not seeing the proper priorities here. Perhaps it's more 
> > of a problem because clients are easier to update with bugfixes than the 
> > server? Or maybe the preference for the client is for scalability 
> > reasons? Could you tell me more about why you prefer a client 
> > implementation?
> > 
> > (And yeah, everything here carries a disclaimer of "I probably can't 
> > make any large changes in the remaining 3 weeks of my internship," but I 
> > think it's still good to know and document what the limitations of the 
> > current implementation are.)
> > 
> > Thanks,
> > Ben
> 
> You do not want to have to upgrade the server because tool foobarx
> became suddenly the most used. Client tools may change over the time as
> well, so if you try to generate stuff on the server you may end up
> having to support multiple version with little way of knowing which
> version that is.
> 
> It is true that multiple client would have to implement "something", but
> that something could be a python library+binary that other tools/script
> can call or pipe through as needed.

Note, from my pov the code should be more or less the same except it
would run on the client rather than the server. Templates would be
delivered via the same package that delivers the tool/module and admins
would have the option to add more locally, though I am not against
sharing templates via the server if we think that is a good idea in
general (but the same issue vs tools changing and rendering templates
broken with one or another version remain).

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] [PATCH] restrict setkeytab operation

[Alexander Bokovoy]

On Mon, 25 Jul 2016, Simo Sorce wrote:

On Mon, 2016-07-25 at 10:55 -0400, Rob Crittenden wrote:

Simo Sorce wrote:
> As described in #232 start restricting the use of the setkeytab
> operation to just the computers objects.
>
> I haven't tested this with older RHEL/CentOS machines that actully use
> the setkeytab operation as I do not have such an old VM handy right now.
>
> Meanwhile I'd like to know if ppl agree with this approach.

What about services?


Do we automatically acquire keytab for services in the old clients ?

Are you thinking about scripted ipa-getkytab callouts ?

There are people still using ipa 3.0 clients and scripting around it,
both with RHEL 6.x and CentOS 6.x. I wouldn't break those on purpose.

--
/ 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] [Design Review Request] V4/Automatic_Certificate_Request_Generation

[Alexander Bokovoy]

On Mon, 25 Jul 2016, Ben Lipton wrote:

On 07/25/2016 05:07 AM, Simo Sorce wrote:

On Mon, 2016-07-25 at 10:50 +0200, Jan Cholasta wrote:

Anyway, my main grudge is that the transformation rules shouldn't
really
be stored on and processed by the server. The server should know the
*what* (mapping rules), but not the *how* (transformation rules). The
*how* is an implementation detail and does not change in time, so
there's no benefit in handling it on the server. It should be handled
exclusively on the client, which I believe would also make the whole
thing more robust (it would not be possible for a bug on the server
to
break all the clients).

W/o entering in specific +1 as a general comment on this.
If it can be done on the client, probably better be done there.

Simo.

My thinking was that while the CSR generation must be done on the 
client, the retrieval and formatting of the data for the CSR should be 
done on the server, so that the functionality is available to all 
consumers of the API (ipa command-line, certmonger, Web UI, something 
else?). I imagine it would be relatively easy to move the formatting 
stuff into the ipa CLI, but all the other clients would then need an 
implementation of their own, and so we'd need to worry about 
interpreting the templates and generating CSRs in multiple different 
languages. It's true that as it stands a bug on the server could break 
all the clients, but on the other hand there's only one implementation 
to maintain, rather than a different one in each client.

For other clients we would need to worry about CSR, not generating them.
For them we *could* make use of the fact that IPA server is IPA client
as well and provide some API to create CSR based on a pre-defined
request type (e.g. don't support all CSR backends, just one, like
python-cryptography). That wouldn't be too flexible but for flexibility
we already accept CSRs generated by someone else.

But maybe I'm not seeing the proper priorities here. Perhaps it's more 
of a problem because clients are easier to update with bugfixes than 
the server? Or maybe the preference for the client is for scalability 
reasons? Could you tell me more about why you prefer a client 
implementation?

Making client responsible for generating the certificate signing
request serves several purposes where privacy is one of main benefits:
access to private key stays at the client side.

(And yeah, everything here carries a disclaimer of "I probably can't 
make any large changes in the remaining 3 weeks of my internship," but 
I think it's still good to know and document what the limitations of 
the current implementation are.)

Agreed.
--
/ 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] [Design Review Request] V4/Automatic_Certificate_Request_Generation

[Simo Sorce]

On Mon, 2016-07-25 at 10:51 -0400, Ben Lipton wrote:
> On 07/25/2016 05:07 AM, Simo Sorce wrote:
> > On Mon, 2016-07-25 at 10:50 +0200, Jan Cholasta wrote:
> >> Anyway, my main grudge is that the transformation rules shouldn't
> >> really
> >> be stored on and processed by the server. The server should know the
> >> *what* (mapping rules), but not the *how* (transformation rules). The
> >> *how* is an implementation detail and does not change in time, so
> >> there's no benefit in handling it on the server. It should be handled
> >> exclusively on the client, which I believe would also make the whole
> >> thing more robust (it would not be possible for a bug on the server
> >> to
> >> break all the clients).
> > W/o entering in specific +1 as a general comment on this.
> > If it can be done on the client, probably better be done there.
> >
> > Simo.
> >
> My thinking was that while the CSR generation must be done on the 
> client, the retrieval and formatting of the data for the CSR should be 
> done on the server, so that the functionality is available to all 
> consumers of the API (ipa command-line, certmonger, Web UI, something 
> else?). I imagine it would be relatively easy to move the formatting 
> stuff into the ipa CLI, but all the other clients would then need an 
> implementation of their own, and so we'd need to worry about 
> interpreting the templates and generating CSRs in multiple different 
> languages. It's true that as it stands a bug on the server could break 
> all the clients, but on the other hand there's only one implementation 
> to maintain, rather than a different one in each client.
> 
> But maybe I'm not seeing the proper priorities here. Perhaps it's more 
> of a problem because clients are easier to update with bugfixes than the 
> server? Or maybe the preference for the client is for scalability 
> reasons? Could you tell me more about why you prefer a client 
> implementation?
> 
> (And yeah, everything here carries a disclaimer of "I probably can't 
> make any large changes in the remaining 3 weeks of my internship," but I 
> think it's still good to know and document what the limitations of the 
> current implementation are.)
> 
> Thanks,
> Ben

You do not want to have to upgrade the server because tool foobarx
became suddenly the most used. Client tools may change over the time as
well, so if you try to generate stuff on the server you may end up
having to support multiple version with little way of knowing which
version that is.

It is true that multiple client would have to implement "something", but
that something could be a python library+binary that other tools/script
can call or pipe through as needed.

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] [PATCH] restrict setkeytab operation

[Simo Sorce]

On Mon, 2016-07-25 at 10:55 -0400, Rob Crittenden wrote:
> Simo Sorce wrote:
> > As described in #232 start restricting the use of the setkeytab
> > operation to just the computers objects.
> >
> > I haven't tested this with older RHEL/CentOS machines that actully use
> > the setkeytab operation as I do not have such an old VM handy right now.
> >
> > Meanwhile I'd like to know if ppl agree with this approach.
> 
> What about services?

Do we automatically acquire keytab for services in the old clients ?

Are you thinking about scripted ipa-getkytab callouts ?

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] [PATCH 0003] Fix several small typos

[Ben Lipton]

On 07/18/2016 04:54 PM, Lukas Slebodnik wrote:

On (18/07/16 16:38), Petr Spacek wrote:

On 14.7.2016 16:11, Ben Lipton wrote:

On 07/14/2016 04:09 AM, Alexander Bokovoy wrote:

On Wed, 13 Jul 2016, Ben Lipton wrote:

Nothing too exciting, just fixes a few typos I've noticed in comments.

ACK. However, please file a ticket and mention it in the commit message.

Is it worth the bureaucracy? I do not think so. We will certainly not backport
typo fixes in comments to older branches so I would say that ticket is useless.

Just my two cents.


+1

LS

Necessary or not, as the ticket is created now, any objection to pushing 
the patch?


Ben

--
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] [PATCH] restrict setkeytab operation

[Rob Crittenden]

Simo Sorce wrote:

As described in #232 start restricting the use of the setkeytab
operation to just the computers objects.

I haven't tested this with older RHEL/CentOS machines that actully use
the setkeytab operation as I do not have such an old VM handy right now.

Meanwhile I'd like to know if ppl agree with this approach.


What about services?

rob

--
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] [Design Review Request] V4/Automatic_Certificate_Request_Generation

[Ben Lipton]

On 07/25/2016 05:07 AM, Simo Sorce wrote:

On Mon, 2016-07-25 at 10:50 +0200, Jan Cholasta wrote:

Anyway, my main grudge is that the transformation rules shouldn't
really
be stored on and processed by the server. The server should know the
*what* (mapping rules), but not the *how* (transformation rules). The
*how* is an implementation detail and does not change in time, so
there's no benefit in handling it on the server. It should be handled
exclusively on the client, which I believe would also make the whole
thing more robust (it would not be possible for a bug on the server
to
break all the clients).

W/o entering in specific +1 as a general comment on this.
If it can be done on the client, probably better be done there.

Simo.

My thinking was that while the CSR generation must be done on the 
client, the retrieval and formatting of the data for the CSR should be 
done on the server, so that the functionality is available to all 
consumers of the API (ipa command-line, certmonger, Web UI, something 
else?). I imagine it would be relatively easy to move the formatting 
stuff into the ipa CLI, but all the other clients would then need an 
implementation of their own, and so we'd need to worry about 
interpreting the templates and generating CSRs in multiple different 
languages. It's true that as it stands a bug on the server could break 
all the clients, but on the other hand there's only one implementation 
to maintain, rather than a different one in each client.


But maybe I'm not seeing the proper priorities here. Perhaps it's more 
of a problem because clients are easier to update with bugfixes than the 
server? Or maybe the preference for the client is for scalability 
reasons? Could you tell me more about why you prefer a client 
implementation?


(And yeah, everything here carries a disclaimer of "I probably can't 
make any large changes in the remaining 3 weeks of my internship," but I 
think it's still good to know and document what the limitations of the 
current implementation are.)


Thanks,
Ben

--
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] [PATCH 0150] replica-install: Fix --domain

[Petr Spacek]

On 25.7.2016 16:16, Jan Cholasta wrote:
> On 25.7.2016 15:55, Petr Spacek wrote:
>> Hello,
>>
>> replica-install: Fix --domain
>>
>> Replica installation must not check existence of --domain - the domain
>> must (logically) exist.
>>
>> https://fedorahosted.org/freeipa/ticket/6130
> 
> Note that Server.domain_name is already defined on line 1204 in
> ipaserver/install/server/install.py.

My bad, here is updated patch.

-- 
Petr^2 Spacek
From 29ddba2b6c031df60d4a9047e374c5ccbdd372ff Mon Sep 17 00:00:00 2001
From: Petr Spacek 
Date: Mon, 25 Jul 2016 15:54:43 +0200
Subject: [PATCH] replica-install: Fix --domain

Replica installation must not check existence of --domain - the domain
must (logically) exist.

https://fedorahosted.org/freeipa/ticket/6130
---
 ipaserver/install/server/common.py  |  5 -
 ipaserver/install/server/install.py | 11 ++-
 2 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/ipaserver/install/server/common.py b/ipaserver/install/server/common.py
index 45fb2dc17976a08acab16783584524721411fb4e..e6093d15cd1067a83ed89945c4a9c983c66ec06f 100644
--- a/ipaserver/install/server/common.py
+++ b/ipaserver/install/server/common.py
@@ -284,11 +284,6 @@ class BaseServer(common.Installable, common.Interactive, core.Composite):
 @domain_name.validator
 def domain_name(self, value):
 validate_domain_name(value)
-if (self.setup_dns and
-not self.dns.allow_zone_overlap):  # pylint: disable=no-member
-print("Checking DNS domain %s, please wait ..." % value)
-check_zone_overlap(value, False)
-
 
 dm_password = Knob(
 str, None,
diff --git a/ipaserver/install/server/install.py b/ipaserver/install/server/install.py
index c0c676b870b481696ae75742c7bf88074b0ecf9c..ad95ddc59a7c1ad8bb27a9750b921b44c1acf58d 100644
--- a/ipaserver/install/server/install.py
+++ b/ipaserver/install/server/install.py
@@ -17,6 +17,7 @@ import six
 
 from ipapython import certmonger, ipaldap, ipautil, sysrestore
 from ipapython.dn import DN
+from ipapython.dnsutil import check_zone_overlap
 from ipapython.install import core
 from ipapython.install.common import step
 from ipapython.install.core import Knob
@@ -1200,12 +1201,20 @@ class ServerCA(BaseServerCA):
 
 class Server(BaseServer):
 realm_name = Knob(BaseServer.realm_name)
-domain_name = Knob(BaseServer.domain_name)
 
 setup_ca = None
 setup_kra = None
 setup_dns = Knob(BaseServer.setup_dns)
 
+domain_name = Knob(BaseServer.domain_name)
+
+@domain_name.validator
+def domain_name(self, value):
+if (self.setup_dns and
+not self.dns.allow_zone_overlap):  # pylint: disable=no-member
+print("Checking DNS domain %s, please wait ..." % value)
+check_zone_overlap(value, False)
+
 dm_password = Knob(
 BaseServer.dm_password,
 description="Directory Manager password",
-- 
2.7.4

-- 
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] [Design Review Request] V4/Automatic_Certificate_Request_Generation

[Ben Lipton]

On 07/25/2016 08:12 AM, Alexander Bokovoy wrote:

On Mon, 25 Jul 2016, Jan Cholasta wrote:
This is turning out to be a common (and, I think, reasonable) 
reaction

to the proposal. It is rather complex, and I worry that it will be
difficult to configure. On the other hand, there is some hidden
complexity to enabling a simpler config format, as well. One of the
goals of the project as it was presented to me was to allow the 
creation

of profiles that add certificate extensions *that FreeIPA doesn't yet
know about*. With the current proposal, one only has to add a rule
generating text that the helper will understand.


... which will be possible only as long as the helper understands the
extension. Which it might not, thus the current proposal works only
for *some* extensions that FreeIPA doesn't yet support.

We can go ad infinitum here but with any helper implementation, be it
python-cryptography or anything else, you will need to have a support
there as well.


My point was that the current proposal is not any better than my 
proposal in this regard, as neither of them allows one to use an 
arbitrary extension.

That's true. One of arguments for supporting openssl format was to allow
people to generate CSRs themselves later. E.g. it would be a stepping
stone to some automation around certificates to those who need it.
Turning everything into python-cryptography has less benefit in this
context.


The idea with unknown extensions was to allow mapping
their acceptance to a specific relationship between IPA objects
(optionally) and an input from the CSR. A simplest example would be an
identity rule that would copy an ASN.1 encoded content from the CSR to
the certificate.

That's on the mapping side, not on the CSR generation side, but it 
would

go similarly for the CSR if you would be able to enter unknown but
otherwise correct ASN.1 stream. There is no difference at which helper
type we are talking about because all of them support inserting ASN.1
content.
Along similar lines, on the CSR generation side, certutil has an 
--extGeneric flag, and openssl also has an "ARBITRARY EXTENSIONS" 
feature described in x509v3_config(5). I'm guessing that generating 
those configs automatically would be a bit beyond the current feature 
set of jinja2, but when we allow the requester to specify contents for 
some of the data fields it should be possible to build ok automation 
around that.



With your suggestion,
if there's a mapping between "san_directoryname" and the 
corresponding
API calls or configuration lines, we need some way for users to 
augment
that mapping without changing the code. If there's no mapping, and 
it's
just done with text processing, we need enough in the config 
format to

be able to generate fairly complex structures:

builder = builder.subject_name(x509.Name(u'CN=user,O=EXAMPLE.COM'))
builder =
builder.add_extension(x509.SubjectAlternativeName([x509.RFC822Name(u'u...@example.com'), 



x509.DirectoryName(x509.Name(u'CN=user,O=EXAMPLE.COM'))]), False)

and we need to do it without it being equivalent to calling eval() on
the config attributes. I'm not sure how to achieve this (is it 
safe to
call getattr(x509, extensiontype)(value) where extensiontype and 
value

are user-specified?) and it definitely would have to be tied to a
particular library/tool.


As I pointed out above, this needs to be figured out for the generic
case for both the current proposal and my suggestion.

OTOH, I think we could use GSER encoding of the extension value:

  { rfc822Name:"u...@example.com",
directoryName:rdnSequence:"CN=user,O=EXAMPLE.COM" }

GSER is not really used widely and does not have standardized encoding
rules beyond its own definition. If you want to allow transformation
rules in GSER that mention existing content in IPA objects, you would
need to deal with templating anyway. At this point it becomes 
irrelevant

what you are templating, though.


True, but the goal here is not to avoid templating, but rather to 
avoid implementation-specific bits on the server, and GSER is the 
only thing that is textual, implementation-neutral and, as a bonus, 
standardized.

If we move these bits to the client, the only thing server will need to
deal with is CSR. The client then would definitely need to have ability
to provide alternative CSR sources (e.g. openssl text format) to aid
API users that don't utilize IPA tools directly. At this point GSER use
is irrelevant either.
The GSER format is new to me, but I don't see any particular reason the 
existing design would not be able to produce this format. But: is there 
an existing library that allows creating a CSR from a GSER description? 
If our goal is to provide an easy way to create certificates according 
to a particular profile, and the CSR is still our main way to provide 
that data to the IPA cert-request feature, we need to be able to build 
that CSR. If we have a client that accepts GSER and has at least the CSR 
generation features we need, then 

Re: [Freeipa-devel] [PATCH 0150] replica-install: Fix --domain

[Jan Cholasta]

On 25.7.2016 15:55, Petr Spacek wrote:

Hello,

replica-install: Fix --domain

Replica installation must not check existence of --domain - the domain
must (logically) exist.

https://fedorahosted.org/freeipa/ticket/6130


Note that Server.domain_name is already defined on line 1204 in 
ipaserver/install/server/install.py.


--
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

[Freeipa-devel] [PATCH 0150] replica-install: Fix --domain

[Petr Spacek]

Hello,

replica-install: Fix --domain

Replica installation must not check existence of --domain - the domain
must (logically) exist.

https://fedorahosted.org/freeipa/ticket/6130

-- 
Petr^2 Spacek
From 2a038b63f0ad6bc1e68ca62821efa8ced4f32a59 Mon Sep 17 00:00:00 2001
From: Petr Spacek 
Date: Mon, 25 Jul 2016 15:54:43 +0200
Subject: [PATCH] replica-install: Fix --domain

Replica installation must not check existence of --domain - the domain
must (logically) exist.

https://fedorahosted.org/freeipa/ticket/6130
---
 ipaserver/install/server/common.py  |  5 -
 ipaserver/install/server/install.py | 10 ++
 2 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/ipaserver/install/server/common.py b/ipaserver/install/server/common.py
index 45fb2dc17976a08acab16783584524721411fb4e..e6093d15cd1067a83ed89945c4a9c983c66ec06f 100644
--- a/ipaserver/install/server/common.py
+++ b/ipaserver/install/server/common.py
@@ -284,11 +284,6 @@ class BaseServer(common.Installable, common.Interactive, core.Composite):
 @domain_name.validator
 def domain_name(self, value):
 validate_domain_name(value)
-if (self.setup_dns and
-not self.dns.allow_zone_overlap):  # pylint: disable=no-member
-print("Checking DNS domain %s, please wait ..." % value)
-check_zone_overlap(value, False)
-
 
 dm_password = Knob(
 str, None,
diff --git a/ipaserver/install/server/install.py b/ipaserver/install/server/install.py
index c0c676b870b481696ae75742c7bf88074b0ecf9c..8e3af4ab1d65746ea37936a33b8a62d379ec410b 100644
--- a/ipaserver/install/server/install.py
+++ b/ipaserver/install/server/install.py
@@ -17,6 +17,7 @@ import six
 
 from ipapython import certmonger, ipaldap, ipautil, sysrestore
 from ipapython.dn import DN
+from ipapython.dnsutil import check_zone_overlap
 from ipapython.install import core
 from ipapython.install.common import step
 from ipapython.install.core import Knob
@@ -1256,6 +1257,15 @@ class Server(BaseServer):
 "Domain Level cannot be higher than {0}".format(
 constants.MAX_DOMAIN_LEVEL))
 
+domain_name = Knob(BaseServer.domain_name)
+
+@domain_name.validator
+def domain_name(self, value):
+if (self.setup_dns and
+not self.dns.allow_zone_overlap):  # pylint: disable=no-member
+print("Checking DNS domain %s, please wait ..." % value)
+check_zone_overlap(value, False)
+
 ip_addresses = Knob(
 BaseServer.ip_addresses,
 description=("Master Server IP Address. This option can be used "
-- 
2.7.4

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [PATCHES 678-679] client: fix hiding of commands which lack server support

[Jan Cholasta]

Hi,

the attached patches fix .

Honza

--
Jan Cholasta
From b6d02e58b105a3a30561dd83fbe67ba59ac2a315 Mon Sep 17 00:00:00 2001
From: Jan Cholasta 
Date: Mon, 25 Jul 2016 14:00:08 +0200
Subject: [PATCH 1/2] Revert "Enable vault-* commands on client"

This reverts commit 9feeaca9fb552229638ce98086aa75905a45b48d.

https://fedorahosted.org/freeipa/ticket/6089
---
 ipaclient/plugins/vault.py | 16 
 1 file changed, 16 insertions(+)

diff --git a/ipaclient/plugins/vault.py b/ipaclient/plugins/vault.py
index a3ce6fe..b7e0cff 100644
--- a/ipaclient/plugins/vault.py
+++ b/ipaclient/plugins/vault.py
@@ -202,6 +202,10 @@ class vault_add(Local):
 ),
 )
 
+@property
+def NO_CLI(self):
+return self.api.Command.vault_add_internal.NO_CLI
+
 def get_args(self):
 for arg in self.api.Command.vault_add_internal.args():
 yield arg
@@ -395,6 +399,10 @@ class vault_mod(Local):
 ),
 )
 
+@property
+def NO_CLI(self):
+return self.api.Command.vault_mod_internal.NO_CLI
+
 def get_args(self):
 for arg in self.api.Command.vault_mod_internal.args():
 yield arg
@@ -569,6 +577,10 @@ class vault_archive(Local):
 ),
 )
 
+@property
+def NO_CLI(self):
+return self.api.Command.vault_archive_internal.NO_CLI
+
 def get_args(self):
 for arg in self.api.Command.vault_archive_internal.args():
 yield arg
@@ -813,6 +825,10 @@ class vault_retrieve(Local):
 ),
 )
 
+@property
+def NO_CLI(self):
+return self.api.Command.vault_retrieve_internal.NO_CLI
+
 def get_args(self):
 for arg in self.api.Command.vault_retrieve_internal.args():
 yield arg
-- 
2.7.4

From 17f704f43667914b10907537880f34a0aa370037 Mon Sep 17 00:00:00 2001
From: Jan Cholasta 
Date: Mon, 18 Jul 2016 09:37:24 +0200
Subject: [PATCH 2/2] client: fix hiding of commands which lack server support

Rather than checking the server counterpart's NO_CLI, which may be False
even for commands supported on the server, check wheter the server
counterpart is a command defined on the server or a local placeholder.

https://fedorahosted.org/freeipa/ticket/6089
---
 ipaclient/plugins/automount.py|  3 ++-
 ipaclient/plugins/otptoken_yubikey.py |  3 ++-
 ipaclient/plugins/vault.py| 12 
 3 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/ipaclient/plugins/automount.py b/ipaclient/plugins/automount.py
index 8405f9f..c6537bc 100644
--- a/ipaclient/plugins/automount.py
+++ b/ipaclient/plugins/automount.py
@@ -54,7 +54,8 @@ class _fake_automountlocation_show(Method):
 class automountlocation_tofiles(MethodOverride):
 @property
 def NO_CLI(self):
-return self.api.Command.automountlocation_show.NO_CLI
+return isinstance(self.api.Command.automountlocation_show,
+  _fake_automountlocation_show)
 
 def output_for_cli(self, textui, result, *keys, **options):
 maps = result['result']['maps']
diff --git a/ipaclient/plugins/otptoken_yubikey.py b/ipaclient/plugins/otptoken_yubikey.py
index 5e0d994..423b670 100644
--- a/ipaclient/plugins/otptoken_yubikey.py
+++ b/ipaclient/plugins/otptoken_yubikey.py
@@ -76,7 +76,8 @@ class otptoken_add_yubikey(Command):
 
 @property
 def NO_CLI(self):
-return self.api.Command.otptoken_add.NO_CLI
+return isinstance(self.api.Command.otptoken_add,
+  _fake_otptoken_add)
 
 def get_args(self):
 for arg in self.api.Command.otptoken_add.args():
diff --git a/ipaclient/plugins/vault.py b/ipaclient/plugins/vault.py
index b7e0cff..e3a1ae3 100644
--- a/ipaclient/plugins/vault.py
+++ b/ipaclient/plugins/vault.py
@@ -204,7 +204,8 @@ class vault_add(Local):
 
 @property
 def NO_CLI(self):
-return self.api.Command.vault_add_internal.NO_CLI
+return isinstance(self.api.Command.vault_add_internal,
+  _fake_vault_add_internal)
 
 def get_args(self):
 for arg in self.api.Command.vault_add_internal.args():
@@ -401,7 +402,8 @@ class vault_mod(Local):
 
 @property
 def NO_CLI(self):
-return self.api.Command.vault_mod_internal.NO_CLI
+return isinstance(self.api.Command.vault_mod_internal,
+  _fake_vault_mod_internal)
 
 def get_args(self):
 for arg in self.api.Command.vault_mod_internal.args():
@@ -579,7 +581,8 @@ class vault_archive(Local):
 
 @property
 def NO_CLI(self):
-return self.api.Command.vault_archive_internal.NO_CLI
+return isinstance(self.api.Command.vault_archive_internal,
+  _fake_vault_archive_internal)
 
 def get_args(self):
 for arg in self.api.Command.vault_archive_internal.args():
@@ -827,7 +830,8 @@ class vault_retrieve(Local):
 
 @property

[Freeipa-devel] [PATCH] restrict setkeytab operation

[Simo Sorce]

As described in #232 start restricting the use of the setkeytab
operation to just the computers objects.

I haven't tested this with older RHEL/CentOS machines that actully use
the setkeytab operation as I do not have such an old VM handy right now.

Meanwhile I'd like to know if ppl agree with this approach.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York
From 26afe94cea65ba50041592cf31f97b9e0502aeb0 Mon Sep 17 00:00:00 2001
From: Simo Sorce 
Date: Mon, 25 Jul 2016 06:46:24 -0400
Subject: [PATCH] Restrict the old setkeytab operation

Allow it only to set computers keys by default. This is to allow older hosts
to join a newer IPA Server only. All other principals are denied access to
the setkeytab operation by default.

Ticket: https://fedorahosted.org/freeipa/ticket/232

Signed-off-by: Simo Sorce 
---
 daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c | 13 -
 install/updates/20-aci.update   |  5 +
 2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c b/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c
index 3c2c44f6198bf74615fff1ae231a48bed77526ee..48880cdb74d2d12f016905c151f8fa9ad36c6d8a 100644
--- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c
+++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c
@@ -1171,6 +1171,8 @@ done:
 return rc;
 }
 
+#define SETKEYS_OP_CHECK "ipaProtectedOperation;set_keys"
+
 /* Password Modify Extended operation plugin function */
 static int ipapwd_setkeytab(Slapi_PBlock *pb, struct ipapwd_krbcfg *krbcfg)
 {
@@ -1238,15 +1240,24 @@ static int ipapwd_setkeytab(Slapi_PBlock *pb, struct ipapwd_krbcfg *krbcfg)
 goto free_and_return;
 }
 
-/* Accesseck strategy:
+/* Access check strategy:
  * If the user has WRITE access, a new keytab can be set on the entry.
  * If not, then we fail immediately with insufficient access. This
  * means that we don't leak any useful information to the client such
  * as current password wrong, etc.
+ *
+ * In addition to the historic check, we now also check if the setkeytab
+ * operation is allowed at all.
  */
 allowed_access = is_allowed_to_access_attr(pb, bindDN, targetEntry,
"krbPrincipalKey", NULL,
SLAPI_ACL_WRITE);
+if (allowed_access) {
+/* check if we are allowed to *set* keys */
+allowed_access = is_allowed_to_access_attr(pb, bindDN, targetEntry,
+   SETKEYS_OP_CHECK, NULL,
+   SLAPI_ACL_WRITE);
+}
 if (!allowed_access) {
 LOG_FATAL("Access not allowed to set keytab on [%s]!\n",
   serviceName);
diff --git a/install/updates/20-aci.update b/install/updates/20-aci.update
index e9c10f54aadf5062c5a03f0d4b36343079462919..0251a7af9b7520f7164b112d19a59d897226f218 100644
--- a/install/updates/20-aci.update
+++ b/install/updates/20-aci.update
@@ -114,6 +114,11 @@ add:aci: (targetattr="ipaProtectedOperation;write_keys")(version 3.0; acl "Entit
 add:aci: (targetattr="ipaProtectedOperation;write_keys")(version 3.0; acl "Admins are allowed to rekey any entity"; allow(write) groupdn = "ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX;;)
 add:aci: (targetfilter="(|(objectclass=ipaHost)(objectclass=ipaService))")(targetattr="ipaProtectedOperation;write_keys")(version 3.0; acl "Entities are allowed to rekey managed entries"; allow(write) userattr="managedby#USERDN";)
 
+# Set Keytab operation Access Control - legacy interface for host joins
+dn: cn=computers,cn=accounts,$SUFFIX
+add:aci: (targetattr="ipaProtectedOperation;set_keys")(version 3.0; acl "Installers are allowed to set host keytabs"; allow(write) userattr="managedby#USERDN";)
+add:aci: (targetattr="ipaProtectedOperation;set_keys")(version 3.0; acl "Admins are allowed to set host keytabs"; allow(write) groupdn = "ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX;;)
+
 # User certificates
 dn: $SUFFIX
 add:aci:(targetattr = "usercertificate")(version 3.0;acl "selfservice:Users can manage their own X.509 certificates";allow (write) userdn = "ldap:///self;;)
-- 
2.5.5

-- 
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] [Design Review Request] V4/Automatic_Certificate_Request_Generation

[Alexander Bokovoy]

On Mon, 25 Jul 2016, Jan Cholasta wrote:

This is turning out to be a common (and, I think, reasonable) reaction
to the proposal. It is rather complex, and I worry that it will be
difficult to configure. On the other hand, there is some hidden
complexity to enabling a simpler config format, as well. One of the
goals of the project as it was presented to me was to allow the creation
of profiles that add certificate extensions *that FreeIPA doesn't yet
know about*. With the current proposal, one only has to add a rule
generating text that the helper will understand.


... which will be possible only as long as the helper understands the
extension. Which it might not, thus the current proposal works only
for *some* extensions that FreeIPA doesn't yet support.

We can go ad infinitum here but with any helper implementation, be it
python-cryptography or anything else, you will need to have a support
there as well.


My point was that the current proposal is not any better than my 
proposal in this regard, as neither of them allows one to use an 
arbitrary extension.

That's true. One of arguments for supporting openssl format was to allow
people to generate CSRs themselves later. E.g. it would be a stepping
stone to some automation around certificates to those who need it.
Turning everything into python-cryptography has less benefit in this
context.


The idea with unknown extensions was to allow mapping
their acceptance to a specific relationship between IPA objects
(optionally) and an input from the CSR. A simplest example would be an
identity rule that would copy an ASN.1 encoded content from the CSR to
the certificate.

That's on the mapping side, not on the CSR generation side, but it would
go similarly for the CSR if you would be able to enter unknown but
otherwise correct ASN.1 stream. There is no difference at which helper
type we are talking about because all of them support inserting ASN.1
content.


With your suggestion,
if there's a mapping between "san_directoryname" and the corresponding
API calls or configuration lines, we need some way for users to augment
that mapping without changing the code. If there's no mapping, and it's
just done with text processing, we need enough in the config format to
be able to generate fairly complex structures:

builder = builder.subject_name(x509.Name(u'CN=user,O=EXAMPLE.COM'))
builder =
builder.add_extension(x509.SubjectAlternativeName([x509.RFC822Name(u'u...@example.com'),

x509.DirectoryName(x509.Name(u'CN=user,O=EXAMPLE.COM'))]), False)

and we need to do it without it being equivalent to calling eval() on
the config attributes. I'm not sure how to achieve this (is it safe to
call getattr(x509, extensiontype)(value) where extensiontype and value
are user-specified?) and it definitely would have to be tied to a
particular library/tool.


As I pointed out above, this needs to be figured out for the generic
case for both the current proposal and my suggestion.

OTOH, I think we could use GSER encoding of the extension value:

  { rfc822Name:"u...@example.com",
directoryName:rdnSequence:"CN=user,O=EXAMPLE.COM" }

GSER is not really used widely and does not have standardized encoding
rules beyond its own definition. If you want to allow transformation
rules in GSER that mention existing content in IPA objects, you would
need to deal with templating anyway. At this point it becomes irrelevant
what you are templating, though.


True, but the goal here is not to avoid templating, but rather to 
avoid implementation-specific bits on the server, and GSER is the only 
thing that is textual, implementation-neutral and, as a bonus, 
standardized.

If we move these bits to the client, the only thing server will need to
deal with is CSR. The client then would definitely need to have ability
to provide alternative CSR sources (e.g. openssl text format) to aid
API users that don't utilize IPA tools directly. At this point GSER use
is irrelevant either.
--
/ 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] [PATCH 42-47][tests] RFE: Allow users to authenticate with alternative names

[Milan Kubík]

On 07/25/2016 01:53 PM, Milan Kubík wrote:

Hi,

I'm sending the tests for kerberos principal aliases rfe. The tests 
are implemented according to test plan [1] sent earlier.
Some of the patches implement modifications and extensions to previous 
code to allow implement the tests themselves.


The patches can be cloned also from github [2].

[1]: http://www.freeipa.org/page/V4/Kerberos_principal_aliases/Test_Plan
[2]: https://github.com/apophys/freeipa/tree/krb5-principal-aliases-test

Cheers,





Self nack for 0047, the ldapconn fixture is not needed. New patch attached.
Git repo updated (force-push).

--
Milan Kubik

From 5dd5fe5d0ccc921949dedb2f3e2497344f87e493 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Milan=20Kub=C3=ADk?= 
Date: Fri, 22 Jul 2016 17:25:06 +0200
Subject: [PATCH] ipatests: Add kerberos principal alias tests

Add tests for alias manipulation, tests authentication and several
error scenarios.

https://fedorahosted.org/freeipa/ticket/3864
https://fedorahosted.org/freeipa/ticket/5413
https://fedorahosted.org/freeipa/ticket/6099
---
 .../test_xmlrpc/test_kerberos_principal_aliases.py | 261 +
 1 file changed, 261 insertions(+)
 create mode 100644 ipatests/test_xmlrpc/test_kerberos_principal_aliases.py

diff --git a/ipatests/test_xmlrpc/test_kerberos_principal_aliases.py b/ipatests/test_xmlrpc/test_kerberos_principal_aliases.py
new file mode 100644
index ..11a69e6664a219c6f6b682266ff1b75327ae0046
--- /dev/null
+++ b/ipatests/test_xmlrpc/test_kerberos_principal_aliases.py
@@ -0,0 +1,261 @@
+# coding: utf-8
+#
+# Copyright (C) 2016  FreeIPA Contributors see COPYING for license
+#
+import ldap
+import pytest
+
+from ipalib import errors, api
+from ipapython import ipautil
+from ipaplatform.paths import paths
+
+from ipatests.util import MockLDAP
+from ipatests.test_xmlrpc.xmlrpc_test import XMLRPC_test
+from ipatests.test_xmlrpc.tracker.user_plugin import UserTracker
+from ipatests.test_xmlrpc.tracker.host_plugin import HostTracker
+from ipatests.test_xmlrpc.tracker.service_plugin import ServiceTracker
+from ipatests.test_xmlrpc.test_range_plugin import (
+get_trust_dn, get_trusted_dom_dict, encode_mockldap_value)
+from ipatests.test_xmlrpc.utils import mocked_trust_containers
+from ipatests.util import unlock_principal_password, change_principal
+
+
+@pytest.yield_fixture
+def trusted_domain():
+"""Fixture providing mocked AD trust entries
+
+The fixture yields after creating a mock of AD trust
+entries in the directory server. After the test, the entries
+are deleted from the directory.
+"""
+trusted_dom = u'trusted.domain.net'
+trusted_dom_dn = get_trust_dn(trusted_dom)
+trusted_dom_sid = u'S-1-5-21-2997650941-1802118864-3094776726'
+
+trusted_dom_add = get_trusted_dom_dict(trusted_dom, trusted_dom_sid)
+
+# Write the changes
+with mocked_trust_containers(), MockLDAP() as ldap:
+ldap.add_entry(trusted_dom_dn, trusted_dom_add)
+yield trusted_dom
+ldap.del_entry(trusted_dom_dn)
+
+
+@pytest.yield_fixture
+def trusted_domain_with_suffix():
+"""Fixture providing mocked AD trust entries
+
+The fixture yields after creating a mock of AD trust
+entries in the directory server. After the test, the entries
+are deleted from the directory.
+"""
+trusted_dom = u'trusted.domain.net'
+trusted_dom_dn = get_trust_dn(trusted_dom)
+trusted_dom_sid = u'S-1-5-21-2997650941-1802118864-3094776726'
+
+trusted_dom_add = get_trusted_dom_dict(trusted_dom, trusted_dom_sid)
+trusted_dom_add['ipaNTAdditionalSuffixes'] = (
+encode_mockldap_value(trusted_dom))
+
+# Write the changes
+with mocked_trust_containers(),  MockLDAP() as ldap:
+ldap.add_entry(trusted_dom_dn, trusted_dom_add)
+yield trusted_dom
+ldap.del_entry(trusted_dom_dn)
+
+
+@pytest.fixture(scope='function')
+def krbalias_user(request):
+tracker = UserTracker(u'krbalias_user', u'krbalias', u'test')
+
+return tracker.make_fixture(request)
+
+
+@pytest.fixture(scope='function')
+def krbalias_user_c(request):
+tracker = UserTracker(u'krbalias_user_conflict', u'krbalias', u'test')
+
+return tracker.make_fixture(request)
+
+
+@pytest.fixture(scope='function')
+def krbalias_host(request):
+tracker = HostTracker(u'testhost-krb')
+
+return tracker.make_fixture(request)
+
+
+@pytest.fixture
+def krb_service_host(request):
+tracker = HostTracker(u'krb-srv-host')
+
+return tracker.make_fixture(request)
+
+
+@pytest.fixture(scope='function')
+def krbalias_service(request, krb_service_host):
+krb_service_host.ensure_exists()
+
+tracker = ServiceTracker(name=u'SRV1', host_fqdn=krb_service_host.name)
+
+return tracker.make_fixture(request)
+
+
+@pytest.fixture
+def ldapservice(request):
+tracker = ServiceTracker(
+name=u'ldap', host_fqdn=api.env.host, options={'has_keytab': True})
+
+

[Freeipa-devel] [PATCH 42-47][tests] RFE: Allow users to authenticate with alternative names

[Milan Kubík]

Hi,

I'm sending the tests for kerberos principal aliases rfe. The tests are 
implemented according to test plan [1] sent earlier.
Some of the patches implement modifications and extensions to previous 
code to allow implement the tests themselves.


The patches can be cloned also from github [2].

[1]: http://www.freeipa.org/page/V4/Kerberos_principal_aliases/Test_Plan
[2]: https://github.com/apophys/freeipa/tree/krb5-principal-aliases-test

Cheers,

--
Milan Kubik

From e4fdd561af48beb02748e9cb14ffcb4e5f257128 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Milan=20Kub=C3=ADk?= 
Date: Fri, 22 Jul 2016 17:07:56 +0200
Subject: [PATCH 1/6] ipatests: Add tracker class for kerberos principal
 aliases

The commit implements a mixin class providing capability
to track and modify kerberos principal aliases on supported
types of entries.

The class using the mixin must inherit from the Tracker class
and must provide the implementation of two methods:

* _make_add_alias_cmd
* _make_remove_alias_cmd

These are used to get the type specific command for the particular
entry class. The methods provided will not work on entries that
do not have 'krbprincipalname' attribute.

The service, host and user trackers are being extended to use this
new mixin class.

https://fedorahosted.org/freeipa/ticket/3864
---
 ipatests/test_xmlrpc/tracker/host_plugin.py  |  10 ++-
 ipatests/test_xmlrpc/tracker/kerberos_aliases.py | 110 +++
 ipatests/test_xmlrpc/tracker/service_plugin.py   |  17 +++-
 ipatests/test_xmlrpc/tracker/user_plugin.py  |  10 ++-
 4 files changed, 141 insertions(+), 6 deletions(-)
 create mode 100644 ipatests/test_xmlrpc/tracker/kerberos_aliases.py

diff --git a/ipatests/test_xmlrpc/tracker/host_plugin.py b/ipatests/test_xmlrpc/tracker/host_plugin.py
index 03113b8fe7de7bfa2d2383b1903ff05d2543a9ed..8630a7d0c96edd725f448f5a460df91dd8f37ccc 100644
--- a/ipatests/test_xmlrpc/tracker/host_plugin.py
+++ b/ipatests/test_xmlrpc/tracker/host_plugin.py
@@ -7,13 +7,14 @@ from __future__ import print_function
 
 from ipapython.dn import DN
 from ipatests.test_xmlrpc.tracker.base import Tracker
+from ipatests.test_xmlrpc.tracker.kerberos_aliases import KerberosAliasMixin
 from ipatests.test_xmlrpc.xmlrpc_test import fuzzy_uuid
 from ipatests.test_xmlrpc import objectclasses
 from ipatests.util import assert_deepequal
 from ipalib import errors
 
 
-class HostTracker(Tracker):
+class HostTracker(Tracker, KerberosAliasMixin):
 """Wraps and tracks modifications to a Host object
 
 Implements the helper functions for host plugin.
@@ -175,3 +176,10 @@ class HostTracker(Tracker):
 pass
 
 request.addfinalizer(cleanup)
+
+#  Kerberos aliases methods
+def _make_add_alias_cmd(self):
+return self.make_command('host_add_principal', self.name)
+
+def _make_remove_alias_cmd(self):
+return self.make_command('host_remove_principal', self.name)
diff --git a/ipatests/test_xmlrpc/tracker/kerberos_aliases.py b/ipatests/test_xmlrpc/tracker/kerberos_aliases.py
new file mode 100644
index ..cf82a7a8ce27506fd0cdbff6d297ffa5c5b6e4b9
--- /dev/null
+++ b/ipatests/test_xmlrpc/tracker/kerberos_aliases.py
@@ -0,0 +1,110 @@
+#
+# Copyright (C) 2016  FreeIPA Contributors see COPYING for license
+#
+"""kerberos_aliases
+
+The module implements a mixin class that provides an interface
+to the Kerberos Aliases feature of freeIPA.
+
+In order to use the class the child class must implement the
+`_make_add_alias_cmd` and `_make_remove_alias_cmd` methods that
+are different for each entity type.
+
+The KerberosAliasMixin class then provides the implementation
+of the manipulation of the kerberos alias in general.
+
+It is up to the child class or the user to validate the
+alias being added for a particular type of an entry.
+"""
+
+from ipatests.test_xmlrpc.tracker.base import Tracker
+
+
+class KerberosAliasError(Exception):
+pass
+
+
+class KerberosAliasMixin:
+"""KerberosAliasMixin"""
+
+def _make_add_alias_cmd(self):
+raise RuntimeError("The _make_add_alias_cmd method "
+   "is not implemented.")
+
+def _make_remove_alias_cmd(self):
+raise RuntimeError("The _make_remove_alias_cmd method "
+   "is not implemented.")
+
+def _check_for_tracker(self):
+if not isinstance(self, Tracker):
+raise KerberosAliasError("Class using {} must inherit from {}."
+ .format(KerberosAliasMixin, Tracker))
+
+def _check_for_krbprincipalname_attr(self):
+# Check if the tracker has a principal name
+# Each compatible entry has at least one kerberos
+# principal matching the canonical principal name
+principals = self.attrs.get('krbprincipalname')
+if self.exists:
+if not principals:
+raise KerberosAliasError(
+"{} 

Re: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation

[Jan Cholasta]

On 25.7.2016 13:11, Alexander Bokovoy wrote:

On Mon, 25 Jul 2016, Jan Cholasta wrote:

On 20.7.2016 16:05, Ben Lipton wrote:

Hi,

Thanks very much for the feedback! Some responses below; I hope you'll
let me know what you think of my reasoning.


On 07/20/2016 04:20 AM, Jan Cholasta wrote:

Hi,

On 17.6.2016 00:06, Ben Lipton wrote:

On 06/14/2016 08:27 AM, Ben Lipton wrote:

Hello all,

I have written up a design proposal for making certificate requests
easier to generate when using alternate certificate profiles:
http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation.


The use case for this is described in
https://fedorahosted.org/freeipa/ticket/4899. I will be working on
implementing this design over the next couple of months. If you have
the time and interest, please take a look and share any comments or
concerns that you have.

Thanks!

Ben


Just a quick update to say that I've created a new document that
covers
the proposed schema additions in a more descriptive way (with
diagrams!)
I'm very new to developing with LDAP, so some more experienced eyes on
the proposal would be very helpful, even if you don't have time to
absorb the full design. Please take a look at
http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation/Schema


if you have a chance.


I finally had a chance to take a look at this, here are some comments:

1) I don't like how transformation rules are tied to a particular
helper and have to be duplicated for each of them. They should be
generic and work with any helper, as helpers are just an
implementation detail and their resulting data is the same.

In fact, I think I would prefer if the CSR was generated using
python-cryptography's CertificateSigningRequestBuilder [1] rather than
openssl or certutil or any other command line tool.


There are lots of tools that users might want to use to manage their
private keys, so I don't know if we can assume that whatever library we
prefer will actually be able to access the private key to sign a CSR,
which is why I thought it would be useful to support more than one.


python-cryptography has the notion of backends, which allow it to
support multiple crypto implementations. Upstream it currently
supports only OpenSSL [2], but some work has been done on PKCS#11
backend [3], which provides support for HSMs and soft-tokens (like NSS
databases).

Alternatively, for NSS databases (and other "simple" cases), you can
generate the private key with python-cryptography using the default
backend, export it to a file and import the file to the target
database, so you don't actually need the PKCS#11 backend for them.

So, the only thing that's currently lacking is HSM support, but given
that we don't support HSMs in IPA nor in certmonger, I don't think
it's an issue for now.


The
purpose of the mapping rule is to tie together the transformation rules
that produce the same data into an object that's
implementation-agnostic, so that profiles referencing those rules are
automatically compatible with all the helper options.


They are implementation-agnostic, as long as you consider `openssl`
and `certutil` the only implementations :-) But I don't think this
solution scales well to other possible implementations.

Anyway, my main grudge is that the transformation rules shouldn't
really be stored on and processed by the server. The server should
know the *what* (mapping rules), but not the *how* (transformation
rules). The *how* is an implementation detail and does not change in
time, so there's no benefit in handling it on the server. It should be
handled exclusively on the client, which I believe would also make the
whole thing more robust (it would not be possible for a bug on the
server to break all the clients).

This is a good point. However, for the scope of Ben's project can we
limit it by openssl and certutil support? Otherwise Ben wouldn't be able
to complete the project in time.


I'm fine with that, but I don't think it's up to me :-)




This is turning out to be a common (and, I think, reasonable) reaction
to the proposal. It is rather complex, and I worry that it will be
difficult to configure. On the other hand, there is some hidden
complexity to enabling a simpler config format, as well. One of the
goals of the project as it was presented to me was to allow the creation
of profiles that add certificate extensions *that FreeIPA doesn't yet
know about*. With the current proposal, one only has to add a rule
generating text that the helper will understand.


... which will be possible only as long as the helper understands the
extension. Which it might not, thus the current proposal works only
for *some* extensions that FreeIPA doesn't yet support.

We can go ad infinitum here but with any helper implementation, be it
python-cryptography or anything else, you will need to have a support
there as well.


My point was that the current proposal is not any better than my 
proposal in this regard, as neither of 

Re: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation

[Alexander Bokovoy]

On Mon, 25 Jul 2016, Jan Cholasta wrote:

On 20.7.2016 16:05, Ben Lipton wrote:

Hi,

Thanks very much for the feedback! Some responses below; I hope you'll
let me know what you think of my reasoning.


On 07/20/2016 04:20 AM, Jan Cholasta wrote:

Hi,

On 17.6.2016 00:06, Ben Lipton wrote:

On 06/14/2016 08:27 AM, Ben Lipton wrote:

Hello all,

I have written up a design proposal for making certificate requests
easier to generate when using alternate certificate profiles:
http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation.

The use case for this is described in
https://fedorahosted.org/freeipa/ticket/4899. I will be working on
implementing this design over the next couple of months. If you have
the time and interest, please take a look and share any comments or
concerns that you have.

Thanks!

Ben


Just a quick update to say that I've created a new document that covers
the proposed schema additions in a more descriptive way (with diagrams!)
I'm very new to developing with LDAP, so some more experienced eyes on
the proposal would be very helpful, even if you don't have time to
absorb the full design. Please take a look at
http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation/Schema

if you have a chance.


I finally had a chance to take a look at this, here are some comments:

1) I don't like how transformation rules are tied to a particular
helper and have to be duplicated for each of them. They should be
generic and work with any helper, as helpers are just an
implementation detail and their resulting data is the same.

In fact, I think I would prefer if the CSR was generated using
python-cryptography's CertificateSigningRequestBuilder [1] rather than
openssl or certutil or any other command line tool.


There are lots of tools that users might want to use to manage their
private keys, so I don't know if we can assume that whatever library we
prefer will actually be able to access the private key to sign a CSR,
which is why I thought it would be useful to support more than one.


python-cryptography has the notion of backends, which allow it to 
support multiple crypto implementations. Upstream it currently 
supports only OpenSSL [2], but some work has been done on PKCS#11 
backend [3], which provides support for HSMs and soft-tokens (like NSS 
databases).


Alternatively, for NSS databases (and other "simple" cases), you can 
generate the private key with python-cryptography using the default 
backend, export it to a file and import the file to the target 
database, so you don't actually need the PKCS#11 backend for them.


So, the only thing that's currently lacking is HSM support, but given 
that we don't support HSMs in IPA nor in certmonger, I don't think 
it's an issue for now.



The
purpose of the mapping rule is to tie together the transformation rules
that produce the same data into an object that's
implementation-agnostic, so that profiles referencing those rules are
automatically compatible with all the helper options.


They are implementation-agnostic, as long as you consider `openssl` 
and `certutil` the only implementations :-) But I don't think this 
solution scales well to other possible implementations.


Anyway, my main grudge is that the transformation rules shouldn't 
really be stored on and processed by the server. The server should 
know the *what* (mapping rules), but not the *how* (transformation 
rules). The *how* is an implementation detail and does not change in 
time, so there's no benefit in handling it on the server. It should be 
handled exclusively on the client, which I believe would also make the 
whole thing more robust (it would not be possible for a bug on the 
server to break all the clients).

This is a good point. However, for the scope of Ben's project can we
limit it by openssl and certutil support? Otherwise Ben wouldn't be able
to complete the project in time.


This is turning out to be a common (and, I think, reasonable) reaction
to the proposal. It is rather complex, and I worry that it will be
difficult to configure. On the other hand, there is some hidden
complexity to enabling a simpler config format, as well. One of the
goals of the project as it was presented to me was to allow the creation
of profiles that add certificate extensions *that FreeIPA doesn't yet
know about*. With the current proposal, one only has to add a rule
generating text that the helper will understand.


... which will be possible only as long as the helper understands the 
extension. Which it might not, thus the current proposal works only 
for *some* extensions that FreeIPA doesn't yet support.

We can go ad infinitum here but with any helper implementation, be it
python-cryptography or anything else, you will need to have a support
there as well. The idea with unknown extensions was to allow mapping
their acceptance to a specific relationship between IPA objects
(optionally) and an input from the CSR. A simplest example would be an

Re: [Freeipa-devel] [PATCH 0029][Tests] Adding authentication test to trust test suite

[Martin Babinsky]

On 07/22/2016 11:20 AM, Lenka Doudova wrote:



On 07/20/2016 02:28 PM, Martin Babinsky wrote:

On 07/19/2016 10:41 AM, Lenka Doudova wrote:

Hi,


this patch adds authentication test (specifically "kinit -E
ipauser@IPADOMAIN") to basic trust test suite, as requested by Sumit.

Intended to be applied after my patches 25.4 and 26.3 (already waiting
to be pushed).


Lenka





Hi Lenka,

Code review:

1.) You have several PEP8 transgressions in the patch, please fix them:
"""
$ git show -U0 | pep8 --diff
./ipatests/test_integration/test_trust.py:172:34: E127 continuation
line over-indented for visual indent
./ipatests/test_integration/test_trust.py:176:35: E128 continuation
line under-indented for visual indent
./ipatests/test_integration/test_trust.py:180:27: E231 missing
whitespace after ','
"""

2.)
+
+
+def unlock_principal_password(user, oldpw, newpw, master):
+container_user = "cn=users,cn=accounts"
+basedn = master.domain.basedn
+
+userdn = "uid={},{},{}".format(user, container_user, basedn)
+
+args = [paths.LDAPPASSWD, '-D', userdn, '-w', oldpw, '-a', oldpw,
+'-s', newpw, '-x']
+return run(args)

there is already a function with the same name in other module:

"""
git grep -ni 'def unlock_principal_password' ipatests
ipatests/test_integration/util.py:82:def
unlock_principal_password(user, oldpw, newpw, master):
ipatests/util.py:676:def unlock_principal_password(user, oldpw, newpw):
"""

Having functions with the same names in different modules makes for
poor coding practice IMHO. Please rename the function to something
like "ldappasswd_user" or something like that so that we have a
distinction.

Also, you should call ldappasswd directly on master (since you pass it
as an argument anyway) using "master.run_command(args)". You should
*not* run any in-test code on the controller unless absolutely necessary.

You can then remove the ipautil.run import from the beginning of the
module.

Commit message woes:

1.) vague summary is vague, I would rather see something like:

"""
test that IPA user can kinit using enterprise principal with IPA domain
"""

2.) Commit message body is longer than 78 characters.

3.) there is no ticket URL, I think you can link
https://fedorahosted.org/freeipa/ticket/6036 or create a new ticket
for the change.


Hi,

thanks for review, fixed (and renamed) patch attached.

Lenka


Thanks, ACK.

Pushed to master: 648b5afa2f2d01d99c1cf2d1f4a87a5da4461246

--
Martin^3 Babinsky

--
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] [PATCH] 0083: webui: remove full name column from user to user group adder dialog

[Alexander Bokovoy]

On Thu, 21 Jul 2016, Pavel Vomacka wrote:

Remove full name from adding user to user group dialog

As the 'cn' is not in the response of user-show there is empty column 
in adder dialog.

Therefore the column was removed.

https://fedorahosted.org/freeipa/ticket/6055

ACK.

--
/ 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] PATCH: Improve on #2795 patches

[Simo Sorce]

On Wed, 2016-07-20 at 15:17 +0200, David Kupka wrote:
> On 20/07/16 12:11, Simo Sorce wrote:
> > Attached patch introduces a helper function and avoids the questionable
> > replace+delete operations where possible (still employed in the
> > entry_to_mods function).
> > Compiles and I am about to test it, but I'd like feedback on it if
> > anyone wants to take a look.
> >
> > Simo.
> >
> >
> >
> 
> Looks and works good, ACK.
> 

Pushed to master: ab4fcb0fe25e313c93caae3b90f68b4010a9f2eb

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] [Design Review Request] V4/Automatic_Certificate_Request_Generation

[Simo Sorce]

On Mon, 2016-07-25 at 10:50 +0200, Jan Cholasta wrote:
> Anyway, my main grudge is that the transformation rules shouldn't
> really 
> be stored on and processed by the server. The server should know the 
> *what* (mapping rules), but not the *how* (transformation rules). The 
> *how* is an implementation detail and does not change in time, so 
> there's no benefit in handling it on the server. It should be handled 
> exclusively on the client, which I believe would also make the whole 
> thing more robust (it would not be possible for a bug on the server
> to 
> break all the clients).

W/o entering in specific +1 as a general comment on this.
If it can be done on the client, probably better be done there.

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] [DESIGN] Text-based rules for CSR autogeneration using Jinja2

[Jan Cholasta]

On 21.7.2016 17:43, Petr Spacek wrote:

On 20.7.2016 19:25, Ben Lipton wrote:

On 07/20/2016 12:21 PM, Simo Sorce wrote:

On Wed, 2016-07-20 at 12:14 -0400, Ben Lipton wrote:

On 07/20/2016 10:37 AM, Simo Sorce wrote:

On Wed, 2016-07-20 at 10:17 -0400, Ben Lipton wrote:

On 07/20/2016 06:27 AM, Simo Sorce wrote:

On Tue, 2016-07-19 at 16:20 -0400, Ben Lipton wrote:

Hi,

I have updated the design page
http://www.freeipa.org/page/V4/Automatic_Certificate_Request_
Gene
rati
on/Mapping_Rules
with my plan for implementing user-configurable rules for
mapping
IPA
data into certificate requests. In brief: we will use Jinja2
for
templating. Data rules (which map individual data items) and
syntax
rules (which group them into certificate fields) will both be
snippets
of Jinja2 markup. The formatting process will be as follows:


I've finally found some time to read the sub-page Mapping_Rules and for me it
is kind of hard to follow. It would not be understandable without this e-mail
and the blog posts (BTW the blog articles are among best I have seen!).

Most importantly, the explanations in brackets above ["Data rules (which map
individual data items) and (which group them into certificate fields)"] are
missing in the wiki page itself :-)

Could you fold relevant parts of the e-mails and blogs back into the wiki page
so it is self-contained?

Besides this nit,
http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation/Mapping_Rules#Planned_implementation
sounds reasonable. I like how it prevents bad data from template-injection.

Regarding
http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation/Schema#Option_A
, I prefer Option A with separate object for each helper. It is somehow
cleaner and it might be useful to use distinct object classes for each helper 
etc.


API for ipa cert-get-requestdata sounds good.
API for ipa cert-request makes sense to me as well.

In any case I would recommend you to consult API design with Jan Cholasta
 - he is our API custodian.


See the other thread for my comments: 
.





BTW I very much like "Alternatives considered" sections, we should have this
for each design!

Good work, I really like the dutiful analysis!




1. Syntax rules will be rendered using Jinja2. Data rules
(rule
text,
not rendered) will be passed as the datarules attribute.
2. Rendered syntax rules will be processed by the Formatter
class
for
the selected CSR generation helper (e.g. openssl or
certutil).
The
formatter combines these partial rules into a full template
for
the
config.
3. The template will be rendered using Jinja2. Relevant data
from
the
IPA database will be available in the context for this
rendering.
4. The final rendered template will be returned to the
caller,
labeled
with its function (e.g. a command line or a config file).

Are there any comments or objections to this approach? Here's
an
example
to show what it might look like in practice.

Example data rules:
email={{subject.email}}
O={{config.ipacertificatesubjectbase}}\nCN={{subject.username
}}

Example syntax rule:
subjectAltName=@{% section %}{{datarules|join('\n')}}{%
endsection %}

Example composed config template:
[ req ]
prompt = no
encrypt_key = no

distinguished_name = {% section
%}O={{config.ipacertificatesubjectbase}}
CN={{subject.username}}{% endsection %}

req_extensions = exts

[ exts ]
subjectAltName=@{% section %}email={{subject.email}}{%
endsection
%}

There's a lot more information about the thinking behind this
at
http://blog.benjaminlipton.com/2016/07/19/csr-generation-temp
lati
ng.h
tml
if you're interested, as well.

Nice work Ben,
it's been really nice to be able to follow your notes on the
blog
post,
one question remains lingering in my head, why jinja2 ?
I know that engine relatively well as I used it in ipsilon, so
I am
not
questioning the choice just asking why specifically jinja2 and
not
something else, potentially language agnostic.

Simo.

Honestly, my reasoning didn't go very far beyond that it seems to
be
widely used and is compatible with python, which is the language
where
the implementation is taking place (in the IPA RPC server). I
thought
about using the built-in python format strings or creating a
simple
domain-specific language, but the likelihood of wanting the
built-in
text processing features (join, replace, maybe even for loops)
seemed
high, and I didn't want to reimplement those features.

Will the additional package dependency be a problem?

I am more concerned a out the ability to process the data (which I
guess is stored in LDAP) by another client, or in the CLI.
Other than that the dependency does not concern me too much
provided
jinja2 templating is stable and has some guarantee that it will be
supportable long term.

If that is not guaranteed it is a problem, we cannot easily swap
out
one language for another once data is stored and used by the
server.
So the most 

Re: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation

[Jan Cholasta]

On 20.7.2016 16:05, Ben Lipton wrote:

Hi,

Thanks very much for the feedback! Some responses below; I hope you'll
let me know what you think of my reasoning.


On 07/20/2016 04:20 AM, Jan Cholasta wrote:

Hi,

On 17.6.2016 00:06, Ben Lipton wrote:

On 06/14/2016 08:27 AM, Ben Lipton wrote:

Hello all,

I have written up a design proposal for making certificate requests
easier to generate when using alternate certificate profiles:
http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation.

The use case for this is described in
https://fedorahosted.org/freeipa/ticket/4899. I will be working on
implementing this design over the next couple of months. If you have
the time and interest, please take a look and share any comments or
concerns that you have.

Thanks!

Ben


Just a quick update to say that I've created a new document that covers
the proposed schema additions in a more descriptive way (with diagrams!)
I'm very new to developing with LDAP, so some more experienced eyes on
the proposal would be very helpful, even if you don't have time to
absorb the full design. Please take a look at
http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generation/Schema

if you have a chance.


I finally had a chance to take a look at this, here are some comments:

1) I don't like how transformation rules are tied to a particular
helper and have to be duplicated for each of them. They should be
generic and work with any helper, as helpers are just an
implementation detail and their resulting data is the same.

In fact, I think I would prefer if the CSR was generated using
python-cryptography's CertificateSigningRequestBuilder [1] rather than
openssl or certutil or any other command line tool.


There are lots of tools that users might want to use to manage their
private keys, so I don't know if we can assume that whatever library we
prefer will actually be able to access the private key to sign a CSR,
which is why I thought it would be useful to support more than one.


python-cryptography has the notion of backends, which allow it to 
support multiple crypto implementations. Upstream it currently supports 
only OpenSSL [2], but some work has been done on PKCS#11 backend [3], 
which provides support for HSMs and soft-tokens (like NSS databases).


Alternatively, for NSS databases (and other "simple" cases), you can 
generate the private key with python-cryptography using the default 
backend, export it to a file and import the file to the target database, 
so you don't actually need the PKCS#11 backend for them.


So, the only thing that's currently lacking is HSM support, but given 
that we don't support HSMs in IPA nor in certmonger, I don't think it's 
an issue for now.



The
purpose of the mapping rule is to tie together the transformation rules
that produce the same data into an object that's
implementation-agnostic, so that profiles referencing those rules are
automatically compatible with all the helper options.


They are implementation-agnostic, as long as you consider `openssl` and 
`certutil` the only implementations :-) But I don't think this solution 
scales well to other possible implementations.


Anyway, my main grudge is that the transformation rules shouldn't really 
be stored on and processed by the server. The server should know the 
*what* (mapping rules), but not the *how* (transformation rules). The 
*how* is an implementation detail and does not change in time, so 
there's no benefit in handling it on the server. It should be handled 
exclusively on the client, which I believe would also make the whole 
thing more robust (it would not be possible for a bug on the server to 
break all the clients).




I do agree that it would be preferable to target APIs rather than
command-line tools. When looking at the openSSL and NSS APIs I came to
the conclusion that they would be more difficult than the command-line
tools to target, as a first implementation. However, I haven't really
looked at python-cryptography, and maybe it would have been a good choice.


The current trend is to port all crypto code to python-cryptography, so 
it is indeed a good choice :-)




2) The schema seems unnecessarily complex. I think all we need is a
single new multi-value attribute in certprofile. For your S/MIME
example, it could be something like:

attr: subjectname=CN={subject.cn},{subject_base}
attr: san_rfc822name={subject.email}
attr: san_directoryname={subject.dn}


This is turning out to be a common (and, I think, reasonable) reaction
to the proposal. It is rather complex, and I worry that it will be
difficult to configure. On the other hand, there is some hidden
complexity to enabling a simpler config format, as well. One of the
goals of the project as it was presented to me was to allow the creation
of profiles that add certificate extensions *that FreeIPA doesn't yet
know about*. With the current proposal, one only has to add a rule
generating text that the helper will