[Freeipa-devel] [freeipa PR#354][opened] Fix DL1 replica installation in CA-less topology

[frasertweedale]

   URL: https://github.com/freeipa/freeipa/pull/354
Author: frasertweedale
 Title: #354: Fix DL1 replica installation in CA-less topology
Action: opened

PR body:
"""
Commit dbb98765d73519289ee22f3de1a5ccde140f6f5d changed certmonger
requests for DS and HTTP certificates during installation to raise
on error (https://fedorahosted.org/freeipa/ticket/6514).
This introduced a regression in DL1 replica installation in CA-less
topology.  A certificate was requested, but prior to the
aforementioned commit this would fail silently and installation
continued, whereas now installation fails.

Guard the certificate request with a check that the topology is
CA-ful.

Fixes: https://fedorahosted.org/freeipa/ticket/6573
"""

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/354/head:pr354
git checkout pr354
From db6038d2bf11f349d79dddc5e10865dd9b3d333a Mon Sep 17 00:00:00 2001
From: Fraser Tweedale 
Date: Tue, 20 Dec 2016 16:45:38 +1000
Subject: [PATCH] Fix DL1 replica installation in CA-less topology

Commit dbb98765d73519289ee22f3de1a5ccde140f6f5d changed certmonger
requests for DS and HTTP certificates during installation to raise
on error (https://fedorahosted.org/freeipa/ticket/6514).
This introduced a regression in DL1 replica installation in CA-less
topology.  A certificate was requested, but prior to the
aforementioned commit this would fail silently and installation
continued, whereas now installation fails.

Guard the certificate request with a check that the topology is
CA-ful.

Fixes: https://fedorahosted.org/freeipa/ticket/6573
---
 ipaserver/install/server/replicainstall.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ipaserver/install/server/replicainstall.py b/ipaserver/install/server/replicainstall.py
index b0cf28f..6e986f7 100644
--- a/ipaserver/install/server/replicainstall.py
+++ b/ipaserver/install/server/replicainstall.py
@@ -1338,7 +1338,7 @@ def install(installer):
 # Always try to install DNS records
 install_dns_records(config, options, remote_api)
 
-if promote:
+if promote and ca_enabled:
 # we need to install http certs to setup ssl for httpd
 install_http_certs(config.host_name,
config.realm_name,
-- 
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#348][comment] ca: fix ca-find with --pkey-only

[frasertweedale]

  URL: https://github.com/freeipa/freeipa/pull/348
Title: #348: ca: fix ca-find with --pkey-only

frasertweedale commented:
"""
IMO the current change is fine, but I would also implement a defensive guard 
within `set_certificate_attrs` in case this somehow happens in some other 
command.

```python
def set_certificate_attrs(entry, options, want_cert=True):
if 'ipacaid' not in entry:
return
ca_id = entry['ipacaid'][0]
...
```
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/348#issuecomment-268125375
-- 
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] CSR autogeneration next steps

[Ben Lipton]

On 12/15/2016 11:11 PM, Ben Lipton wrote:


On 12/12/2016 03:52 AM, Jan Cholasta wrote:

On 5.12.2016 16:48, Ben Lipton wrote:

Hi Jan, thanks for the comments.


On 12/05/2016 04:25 AM, Jan Cholasta wrote:

Hi Ben,

On 3.11.2016 00:12, Ben Lipton wrote:

Hi everybody,

Soon I'm going to have to reduce the amount of time I spend on new
development work for the CSR autogeneration project, and I want to 
leave

the project in as organized a state as possible. So, I'm taking
inventory of the work I've done in order to make sure that what's 
ready
for review can get reviewed and the ideas that have been discussed 
get

prototyped or at least recorded so they won't be forgotten.


Thanks, I have some questions and comments, see below.



Code that's ready for review (I will continue to put in as much 
time as

needed to help get these ready for submission):

- Current PR: https://github.com/freeipa/freeipa/pull/10


How hard would it be to update the PR to use the "new" interface from
the design thread? By this I mean that currently there is a command
(cert_get_requestdata), which creates a CSR from profile id +
principal + helper, but in the design we discussed a command which
creates a CertificationRequestInfo from profile id + principal +
public key.

Internally it could use the OpenSSL helper, no need to implement the
full "new" design. With your build_requestinfo.c code below it looks
like it should be pretty straightforward.


This is probably doable with the cffi, but I'm concerned about
usability. A user can run the current command to get a (reusable)
script, and run the script to get a CSR. It works with keys in both PEM
files and NSS databases already. If we change to outputting a
CertificationRequestInfo, in order to make this usable on the command
line, we'll need:
- An additional tool to sign a CSR given a CertificationRequestInfo 
(for

both types of key storage).
- A way to extract a SubjectPublicKeyInfo structure from a key within
the ipa command (like [1] but we need it for both types of key storage)
Since as far as I know there's no standard encoding for files 
containing

only a CertificationRequestInfo or a SubjectPublicKeyInfo, we'll be
writing and distributing these ourselves. I think that's where most of
the extra work will come in.


For PEM files, this is easily doable using python-cryptography (to 
extract SubjectPublicKeyInfo and sign CertificationRequestInfo) and 
PyASN1 (to create a CSR from the CertificationRequestInfo and the 
signature).


I didn't realize that python-cryptography knew about 
SubjectPublicKeyInfo structures, but indeed this seems to be pretty 
straightforward:


key = load_pem_private_key(key_bytes, None, default_backend())
pubkey_info = key.public_key().public_bytes(Encoding.DER, 
PublicFormat.SubjectPublicKeyInfo)


Thanks for letting me know this functionality already existed.


For NSS databases, this will be trickier and will require calling C 
functions, as neither certutil nor python-nss provide a way to a) 
address existing keys in the database by key ID b) get 
SubjectPublicKeyInfo for a given key.


As for encoding, the obvious choice is DER. It does not really matter 
there is no standard file format, as we won't be transferring these 
as files anyway.


Agreed. I just meant there aren't tools already because this isn't a 
type of file one often needs to process.




Would it be ok to stick with the current design in this PR? I'd feel
much better if we could get the basic functionality into the repo and
then iterate on it rather than changing the plan at this point. I can
create a separate PR to change cert_get_requestdata to this new
interface and at the same time add the necessary adapters (bullet 
points

above) to make it user-friendly.


Works for me.


Updated the PR to fix conflicts with master. Had some trouble with CI 
but creating a new PR with the same commits fixed it 
(https://github.com/freeipa/freeipa/pull/337). Not sure if it's fixed 
permanently, so I guess I'll just keep the two PRs synchronized now, 
or we could close the old one.




I would probably just implement the adapters within the
cert_build/cert_request client code unless you think having standalone
tools is valuable. I suppose certmonger is going to need these features
too, but I don't know how well sharing code between them is going to 
work.


cert-request is exactly the place where it should be :-) I wouldn't 
bother with certmonger until we have a server-side csrgen.






- Allow some fields to be specified by the user at creation time:
https://github.com/LiptonB/freeipa/commits/local-user-data


Good idea :-)



- Automation for the full process from getting CSR data to requesting
cert: https://github.com/LiptonB/freeipa/commits/local-cert-build


LGTM, although I would prefer if this was a client-side extension of
cert-request rather than a completely new command.


I did try that at first, but I struggled to figure out the interface 
for

the modified 

Re: [Freeipa-devel] bind-dyndb-ldap: [PATCH] Handle termination of SyncRepl watcher thread

[Tomas Krizek]

On 12/19/2016 02:04 PM, thierry bordaz wrote:
> Hi Tomas,
>
> The patch looks good to me.
> Just a minor remark.
> ldap_inst->exiting=TRUE and signaling the watcher thread is the same
> action. Ideally the signal handler would set 'existing=TRUE', but
> there is no nice way for the signal handler to retrieve/set the
> 'existing' flag. Do you think we could move 'ldap_inst->exiting=TRUE'
> and pthread_kill in a same wrapper function (for example
> watcher_shutdown).
>
> thanks
> thierry
>
> On 12/19/2016 01:04 PM, Tomas Krizek wrote:
>> Hi Thierry,
>>
>> could you please take a look at this bind-dyndb-ldap patch? I was trying
>> to fix https://fedorahosted.org/bind-dyndb-ldap/ticket/149
>>
>> I wasn't able to reproduce the issue, but I think the problem is fixed
>> now. Petr Spacek was helping me with this, but I think it would be good
>> if you could take a look as well.
>>
>> We were able to identify two causes: a) isc_thread_create fails and
>> ldap_inst->watcher is undefined (fixed by setting it to 0) and b) the
>> thread terminates for some reason (i.e. some checks fail) and then a
>> signal can't be sent to it. This was addressed by removing the REQUIRE
>> and logging an error instead.
>>
>> Thanks.
>>
>
Moved the ldap_inst-> exiting and pthread_kill to a wrapper function.

Please continue the review at
https://github.com/freeipa/bind-dyndb-ldap/pull/6

-- 
Tomas Krizek

-- 
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] [bind-dyndb-ldap PR#6][synchronized] handle termination of syncrepl watcher thread

[tomaskrizek]

   URL: https://github.com/freeipa/bind-dyndb-ldap/pull/6
Author: tomaskrizek
 Title: #6: handle termination of syncrepl watcher thread
Action: synchronized

To pull the PR as Git branch:
git remote add ghbind-dyndb-ldap https://github.com/freeipa/bind-dyndb-ldap
git fetch ghbind-dyndb-ldap pull/6/head:pr6
git checkout pr6
From 60db7a008c9655b9e7f8c8a8e9f52a55249fa0ed Mon Sep 17 00:00:00 2001
From: Tomas Krizek 
Date: Mon, 19 Dec 2016 12:39:07 +0100
Subject: [PATCH] handle termination of syncrepl watcher thread

In some cases, the thread could have been already terminated and
sending a signal to the thread using pthread_kill() would result in an
error. Now if the thread has already been terminated for some reason,
only an error message is logged.

https://fedorahosted.org/bind-dyndb-ldap/ticket/149
---
 src/ldap_helper.c | 31 +--
 src/ldap_helper.h |  1 +
 2 files changed, 22 insertions(+), 10 deletions(-)

diff --git a/src/ldap_helper.c b/src/ldap_helper.c
index a11751d..570e202 100644
--- a/src/ldap_helper.c
+++ b/src/ldap_helper.c
@@ -668,6 +668,7 @@ new_ldap_instance(isc_mem_t *mctx, const char *db_name, const char *parameters,
 	result = isc_thread_create(ldap_syncrepl_watcher, ldap_inst,
    _inst->watcher);
 	if (result != ISC_R_SUCCESS) {
+		ldap_inst->watcher = 0;
 		log_error("Failed to create syncrepl watcher thread");
 		goto cleanup;
 	}
@@ -696,16 +697,7 @@ destroy_ldap_instance(ldap_instance_t **ldap_instp)
 		return;
 
 	if (ldap_inst->watcher != 0) {
-		ldap_inst->exiting = ISC_TRUE;
-		/*
-		 * Wake up the watcher thread. This might look like a hack
-		 * but isc_thread_t is actually pthread_t and libisc don't
-		 * have any isc_thread_kill() func.
-		 *
-		 * We use SIGUSR1 to not to interfere with any signal
-		 * used by BIND itself.
-		 */
-		REQUIRE(pthread_kill(ldap_inst->watcher, SIGUSR1) == 0);
+		watcher_shutdown(ldap_inst);
 		RUNTIME_CHECK(isc_thread_join(ldap_inst->watcher, NULL)
 			  == ISC_R_SUCCESS);
 		ldap_inst->watcher = 0;
@@ -747,6 +739,25 @@ destroy_ldap_instance(ldap_instance_t **ldap_instp)
 	*ldap_instp = NULL;
 }
 
+void watcher_shutdown(ldap_instance_t *ldap_inst)
+{
+	REQUIRE(ldap_inst != NULL);
+
+	ldap_inst->exiting = ISC_TRUE;
+	/*
+	 * Wake up the watcher thread. This might look like a hack
+	 * but isc_thread_t is actually pthread_t and libisc don't
+	 * have any isc_thread_kill() func.
+	 *
+	 * We use SIGUSR1 to not to interfere with any signal
+	 * used by BIND itself.
+	 */
+	if (pthread_kill(ldap_inst->watcher, SIGUSR1) != 0) {
+		log_error("unable to send signal to SyncRepl watcher thread "
+  "(already terminated?)");
+	}
+}
+
 static isc_result_t ATTR_NONNULLS ATTR_CHECKRESULT
 new_ldap_connection(ldap_pool_t *pool, ldap_connection_t **ldap_connp)
 {
diff --git a/src/ldap_helper.h b/src/ldap_helper.h
index 6cfece5..3599b8e 100644
--- a/src/ldap_helper.h
+++ b/src/ldap_helper.h
@@ -45,6 +45,7 @@ new_ldap_instance(isc_mem_t *mctx, const char *db_name, const char *parameters,
 		  const char *file, unsigned long line,
 		  const dns_dyndbctx_t *dctx, ldap_instance_t **ldap_instp) ATTR_NONNULLS;
 void destroy_ldap_instance(ldap_instance_t **ldap_inst) ATTR_NONNULLS;
+void watcher_shutdown(ldap_instance_t *ldap_inst) ATTR_NONNULLS;
 
 isc_result_t
 ldap_delete_zone2(ldap_instance_t *inst, dns_name_t *name, isc_boolean_t lock)
-- 
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#351][comment] [fedora-26] named.conf template: update API for bind 9.11

[tomaskrizek]

  URL: https://github.com/freeipa/freeipa/pull/351
Title: #351: [fedora-26] named.conf template: update API for bind 9.11

tomaskrizek commented:
"""
The version of BIND in `freeipa.spec.in` is also subject to change. There is 
currently a bug that affects `named-pkcs11`, but not `named`.

I also have a [COPR 
repo](https://copr.fedorainfracloud.org/coprs/tkrizek/bind-9.11/) with bind 
9.11 for F25. I'm going to add bind-dyndb-ldap v11.0 there as well.

I'll also try to build for Fedora 24.
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/351#issuecomment-268003008
-- 
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#351][synchronized] [fedora-26] named.conf template: update API for bind 9.11

[tomaskrizek]

   URL: https://github.com/freeipa/freeipa/pull/351
Author: tomaskrizek
 Title: #351: [fedora-26] named.conf template: update API for bind 9.11
Action: synchronized

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/351/head:pr351
git checkout pr351
From bf1a7f648ca008668dfbc2ee48f89f70c5ab2d92 Mon Sep 17 00:00:00 2001
From: Tomas Krizek 
Date: Mon, 19 Dec 2016 13:12:19 +0100
Subject: [PATCH 1/2] named.conf template: update API for bind 9.11

Use the new API for bind 9.11. Removed deprecated "serial_autoincrement"
and updated the rest of configuration to conform to the new format.

https://fedorahosted.org/freeipa/ticket/6565
---
 install/share/bind.named.conf.template | 16 +++-
 1 file changed, 7 insertions(+), 9 deletions(-)

diff --git a/install/share/bind.named.conf.template b/install/share/bind.named.conf.template
index e8ea8fb..21b4098 100644
--- a/install/share/bind.named.conf.template
+++ b/install/share/bind.named.conf.template
@@ -43,13 +43,11 @@ zone "." IN {
 include "$RFC1912_ZONES";
 include "$ROOT_KEY";
 
-dynamic-db "ipa" {
-	library "ldap.so";
-	arg "uri ldapi://%2fvar%2frun%2fslapd-$SERVER_ID.socket";
-	arg "base cn=dns, $SUFFIX";
-	arg "server_id $FQDN";
-	arg "auth_method sasl";
-	arg "sasl_mech GSSAPI";
-	arg "sasl_user DNS/$FQDN";
-	arg "serial_autoincrement yes";
+dyndb "ipa-ldap" "/usr/lib64/bind/ldap.so" {
+	uri "ldapi://%2fvar%2frun%2fslapd-$SERVER_ID.socket";
+	base "cn=dns, $SUFFIX";
+	server_id "$FQDN";
+	auth_method "sasl";
+	sasl_mech "GSSAPI";
+	sasl_user "DNS/$FQDN";
 };

From c05e5d16e5b4da5c1a20757a378aa5e4e767ab62 Mon Sep 17 00:00:00 2001
From: Tomas Krizek 
Date: Mon, 19 Dec 2016 16:52:08 +0100
Subject: [PATCH 2/2] bump required version of BIND, bind-dyndb-ldap

bynd-dyndb-ldap used a custom configuration file format. Since BIND 9.11,
an API was accepted upstream. This caused backward incompatible changes
to the named.conf configuration file used to configure the
bind-dyndb-ldap BIND plugin. Version 11.0 of bind-dyndb-ldap plugin and
BIND 9.11 are required to use with the new config file format.

https://fedorahosted.org/freeipa/ticket/6565
---
 freeipa.spec.in | 17 +
 1 file changed, 5 insertions(+), 12 deletions(-)

diff --git a/freeipa.spec.in b/freeipa.spec.in
index cba40c2..99b3a0f 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -295,18 +295,11 @@ Summary: IPA integrated DNS server with support for automatic DNSSEC signing
 Group: System Environment/Base
 BuildArch: noarch
 Requires: %{name}-server = %{version}-%{release}
-Requires: bind-dyndb-ldap >= 10.0
-%if 0%{?fedora} >= 21
-Requires: bind >= 9.9.6-3
-Requires: bind-utils >= 9.9.6-3
-Requires: bind-pkcs11 >= 9.9.6-3
-Requires: bind-pkcs11-utils >= 9.9.6-3
-%else
-Requires: bind >= 9.9.4-21
-Requires: bind-utils >= 9.9.4-21
-Requires: bind-pkcs11 >= 9.9.4-21
-Requires: bind-pkcs11-utils >= 9.9.4-21
-%endif
+Requires: bind-dyndb-ldap >= 11.0
+Requires: bind >= 9.11.0-2
+Requires: bind-utils >= 9.11.0-2
+Requires: bind-pkcs11 >= 9.11.0-2
+Requires: bind-pkcs11-utils >= 9.11.0-2
 Requires: opendnssec >= 1.4.6-4
 
 Provides: %{alt_name}-server-dns = %{version}
-- 
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#279][+ack] installer: Stop adding distro-specific NTP servers into ntp.conf

[stlaz]

  URL: https://github.com/freeipa/freeipa/pull/279
Title: #279: installer: Stop adding distro-specific NTP servers into ntp.conf

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#314][comment] RFC: privilege separation for ipa framework code

[simo5]

  URL: https://github.com/freeipa/freeipa/pull/314
Title: #314: RFC: privilege separation for ipa framework code

simo5 commented:
"""
I think this code is ready to be included.
I am still playing with a minor change in mod_auth_gssapi, but that can also go 
in later.
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/314#issuecomment-267997245
-- 
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] FreeIPA on FIPS + NSS question

[Standa Laznicka]

On 12/19/2016 03:07 PM, John Dennis wrote:

On 12/19/2016 03:12 AM, Standa Laznicka wrote:

On 12/16/2016 03:23 PM, Rob Crittenden wrote:

Standa Laznicka wrote:

Hello,

I started a design page for FreeIPA on FIPS-enabled systems:
https://www.freeipa.org/page/V4/FreeIPA-on-FIPS

Me and Tomáš are still investigating what of all things will need to
change in order to have FreeIPA on FIPS-enabled RHEL. So far I managed
to install and run patched FreeIPA server and client and connect them
together.

There are some issues with NSS when trying to create an HTTPS request
(apparently, NSS requires an NSS database password to set up an SSL
connection). I am actually thinking of removing NSSConnection from the
client altogether.

Can you expand on this a bit? NSS should only need a pin when it needs
access to a private key. What connection(s) are you talking about, and
what would you replace NSSConnection with?

rob


Hello Rob,

Thank you for this excellent question, in order to cut the email short I
seem to have omitted quite a few information.

One of the very first problems I had with FreeIPA with FIPS was that NSS
was always asking for password/pin. I was discussing this with the NSS
guys on their IRC chat last week and it turns out that NSS tries to
create a private key every time you want to use it as a backend for an
SSL connection on FIPS. I still don't think this is quite right so I may
open a bugzilla for that.


I don't understand, I thought the case you were having problems with 
was the FreeIPA client, not the server. I assume when you use the term 
"backend" you mean server, and yes when NSS is in server mode it will 
access to keys. So isn't the problem NSS is not being initialized 
correctly so that it recognizes it is in client mode and not server mode?


What I meant was "a client backend for an SSL connection" - we're using 
NSS implementation of SSL (via python-nss) for HTTPS connections from 
client to server during which we're getting a CA cert from an NSS 
database but this eventually leads to a password prompt.


Anyway, the guys suggested me that we could try to create the database
with an empty password and everything will work. I don't quite like
that, too, but it's at least something if you don't want the `ipa`
command to always bug you for password you have no way knowing if you're
just a regular user.

What I think would be a better way to go is to use
httplib.HTTPSConnection. We have the needed certificates in
/etc/ipa/ca.crt anyway so why not use them instead. We had a discussion
with Honza this morning and it seems that with this approach we may get
rid of the NSSConnection class altogether (although I still need to
check a few spots) and start the process of moving away from NSS which
was discussed some year ago in an internal mailing list (for some 
reason).


Will be happy to hear thoughts on this,
Standa


I'm not a big fan of NSS, it has it's issues. As the author of the 
Python binding I'm quite aware of all the nasty behaviors NSS has and 
needs to be worked around. I wouldn't be sad to see it go but OpenSSL 
has it's own issues too. If you remove NSS you're also removing the 
option to support smart cards, HSM's etc. Perhaps before removing 
functionality it would be good to assess what the requirements are.


I'm sorry I generalized too much, the original topic was moving away 
from python-nss (of which I am even more sorry as you're the author).


--
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#279][comment] installer: Stop adding distro-specific NTP servers into ntp.conf

[pspacek]

  URL: https://github.com/freeipa/freeipa/pull/279
Title: #279: installer: Stop adding distro-specific NTP servers into ntp.conf

pspacek commented:
"""
ACK
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/279#issuecomment-267986862
-- 
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#352][opened] Clarify meaning of --domain and --realm in installers

[pspacek]

   URL: https://github.com/freeipa/freeipa/pull/352
Author: pspacek
 Title: #352: Clarify meaning of --domain and --realm in installers
Action: opened

PR body:
"""
Man pages need bigger overhaul. Take this as hot-fix for FAQ.

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

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/352/head:pr352
git checkout pr352
From b3787598a84918614032dbdf4774eee6918500be Mon Sep 17 00:00:00 2001
From: Petr Spacek 
Date: Mon, 19 Dec 2016 15:09:59 +0100
Subject: [PATCH] Clarify meaning of --domain and --realm in installers

Man pages need bigger overhaul. Take this as hot-fix for FAQ.

https://fedorahosted.org/freeipa/ticket/6574
---
 client/man/ipa-client-install.1 | 31 ++---
 install/tools/man/ipa-dns-install.1 | 29 +--
 install/tools/man/ipa-replica-install.1 | 40 +++-
 install/tools/man/ipa-server-install.1  | 41 +
 ipalib/install/service.py   |  6 +++--
 5 files changed, 66 insertions(+), 81 deletions(-)

diff --git a/client/man/ipa-client-install.1 b/client/man/ipa-client-install.1
index 9ae0b8b..ae769bc 100644
--- a/client/man/ipa-client-install.1
+++ b/client/man/ipa-client-install.1
@@ -1,22 +1,7 @@
 .\" A man page for ipa-client-install
-.\" Copyright (C) 2008 Red Hat, Inc.
+.\" Copyright (C) 2008-2016  FreeIPA Contributors see COPYING for license
 .\"
-.\" 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: Rob Crittenden 
-.\"
-.TH "ipa-client-install" "1" "Jan 31 2013" "FreeIPA" "FreeIPA Manual Pages"
+.TH "ipa-client-install" "1" "Dec 19 2016" "FreeIPA" "FreeIPA Manual Pages"
 .SH "NAME"
 ipa\-client\-install \- Configure an IPA client
 .SH "SYNOPSIS"
@@ -84,13 +69,21 @@ Consequences of the re\-enrollment on the host entry:
 .SS "BASIC OPTIONS"
 .TP
 \fB\-\-domain\fR=\fIDOMAIN\fR
-Set the domain name to DOMAIN. When no \-\-server option is specified, the installer will try to discover all available servers via DNS SRV record autodiscovery (see DNS Autodiscovery section for details).
+The primary DNS domain of existing IPA deployment e.g. example.com. This DNS domain should contain the SRV records generated by IPA server installer. Usually the name is lower-cased name of IPA Kerberos realm name.
+
+When no \-\-server option is specified, this domain will be used by the installer to discover all available servers via DNS SRV record autodiscovery (see DNS Autodiscovery section for details).
+
+Default value used by the installer is domain part of the hostname. This option needs to be specified if the primary IPA DNS domain is different than the default value.
 .TP
 \fB\-\-server\fR=\fISERVER\fR
 Set the FQDN of the IPA server to connect to. May be specified multiple times to add multiple servers to ipa_server value in sssd.conf or krb5.conf. Only the first value is considered when used with \-\-no\-sssd. When this option is used, DNS autodiscovery for Kerberos is disabled and a fixed list of KDC and Admin servers is configured.
+
+Under normal circumstances, this option is not needed as the list of servers is retrieved from the primary IPA DNS domain.
 .TP
 \fB\-\-realm\fR=\fIREALM_NAME\fR
-Set the IPA realm name to REALM_NAME. Under normal circumstances, this option is not needed as the realm name is retrieved from the IPA server.
+The Kerberos realm of existing IPA deployment. Usually it is upper-cased name of the primary DNS domain used by the IPA installation.
+
+Under normal circumstances, this option is not needed as the realm name is retrieved from the IPA server.
 .TP
 \fB\-\-fixed\-primary\fR
 Configure SSSD to use a fixed server as the primary IPA server. The default is to use DNS SRV records to determine the primary server to use and fall back to the server the client is enrolled with. When used in conjunction with \-\-server then no _srv_ value is set in the ipa_server option in sssd.conf.
diff --git a/install/tools/man/ipa-dns-install.1 b/install/tools/man/ipa-dns-install.1
index ad937cc..1f1e9a4 100644
--- a/install/tools/man/ipa-dns-install.1
+++ b/install/tools/man/ipa-dns-install.1
@@ -1,20 +1,5 @@
-.\" A man page for ipa-dns-install
-.\" Copyright (C) 2010 Red Hat, Inc.
-.\"
-.\" This program is free 

Re: [Freeipa-devel] [DESIGN] FreeIPA on FIPS + NSS question

[John Dennis]

On 12/19/2016 03:12 AM, Standa Laznicka wrote:

On 12/16/2016 03:23 PM, Rob Crittenden wrote:

Standa Laznicka wrote:

Hello,

I started a design page for FreeIPA on FIPS-enabled systems:
https://www.freeipa.org/page/V4/FreeIPA-on-FIPS

Me and Tomáš are still investigating what of all things will need to
change in order to have FreeIPA on FIPS-enabled RHEL. So far I managed
to install and run patched FreeIPA server and client and connect them
together.

There are some issues with NSS when trying to create an HTTPS request
(apparently, NSS requires an NSS database password to set up an SSL
connection). I am actually thinking of removing NSSConnection from the
client altogether.

Can you expand on this a bit? NSS should only need a pin when it needs
access to a private key. What connection(s) are you talking about, and
what would you replace NSSConnection with?

rob


Hello Rob,

Thank you for this excellent question, in order to cut the email short I
seem to have omitted quite a few information.

One of the very first problems I had with FreeIPA with FIPS was that NSS
was always asking for password/pin. I was discussing this with the NSS
guys on their IRC chat last week and it turns out that NSS tries to
create a private key every time you want to use it as a backend for an
SSL connection on FIPS. I still don't think this is quite right so I may
open a bugzilla for that.


I don't understand, I thought the case you were having problems with was 
the FreeIPA client, not the server. I assume when you use the term 
"backend" you mean server, and yes when NSS is in server mode it will 
access to keys. So isn't the problem NSS is not being initialized 
correctly so that it recognizes it is in client mode and not server mode?




Anyway, the guys suggested me that we could try to create the database
with an empty password and everything will work. I don't quite like
that, too, but it's at least something if you don't want the `ipa`
command to always bug you for password you have no way knowing if you're
just a regular user.

What I think would be a better way to go is to use
httplib.HTTPSConnection. We have the needed certificates in
/etc/ipa/ca.crt anyway so why not use them instead. We had a discussion
with Honza this morning and it seems that with this approach we may get
rid of the NSSConnection class altogether (although I still need to
check a few spots) and start the process of moving away from NSS which
was discussed some year ago in an internal mailing list (for some reason).

Will be happy to hear thoughts on this,
Standa


I'm not a big fan of NSS, it has it's issues. As the author of the 
Python binding I'm quite aware of all the nasty behaviors NSS has and 
needs to be worked around. I wouldn't be sad to see it go but OpenSSL 
has it's own issues too. If you remove NSS you're also removing the 
option to support smart cards, HSM's etc. Perhaps before removing 
functionality it would be good to assess what the requirements are.



--
John

--
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] bind-dyndb-ldap: [PATCH] Handle termination of SyncRepl watcher thread

[thierry bordaz]

Hi Tomas,

The patch looks good to me.
Just a minor remark.
ldap_inst->exiting=TRUE and signaling the watcher thread is the same 
action. Ideally the signal handler would set 'existing=TRUE', but there 
is no nice way for the signal handler to retrieve/set the 'existing' 
flag. Do you think we could move 'ldap_inst->exiting=TRUE' and 
pthread_kill in a same wrapper function (for example watcher_shutdown).


thanks
thierry

On 12/19/2016 01:04 PM, Tomas Krizek wrote:

Hi Thierry,

could you please take a look at this bind-dyndb-ldap patch? I was trying
to fix https://fedorahosted.org/bind-dyndb-ldap/ticket/149

I wasn't able to reproduce the issue, but I think the problem is fixed
now. Petr Spacek was helping me with this, but I think it would be good
if you could take a look as well.

We were able to identify two causes: a) isc_thread_create fails and
ldap_inst->watcher is undefined (fixed by setting it to 0) and b) the
thread terminates for some reason (i.e. some checks fail) and then a
signal can't be sent to it. This was addressed by removing the REQUIRE
and logging an error instead.

Thanks.



--
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] bind-dyndb-ldap: [PATCH] Handle termination of SyncRepl watcher thread

[Petr Spacek]

On 19.12.2016 13:04, Tomas Krizek wrote:
> Hi Thierry,
> 
> could you please take a look at this bind-dyndb-ldap patch? I was trying
> to fix https://fedorahosted.org/bind-dyndb-ldap/ticket/149
> 
> I wasn't able to reproduce the issue, but I think the problem is fixed
> now. Petr Spacek was helping me with this, but I think it would be good
> if you could take a look as well.
> 
> We were able to identify two causes: a) isc_thread_create fails and
> ldap_inst->watcher is undefined (fixed by setting it to 0) and b) the
> thread terminates for some reason (i.e. some checks fail) and then a
> signal can't be sent to it. This was addressed by removing the REQUIRE
> and logging an error instead.

Please send this as PR on Github and abandon this thread ;-)

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

[Freeipa-devel] [freeipa PR#349][closed] spec file: do not define with_lint inside a comment

[martbab]

   URL: https://github.com/freeipa/freeipa/pull/349
Author: jcholast
 Title: #349: spec file: do not define with_lint inside a comment
Action: closed

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/349/head:pr349
git checkout pr349
-- 
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#349][+pushed] spec file: do not define with_lint inside a comment

[martbab]

  URL: https://github.com/freeipa/freeipa/pull/349
Title: #349: spec file: do not define with_lint inside a comment

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#351][opened] [fedora-26] named.conf template: update API for bind 9.11

[tomaskrizek]

   URL: https://github.com/freeipa/freeipa/pull/351
Author: tomaskrizek
 Title: #351: [fedora-26] named.conf template: update API for bind 9.11
Action: opened

PR body:
"""
Please **do not merge** this patch upstream, we need to have BIND 9.11 
available before we do, otherwise it will break DNS installation. This patch is 
intended for Fedora 26 downstream and I'm only posting it for review.

This patch only fixes DNS for new IPA installations. Another patch for fixing 
existing named configs is necessary. This will most likely be fixed in 
bind-dyndb-ldap upstream.

---

Use the new API for bind 9.11. Removed deprecated "serial_autoincrement"
and updated the rest of configuration to conform to the new format.

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

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/351/head:pr351
git checkout pr351
From bf1a7f648ca008668dfbc2ee48f89f70c5ab2d92 Mon Sep 17 00:00:00 2001
From: Tomas Krizek 
Date: Mon, 19 Dec 2016 13:12:19 +0100
Subject: [PATCH] named.conf template: update API for bind 9.11

Use the new API for bind 9.11. Removed deprecated "serial_autoincrement"
and updated the rest of configuration to conform to the new format.

https://fedorahosted.org/freeipa/ticket/6565
---
 install/share/bind.named.conf.template | 16 +++-
 1 file changed, 7 insertions(+), 9 deletions(-)

diff --git a/install/share/bind.named.conf.template b/install/share/bind.named.conf.template
index e8ea8fb..21b4098 100644
--- a/install/share/bind.named.conf.template
+++ b/install/share/bind.named.conf.template
@@ -43,13 +43,11 @@ zone "." IN {
 include "$RFC1912_ZONES";
 include "$ROOT_KEY";
 
-dynamic-db "ipa" {
-	library "ldap.so";
-	arg "uri ldapi://%2fvar%2frun%2fslapd-$SERVER_ID.socket";
-	arg "base cn=dns, $SUFFIX";
-	arg "server_id $FQDN";
-	arg "auth_method sasl";
-	arg "sasl_mech GSSAPI";
-	arg "sasl_user DNS/$FQDN";
-	arg "serial_autoincrement yes";
+dyndb "ipa-ldap" "/usr/lib64/bind/ldap.so" {
+	uri "ldapi://%2fvar%2frun%2fslapd-$SERVER_ID.socket";
+	base "cn=dns, $SUFFIX";
+	server_id "$FQDN";
+	auth_method "sasl";
+	sasl_mech "GSSAPI";
+	sasl_user "DNS/$FQDN";
 };
-- 
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#349][+ack] spec file: do not define with_lint inside a comment

[martbab]

  URL: https://github.com/freeipa/freeipa/pull/349
Title: #349: spec file: do not define with_lint inside a comment

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#350][opened] spec file: revert to the previous Release tag

[jcholast]

   URL: https://github.com/freeipa/freeipa/pull/350
Author: jcholast
 Title: #350: spec file: revert to the previous Release tag
Action: opened

PR body:
"""
Revert from the current Release tag value `upstream` to the previously used
`0%{?dist}`, because:

* `0` sorts before `1`, which is usually used as the initial release number
  in downstream packages,

* the information provided by `%{?dist}` is useful, as packages built on
  one OS are not always installable on another OS.

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

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/350/head:pr350
git checkout pr350
From 0c8451d3e9b86b7e397b49a7dd25b9b3e5a0a222 Mon Sep 17 00:00:00 2001
From: Jan Cholasta 
Date: Mon, 5 Dec 2016 12:18:54 +0100
Subject: [PATCH] spec file: revert to the previous Release tag

Revert from the current Release tag value `upstream` to the previously used
`0%{?dist}`, because:

* `0` sorts before `1`, which is usually used as the initial release number
  in downstream packages,

* the information provided by `%{?dist}` is useful, as packages built on
  one OS are not always installable on another OS.

https://fedorahosted.org/freeipa/ticket/6418
---
 freeipa.spec.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/freeipa.spec.in b/freeipa.spec.in
index fbb3945..c58c057 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -41,7 +41,7 @@
 
 Name:   freeipa
 Version:%{IPA_VERSION}
-Release:upstream
+Release:0%{?dist}
 Summary:The Identity, Policy and Audit system
 
 Group:  System Environment/Base
-- 
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#333][comment] Remove named-pkcs11 workarounds from DNSSEC tests.

[mbasti-rh]

  URL: https://github.com/freeipa/freeipa/pull/333
Title: #333: Remove named-pkcs11 workarounds from DNSSEC tests.

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

See the full comment at 
https://github.com/freeipa/freeipa/pull/333#issuecomment-267949826
-- 
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#333][+pushed] Remove named-pkcs11 workarounds from DNSSEC tests.

[mbasti-rh]

  URL: https://github.com/freeipa/freeipa/pull/333
Title: #333: Remove named-pkcs11 workarounds from DNSSEC tests.

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#333][closed] Remove named-pkcs11 workarounds from DNSSEC tests.

[mbasti-rh]

   URL: https://github.com/freeipa/freeipa/pull/333
Author: pspacek
 Title: #333: Remove named-pkcs11 workarounds from DNSSEC tests.
Action: closed

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/333/head:pr333
git checkout pr333
-- 
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#334][synchronized] Py3: Fix ToASCII method

[mbasti-rh]

   URL: https://github.com/freeipa/freeipa/pull/334
Author: mbasti-rh
 Title: #334: Py3: Fix ToASCII method
Action: synchronized

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/334/head:pr334
git checkout pr334
From 49065f3ea24eb229faf1ed5cd8df67a35bc59d80 Mon Sep 17 00:00:00 2001
From: Martin Basti 
Date: Wed, 14 Dec 2016 10:12:05 +0100
Subject: [PATCH] Py3: Fix ToASCII method

in Py2 to_text method returns Py2 non-unicode string, but in Py3 to_text method
returns Py3 default (unicode) string. So only in Py2 we have to decode
str to unicode.

https://fedorahosted.org/freeipa/ticket/5935
---
 freeipa.spec.in  | 20 ++--
 ipapython/dnsutil.py | 11 ---
 ipasetup.py.in   |  2 +-
 3 files changed, 19 insertions(+), 14 deletions(-)

diff --git a/freeipa.spec.in b/freeipa.spec.in
index fbb3945..099798c 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -126,8 +126,8 @@ BuildRequires:  python-memcached
 BuildRequires:  python-lxml
 # 5.0.0: QRCode.print_ascii
 BuildRequires:  python-qrcode-core >= 5.0.0
-# 1.13: python-dns URI record support
-BuildRequires:  python-dns >= 1.13
+# 1.15: python-dns changed return type in to_text() method in PY3
+BuildRequires:  python-dns >= 1.15
 BuildRequires:  jsl
 BuildRequires:  python-yubico
 # pki Python package
@@ -163,8 +163,8 @@ BuildRequires:  python3-memcached
 BuildRequires:  python3-lxml
 # 5.0.0: QRCode.print_ascii
 BuildRequires:  python3-qrcode-core >= 5.0.0
-# 1.13: python-dns URI record support
-BuildRequires:  python3-dns >= 1.13
+# 1.15: python-dns changed return type in to_text() method in PY3
+BuildRequires:  python3-dns >= 1.15
 BuildRequires:  python3-yubico
 # pki Python package
 # 10.2.1: crypto.NSSCryptoProvider(password_file)
@@ -294,7 +294,7 @@ Requires: python-gssapi >= 1.2.0
 Requires: python-sssdconfig
 Requires: python-pyasn1
 Requires: dbus-python
-Requires: python-dns >= 1.13
+Requires: python-dns >= 1.15
 Requires: python-kdcproxy >= 0.3
 Requires: rpm-libs
 
@@ -323,7 +323,7 @@ Requires: python3-gssapi >= 1.2.0
 Requires: python3-sssdconfig
 Requires: python3-pyasn1
 Requires: python3-dbus
-Requires: python3-dns >= 1.11.1
+Requires: python3-dns >= 1.15
 Requires: python3-kdcproxy >= 0.3
 Requires: rpm-libs
 
@@ -482,7 +482,7 @@ BuildArch: noarch
 Requires: %{name}-client-common = %{version}-%{release}
 Requires: %{name}-common = %{version}-%{release}
 Requires: python2-ipalib = %{version}-%{release}
-Requires: python-dns >= 1.13
+Requires: python-dns >= 1.15
 
 %description -n python2-ipaclient
 IPA is an integrated solution to provide centrally managed Identity (users,
@@ -504,7 +504,7 @@ BuildArch: noarch
 Requires: %{name}-client-common = %{version}-%{release}
 Requires: %{name}-common = %{version}-%{release}
 Requires: python3-ipalib = %{version}-%{release}
-Requires: python3-dns >= 1.11.1
+Requires: python3-dns >= 1.15
 
 %description -n python3-ipaclient
 IPA is an integrated solution to provide centrally managed Identity (users,
@@ -598,7 +598,7 @@ Requires: python-cffi
 Requires: python-ldap >= 2.4.15
 Requires: python-requests
 Requires: python-custodia
-Requires: python-dns >= 1.13
+Requires: python-dns >= 1.15
 Requires: python-enum34
 Requires: python-netifaces >= 0.10.4
 Requires: pyusb
@@ -648,7 +648,7 @@ Requires: python3-cffi
 Requires: python3-pyldap >= 2.4.15
 Requires: python3-custodia
 Requires: python3-requests
-Requires: python3-dns >= 1.11.1
+Requires: python3-dns >= 1.15
 Requires: python3-netifaces >= 0.10.4
 Requires: python3-pyusb
 
diff --git a/ipapython/dnsutil.py b/ipapython/dnsutil.py
index 16549c8..011b722 100644
--- a/ipapython/dnsutil.py
+++ b/ipapython/dnsutil.py
@@ -69,9 +69,14 @@ def __deepcopy__(self, memo):
 def __str__(self):
 return self.to_unicode()
 
-def ToASCII(self):
-#method named by RFC 3490 and python standard library
-return self.to_text().decode('ascii')  # must be unicode string
+# method ToASCII named by RFC 3490 and python standard library
+if six.PY2:
+def ToASCII(self):
+# must be unicode string in Py2
+return self.to_text().decode('ascii')
+else:
+def ToASCII(self):
+return self.to_text()
 
 def canonicalize(self):
 return DNSName(super(DNSName, self).canonicalize())
diff --git a/ipasetup.py.in b/ipasetup.py.in
index 6a33fb8..c221e0d 100644
--- a/ipasetup.py.in
+++ b/ipasetup.py.in
@@ -64,7 +64,7 @@ if SETUPTOOLS_VERSION < (8, 0, 0):
 
 PACKAGE_VERSION = {
 'cryptography': 'cryptography >= 1.3.1',
-'dnspython': 'dnspython >= 1.13',
+'dnspython': 'dnspython >= 1.15',
 'gssapi': 'gssapi >= 1.2.0',
 'ipaclient': 'ipaclient == {}'.format(VERSION),
 'ipalib': 'ipalib == {}'.format(VERSION),
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: 

[Freeipa-devel] bind-dyndb-ldap: [PATCH] Handle termination of SyncRepl watcher thread

[Tomas Krizek]

Hi Thierry,

could you please take a look at this bind-dyndb-ldap patch? I was trying
to fix https://fedorahosted.org/bind-dyndb-ldap/ticket/149

I wasn't able to reproduce the issue, but I think the problem is fixed
now. Petr Spacek was helping me with this, but I think it would be good
if you could take a look as well.

We were able to identify two causes: a) isc_thread_create fails and
ldap_inst->watcher is undefined (fixed by setting it to 0) and b) the
thread terminates for some reason (i.e. some checks fail) and then a
signal can't be sent to it. This was addressed by removing the REQUIRE
and logging an error instead.

Thanks.

-- 
Tomas Krizek

From b801fb06a77f2ec8867884bc769d5bb1db0e1c2e Mon Sep 17 00:00:00 2001
From: Tomas Krizek 
Date: Mon, 19 Dec 2016 12:39:07 +0100
Subject: [PATCH] handle termination of syncrepl watcher thread

In some cases, the thread could have been already terminated and
sending a signal to the thread using pthread_kill() would result in an
error. Now if the thread has already been terminated for some reason,
only an error message is logged.

https://fedorahosted.org/bind-dyndb-ldap/ticket/149
---
 src/ldap_helper.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/src/ldap_helper.c b/src/ldap_helper.c
index ad6e417..f4c1811 100644
--- a/src/ldap_helper.c
+++ b/src/ldap_helper.c
@@ -643,6 +643,7 @@ new_ldap_instance(isc_mem_t *mctx, const char *db_name,
 	result = isc_thread_create(ldap_syncrepl_watcher, ldap_inst,
    _inst->watcher);
 	if (result != ISC_R_SUCCESS) {
+		ldap_inst->watcher = 0;
 		log_error("Failed to create syncrepl watcher thread");
 		goto cleanup;
 	}
@@ -683,7 +684,10 @@ destroy_ldap_instance(ldap_instance_t **ldap_instp)
 		 * We use SIGUSR1 to not to interfere with any signal
 		 * used by BIND itself.
 		 */
-		REQUIRE(pthread_kill(ldap_inst->watcher, SIGUSR1) == 0);
+		if (pthread_kill(ldap_inst->watcher, SIGUSR1) != 0) {
+			log_error("unable to send signal to syncrepl watcher thread "
+	  "(already terminated?)");
+		}
 		RUNTIME_CHECK(isc_thread_join(ldap_inst->watcher, NULL)
 			  == ISC_R_SUCCESS);
 		ldap_inst->watcher = 0;
-- 
2.9.3

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

[Freeipa-devel] [freeipa PR#349][opened] spec file: do not define with_lint inside a comment

[jcholast]

   URL: https://github.com/freeipa/freeipa/pull/349
Author: jcholast
 Title: #349: spec file: do not define with_lint inside a comment
Action: opened

PR body:
"""
RPM expands macros even inside comments in spec files, so the with_lint
macro is unintentionally always defined.

Escape the percent sign in '%global' in the comment to prevent this.

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

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/349/head:pr349
git checkout pr349
From 8c3b11e059e32c826694a39d8b886ca1230ea6a8 Mon Sep 17 00:00:00 2001
From: Jan Cholasta 
Date: Mon, 5 Dec 2016 12:17:54 +0100
Subject: [PATCH] spec file: do not define with_lint inside a comment

RPM expands macros even inside comments in spec files, so the with_lint
macro is unintentionally always defined.

Escape the percent sign in '%global' in the comment to prevent this.

https://fedorahosted.org/freeipa/ticket/6418
---
 freeipa.spec.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/freeipa.spec.in b/freeipa.spec.in
index fbb3945..831df4f 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -9,7 +9,7 @@
 %endif
 
 # lint is not executed during rpmbuild
-# %global with_lint 1
+# %%global with_lint 1
 
 %global alt_name ipa
 %if 0%{?rhel}
-- 
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#334][comment] Py3: Fix ToASCII method

[mbasti-rh]

  URL: https://github.com/freeipa/freeipa/pull/334
Title: #334: Py3: Fix ToASCII method

mbasti-rh commented:
"""
I reworked commit:
- keep python-dns 1.15 in build requires at it changed return type of to_text 
function
- removed .encode() check 
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/334#issuecomment-267948095
-- 
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#334][synchronized] Py3: Fix ToASCII method

[mbasti-rh]

   URL: https://github.com/freeipa/freeipa/pull/334
Author: mbasti-rh
 Title: #334: Py3: Fix ToASCII method
Action: synchronized

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/334/head:pr334
git checkout pr334
From e5825f44dafc4fb96965fb90d2f0442846970a71 Mon Sep 17 00:00:00 2001
From: Martin Basti 
Date: Wed, 14 Dec 2016 10:12:05 +0100
Subject: [PATCH 1/2] Py3: Fix ToASCII method

in Py2 to_text method returns Py2 non-unicode string, but in Py3 to_text method
returns Py3 default (unicode) string. So only in Py2 we have to decode
str to unicode.

https://fedorahosted.org/freeipa/ticket/5935
---
 freeipa.spec.in  | 20 ++--
 ipapython/dnsutil.py |  5 -
 ipasetup.py.in   |  2 +-
 3 files changed, 15 insertions(+), 12 deletions(-)

diff --git a/freeipa.spec.in b/freeipa.spec.in
index fbb3945..73210b7 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -126,8 +126,8 @@ BuildRequires:  python-memcached
 BuildRequires:  python-lxml
 # 5.0.0: QRCode.print_ascii
 BuildRequires:  python-qrcode-core >= 5.0.0
-# 1.13: python-dns URI record support
-BuildRequires:  python-dns >= 1.13
+# 1.15: python-dns PY3 support (many improvements)
+BuildRequires:  python-dns >= 1.15
 BuildRequires:  jsl
 BuildRequires:  python-yubico
 # pki Python package
@@ -163,8 +163,8 @@ BuildRequires:  python3-memcached
 BuildRequires:  python3-lxml
 # 5.0.0: QRCode.print_ascii
 BuildRequires:  python3-qrcode-core >= 5.0.0
-# 1.13: python-dns URI record support
-BuildRequires:  python3-dns >= 1.13
+# 1.15: python-dns PY3 support (many improvements)
+BuildRequires:  python3-dns >= 1.15
 BuildRequires:  python3-yubico
 # pki Python package
 # 10.2.1: crypto.NSSCryptoProvider(password_file)
@@ -294,7 +294,7 @@ Requires: python-gssapi >= 1.2.0
 Requires: python-sssdconfig
 Requires: python-pyasn1
 Requires: dbus-python
-Requires: python-dns >= 1.13
+Requires: python-dns >= 1.15
 Requires: python-kdcproxy >= 0.3
 Requires: rpm-libs
 
@@ -323,7 +323,7 @@ Requires: python3-gssapi >= 1.2.0
 Requires: python3-sssdconfig
 Requires: python3-pyasn1
 Requires: python3-dbus
-Requires: python3-dns >= 1.11.1
+Requires: python3-dns >= 1.15
 Requires: python3-kdcproxy >= 0.3
 Requires: rpm-libs
 
@@ -482,7 +482,7 @@ BuildArch: noarch
 Requires: %{name}-client-common = %{version}-%{release}
 Requires: %{name}-common = %{version}-%{release}
 Requires: python2-ipalib = %{version}-%{release}
-Requires: python-dns >= 1.13
+Requires: python-dns >= 1.15
 
 %description -n python2-ipaclient
 IPA is an integrated solution to provide centrally managed Identity (users,
@@ -504,7 +504,7 @@ BuildArch: noarch
 Requires: %{name}-client-common = %{version}-%{release}
 Requires: %{name}-common = %{version}-%{release}
 Requires: python3-ipalib = %{version}-%{release}
-Requires: python3-dns >= 1.11.1
+Requires: python3-dns >= 1.15
 
 %description -n python3-ipaclient
 IPA is an integrated solution to provide centrally managed Identity (users,
@@ -598,7 +598,7 @@ Requires: python-cffi
 Requires: python-ldap >= 2.4.15
 Requires: python-requests
 Requires: python-custodia
-Requires: python-dns >= 1.13
+Requires: python-dns >= 1.15
 Requires: python-enum34
 Requires: python-netifaces >= 0.10.4
 Requires: pyusb
@@ -648,7 +648,7 @@ Requires: python3-cffi
 Requires: python3-pyldap >= 2.4.15
 Requires: python3-custodia
 Requires: python3-requests
-Requires: python3-dns >= 1.11.1
+Requires: python3-dns >= 1.15
 Requires: python3-netifaces >= 0.10.4
 Requires: python3-pyusb
 
diff --git a/ipapython/dnsutil.py b/ipapython/dnsutil.py
index 16549c8..ba0f0aa 100644
--- a/ipapython/dnsutil.py
+++ b/ipapython/dnsutil.py
@@ -71,7 +71,10 @@ def __str__(self):
 
 def ToASCII(self):
 #method named by RFC 3490 and python standard library
-return self.to_text().decode('ascii')  # must be unicode string
+res = self.to_text()
+if six.PY2:
+return res.decode('ascii')  # must be unicode string in Python 2
+return res
 
 def canonicalize(self):
 return DNSName(super(DNSName, self).canonicalize())
diff --git a/ipasetup.py.in b/ipasetup.py.in
index 6a33fb8..c221e0d 100644
--- a/ipasetup.py.in
+++ b/ipasetup.py.in
@@ -64,7 +64,7 @@ if SETUPTOOLS_VERSION < (8, 0, 0):
 
 PACKAGE_VERSION = {
 'cryptography': 'cryptography >= 1.3.1',
-'dnspython': 'dnspython >= 1.13',
+'dnspython': 'dnspython >= 1.15',
 'gssapi': 'gssapi >= 1.2.0',
 'ipaclient': 'ipaclient == {}'.format(VERSION),
 'ipalib': 'ipalib == {}'.format(VERSION),

From 91255febf3e0c9f99e54aa10e52fe0c994d23b1b Mon Sep 17 00:00:00 2001
From: Martin Basti 
Date: Wed, 14 Dec 2016 12:09:34 +0100
Subject: [PATCH 2/2] zonemgr_callback: py3 fix

str and bytes cannot be concatenated in Py3

https://fedorahosted.org/freeipa/ticket/5990
---
 freeipa.spec.in   |  4 ++--
 ipapython/dnsutil.py  | 14 --
 

[Freeipa-devel] [freeipa PR#348][opened] ca: fix ca-find with --pkey-only

[jcholast]

   URL: https://github.com/freeipa/freeipa/pull/348
Author: jcholast
 Title: #348: ca: fix ca-find with --pkey-only
Action: opened

PR body:
"""
Since commit 32b1743e5fb318b226a602ec8d9a4b6ef2a25c9d, ca-find will fail
with internal error if --pkey-only is specified, because the code to
look up the CA certificate and certificate chain assumes that the ipaCAId
attribute is always present in the result.

Fix this by not attempting to lookup the certificate / chain at all when
--pkey-only is specified.

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

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/348/head:pr348
git checkout pr348
From dda67fc7ed2d45bf90ee795a7e20edd41931ceb1 Mon Sep 17 00:00:00 2001
From: Jan Cholasta 
Date: Fri, 16 Dec 2016 14:19:00 +0100
Subject: [PATCH] ca: fix ca-find with --pkey-only

Since commit 32b1743e5fb318b226a602ec8d9a4b6ef2a25c9d, ca-find will fail
with internal error if --pkey-only is specified, because the code to
look up the CA certificate and certificate chain assumes that the ipaCAId
attribute is always present in the result.

Fix this by not attempting to lookup the certificate / chain at all when
--pkey-only is specified.

https://fedorahosted.org/freeipa/ticket/6178
---
 ipaserver/plugins/ca.py | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/ipaserver/plugins/ca.py b/ipaserver/plugins/ca.py
index 2510a79..72f5443 100644
--- a/ipaserver/plugins/ca.py
+++ b/ipaserver/plugins/ca.py
@@ -192,8 +192,9 @@ class ca_find(LDAPSearch):
 def execute(self, *keys, **options):
 ca_enabled_check()
 result = super(ca_find, self).execute(*keys, **options)
-for entry in result['result']:
-set_certificate_attrs(entry, options, want_cert=False)
+if not options.get('pkey_only', False):
+for entry in result['result']:
+set_certificate_attrs(entry, options, want_cert=False)
 return 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] Certificate Identity Mapping

[Sumit Bose]

On Mon, Dec 19, 2016 at 10:02:58AM +0100, Jan Cholasta wrote:
> I agree with *almost* everything Sumit said. See my inline comments below.
> 
> On 16.12.2016 11:53, Sumit Bose wrote:
> > On Tue, Dec 06, 2016 at 04:39:10PM +0100, Florence Blanc-Renaud wrote:
> > > Hi,
> > > 
> > > I have started a feature description for the Certificate Identity Mapping 
> > > at
> > > the following location:
> > > http://www.freeipa.org/page/V4/Certificate_Identity_Mapping
> > > 
> > > This is a first step, focusing on the interface we would like to provide. 
> > > It
> > > still contains open questions, some of which are linked to the 
> > > corresponding
> > > design on SSSD side:
> > > https://fedorahosted.org/sssd/wiki/DesignDocs/MatchingAndMappingCertificates
> > > https://fedorahosted.org/sssd/wiki/DesignDocs/SmartcardsAndMultipleIdentities
> > > 
> > > Comments, concerns and suggestions are welcome. Thanks!
> > 
> > Hi Flo,
> > 
> > thank you very much for setting up the page.
> > 
> > My comments are mostly about the commands.
> > 
> > certmappingconfig-mod:
> > 
> > * --enable=Boolean: if this option is 'False' SSSD will basically show
> >   the current behavior and just look up the certificates directly. But I
> >   wonder if the option is needed at all because not adding any mapping
> >   rules would have the same effect.
> > 
> >   What is the scope here, only the IPA domain, or all trusted domains as
> >   well? If it is for trusted domains as well will the certmappingrule-*
> >   commands and user-{add/remove}-certmapping return an error?
> > 
> >   So, in general I see an overlap with the mapping rules and I think it
> >   would be clearer to drop this option and do the lookups according to
> >   the mapping rules.
> > 
> > * --prompt-username=Boolean: the description implies that this option is
> >   synonymous to 1:1 mapping, but it is not. On Linux authentication in
> >   most cases use a user name either by directly asking (e.g. /bin/login)
> >   or using the current user name (e.g. sudo). So, according to its name
> >   it would only control if gdm is allowed to ask for an (optional) user
> >   name.
> > 
> >   If the option is renamed to e.g. --force-1-to-1-mapping to really
> >   enforce a 1:1 mapping then it would make sense to derived to gdm
> >   behavior. I.e. if 1:1 mapping is enforce it makes no sense for gdm to
> >   ask for a user name and if it is not enforced then it makes sense to
> >   offer and optional user name input field.
> > 
> > * --enable-username-mismatch=Boolean: I think this option can be
> >   dropped. My test so far show that if a non-matching hint is given on a
> >   Windows client authentication fails.
> > 
> > * --alternate-attribute=STRING: I think this option isn't needed as
> >   well. For IPA server-side we should decide on an attribute name and
> >   add it to the schema for user objects. On the client side the
> >   attribute name can be taken from the mapping rule.A
> > 
> > 
> > certmappingrule.*:
> > 
> > * ISSUERDN: it looks like you want to use issuerName here. In
> >   certificateRecord it it used with LDAP ordering and I would prefer
> >   LDAP ordering at all points where we have a choice. Unfortunately in the
> >   issuer-subject mapping AD dictates X.500 ordering.
> 
> LDAP ordering should indeed be preferred, as it is used everywhere else in
> IPA. We can convert to/from X.500 ordering where necessary, when possible.
> 
> > 
> > * DOMAINDN: does this refer to the nsslapd-certmap-basedn attribute in
> >   the example? My intention in the SSSD design-page was to specify the
> >   domain (as in DNS domain/IPA domain/trusted domain) where the matching
> >   user should be searched. Different domains might certificates from
> >   different issuers and some domains might not even use certificates.
> >   With this information SSSD does not have to search any domain trusted
> >   by IPA from a given certificate, but look only at domains listed here
> >   (the attribute should be a multi-value one).
> > 
> >   There are objects in the LDAP tree for each trusted domain which are
> >   used by SSSD so using a DN syntax would be valid here.
> 
> We use domain names rather than DNs to refer to domains everywhere else in
> the framework. I don't think this place should be an exception.

I'm fine with domain names as well. In fact I didn't thought of using
DNs for this before I read DOMAINDN on the design page.

> 
> > 
> > * LDAPSEARCHFILTER: I think a separate option is not need. LDAP search
> >   filters should just be a special kind of mapping rules. I can image in
> >   syntax like: . I
> >   think the difficult part with the LDAP filters will to define sensible
> >   templates.
> 
> I'm not sure I understand. Could you please elaborate a little bit?

A LDAP search filter which would cover the AD behavior would look like: 

(|(altSecurityIdentities=%A%B)(userPrincipalName=%C)(samAccountName=%D))

where

%A: must be 

Re: [Freeipa-devel] require n out of m keys/users to authenticate an ssh session?

[Alexander Bokovoy]

On ma, 19 joulu 2016, Oucema Bellagha wrote:

Hi folks,


Thanks for the feedback, I already tried the AuthenticationMethods
"publickey,publickey" but is there any tool allowing this kind of
connection from two clients to the server in the same time using
ssh-Key cause it's not possible using putty ..

No, as I said, it is not designed in the SSH protocol

P.S. Answer to the list, not personally.




Cheers,



From: Alexander Bokovoy 
Sent: Monday, December 19, 2016 9:06:51 AM
To: Oucema Bellagha
Cc: freeipa-devel@redhat.com
Subject: Re: [Freeipa-devel] require n out of m keys/users to authenticate an 
ssh session?

On ma, 19 joulu 2016, Oucema Bellagha wrote:

I'm looking for an option - eventually to extend standard ssh - in such
a way that I need (at least) two people/keys out of m possible to
authenticate a session instead of one out of m known once...

e.g:
to authenticate to server X : I need two people A and (B or C) together.

anyone seen this or know how to do?

I know there is key + password (which is kind of this direction) but
not exactly what I'm looking for...

You can use the very same directive AuthenticationMethods to ask for
multiple keys too.

  AuthenticationMethods "publickey,publickey,publickey"

would require three different public keys to authenticate.

However, there is nothing in SSH protocol that would enforce different
people to be involved at the client side.
--
/ Alexander Bokovoy


--
/ 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] require n out of m keys/users to authenticate an ssh session?

[Alexander Bokovoy]

On ma, 19 joulu 2016, Oucema Bellagha wrote:

I'm looking for an option - eventually to extend standard ssh - in such
a way that I need (at least) two people/keys out of m possible to
authenticate a session instead of one out of m known once...

e.g:
to authenticate to server X : I need two people A and (B or C) together.

anyone seen this or know how to do?

I know there is key + password (which is kind of this direction) but
not exactly what I'm looking for...

You can use the very same directive AuthenticationMethods to ask for
multiple keys too.

  AuthenticationMethods "publickey,publickey,publickey"

would require three different public keys to authenticate.

However, there is nothing in SSH protocol that would enforce different
people to be involved at the client side.
--
/ 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] Certificate Identity Mapping

[Jan Cholasta]

I agree with *almost* everything Sumit said. See my inline comments below.

On 16.12.2016 11:53, Sumit Bose wrote:

On Tue, Dec 06, 2016 at 04:39:10PM +0100, Florence Blanc-Renaud wrote:

Hi,

I have started a feature description for the Certificate Identity Mapping at
the following location:
http://www.freeipa.org/page/V4/Certificate_Identity_Mapping

This is a first step, focusing on the interface we would like to provide. It
still contains open questions, some of which are linked to the corresponding
design on SSSD side:
https://fedorahosted.org/sssd/wiki/DesignDocs/MatchingAndMappingCertificates
https://fedorahosted.org/sssd/wiki/DesignDocs/SmartcardsAndMultipleIdentities

Comments, concerns and suggestions are welcome. Thanks!


Hi Flo,

thank you very much for setting up the page.

My comments are mostly about the commands.

certmappingconfig-mod:

* --enable=Boolean: if this option is 'False' SSSD will basically show
  the current behavior and just look up the certificates directly. But I
  wonder if the option is needed at all because not adding any mapping
  rules would have the same effect.

  What is the scope here, only the IPA domain, or all trusted domains as
  well? If it is for trusted domains as well will the certmappingrule-*
  commands and user-{add/remove}-certmapping return an error?

  So, in general I see an overlap with the mapping rules and I think it
  would be clearer to drop this option and do the lookups according to
  the mapping rules.

* --prompt-username=Boolean: the description implies that this option is
  synonymous to 1:1 mapping, but it is not. On Linux authentication in
  most cases use a user name either by directly asking (e.g. /bin/login)
  or using the current user name (e.g. sudo). So, according to its name
  it would only control if gdm is allowed to ask for an (optional) user
  name.

  If the option is renamed to e.g. --force-1-to-1-mapping to really
  enforce a 1:1 mapping then it would make sense to derived to gdm
  behavior. I.e. if 1:1 mapping is enforce it makes no sense for gdm to
  ask for a user name and if it is not enforced then it makes sense to
  offer and optional user name input field.

* --enable-username-mismatch=Boolean: I think this option can be
  dropped. My test so far show that if a non-matching hint is given on a
  Windows client authentication fails.

* --alternate-attribute=STRING: I think this option isn't needed as
  well. For IPA server-side we should decide on an attribute name and
  add it to the schema for user objects. On the client side the
  attribute name can be taken from the mapping rule.A


certmappingrule.*:

* ISSUERDN: it looks like you want to use issuerName here. In
  certificateRecord it it used with LDAP ordering and I would prefer
  LDAP ordering at all points where we have a choice. Unfortunately in the
  issuer-subject mapping AD dictates X.500 ordering.


LDAP ordering should indeed be preferred, as it is used everywhere else 
in IPA. We can convert to/from X.500 ordering where necessary, when 
possible.




* DOMAINDN: does this refer to the nsslapd-certmap-basedn attribute in
  the example? My intention in the SSSD design-page was to specify the
  domain (as in DNS domain/IPA domain/trusted domain) where the matching
  user should be searched. Different domains might certificates from
  different issuers and some domains might not even use certificates.
  With this information SSSD does not have to search any domain trusted
  by IPA from a given certificate, but look only at domains listed here
  (the attribute should be a multi-value one).

  There are objects in the LDAP tree for each trusted domain which are
  used by SSSD so using a DN syntax would be valid here.


We use domain names rather than DNs to refer to domains everywhere else 
in the framework. I don't think this place should be an exception.




* LDAPSEARCHFILTER: I think a separate option is not need. LDAP search
  filters should just be a special kind of mapping rules. I can image in
  syntax like: . I
  think the difficult part with the LDAP filters will to define sensible
  templates.


I'm not sure I understand. Could you please elaborate a little bit?


  But as long as we keep the general mapping rule syntax
  flexible the LDAP filter rules can be added in a later version.


IMHO it should be the other way round and LDAP filters should be 
implemented first, as they offer all the flexibility we need (all of the 
other fields can be easily implemented on top of LDAP filters) and are 
by default extensible without having to update servers and clients.




* enable/disable: I think this is a good idea and would be consistent
  with other rules like HBAC and sudo

* user-{add/mod} LOGIN --certmappingdata DATA: I think it might be
  better to not add this option and only implement the
  'user-{add/remove}-certmapping' commands

* user-{add/remove}-certmapping: you say '... almost any type of 

[Freeipa-devel] require n out of m keys/users to authenticate an ssh session?

[Oucema Bellagha]

I'm looking for an option - eventually to extend standard ssh - in such a way 
that I need (at least) two people/keys out of m possible to authenticate a 
session instead of one out of m known once...

e.g:
to authenticate to server X : I need two people A and (B or C) together.

anyone seen this or know how to do?

I know there is key + password (which is kind of this direction) but not 
exactly what I'm looking for...


Thanks,


-- 
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] FreeIPA on FIPS + NSS question

[Standa Laznicka]

On 12/16/2016 03:23 PM, Rob Crittenden wrote:

Standa Laznicka wrote:

Hello,

I started a design page for FreeIPA on FIPS-enabled systems:
https://www.freeipa.org/page/V4/FreeIPA-on-FIPS

Me and Tomáš are still investigating what of all things will need to
change in order to have FreeIPA on FIPS-enabled RHEL. So far I managed
to install and run patched FreeIPA server and client and connect them
together.

There are some issues with NSS when trying to create an HTTPS request
(apparently, NSS requires an NSS database password to set up an SSL
connection). I am actually thinking of removing NSSConnection from the
client altogether.

Can you expand on this a bit? NSS should only need a pin when it needs
access to a private key. What connection(s) are you talking about, and
what would you replace NSSConnection with?

rob


Hello Rob,

Thank you for this excellent question, in order to cut the email short I 
seem to have omitted quite a few information.


One of the very first problems I had with FreeIPA with FIPS was that NSS 
was always asking for password/pin. I was discussing this with the NSS 
guys on their IRC chat last week and it turns out that NSS tries to 
create a private key every time you want to use it as a backend for an 
SSL connection on FIPS. I still don't think this is quite right so I may 
open a bugzilla for that.


Anyway, the guys suggested me that we could try to create the database 
with an empty password and everything will work. I don't quite like 
that, too, but it's at least something if you don't want the `ipa` 
command to always bug you for password you have no way knowing if you're 
just a regular user.


What I think would be a better way to go is to use 
httplib.HTTPSConnection. We have the needed certificates in 
/etc/ipa/ca.crt anyway so why not use them instead. We had a discussion 
with Honza this morning and it seems that with this approach we may get 
rid of the NSSConnection class altogether (although I still need to 
check a few spots) and start the process of moving away from NSS which 
was discussed some year ago in an internal mailing list (for some reason).


Will be happy to hear thoughts on this,
Standa

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