Re: [Freeipa-devel] [RFC] Matching and Mapping Certificates

[Jan Cholasta]

On 17.10.2016 16:50, Rob Crittenden wrote:

Jan Cholasta wrote:

Hi,

On 13.10.2016 18:52, Sumit Bose wrote:

= Issuer specific matching =
Although the MIT Kerberos rules allow to select the issuer of a
certificate there are use cases where a more specific selection is
needed. E.g. if there are some default matching rules for all issuers
and some other issuer specific rules where the default rules should
not apply. To make this possible with the above scheme the default
rules must have an  clause which matches all but the issuer
with the specific rules. Writing regular-expressions to not match a
specific string or a list of strings is at least error-prone if not
impossible.

To make it easier to define issuer specific rules and default rules at
the same time and optional issuer string can be added to the rule to
indicate that for the given issuer only those rules should be
considered. Given the use-case I think it is acceptable to require
that the full issuer must be specified here in LDAP order (see below)
and case-sensitive matching is used.


This could also be solved by adding priority to rules - if two rules
match, the one with higher priority (the issuer specific rule) is
preferred over the one with lower priority (the default rule). IMO this
is better than an optional issuer string as it offers greater
flexibility.


The use cases I've seen haven't had to do with priority, though that
would be a nice enhancement, but with only allowing certificates issued
by a specific CA to be allowed (this is pretty common in web servers).
Being able to say "only do the matching on certificates issued by foo"
is valuable.


Sure, I'm not suggesting that matching by issuer should be removed, only 
that rule precedence should not be determined by the issuer field setting.


--
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] [help]

[郑磊]

Hello everyone,
I'm using freeipa, and having a test and research with the  function of 
freeipa. At the same time, I have carried on the Chinese  translation to the 
web interface, also added own log module in web  interface, referring to the 
following screenshots. However, for these changes I don't know how to interact 
with  the community. Is there a administrator to review these changes? Who 
should I send mail to? Please help me. Thank you very much!-- 
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] [freeipa PR#168][opened] Update cli.py

[Garont]

   URL: https://github.com/freeipa/freeipa/pull/168
Author: Garont
 Title: #168: Update cli.py
Action: opened

PR body:
"""
fix for ipa host-find

ipa: ERROR: UnicodeEncodeError: 'ascii' codec can't encode characters in 
position 15-26: ordinal not in range(128)
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/ipalib/cli.py", line 1339, in run
sys.exit(api.Backend.cli.run(argv))
  File "/usr/lib/python2.7/site-packages/ipalib/cli.py", line 1104, in run
rv = cmd.output_for_cli(self.api.Backend.textui, result, *args, **options)
  File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 1029, in 
output_for_cli
textui.print_entries(result, order, labels, flags, print_all)
  File "/usr/lib/python2.7/site-packages/ipalib/cli.py", line 354, in 
print_entries
self.print_entry(entry, order, labels, flags, print_all, format, indent)
  File "/usr/lib/python2.7/site-packages/ipalib/cli.py", line 394, in 
print_entry
label, value, format, indent, one_value_per_line
  File "/usr/lib/python2.7/site-packages/ipalib/cli.py", line 317, in 
print_attribute
self.print_indented(format % (attr, text[0]), indent)
  File "/usr/lib/python2.7/site-packages/ipalib/cli.py", line 240, in 
print_indented
print (CLI_TAB * indent + text)
UnicodeEncodeError: 'ascii' codec can't encode characters in position 15-26: 
ordinal not in range(128)
ipa: ERROR: an internal error has occurred
"""

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/168/head:pr168
git checkout pr168
From 776117d6a1f478b87e61bfc42e6c80c63d9d Mon Sep 17 00:00:00 2001
From: Roman Rubilov 
Date: Mon, 17 Oct 2016 20:09:55 +0300
Subject: [PATCH] Update cli.py

fix for ipa host-find

ipa: ERROR: UnicodeEncodeError: 'ascii' codec can't encode characters in position 15-26: ordinal not in range(128)
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/ipalib/cli.py", line 1339, in run
sys.exit(api.Backend.cli.run(argv))
  File "/usr/lib/python2.7/site-packages/ipalib/cli.py", line 1104, in run
rv = cmd.output_for_cli(self.api.Backend.textui, result, *args, **options)
  File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 1029, in output_for_cli
textui.print_entries(result, order, labels, flags, print_all)
  File "/usr/lib/python2.7/site-packages/ipalib/cli.py", line 354, in print_entries
self.print_entry(entry, order, labels, flags, print_all, format, indent)
  File "/usr/lib/python2.7/site-packages/ipalib/cli.py", line 394, in print_entry
label, value, format, indent, one_value_per_line
  File "/usr/lib/python2.7/site-packages/ipalib/cli.py", line 317, in print_attribute
self.print_indented(format % (attr, text[0]), indent)
  File "/usr/lib/python2.7/site-packages/ipalib/cli.py", line 240, in print_indented
print (CLI_TAB * indent + text)
UnicodeEncodeError: 'ascii' codec can't encode characters in position 15-26: ordinal not in range(128)
ipa: ERROR: an internal error has occurred
---
 ipalib/cli.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ipalib/cli.py b/ipalib/cli.py
index 05bc0f5..247cb9c 100644
--- a/ipalib/cli.py
+++ b/ipalib/cli.py
@@ -248,7 +248,7 @@ def print_indented(self, text, indent=1):
 >>> ui.print_indented('No indentation.', indent=0)
 No indentation.
 """
-print((CLI_TAB * indent + text))
+print((CLI_TAB * indent + text.encode("utf-8")))
 
 def print_keyval(self, rows, indent=1):
 """
-- 
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] [Test][Patch-0047] Added a test for Ticket N 5964

[Martin Basti]

1)

you don't need to disable/enable dirsrv, just stop/start. Please remove 
disable/enable parts



2)

 traceback 


self = object at 0x7f6a502eec90>


def test_delete_ruvs(self):
"""
http://www.freeipa.org/page/V4/Manage_replication_topology_4_4/
Test_Plan#Test_case:_clean-ruv_subcommand
"""
replica = self.replicas[0]
master = self.master
res1 = master.run_command(['ipa-replica-manage', 'list-ruv', '-p',
  master.config.dirman_password])
>   assert(res1.stdout_text.count(replica.hostname) == 2 and
   "Certificate Server Replica Update Vectors" in res1), (
"CA-specific RUVs are not displayed")
E   TypeError: argument of type 'SSHCommand' is not iterable

test_integration/test_topology.py:215: TypeError
>> entering PDB 
>>>
> 
/usr/lib/python2.7/site-packages/ipatests/test_integration/test_topology.py(215)test_delete_ruvs()


-> assert(res1.stdout_text.count(replica.hostname) == 2 and



On 14.10.2016 11:36, Oleg Fayans wrote:

Right you are! I am sorry.

On 10/13/2016 06:10 PM, Martin Basti wrote:

I think that you forgot to squash commits. Patch 47 doesn't apply


On 13.10.2016 14:01, Oleg Fayans wrote:

Hi Martin,

Thanks for the review.
With disabling directory server it works as well, thanks for the hint.
Also I moved the cleanup logic to the test itself for the sake of
simplicity. Patch-0048 was not changed

On 10/12/2016 02:35 PM, Martin Basti wrote:

1)

Can you just turn off dirsrv on replica instead of doing iptables 
magic?



2) NACK

No more eval() ever in code, use 'getattr', 'get' or whatever in the
object that can be used.

+evalhost = eval("args[0].%s" % host)

Martin^2

On 12.10.2016 14:03, Oleg Fayans wrote:

Hi Martin,

After extensive discussion with Ludwig, I finally got the clue on how
does this feature work. When we uninstall the replica, the master
cleans the replication agreements with this replica and automatically
cleans all replica's RUVs.
If we clean replica's RUVs on master without uninstalling the 
replica,

the replica's RUVs get recreated on master (replication works!). So,
the only way to test the clean-ruv subcommand is to turn off the
replica, or block the traffic on it so it gets inaccessible to 
updates

from master.
The testcases were updated, see [1] and [2]

The updated versions of the patches are attached

[1]
http://www.freeipa.org/page/V4/Manage_replication_topology_4_4/Test_Plan#Test_case:_.2A-ruv_subcommands_of_ipa-replica-manage_are_extended_to_handle_CA-specific_RUVs 





[2]
http://www.freeipa.org/page/V4/Manage_replication_topology_4_4/Test_Plan#Test_case:_clean-ruv_subcommand 





On 08/05/2016 06:36 PM, Martin Basti wrote:



On 03.08.2016 14:45, Oleg Fayans wrote:

Hi Martin,

Thanks for the review! Both patches were updated.

On 07/28/2016 04:11 PM, Martin Basti wrote:



On 08.07.2016 15:41, Oleg Fayans wrote:

Hi Martin,

Thanks for the review!

On 07/08/2016 02:18 PM, Martin Basti wrote:



On 27.06.2016 13:53, Oleg Fayans wrote:

Hi guys,

Is there a chance the patches NN 0047.1 and 0048.1 get reviewed
before
4.4 release? They cover a good part of the Managed Topology 4.4
feature.

On 06/17/2016 11:18 AM, Oleg Fayans wrote:

One more test was added to the patch-0048

On 06/17/2016 09:43 AM, Oleg Fayans wrote:

Fixed a bug in the previous patch, automated 2 more testcases
from
http://www.freeipa.org/page/V4/Manage_replication_topology_4_4/Test_Plan 








On 06/16/2016 04:46 PM, Oleg Fayans wrote:










IIUC, this will turn off the machine completely, how is cleanup
done
then.  AFAIK our tests cannot turn on machine again and run
cleanup, so
you will not be able to run more tests on the same topology
without
manual cleanup and manual start.

+replica = self.replicas[0]
+replica.run_command(['poweroff'])

IMO would be better to just call 'ipactl stop' instead of
'poweroff'


Agreed! Fixed.



Martin^2






*Automated ipa-replica-manage del tests*

1)
+replica.run_command(['ipactl', 'stop'])
+time.sleep(3)

Why do you need sleep here?


Removed, it was left from the old "poweroff" approach




2)
+ruvid_re = re.compile(".*%s:389: (\d+).*" %
replica.hostname)
+replica_ruvs = ruvid_re.findall(result.stdout_text)
+master.run_command(['ipa-replica-manage', 'clean-ruv', 
'f',

+'-p', master.config.dirman_password,
+replica_ruvs[0]])

Because you are using re.findall(), without any match you will
receive

Re: [Freeipa-devel] Feature branches for sub-team efforts

[Simo Sorce]

On Tue, 2016-10-11 at 16:19 +0200, Petr Vobornik wrote:
> On 10/11/2016 03:50 PM, Alexander Bokovoy wrote:
> > On ti, 11 loka 2016, Petr Vobornik wrote:
> >> Hi List,
> >>
> >> we discussed locally a proposal about creating a feature branch for each
> >> sub-team effort in our main git. Currently it would be for the 4 ongoing
> >> refactoring efforts + Simo's work
> >>
> >> Why?
> >> It will allow each developer to create a pull request against the
> >> feature branch and thus it will enable iterative development by multiple
> >> devs without affecting other sub-teams. When the feature(refactoring) is
> >> finished, the branch would be rebased on master and merged there. Note:
> >> rebases can be done as needed - e.g. when other subteam finishes its
> >> work.
> >>
> >> Concerns:
> >> 1. Upstream git repo would be full of such branches.
> >> - This can be mitigated by deleting the feature branches when their are
> >> released or merged(up to discussion)
> > Don't put them in the upstream git repo. Let people decide where they
> > want to have them -- all Fedora contributors have access to
> > fedorapeople.org git hosting and there is github one button click
> > ('Clone') away from the github mirror.
> > 
> > It is not a problem to keep a separate git branch published this way.
> > 
> 
> It is not a matter of making the code public. That can be done easily as
> you write. Other alternative is own branch in GitHub fork.

Please go with this.
I see no point in having these branches in the main repo, it is just
clutter.

> > May be I misunderstand you -- if you just want people to propose merge
> > requests on github with pre-defined names, then that's just fine.
> > 
> 
> Basically it's all about review.
> 
> Example use case: More than 1 devs are working on a same big effort.
> This effort will probably consists of 10s of commits. The big effort is
> divided into smaller ones which can be implemented and reviewed
> separately. In our previous mode, the sub task would be merged to master
> it is reviewed and ACKed. But now we cannot do that. We want to merge
> the whole big task at once when it is finishes and tested.
> 
> One dev could probably have a branch on personal fork of FreeIPA on
> GitHub which would work as the feature branch. Other team members would
> create pull requests against it.

Exactly.

> In such case we would loose mail notifications and would have to extend
> our tooling because ipatool can use only one upstream on push.

Why would you need ipatool for a working branch ?

> Pre-defined names for PRs is a good idea - we could easily see what
> effort the pull request is related to.

Predefined how ?

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] What would break if loopback addresses were allowed for IPA server?

[Simo Sorce]

On Mon, 2016-10-17 at 09:02 +0200, Petr Spacek wrote:
> On 27.9.2016 14:31, Jan Pazdziora wrote:
> > On Wed, Sep 21, 2016 at 12:01:44PM +0200, Jan Pazdziora wrote:
> >>
> >> I've recently hit again the situation of IPA installer not happy
> >> about the provided IP address not being local to it, this time in
> >> containerized environment:
> >>
> >>https://bugzilla.redhat.com/show_bug.cgi?id=1377973
> >>
> >> During the discussion, we came to an interesting question:
> >>
> >>What would break if loopback addresses were allowed for IPA
> >>server?
> >>
> >> Of course, the idea is that it would only be used for installation and
> >> then IPA would change its IP address in DNS to whatever is the real IP
> >> address under which it is accessible.
> >>
> >> Where does the allow_loopback=False requirement in the installer come
> >> from and what would break if it was removed altogether?
> > 
> > I also see messages like
> > 
> > Adding [10.11.12.13 ipa.example.com] to your /etc/hosts file
> > 
> > in some cases. Actually, it's
> > 
> > 10.11.12.13 ipa.example.com ipa
> > 
> > which gets added so the message is not accurate.
> > 
> > Modification of /etc/hosts itself seems unfortunate. Should the IP
> > address change in the future, there will be one more place where
> > the IP address stays hardcoded.
> > 
> > I wonder why
> > 
> > hosts:  files dns myhostname
> > 
> > isn't enough, and whether
> > 
> > hosts:  files myhostname dns
> > 
> > might actually be better order.
> 
> Theoretically yes. Practically it will break Dogtag and other components which
> are not able to cope up with link-local addresses returned from myhostname 
> module.
> 
> 
> > When the value is not in /etc/hosts,
> > I see weird startup issues, presumably because individual components
> > time out resolving $HOSTNAME, so systemctl start ipa fails. Perhaps
> > it has something to do with named being up at that point, rather than
> > unreachable, just not resolving anything yet. Chicken and egg.
> > 
> > I wonder why we cannot add ipa.example.com to 127.0.0.1. I've tried
> > that and have seen
> > 
> > named-pkcs11[453]: LDAP error: Local error: SASL(-1): generic
> > failure: GSSAPI Error: Unspecified GSS failure.  Minor code
> > may provide more information (Server
> > ldap/localh...@example.test not found in Kerberos database):
> > bind to LDAP server failed
> > 
> > which suggests something derives the hostname and thus the principal
> > from the IP address used. Why is not $HOSTNAME used everywhere? What
> > part of the system cares about the IP address (and the reverse
> > resolution)?
> 
> AFAIK FQDN is used everywhere. The "localhost" name might be coming from
> Kerberos name canonicalization, which works like this:
> FQDN (name resolution) record-> IP address (IP address resolution)->new name.
> 
> You might try to add rdns=false to [libdefaults] section in /etc/krb5.conf. It
> should be default anyway, but why not try it explicitly.
> 
> Also, I would try if dns_canonicalize_hostname=false makes any difference or 
> not.

Btw this attribute came up also elsewhere, I think we should consider
changing ipa-client-install (or SSSD) to make
dns_canonicalize_hostname=false the default in IPa installs.

Should we open a ticket for that?

Simo.

> 
> > If overloading 127.0.0.1 with the $HOSTNAME does not work, could
> > 127.0.0.2 do the trick? It seems to work for subsequent starts (did
> > not try it during ipa-server-install) in containers.
> 
> It will likely suffer with very similar problems. It if works, it works just
> accidentally and might break at any time in future.
> 
> Before we touch IP address/domain name logic, we need to agree how it should
> behave.
> 
> What is the purpose of --ip-address option?
> a) Specify IP addresses used in DNS.
> ab) What checks should be performed on it?
> b) To bind deamons only to specific IP addresses instead of all interfaces?
> 
> I have seen requests for both. We need to decide what is the intended behavior
> and design it before making further changes. The spaghetti code is too
> intertwined for making any non-systematic changes.
> 
> -- 
> Petr^2 Spacek
> 


-- 
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] [RFC] Matching and Mapping Certificates

[Simo Sorce]

On Thu, 2016-10-13 at 18:52 +0200, Sumit Bose wrote:
>  Compatibility with Active Directory 
> Active Directory uses a per-user LDAP attribute
> [https://msdn.microsoft.com/en-us/library/cc220106.aspx 
> altSecurityIdentities] to allow arbitrary user-certificate mappings is there 
> is no suitable user-principal-name entry in the SAN of the certificate.
> 
> Unfortunately it is more or less undocumented how AD use the values of
> this attribute. The best overview I found is in
> https://blogs.msdn.microsoft.com/spatdsg/2010/06/18/howto-map-a-user-to-a-certificate-via-all-the-methods-available-in-the-altsecurityidentities-attribute/.

A few more pointers Sumit:
- This describes what is allowed for users:
https://msdn.microsoft.com/en-us/library/ms677943%28v=vs.85%29.aspx

- This describes a use for devices:
https://msdn.microsoft.com/en-us/library/dn408946.aspx

- additional description specific for PKINIT:
https://msdn.microsoft.com/en-us/library/hh536384.aspx

- This is a good detailed overview of the Smart Card logon workflow in
windows, it describes Vista but I do not think it changed in fundamental
ways in following releases:
https://msdn.microsoft.com/en-us/library/bb905527.aspx

NOTE: Please look at the small paragraph named "Smart card logon across
forests", we definitely want to think about this problem as well from
the get-go and not try to retrofit something later on.


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

[Freeipa-devel] [freeipa PR#157][comment] git: Add commit template

[mbasti-rh]

  URL: https://github.com/freeipa/freeipa/pull/157
Title: #157: git: Add commit template

mbasti-rh commented:
"""
I disagree here with Honza,  I liked those comments more at bottom. Why do we 
even need that comments? git commit command with vim set as editor is doing 
that automatically.
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/157#issuecomment-254242928
-- 
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] [freeipa PR#167][closed] Move ipa.1 man file

[mbasti-rh]

   URL: https://github.com/freeipa/freeipa/pull/167
Author: tiran
 Title: #167: Move ipa.1 man file
Action: closed

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/167/head:pr167
git checkout pr167
-- 
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] [freeipa PR#155][comment] Build system cleanup

[mbasti-rh]

  URL: https://github.com/freeipa/freeipa/pull/155
Title: #155: Build system cleanup

mbasti-rh commented:
"""
Needs rebase
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/155#issuecomment-254240565
-- 
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] [freeipa PR#167][+pushed] Move ipa.1 man file

[mbasti-rh]

  URL: https://github.com/freeipa/freeipa/pull/167
Title: #167: Move ipa.1 man file

Label: +pushed
-- 
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] [freeipa PR#167][comment] Move ipa.1 man file

[mbasti-rh]

  URL: https://github.com/freeipa/freeipa/pull/167
Title: #167: Move ipa.1 man file

mbasti-rh commented:
"""
Fixed upstream
master:
https://fedorahosted.org/freeipa/changeset/b9d68b5c3503bb708f637be6bb173a742b4105b4
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/167#issuecomment-254239607
-- 
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] [freeipa PR#143][synchronized] Issue6386 nss dir

[tiran]

   URL: https://github.com/freeipa/freeipa/pull/143
Author: tiran
 Title: #143: Issue6386 nss dir
Action: synchronized

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/143/head:pr143
git checkout pr143
From aaf29bb7be2b2d4e8c958356780995a9ad3e1c58 Mon Sep 17 00:00:00 2001
From: Christian Heimes 
Date: Thu, 6 Oct 2016 16:24:43 +0200
Subject: [PATCH] Use api.env.nss_dir instead of paths.IPA_NSSDB_DIR

ipaclient plugins are now using nss_dir from api.env instead of
hard-coded paths.IPA_NSSDB_DIR.

Closes: https://fedorahosted.org/freeipa/ticket/6386
Signed-off-by: Christian Heimes 
---
 ipaclient/ipa_certupdate.py   | 2 +-
 ipaclient/plugins/otptoken.py | 3 +--
 ipaclient/plugins/vault.py| 7 ++-
 3 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/ipaclient/ipa_certupdate.py b/ipaclient/ipa_certupdate.py
index 2c6b94f..550bbb6 100644
--- a/ipaclient/ipa_certupdate.py
+++ b/ipaclient/ipa_certupdate.py
@@ -108,7 +108,7 @@ def run(self):
 def update_client(self, certs):
 self.update_file(paths.IPA_CA_CRT, certs)
 
-ipa_db = certdb.NSSDatabase(paths.IPA_NSSDB_DIR)
+ipa_db = certdb.NSSDatabase(api.env.nss_dir)
 
 # Remove old IPA certs from /etc/ipa/nssdb
 for nickname in ('IPA CA', 'External CA cert'):
diff --git a/ipaclient/plugins/otptoken.py b/ipaclient/plugins/otptoken.py
index dd4a718..885a612 100644
--- a/ipaclient/plugins/otptoken.py
+++ b/ipaclient/plugins/otptoken.py
@@ -25,7 +25,6 @@
 from ipalib.messages import add_message, ResultFormattingError
 from ipalib.plugable import Registry
 from ipalib.frontend import Local
-from ipaplatform.paths import paths
 from ipapython.dn import DN
 from ipapython.nsslib import NSSConnection
 from ipapython.version import API_VERSION
@@ -174,7 +173,7 @@ def forward(self, *args, **kwargs):
 
 # Sync the token.
 # pylint: disable=E1101
-handler = HTTPSHandler(dbdir=paths.IPA_NSSDB_DIR,
+handler = HTTPSHandler(dbdir=api.env.nss_dir,
tls_version_min=api.env.tls_version_min,
tls_version_max=api.env.tls_version_max)
 rsp = urllib.request.build_opener(handler).open(sync_uri, query)
diff --git a/ipaclient/plugins/vault.py b/ipaclient/plugins/vault.py
index b8b4f29..c099e9e 100644
--- a/ipaclient/plugins/vault.py
+++ b/ipaclient/plugins/vault.py
@@ -43,7 +43,6 @@
 from ipalib import Bytes, Flag, Str
 from ipalib.plugable import Registry
 from ipalib import _
-from ipaplatform.paths import paths
 
 
 def validated_read(argname, filename, mode='r', encoding=None):
@@ -752,8 +751,7 @@ def forward(self, *args, **options):
 error=_('Invalid vault type'))
 
 # initialize NSS database
-current_dbdir = paths.IPA_NSSDB_DIR
-nss.nss_init(current_dbdir)
+nss.nss_init(api.env.nss_dir)
 
 # retrieve transport certificate
 config = self.api.Command.vaultconfig_show()['result']
@@ -912,8 +910,7 @@ def forward(self, *args, **options):
 vault_type = vault['ipavaulttype'][0]
 
 # initialize NSS database
-current_dbdir = paths.IPA_NSSDB_DIR
-nss.nss_init(current_dbdir)
+nss.nss_init(api.env.nss_dir)
 
 # retrieve transport certificate
 config = self.api.Command.vaultconfig_show()['result']
-- 
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] [RFC] Matching and Mapping Certificates

[Rob Crittenden]

Jan Cholasta wrote:

Hi,

On 13.10.2016 18:52, Sumit Bose wrote:

= Issuer specific matching =
Although the MIT Kerberos rules allow to select the issuer of a
certificate there are use cases where a more specific selection is
needed. E.g. if there are some default matching rules for all issuers
and some other issuer specific rules where the default rules should
not apply. To make this possible with the above scheme the default
rules must have an  clause which matches all but the issuer
with the specific rules. Writing regular-expressions to not match a
specific string or a list of strings is at least error-prone if not
impossible.

To make it easier to define issuer specific rules and default rules at
the same time and optional issuer string can be added to the rule to
indicate that for the given issuer only those rules should be
considered. Given the use-case I think it is acceptable to require
that the full issuer must be specified here in LDAP order (see below)
and case-sensitive matching is used.


This could also be solved by adding priority to rules - if two rules
match, the one with higher priority (the issuer specific rule) is
preferred over the one with lower priority (the default rule). IMO this
is better than an optional issuer string as it offers greater flexibility.


The use cases I've seen haven't had to do with priority, though that 
would be a nice enhancement, but with only allowing certificates issued 
by a specific CA to be allowed (this is pretty common in web servers). 
Being able to say "only do the matching on certificates issued by foo" 
is valuable.


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

[Freeipa-devel] [freeipa PR#143][comment] Issue6386 nss dir

[jcholast]

  URL: https://github.com/freeipa/freeipa/pull/143
Title: #143: Issue6386 nss dir

jcholast commented:
"""
NACK, see inline comments.
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/143#issuecomment-254226440
-- 
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] [freeipa PR#167][+ack] Move ipa.1 man file

[pspacek]

  URL: https://github.com/freeipa/freeipa/pull/167
Title: #167: Move ipa.1 man file

Label: +ack
-- 
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] [freeipa PR#143][synchronized] Issue6386 nss dir

[tiran]

   URL: https://github.com/freeipa/freeipa/pull/143
Author: tiran
 Title: #143: Issue6386 nss dir
Action: synchronized

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/143/head:pr143
git checkout pr143
From aaf29bb7be2b2d4e8c958356780995a9ad3e1c58 Mon Sep 17 00:00:00 2001
From: Christian Heimes 
Date: Thu, 6 Oct 2016 16:24:43 +0200
Subject: [PATCH 1/2] Use api.env.nss_dir instead of paths.IPA_NSSDB_DIR

ipaclient plugins are now using nss_dir from api.env instead of
hard-coded paths.IPA_NSSDB_DIR.

Closes: https://fedorahosted.org/freeipa/ticket/6386
Signed-off-by: Christian Heimes 
---
 ipaclient/ipa_certupdate.py   | 2 +-
 ipaclient/plugins/otptoken.py | 3 +--
 ipaclient/plugins/vault.py| 7 ++-
 3 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/ipaclient/ipa_certupdate.py b/ipaclient/ipa_certupdate.py
index 2c6b94f..550bbb6 100644
--- a/ipaclient/ipa_certupdate.py
+++ b/ipaclient/ipa_certupdate.py
@@ -108,7 +108,7 @@ def run(self):
 def update_client(self, certs):
 self.update_file(paths.IPA_CA_CRT, certs)
 
-ipa_db = certdb.NSSDatabase(paths.IPA_NSSDB_DIR)
+ipa_db = certdb.NSSDatabase(api.env.nss_dir)
 
 # Remove old IPA certs from /etc/ipa/nssdb
 for nickname in ('IPA CA', 'External CA cert'):
diff --git a/ipaclient/plugins/otptoken.py b/ipaclient/plugins/otptoken.py
index dd4a718..885a612 100644
--- a/ipaclient/plugins/otptoken.py
+++ b/ipaclient/plugins/otptoken.py
@@ -25,7 +25,6 @@
 from ipalib.messages import add_message, ResultFormattingError
 from ipalib.plugable import Registry
 from ipalib.frontend import Local
-from ipaplatform.paths import paths
 from ipapython.dn import DN
 from ipapython.nsslib import NSSConnection
 from ipapython.version import API_VERSION
@@ -174,7 +173,7 @@ def forward(self, *args, **kwargs):
 
 # Sync the token.
 # pylint: disable=E1101
-handler = HTTPSHandler(dbdir=paths.IPA_NSSDB_DIR,
+handler = HTTPSHandler(dbdir=api.env.nss_dir,
tls_version_min=api.env.tls_version_min,
tls_version_max=api.env.tls_version_max)
 rsp = urllib.request.build_opener(handler).open(sync_uri, query)
diff --git a/ipaclient/plugins/vault.py b/ipaclient/plugins/vault.py
index b8b4f29..c099e9e 100644
--- a/ipaclient/plugins/vault.py
+++ b/ipaclient/plugins/vault.py
@@ -43,7 +43,6 @@
 from ipalib import Bytes, Flag, Str
 from ipalib.plugable import Registry
 from ipalib import _
-from ipaplatform.paths import paths
 
 
 def validated_read(argname, filename, mode='r', encoding=None):
@@ -752,8 +751,7 @@ def forward(self, *args, **options):
 error=_('Invalid vault type'))
 
 # initialize NSS database
-current_dbdir = paths.IPA_NSSDB_DIR
-nss.nss_init(current_dbdir)
+nss.nss_init(api.env.nss_dir)
 
 # retrieve transport certificate
 config = self.api.Command.vaultconfig_show()['result']
@@ -912,8 +910,7 @@ def forward(self, *args, **options):
 vault_type = vault['ipavaulttype'][0]
 
 # initialize NSS database
-current_dbdir = paths.IPA_NSSDB_DIR
-nss.nss_init(current_dbdir)
+nss.nss_init(api.env.nss_dir)
 
 # retrieve transport certificate
 config = self.api.Command.vaultconfig_show()['result']

From 92d50c25ab92e0940f1c2f096d4c45d1c7ab5c99 Mon Sep 17 00:00:00 2001
From: Christian Heimes 
Date: Thu, 6 Oct 2016 16:42:37 +0200
Subject: [PATCH 2/2] Set nss_dir to confdir/nssdb

Closes: https://fedorahosted.org/freeipa/ticket/6386
Signed-off-by: Christian Heimes 
---
 ipalib/config.py| 4 
 ipalib/constants.py | 2 +-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/ipalib/config.py b/ipalib/config.py
index a273e3d..b969afa 100644
--- a/ipalib/config.py
+++ b/ipalib/config.py
@@ -518,6 +518,10 @@ def _finalize_core(self, **defaults):
 self._merge_from_file(self.conf)
 self._merge_from_file(self.conf_default)
 
+# Set nss_dir to nssdb directory in confdir
+if 'nss_dir' not in self:
+self.nss_dir = self._join('confdir', 'nssdb')
+
 # Determine if in_server:
 if 'in_server' not in self:
 self.in_server = (self.context == 'server')
diff --git a/ipalib/constants.py b/ipalib/constants.py
index c423117..3ef5ddf 100644
--- a/ipalib/constants.py
+++ b/ipalib/constants.py
@@ -133,7 +133,7 @@
 
 ('rpc_protocol', 'jsonrpc'),
 
-('nss_dir', paths.IPA_NSSDB_DIR),
+('nss_dir', paths.IPA_NSSDB_DIR),  # Set to confdir/nssdb in _finalize_core()
 
 # Define an inclusive range of SSL/TLS version support
 ('tls_version_min', 'tls1.0'),
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: 

[Freeipa-devel] [freeipa PR#167][opened] Move ipa.1 man file

[tiran]

   URL: https://github.com/freeipa/freeipa/pull/167
Author: tiran
 Title: #167: Move ipa.1 man file
Action: opened

PR body:
"""
setuptools does not support data_files any more. The ipa(1) man page is
now handled like the remaining man pages.

Signed-off-by: Christian Heimes 
"""

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/167/head:pr167
git checkout pr167
From 75c1a308dc4e2c86527782718b621b36dab0412b Mon Sep 17 00:00:00 2001
From: Christian Heimes 
Date: Mon, 17 Oct 2016 15:56:41 +0200
Subject: [PATCH] Move ipa.1 man file

setuptools does not support data_files any more. The ipa(1) man page is
now handled like the remaining man pages.

Signed-off-by: Christian Heimes 
---
 client/man/Makefile.am |   3 +-
 client/man/ipa.1   | 204 +
 ipa.1  | 204 -
 ipaclient/setup.py.in  |   1 -
 setup.py   |  42 --
 5 files changed, 206 insertions(+), 248 deletions(-)
 create mode 100644 client/man/ipa.1
 delete mode 100644 ipa.1

diff --git a/client/man/Makefile.am b/client/man/Makefile.am
index 9d8a9c0..1f067ab 100644
--- a/client/man/Makefile.am
+++ b/client/man/Makefile.am
@@ -10,7 +10,8 @@ man1_MANS = \
 		ipa-client-install.1	\
 		ipa-client-automount.1	\
 		ipa-certupdate.1	\
-		ipa-join.1
+		ipa-join.1		\
+		ipa.1
 
 man5_MANS =\
 		default.conf.5
diff --git a/client/man/ipa.1 b/client/man/ipa.1
new file mode 100644
index 000..9194ca0
--- /dev/null
+++ b/client/man/ipa.1
@@ -0,0 +1,204 @@
+.\" A man page for ipa
+.\" Copyright (C) 2010-2016 Red Hat, Inc.
+.\"
+.\" This program is free software; you can redistribute it and/or modify
+.\" it under the terms of the GNU General Public License as published by
+.\" the Free Software Foundation, either version 3 of the License, or
+.\" (at your option) any later version.
+.\"
+.\" This program is distributed in the hope that it will be useful, but
+.\" WITHOUT ANY WARRANTY; without even the implied warranty of
+.\" MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+.\" General Public License for more details.
+.\"
+.\" You should have received a copy of the GNU General Public License
+.\" along with this program.  If not, see .
+.\"
+.\" Author: Pavel Zuna 
+.\"
+.TH "ipa" "1" "Apr 29 2016" "FreeIPA" "FreeIPA Manual Pages"
+.SH "NAME"
+ipa \- IPA command\-line interface
+.SH "SYNOPSIS"
+.nf
+\fBipa\fR [options] [\fB\-c\fR \fIFILE\fR] [\fB\-e\fR \fIKEY=VAL\fR] \fICOMMAND\fR [parameters]
+.fi
+.SH "DESCRIPTION"
+IPA is an integrated security information management solution based on 389 Directory Server (formerly know as Fedora Directory Server), MIT Kerberos, Dogtag Certificate System, NTP and DNS. It includes a web interface and command\-line administration tools for managing identity data.
+
+This manual page focuses on the \fIipa\fR script that serves as the main command\-line interface (CLI) for IPA administration.
+
+More information about the project is available on its homepage located at http://www.freeipa.org.
+.SH "OPTIONS"
+.TP
+\fB\-c\fR \fIFILE\fR
+Load configuration from \fIFILE\fR.
+.TP
+\fB\-d\fR, \fB\-\-debug\fR
+Produce full debugging output.
+.TP
+\fB\-\-delegate\fR
+Delegate the user's TGT to the IPA server
+.TP
+\fB\-e\fR \fIKEY=VAL\fR
+Set environmental variable \fIKEY\fR to the value \fIVAL\fR. This option overrides configuration files.
+.TP
+\fB\-h\fR, \fB\-\-help\fR
+Display a help message with a list of options.
+.TP
+\fB\-n\fR, \fB\-\-no\-prompt\fR
+Don't prompt for any parameters of \fBCOMMAND\fR, even if they are required.
+.TP
+\fB\-a\fR, \fB\-\-prompt\-all\fR
+Prompt for all parameters of \fICOMMAND\fR, even if they are optional.
+.TP
+\fB\-f\fR, \fB\-\-no\-fallback\fR
+Don't fall back to other IPA servers if the default doesn't work.
+.TP
+\fB\-v\fR, \fB\-\-verbose\fR
+Produce verbose output. A second -v pretty-prints the JSON request and response. A third \-v displays the HTTP request and response.
+.TP
+\fB\-\-version\fR
+Display the IPA version and API version.
+.SH "COMMANDS"
+The principal function of the CLI is to execute administrative commands specified by the \fICOMMAND\fR argument. The majority of commands are executed remotely over XML\-RPC on a IPA server listed in the configuration file (see FILES section of this manual page).
+
+From the implementation perspective, the CLI distinguishes two types of commands \- built\-ins and plugin provided.
+
+Built\-in commands are static and are all available in all installations of IPA. There are two of them:
+.TP
+\fBconsole\fR
+Start the IPA interactive Python console.
+.TP
+\fBhelp\fR [\fITOPIC\fR | \fICOMMAND\fR | \fBtopics\fR | \fBcommands\fR]
+Display help for a command or topic.
+
+The \fBhelp\fR command invokes the built\-in documentation 

[Freeipa-devel] [freeipa PR#117][comment] Make ipa-replica-install run in interactive mode

[simo5]

  URL: https://github.com/freeipa/freeipa/pull/117
Title: #117: Make ipa-replica-install run in interactive mode

simo5 commented:
"""
@stlaz, sure, what I meant is that the checking code should be made common and 
run in ipa-repliuca-install, certainly I was not suggesting to just duplicate 
all that code. Perhaps refactoring will just do that.
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/117#issuecomment-254207783
-- 
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] [freeipa PR#166][opened] WebUI: services without canonical name are shown correctly

[pvomacka]

   URL: https://github.com/freeipa/freeipa/pull/166
Author: pvomacka
 Title: #166: WebUI: services without canonical name are shown correctly
Action: opened

PR body:
"""
There is a change introduced in 4.4 that new services have canonical name. The 
old ones
didn't have it, therefore these services were not correctly displayed in WebUI.

This patch adds support for this type of services. Service name is taken from
'krbprincipalname' attribute in case that 'krbcanonicalname' attribute is not 
present
in server response.

https://fedorahosted.org/freeipa/ticket/6397
"""

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/166/head:pr166
git checkout pr166
From 581ab0ea485dad118fc6ffebf8708e198e7025be Mon Sep 17 00:00:00 2001
From: Pavel Vomacka 
Date: Mon, 17 Oct 2016 14:33:07 +0200
Subject: [PATCH] WebUI: services without canonical name are shown correctly

There is a change introduced in 4.4 that new services have canonical name. The old ones
didn't have it, therefore these services were not correctly displayed in WebUI.

This patch adds support for this type of services. Service name is taken from
'krbprincipalname' attribute in case that 'krbcanonicalname' attribute is not present
in server response.

https://fedorahosted.org/freeipa/ticket/6397
---
 install/ui/src/freeipa/service.js | 92 ++-
 1 file changed, 90 insertions(+), 2 deletions(-)

diff --git a/install/ui/src/freeipa/service.js b/install/ui/src/freeipa/service.js
index 30e336c..f8d3fbd 100644
--- a/install/ui/src/freeipa/service.js
+++ b/install/ui/src/freeipa/service.js
@@ -28,11 +28,12 @@ define([
 './reg',
 './rpc',
 './text',
+'./util',
 './details',
 './search',
 './association',
 './entity'],
-function(declare, field_mod, builder, IPA, $, phases, reg, rpc, text) {
+function(declare, field_mod, builder, IPA, $, phases, reg, rpc, text, util) {
 
 var exp =IPA.service = {};
 
@@ -58,7 +59,16 @@ return {
 facets: [
 {
 $type: 'search',
-columns: [ 'krbcanonicalname' ]
+$factory: IPA.service.search_facet,
+columns: [
+{
+name: 'krbcanonicalname',
+adapter: {
+$type: 'service_adapter',
+alt_attr: 'krbprincipalname'
+}
+}
+]
 },
 {
 $type: 'details',
@@ -403,6 +413,82 @@ return {
 }
 };};
 
+
+/**
+ * Custom search facet for services. It has alternative primary key, in case
+ * that the service doesn't have canonical name.
+ */
+IPA.service.search_facet = function(spec) {
+spec = spec || {};
+
+spec.alternative_pkey = spec.alternative_pkey || 'krbprincipalname';
+
+var that = IPA.search_facet(spec);
+
+that.alternative_pkey = spec.alternative_pkey;
+
+that.get_records_map = function(data) {
+
+var records_map = $.ordered_map();
+
+var result = data.result.result;
+var pkey_name = that.managed_entity.metadata.primary_key ||
+that.primary_key_name;
+var adapter = builder.build('adapter', 'adapter', {context: that});
+
+for (var i=0; i

[Freeipa-devel] [freeipa PR#165][comment] Tests: Verify that cert-find show CA without --all

[pvoborni]

  URL: https://github.com/freeipa/freeipa/pull/165
Title: #165: Tests: Verify that cert-find show CA without --all

pvoborni commented:
"""
Right, I only wanted to highlight the issue in #6022. It should be a separate 
patch. 
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/165#issuecomment-254165884
-- 
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] [freeipa PR#165][comment] Tests: Verify that cert-find show CA without --all

[mirielka]

  URL: https://github.com/freeipa/freeipa/pull/165
Title: #165: Tests: Verify that cert-find show CA without --all

mirielka commented:
"""
I added check for cert-show and cert-request (it was quite easy to add it to 
existing test). I'd prefer to add test for #6022 separately when bugfix is 
provided.
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/165#issuecomment-254157384
-- 
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] [freeipa PR#165][synchronized] Tests: Verify that cert-find show CA without --all

[mirielka]

   URL: https://github.com/freeipa/freeipa/pull/165
Author: mirielka
 Title: #165: Tests: Verify that cert-find show CA without --all
Action: synchronized

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/165/head:pr165
git checkout pr165
From d704b597c1f12a84418b9591abc7f9e4f1c4bb0e Mon Sep 17 00:00:00 2001
From: Lenka Doudova 
Date: Fri, 14 Oct 2016 11:56:21 +0200
Subject: [PATCH] Tests: Verify that cert commands show CA without --all

Verify that command cert-find, cert-show and cert-request show CA even without
--all.

https://fedorahosted.org/freeipa/ticket/6151
---
 ipatests/test_xmlrpc/test_cert_plugin.py | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/ipatests/test_xmlrpc/test_cert_plugin.py b/ipatests/test_xmlrpc/test_cert_plugin.py
index cb5175d..bac3e94 100644
--- a/ipatests/test_xmlrpc/test_cert_plugin.py
+++ b/ipatests/test_xmlrpc/test_cert_plugin.py
@@ -165,6 +165,7 @@ def test_0002_cert_add(self):
 csr = unicode(self.generateCSR(str(self.subject)))
 res = api.Command['cert_request'](csr, principal=self.service_princ, add=True)['result']
 assert DN(res['subject']) == self.subject
+assert 'cacn' in res
 # save the cert for the service_show/find tests
 cert = res['certificate'].encode('ascii')
 # save cert's SN for URI test
@@ -222,7 +223,22 @@ def test_0007_service_show(self):
 )
 assert set(certs_encoded) == set([cert, newcert])
 
-def test_0008_cleanup(self):
+def test_0008_cert_show(self):
+"""
+Verify that cert-show shows CA of the certificate without --all
+"""
+res = api.Command['cert_show'](sn)['result']
+assert 'cacn' in res
+
+def test_0009_cert_find(self):
+"""
+Verify that cert-find shows CA of the certificate without --all
+"""
+res = api.Command['cert_find'](min_serial_number=sn,
+   max_serial_number=sn)['result'][0]
+assert 'cacn' in res
+
+def test_00010_cleanup(self):
 """
 Clean up cert test data
 """
-- 
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] [freeipa PR#165][synchronized] Tests: Verify that cert-find show CA without --all

[mirielka]

   URL: https://github.com/freeipa/freeipa/pull/165
Author: mirielka
 Title: #165: Tests: Verify that cert-find show CA without --all
Action: synchronized

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/165/head:pr165
git checkout pr165
From 41dee6b75d0e76a7c889c52d38bec9dc4c748943 Mon Sep 17 00:00:00 2001
From: Lenka Doudova 
Date: Fri, 14 Oct 2016 11:56:21 +0200
Subject: [PATCH] Tests: Verify that cert commands show CA without --all

Verify that command cert-find, cert-show and cert-request show CA even without
--all.

https://fedorahosted.org/freeipa/ticket/6151
---
 ipatests/test_xmlrpc/test_cert_plugin.py | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/ipatests/test_xmlrpc/test_cert_plugin.py b/ipatests/test_xmlrpc/test_cert_plugin.py
index cb5175d..f1324cc 100644
--- a/ipatests/test_xmlrpc/test_cert_plugin.py
+++ b/ipatests/test_xmlrpc/test_cert_plugin.py
@@ -165,6 +165,7 @@ def test_0002_cert_add(self):
 csr = unicode(self.generateCSR(str(self.subject)))
 res = api.Command['cert_request'](csr, principal=self.service_princ, add=True)['result']
 assert DN(res['subject']) == self.subject
+assert 'cacn' in res
 # save the cert for the service_show/find tests
 cert = res['certificate'].encode('ascii')
 # save cert's SN for URI test
@@ -222,7 +223,21 @@ def test_0007_service_show(self):
 )
 assert set(certs_encoded) == set([cert, newcert])
 
-def test_0008_cleanup(self):
+def test_0008_cert_show(self):
+"""
+Verify that cert-show shows CA of the certificate without --all
+"""
+res = api.Command['cert_show'](sn)['result']
+assert 'cacn' in res
+
+def test_0009_cert_find(self):
+"""
+Verify that cert-find shows CA of the certificate without --all
+"""
+res = api.Command['cert_find'](min_serial_number=sn, max_serial_number=sn)['result'][0]
+assert 'cacn' in res
+
+def test_00010_cleanup(self):
 """
 Clean up cert test data
 """
-- 
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] [RFC] Matching and Mapping Certificates

[Jan Cholasta]

Hi,

On 13.10.2016 18:52, Sumit Bose wrote:

On Tue, Oct 11, 2016 at 01:37:09PM +0200, Sumit Bose wrote:

On Thu, Oct 06, 2016 at 12:49:30PM +0200, Sumit Bose wrote:

Hi,

I've started to write a SSSD design page about enhancing the current
mapping of certificates to users and how to select/match a suitable
certificate if multiple certificates are on a Smartcard.

My currently thoughts and idea and be found at
https://fedorahosted.org/sssd/wiki/DesignDocs/MatchingAndMappingCertificates
and for your convenience below as well.

Comments and suggestions are welcome. Please let me know about concerns,
alternatives and missing use-cases/user-stories.

bye,
Sumit



Hi,

Rob, Fraser, Alexander, thank you for your comments. I think both the
issuer specific matching and the OID in the SUBJECT matching are good
ideas. I updated the design page accordingly. The changes can be shown
with
https://fedorahosted.org/sssd/wiki/DesignDocs/MatchingAndMappingCertificates?action=diff=9_version=6

The updated version can be found below as well. Of course more comments and
suggestions are still very welcome.



I did another update. A "Compatibility with Active Director" section is
added which made me realize that there are use-cases for using the
issuer in the mapping as well and the sub-strings in LDAP search filters
might be useful as well.

The changes can be seen with
https://fedorahosted.org/sssd/wiki/DesignDocs/MatchingAndMappingCertificates?action=diff=10_version=9

Please let me know your comments and suggestions.

bye,
Sumit

= Matching and Mapping Certificates =

Related ticket(s):
 * http://www.freeipa.org/page/V4/User_Certificates#Certificate_Identity_Mapping

=== Problem statement ===
 Mapping 
Currently it is required that a certificate used for authentication is either 
stored in the LDAP user entry or in a matching override. This might not always 
be applicable and other ways are needed to relate a user with a certificate.

 Matching 
Even if SSSD will support multiple certificates on a Smartcard in the context 
of https://fedorahosted.org/sssd/ticket/3050 it might be necessary to restrict 
(or relax) the current certificate selection in certain environments.

=== Use cases ===
 Mapping 
In some environments it might not be possible or would cause unwanted effort to 
add certificates to the LDAP entry of the users to allow Smartcard based 
authentication. Reasons might be:
* Certificates/Smartcards are issued externally
* LDAP schema extension is not possible or not allowed

 Matching 
A user might have multiple certificate on a Smartcard which are suitable for 
authentication. But on some host in the environment only certificates from a 
specific CA (while all other CAs are trusted as well) or with some special 
extension should be valid for login.

=== Overview of the solution ===
To match a certificate a language/syntax has to be defined which allows to 
reference items from the certificate and compare the values with the expected 
data. To map the certificates to a user the language/syntax should allow to 
relate certificate items with LDAP attributes so that the value(s) from the 
certificate item can be used in a LDAP search filter.


Note that in some cases it might be possible to map a certificate to a 
user without having to do an extra LDAP search, for example when the 
certificate contains the principal name of the user. Does the design 
allow this? Or is there no extra LDAP search?





=== Implementation details ===
 Matching 
The pkinit plugin of MIT Kerberos must find a suitable certificate from a 
Smartcard as well and has defined the following syntax (see the 
pkinit_cert_match section of the krb5.conf man page or 
http://web.mit.edu/Kerberos/krb5-1.14/doc/admin/conf_files/krb5_conf.html for 
details). The main components are

* regular-expression
* regular-expression
* regular-expression
* extended-key-usage-list
* key-usage-list

and can be grouped together with a prefixed '&&' (and) or '`||`' (or) operator 
('&&' is the default). If multiple rules are given they are iterated with the order in 
the config file as long as a rule matches exactly one certificate.

'''Question: MIT Kerberos use case-sensitive matching and POSIX Extended 
Regular Expression syntax, shall we do the same?'''

While  and  are (imo) already quite flexible I can see some 
potential extensions for the other components.


I don't think regular expressions are a particularly good choice for DN 
matching. It is difficult to express assertions which are quite natural 
for DNs (matching multi-attribute RDNs, matching the same attribute type 
by different identifiers, respecting the defined matching rules of 
attribute types) and at the same time it is easy to express assertions 
which do not make much sense for DNs (matching substrings in attribute 
names, matching accross multiple syntactical elements, etc.).


That said, does the design have to be based on the MIT pkinit matching? 

Re: [Freeipa-devel] What would break if loopback addresses were allowed for IPA server?

[Petr Spacek]

On 27.9.2016 14:31, Jan Pazdziora wrote:
> On Wed, Sep 21, 2016 at 12:01:44PM +0200, Jan Pazdziora wrote:
>>
>> I've recently hit again the situation of IPA installer not happy
>> about the provided IP address not being local to it, this time in
>> containerized environment:
>>
>>  https://bugzilla.redhat.com/show_bug.cgi?id=1377973
>>
>> During the discussion, we came to an interesting question:
>>
>>  What would break if loopback addresses were allowed for IPA
>>  server?
>>
>> Of course, the idea is that it would only be used for installation and
>> then IPA would change its IP address in DNS to whatever is the real IP
>> address under which it is accessible.
>>
>> Where does the allow_loopback=False requirement in the installer come
>> from and what would break if it was removed altogether?
> 
> I also see messages like
> 
>   Adding [10.11.12.13 ipa.example.com] to your /etc/hosts file
> 
> in some cases. Actually, it's
> 
>   10.11.12.13 ipa.example.com ipa
> 
> which gets added so the message is not accurate.
> 
> Modification of /etc/hosts itself seems unfortunate. Should the IP
> address change in the future, there will be one more place where
> the IP address stays hardcoded.
> 
> I wonder why
> 
>   hosts:  files dns myhostname
> 
> isn't enough, and whether
> 
>   hosts:  files myhostname dns
> 
> might actually be better order.

Theoretically yes. Practically it will break Dogtag and other components which
are not able to cope up with link-local addresses returned from myhostname 
module.


> When the value is not in /etc/hosts,
> I see weird startup issues, presumably because individual components
> time out resolving $HOSTNAME, so systemctl start ipa fails. Perhaps
> it has something to do with named being up at that point, rather than
> unreachable, just not resolving anything yet. Chicken and egg.
> 
> I wonder why we cannot add ipa.example.com to 127.0.0.1. I've tried
> that and have seen
> 
>   named-pkcs11[453]: LDAP error: Local error: SASL(-1): generic
>   failure: GSSAPI Error: Unspecified GSS failure.  Minor code
>   may provide more information (Server
>   ldap/localh...@example.test not found in Kerberos database):
>   bind to LDAP server failed
> 
> which suggests something derives the hostname and thus the principal
> from the IP address used. Why is not $HOSTNAME used everywhere? What
> part of the system cares about the IP address (and the reverse
> resolution)?

AFAIK FQDN is used everywhere. The "localhost" name might be coming from
Kerberos name canonicalization, which works like this:
FQDN (name resolution) record-> IP address (IP address resolution)->new name.

You might try to add rdns=false to [libdefaults] section in /etc/krb5.conf. It
should be default anyway, but why not try it explicitly.

Also, I would try if dns_canonicalize_hostname=false makes any difference or 
not.


> If overloading 127.0.0.1 with the $HOSTNAME does not work, could
> 127.0.0.2 do the trick? It seems to work for subsequent starts (did
> not try it during ipa-server-install) in containers.

It will likely suffer with very similar problems. It if works, it works just
accidentally and might break at any time in future.

Before we touch IP address/domain name logic, we need to agree how it should
behave.

What is the purpose of --ip-address option?
a) Specify IP addresses used in DNS.
ab) What checks should be performed on it?
b) To bind deamons only to specific IP addresses instead of all interfaces?

I have seen requests for both. We need to decide what is the intended behavior
and design it before making further changes. The spaghetti code is too
intertwined for making any non-systematic changes.

-- 
Petr^2 Spacek

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

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

[Jan Cholasta]

On 13.10.2016 17:23, Ben Lipton wrote:

Thank you, this was a really helpful clarification of your point.
Comments below. Once again, I'm sorry I missed the email for so long.

Ben

On 09/05/2016 06:52 AM, Jan Cholasta wrote:

On 27.8.2016 22:40, Ben Lipton wrote:

On 08/25/2016 04:11 PM, Rob Crittenden wrote:

Ben Lipton wrote:

On 08/23/2016 03:54 AM, Jan Cholasta wrote:

On 8.8.2016 22:23, Ben Lipton wrote:

On 07/25/2016 07:45 AM, Jan Cholasta wrote:

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