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

[Sumit Bose]

On Fri, Apr 07, 2017 at 10:38:55AM +0200, Jakub Hrozek 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
> 
> I converted the page to pagure markdown:
> 
> https://docs.pagure.org/SSSD.sssd/design_pages/matching_and_mapping_certificates.html
> 
> There are no changes to the content except for fixing typos.

Thank you for doing the conversion and fixing the typos. I will now
update the page to reflect the current state of the code.

bye,
Sumit
> 
> -- 
> 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

-- 
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#672][opened] IPA-KDB: use relative path in ipa-certmap config snippet

[sumit-bose]

   URL: https://github.com/freeipa/freeipa/pull/672
Author: sumit-bose
 Title: #672: IPA-KDB: use relative path in ipa-certmap config snippet
Action: opened

PR body:
"""
Architecture specific paths should be avoided in the global Kerberos
configuration because it is read e.g. by 32bit and 64bit libraries they
are installed in parallel.

Resolves https://pagure.io/freeipa/issue/6833
"""

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/672/head:pr672
git checkout pr672
From 54460a33d3d95dbcaec56bf45999a39c10da60ed Mon Sep 17 00:00:00 2001
From: Sumit Bose 
Date: Wed, 29 Mar 2017 15:46:50 +0200
Subject: [PATCH] IPA-KDB: use relative path in ipa-certmap config snippet

Architecture specific paths should be avoided in the global Kerberos
configuration because it is read e.g. by 32bit and 64bit libraries they
are installed in parallel.

Resolves https://pagure.io/freeipa/issue/6833
---
 daemons/ipa-kdb/Makefile.am | 12 
 daemons/ipa-kdb/ipa-certauth|  5 +
 daemons/ipa-kdb/ipa-certauth.in |  5 -
 3 files changed, 9 insertions(+), 13 deletions(-)
 create mode 100644 daemons/ipa-kdb/ipa-certauth
 delete mode 100644 daemons/ipa-kdb/ipa-certauth.in

diff --git a/daemons/ipa-kdb/Makefile.am b/daemons/ipa-kdb/Makefile.am
index 715666e..259bc3b 100644
--- a/daemons/ipa-kdb/Makefile.am
+++ b/daemons/ipa-kdb/Makefile.am
@@ -40,18 +40,16 @@ ipadb_la_SOURCES = 		\
 	ipa_kdb_audit_as.c	\
 	$(NULL)
 
+dist_noinst_DATA = ipa_kdb.exports
+
 if BUILD_IPA_CERTAUTH_PLUGIN
 ipadb_la_SOURCES += ipa_kdb_certauth.c
 
 
-%: %.in
-	sed \
-		-e 's|@plugindir@|$(plugindir)|g' \
-		'$(srcdir)/$@.in' >$@
-
 krb5confdir = $(sysconfdir)/krb5.conf.d
 krb5conf_DATA = ipa-certauth
-CLEANFILES = $(krb5conf_DATA)
+else
+dist_noinst_DATA += ipa-certauth
 endif
 
 ipadb_la_LDFLAGS = 		\
@@ -105,8 +103,6 @@ ipa_kdb_tests_LDADD =  \
-lsss_idmap \
$(NULL)
 
-dist_noinst_DATA = ipa_kdb.exports ipa-certauth.in
-
 clean-local:
 	rm -f tests/.dirstamp
 
diff --git a/daemons/ipa-kdb/ipa-certauth b/daemons/ipa-kdb/ipa-certauth
new file mode 100644
index 000..6fde082
--- /dev/null
+++ b/daemons/ipa-kdb/ipa-certauth
@@ -0,0 +1,5 @@
+[plugins]
+ certauth = {
+  module = ipakdb:kdb/ipadb.so
+  enable_only = ipakdb
+ }
diff --git a/daemons/ipa-kdb/ipa-certauth.in b/daemons/ipa-kdb/ipa-certauth.in
deleted file mode 100644
index eda89a2..000
--- a/daemons/ipa-kdb/ipa-certauth.in
+++ /dev/null
@@ -1,5 +0,0 @@
-[plugins]
- certauth = {
-  module = ipakdb:@plugindir@/ipadb.so
-  enable_only = ipakdb
- }
-- 
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#644][synchronized] extdom: improve certificate request

[sumit-bose]

   URL: https://github.com/freeipa/freeipa/pull/644
Author: sumit-bose
 Title: #644: extdom: improve certificate request
Action: synchronized

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/644/head:pr644
git checkout pr644
From e04d0cfe6735a14aa0535d45982ea2aa7480edf5 Mon Sep 17 00:00:00 2001
From: Sumit Bose 
Date: Fri, 17 Mar 2017 14:10:52 +0100
Subject: [PATCH 1/2] extdom: do reverse search for domain separator

To avoid issues which @-signs in the short user or group names it is
better to search for the domain separator starting at the end of the
fully-qualified name.
---
 daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c
index e629247..aa1ff10 100644
--- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c
+++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c
@@ -515,7 +515,7 @@ int pack_ber_user(struct ipa_extdom_ctx *ctx,
 char *short_user_name = NULL;
 
 short_user_name = strdup(user_name);
-if ((locat = strchr(short_user_name, SSSD_DOMAIN_SEPARATOR)) != NULL) {
+if ((locat = strrchr(short_user_name, SSSD_DOMAIN_SEPARATOR)) != NULL) {
 if (strcasecmp(locat+1, domain_name) == 0  ) {
 locat[0] = '\0';
 } else {
@@ -626,7 +626,7 @@ int pack_ber_group(enum response_types response_type,
 char *short_group_name = NULL;
 
 short_group_name = strdup(group_name);
-if ((locat = strchr(short_group_name, SSSD_DOMAIN_SEPARATOR)) != NULL) {
+if ((locat = strrchr(short_group_name, SSSD_DOMAIN_SEPARATOR)) != NULL) {
 if (strcasecmp(locat+1, domain_name) == 0  ) {
 locat[0] = '\0';
 } else {
@@ -901,7 +901,7 @@ static int handle_sid_or_cert_request(struct ipa_extdom_ctx *ctx,
 goto done;
 }
 
-sep = strchr(fq_name, SSSD_DOMAIN_SEPARATOR);
+sep = strrchr(fq_name, SSSD_DOMAIN_SEPARATOR);
 if (sep == NULL) {
 set_err_msg(req, "Failed to split fully qualified name");
 ret = LDAP_OPERATIONS_ERROR;

From 33952e2a2cf8e7afeac492ade676027b12649501 Mon Sep 17 00:00:00 2001
From: Sumit Bose 
Date: Fri, 17 Mar 2017 14:48:50 +0100
Subject: [PATCH 2/2] extdom: improve cert request

Certificates can be assigned to multiple user so the extdom plugin must
use sss_nss_getlistbycert() instead of sss_nss_getnamebycert() and
return a list of fully-qualified user names.

Due to issues on the SSSD side the current version of lookups by
certificates didn't work at all and the changes here won't break
existing clients.

Related to https://pagure.io/freeipa/issue/6826
---
 .../ipa-extdom-extop/ipa_extdom.h  |   3 +-
 .../ipa-extdom-extop/ipa_extdom_common.c   | 157 ++---
 server.m4  |   2 +-
 3 files changed, 143 insertions(+), 19 deletions(-)

diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h
index 34e2d3c..bc29f06 100644
--- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h
+++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h
@@ -95,7 +95,8 @@ enum response_types {
 RESP_USER,
 RESP_GROUP,
 RESP_USER_GROUPLIST,
-RESP_GROUP_MEMBERS
+RESP_GROUP_MEMBERS,
+RESP_NAME_LIST
 };
 
 struct extdom_req {
diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c
index aa1ff10..fe225fa 100644
--- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c
+++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c
@@ -698,6 +698,90 @@ int pack_ber_group(enum response_types response_type,
 return ret;
 }
 
+int pack_ber_name_list(struct extdom_req *req, char **fq_name_list,
+   struct berval **berval)
+{
+BerElement *ber = NULL;
+int ret;
+char *sep;
+size_t c;
+size_t len;
+size_t name_len;
+
+/* count the names */
+for (c = 0; fq_name_list[c] != NULL; c++);
+if (c == 0) {
+set_err_msg(req, "Empty name list");
+return LDAP_NO_SUCH_OBJECT;
+}
+
+ber = ber_alloc_t( LBER_USE_DER );
+if (ber == NULL) {
+set_err_msg(req, "BER alloc failed");
+return LDAP_OPERATIONS_ERROR;
+}
+
+
+ret = ber_printf(ber,"{e{", RESP_NAME_LIST);
+if (ret == -1) {
+set_err_msg(req, "BER start failed");
+ber_free(ber, 1);
+return LDAP_OPERATIONS_ERROR;
+}
+
+for (c = 0; fq_name_list[c] != NULL; c++) {
+len = strlen(fq_name_list[c]);
+if (len < 3) {
+set_err_msg(req, "Fully qualified na

[Freeipa-devel] [freeipa PR#657][synchronized] configure: fix --disable-server with certauth plugin

[sumit-bose]

   URL: https://github.com/freeipa/freeipa/pull/657
Author: sumit-bose
 Title: #657: configure: fix --disable-server with certauth plugin
Action: synchronized

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/657/head:pr657
git checkout pr657
From cb688e60671f8deeb89904d0e5852530f90e0cfc Mon Sep 17 00:00:00 2001
From: Sumit Bose 
Date: Mon, 27 Mar 2017 12:18:53 +0200
Subject: [PATCH 1/2] configure: fix --disable-server with certauth plugin

Resolves https://pagure.io/freeipa/issue/6816
---
 configure.ac | 12 
 server.m4|  5 -
 2 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/configure.ac b/configure.ac
index 7a67ec0..68340c8 100644
--- a/configure.ac
+++ b/configure.ac
@@ -225,6 +225,18 @@ AM_COND_IF([ENABLE_SERVER], [
 ])
 
 dnl ---
+dnl - Check if IPA certauth plugin can be build
+dnl ---
+
+AM_CONDITIONAL([BUILD_IPA_CERTAUTH_PLUGIN],
+   [test x$have_certauth_plugin = xyes -a x"$SSSCERTMAP_LIBS" != x])
+AM_COND_IF([BUILD_IPA_CERTAUTH_PLUGIN], [
+AM_COND_IF([ENABLE_SERVER],
+   [AC_MSG_NOTICE([Build IPA KDB certauth plugin])],
+   [AC_MSG_WARN([Cannot build IPA KDB certauth plugin])])
+])
+
+dnl ---
 dnl - Check for program paths
 dnl ---
 AC_PATH_PROG(UNLINK, unlink, [AC_MSG_ERROR([unlink not found])])
diff --git a/server.m4 b/server.m4
index 7b2e94d..a4c9919 100644
--- a/server.m4
+++ b/server.m4
@@ -37,11 +37,6 @@ PKG_CHECK_EXISTS([sss_certmap],
 AC_CHECK_HEADER([krb5/certauth_plugin.h],
 [have_certauth_plugin=yes],
 [have_certauth_plugin=no])
-AM_CONDITIONAL([BUILD_IPA_CERTAUTH_PLUGIN],
-   [test x$have_certauth_plugin = xyes -a x"$SSSCERTMAP_LIBS" != x])
-AM_COND_IF([BUILD_IPA_CERTAUTH_PLUGIN],
-   [AC_MSG_NOTICE([Build IPA KDB certauth plugin])],
-   [AC_MSG_WARN([Cannot build IPA KDB certauth plugin])])
 
 dnl ---
 dnl - Check for KRB5 krad

From 3b4f9f382bf31a192cf2721d9a1e8423573f833b Mon Sep 17 00:00:00 2001
From: Sumit Bose 
Date: Mon, 27 Mar 2017 13:19:57 +0200
Subject: [PATCH 2/2] ipa-kdb: do not depend on certauth_plugin.h

Related to https://pagure.io/freeipa/issue/4905
---
 configure.ac  | 2 ++
 daemons/ipa-kdb/ipa_kdb.c | 2 ++
 daemons/ipa-kdb/ipa_kdb.h | 8 
 3 files changed, 12 insertions(+)

diff --git a/configure.ac b/configure.ac
index 68340c8..f5c5270 100644
--- a/configure.ac
+++ b/configure.ac
@@ -231,6 +231,8 @@ dnl ---
 AM_CONDITIONAL([BUILD_IPA_CERTAUTH_PLUGIN],
[test x$have_certauth_plugin = xyes -a x"$SSSCERTMAP_LIBS" != x])
 AM_COND_IF([BUILD_IPA_CERTAUTH_PLUGIN], [
+AC_DEFINE([HAVE_KRB5_CERTAUTH_PLUGIN], [1],
+[MIT Kerberos version supports certauth plugin])
 AM_COND_IF([ENABLE_SERVER],
[AC_MSG_NOTICE([Build IPA KDB certauth plugin])],
[AC_MSG_WARN([Cannot build IPA KDB certauth plugin])])
diff --git a/daemons/ipa-kdb/ipa_kdb.c b/daemons/ipa-kdb/ipa_kdb.c
index a961e4e..050bfc9 100644
--- a/daemons/ipa-kdb/ipa_kdb.c
+++ b/daemons/ipa-kdb/ipa_kdb.c
@@ -67,7 +67,9 @@ static void ipadb_context_free(krb5_context kcontext,
 }
 free(cfg->authz_data);
 
+#ifdef HAVE_KRB5_CERTAUTH_PLUGIN
 ipa_certauth_free_moddata(&((*ctx)->certauth_moddata));
+#endif
 
 free(*ctx);
 *ctx = NULL;
diff --git a/daemons/ipa-kdb/ipa_kdb.h b/daemons/ipa-kdb/ipa_kdb.h
index 632c197..72573a6 100644
--- a/daemons/ipa-kdb/ipa_kdb.h
+++ b/daemons/ipa-kdb/ipa_kdb.h
@@ -30,6 +30,8 @@
  * filtering purposes */
 #define SECURID 1
 
+#include "config.h"
+
 #include 
 #include 
 #include 
@@ -40,7 +42,9 @@
 #include 
 #include 
 #include 
+#ifdef HAVE_KRB5_CERTAUTH_PLUGIN
 #include 
+#endif
 
 #include "ipa_krb5.h"
 #include "ipa_pwd.h"
@@ -112,7 +116,9 @@ struct ipadb_context {
 krb5_key_salt_tuple *def_encs;
 int n_def_encs;
 struct ipadb_mspac *mspac;
+#ifdef HAVE_KRB5_CERTAUTH_PLUGIN
 krb5_certauth_moddata certauth_moddata;
+#endif
 
 /* Don't access this directly, use ipadb_get_global_config(). */
 struct ipadb_global_config config;
@@ -334,5 +340,7 @@ int ipadb_get_enc_salt_types(struct ipadb_context *ipactx, LDAPMessage *entry,
  char *attr, krb5_key_salt_tuple **enc_salt_types,
  int *n_enc_salt_types);
 
+#ifdef HAVE_KRB5_CERTAUTH_PLUGIN
 /* CERTAUTH PLUGIN */
 void ipa_certauth_free_moddata(krb5_certauth_mo

[Freeipa-devel] [freeipa PR#657][synchronized] configure: fix --disable-server with certauth plugin

[sumit-bose]

   URL: https://github.com/freeipa/freeipa/pull/657
Author: sumit-bose
 Title: #657: configure: fix --disable-server with certauth plugin
Action: synchronized

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/657/head:pr657
git checkout pr657
From 5aae02c0c4bc5438a43937ec9ffa72b0c38eda88 Mon Sep 17 00:00:00 2001
From: Sumit Bose 
Date: Mon, 27 Mar 2017 12:18:53 +0200
Subject: [PATCH] configure: fix --disable-server with certauth plugin

Resolves https://pagure.io/freeipa/issue/6816
---
 configure.ac | 12 
 server.m4|  5 -
 2 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/configure.ac b/configure.ac
index 7a67ec0..ab75672 100644
--- a/configure.ac
+++ b/configure.ac
@@ -225,6 +225,18 @@ AM_COND_IF([ENABLE_SERVER], [
 ])
 
 dnl ---
+dnl - Check if IPA certauth plugin can be build
+dnl ---
+
+AM_CONDITIONAL([BUILD_IPA_CERTAUTH_PLUGIN],
+   [test x$have_certauth_plugin = xyes -a x"$SSSCERTMAP_LIBS" != x])
+AM_COND_IF([ENABLE_SERVER], [
+AM_COND_IF([BUILD_IPA_CERTAUTH_PLUGIN],
+   [AC_MSG_NOTICE([Build IPA KDB certauth plugin])],
+   [AC_MSG_WARN([Cannot build IPA KDB certauth plugin])])
+])
+
+dnl ---
 dnl - Check for program paths
 dnl ---
 AC_PATH_PROG(UNLINK, unlink, [AC_MSG_ERROR([unlink not found])])
diff --git a/server.m4 b/server.m4
index 7b2e94d..a4c9919 100644
--- a/server.m4
+++ b/server.m4
@@ -37,11 +37,6 @@ PKG_CHECK_EXISTS([sss_certmap],
 AC_CHECK_HEADER([krb5/certauth_plugin.h],
 [have_certauth_plugin=yes],
 [have_certauth_plugin=no])
-AM_CONDITIONAL([BUILD_IPA_CERTAUTH_PLUGIN],
-   [test x$have_certauth_plugin = xyes -a x"$SSSCERTMAP_LIBS" != x])
-AM_COND_IF([BUILD_IPA_CERTAUTH_PLUGIN],
-   [AC_MSG_NOTICE([Build IPA KDB certauth plugin])],
-   [AC_MSG_WARN([Cannot build IPA KDB certauth plugin])])
 
 dnl ---
 dnl - Check for KRB5 krad
-- 
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#657][opened] configure: fix --disable-server with certauth plugin

[sumit-bose]

   URL: https://github.com/freeipa/freeipa/pull/657
Author: sumit-bose
 Title: #657: configure: fix --disable-server with certauth plugin
Action: opened

PR body:
"""
Resolves https://pagure.io/freeipa/issue/6816
"""

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/657/head:pr657
git checkout pr657
From bc6aa4f0d8c9f3231f4477dc58bbe6ea50e36428 Mon Sep 17 00:00:00 2001
From: Sumit Bose 
Date: Mon, 27 Mar 2017 12:18:53 +0200
Subject: [PATCH] configure: fix --disable-server with certauth plugin

Resolves https://pagure.io/freeipa/issue/6816
---
 configure.ac | 10 ++
 server.m4|  5 -
 2 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/configure.ac b/configure.ac
index 7a67ec0..e432b82 100644
--- a/configure.ac
+++ b/configure.ac
@@ -225,6 +225,16 @@ AM_COND_IF([ENABLE_SERVER], [
 ])
 
 dnl ---
+dnl - Check if IPA certauth plugin can be build
+dnl ---
+
+AM_CONDITIONAL([BUILD_IPA_CERTAUTH_PLUGIN],
+   [test x$have_certauth_plugin = xyes -a x"$SSSCERTMAP_LIBS" != x])
+AM_COND_IF([BUILD_IPA_CERTAUTH_PLUGIN],
+   [AC_MSG_NOTICE([Build IPA KDB certauth plugin])],
+   [AC_MSG_WARN([Cannot build IPA KDB certauth plugin])])
+
+dnl ---
 dnl - Check for program paths
 dnl ---
 AC_PATH_PROG(UNLINK, unlink, [AC_MSG_ERROR([unlink not found])])
diff --git a/server.m4 b/server.m4
index 7b2e94d..a4c9919 100644
--- a/server.m4
+++ b/server.m4
@@ -37,11 +37,6 @@ PKG_CHECK_EXISTS([sss_certmap],
 AC_CHECK_HEADER([krb5/certauth_plugin.h],
 [have_certauth_plugin=yes],
 [have_certauth_plugin=no])
-AM_CONDITIONAL([BUILD_IPA_CERTAUTH_PLUGIN],
-   [test x$have_certauth_plugin = xyes -a x"$SSSCERTMAP_LIBS" != x])
-AM_COND_IF([BUILD_IPA_CERTAUTH_PLUGIN],
-   [AC_MSG_NOTICE([Build IPA KDB certauth plugin])],
-   [AC_MSG_WARN([Cannot build IPA KDB certauth plugin])])
 
 dnl ---
 dnl - Check for KRB5 krad
-- 
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#644][closed] extdom: improve certificate request

[sumit-bose]

   URL: https://github.com/freeipa/freeipa/pull/644
Author: sumit-bose
 Title: #644: extdom: improve certificate request
Action: closed

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/644/head:pr644
git checkout pr644
-- 
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#644][reopened] extdom: improve certificate request

[sumit-bose]

   URL: https://github.com/freeipa/freeipa/pull/644
Author: sumit-bose
 Title: #644: extdom: improve certificate request
Action: reopened

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/644/head:pr644
git checkout pr644
-- 
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#575][closed] IPA certauth plugin

[sumit-bose]

   URL: https://github.com/freeipa/freeipa/pull/575
Author: sumit-bose
 Title: #575: IPA certauth plugin
Action: closed

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/575/head:pr575
git checkout pr575
-- 
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#575][reopened] IPA certauth plugin

[sumit-bose]

   URL: https://github.com/freeipa/freeipa/pull/575
Author: sumit-bose
 Title: #575: IPA certauth plugin
Action: reopened

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/575/head:pr575
git checkout pr575
-- 
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#644][synchronized] extdom: improve certificate request

[sumit-bose]

   URL: https://github.com/freeipa/freeipa/pull/644
Author: sumit-bose
 Title: #644: extdom: improve certificate request
Action: synchronized

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/644/head:pr644
git checkout pr644
From 90e000fbccf8be924520f7cb480ce115ed74c983 Mon Sep 17 00:00:00 2001
From: Sumit Bose 
Date: Fri, 17 Mar 2017 14:10:52 +0100
Subject: [PATCH 1/2] extdom: do reverse search for domain separator

To avoid issues which @-signs in the short user or group names it is
better to search for the domain separator starting at the end of the
fully-qualified name.
---
 daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c
index e629247..aa1ff10 100644
--- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c
+++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c
@@ -515,7 +515,7 @@ int pack_ber_user(struct ipa_extdom_ctx *ctx,
 char *short_user_name = NULL;
 
 short_user_name = strdup(user_name);
-if ((locat = strchr(short_user_name, SSSD_DOMAIN_SEPARATOR)) != NULL) {
+if ((locat = strrchr(short_user_name, SSSD_DOMAIN_SEPARATOR)) != NULL) {
 if (strcasecmp(locat+1, domain_name) == 0  ) {
 locat[0] = '\0';
 } else {
@@ -626,7 +626,7 @@ int pack_ber_group(enum response_types response_type,
 char *short_group_name = NULL;
 
 short_group_name = strdup(group_name);
-if ((locat = strchr(short_group_name, SSSD_DOMAIN_SEPARATOR)) != NULL) {
+if ((locat = strrchr(short_group_name, SSSD_DOMAIN_SEPARATOR)) != NULL) {
 if (strcasecmp(locat+1, domain_name) == 0  ) {
 locat[0] = '\0';
 } else {
@@ -901,7 +901,7 @@ static int handle_sid_or_cert_request(struct ipa_extdom_ctx *ctx,
 goto done;
 }
 
-sep = strchr(fq_name, SSSD_DOMAIN_SEPARATOR);
+sep = strrchr(fq_name, SSSD_DOMAIN_SEPARATOR);
 if (sep == NULL) {
 set_err_msg(req, "Failed to split fully qualified name");
 ret = LDAP_OPERATIONS_ERROR;

From ed8703fa99fd31997d6a0fcfcf10e5fe487a0f7a Mon Sep 17 00:00:00 2001
From: Sumit Bose 
Date: Fri, 17 Mar 2017 14:48:50 +0100
Subject: [PATCH 2/2] extdom: improve cert request

Certificates can be assigned to multiple user so the extdom plugin must
use sss_nss_getlistbycert() instead of sss_nss_getnamebycert() and
return a list of fully-qualified user names.

Due to issues on the SSSD side the current version of lookups by
certificates didn't work at all and the changes here won't break
existing clients.

Related to https://pagure.io/freeipa/issue/6646
---
 .../ipa-extdom-extop/ipa_extdom.h  |   3 +-
 .../ipa-extdom-extop/ipa_extdom_common.c   | 157 ++---
 server.m4  |   2 +-
 3 files changed, 143 insertions(+), 19 deletions(-)

diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h
index 34e2d3c..bc29f06 100644
--- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h
+++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h
@@ -95,7 +95,8 @@ enum response_types {
 RESP_USER,
 RESP_GROUP,
 RESP_USER_GROUPLIST,
-RESP_GROUP_MEMBERS
+RESP_GROUP_MEMBERS,
+RESP_NAME_LIST
 };
 
 struct extdom_req {
diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c
index aa1ff10..fe225fa 100644
--- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c
+++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c
@@ -698,6 +698,90 @@ int pack_ber_group(enum response_types response_type,
 return ret;
 }
 
+int pack_ber_name_list(struct extdom_req *req, char **fq_name_list,
+   struct berval **berval)
+{
+BerElement *ber = NULL;
+int ret;
+char *sep;
+size_t c;
+size_t len;
+size_t name_len;
+
+/* count the names */
+for (c = 0; fq_name_list[c] != NULL; c++);
+if (c == 0) {
+set_err_msg(req, "Empty name list");
+return LDAP_NO_SUCH_OBJECT;
+}
+
+ber = ber_alloc_t( LBER_USE_DER );
+if (ber == NULL) {
+set_err_msg(req, "BER alloc failed");
+return LDAP_OPERATIONS_ERROR;
+}
+
+
+ret = ber_printf(ber,"{e{", RESP_NAME_LIST);
+if (ret == -1) {
+set_err_msg(req, "BER start failed");
+ber_free(ber, 1);
+return LDAP_OPERATIONS_ERROR;
+}
+
+for (c = 0; fq_name_list[c] != NULL; c++) {
+len = strlen(fq_name_list[c]);
+if (len < 3) {
+set_err_msg(req, "Fully qualified na

[Freeipa-devel] [freeipa PR#575][synchronized] IPA certauth plugin

[sumit-bose]

   URL: https://github.com/freeipa/freeipa/pull/575
Author: sumit-bose
 Title: #575: IPA certauth plugin
Action: synchronized

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/575/head:pr575
git checkout pr575
From e84f70cceec2421968977e4012bbf747e060b5f4 Mon Sep 17 00:00:00 2001
From: Sumit Bose 
Date: Wed, 15 Feb 2017 12:09:20 +0100
Subject: [PATCH 1/2] ipa-kdb: add ipadb_fetch_principals_with_extra_filter()

Additionally make ipadb_find_principal public.

Related to https://pagure.io/freeipa/issue/4905
---
 daemons/ipa-kdb/ipa_kdb.h| 11 +++
 daemons/ipa-kdb/ipa_kdb_principals.c | 58 
 2 files changed, 56 insertions(+), 13 deletions(-)

diff --git a/daemons/ipa-kdb/ipa_kdb.h b/daemons/ipa-kdb/ipa_kdb.h
index 8a3f7d3..72f2675 100644
--- a/daemons/ipa-kdb/ipa_kdb.h
+++ b/daemons/ipa-kdb/ipa_kdb.h
@@ -198,6 +198,17 @@ krb5_error_code ipadb_put_principal(krb5_context kcontext,
 char **db_args);
 krb5_error_code ipadb_delete_principal(krb5_context kcontext,
krb5_const_principal search_for);
+krb5_error_code
+ipadb_fetch_principals_with_extra_filter(struct ipadb_context *ipactx,
+ unsigned int flags,
+ const char *principal,
+ const char *filter,
+ LDAPMessage **result);
+krb5_error_code ipadb_find_principal(krb5_context kcontext,
+ unsigned int flags,
+ LDAPMessage *res,
+ char **principal,
+ LDAPMessage **entry);
 #if KRB5_KDB_API_VERSION < 8
 krb5_error_code ipadb_iterate(krb5_context kcontext,
   char *match_entry,
diff --git a/daemons/ipa-kdb/ipa_kdb_principals.c b/daemons/ipa-kdb/ipa_kdb_principals.c
index 3bd8fb8..82c8574 100644
--- a/daemons/ipa-kdb/ipa_kdb_principals.c
+++ b/daemons/ipa-kdb/ipa_kdb_principals.c
@@ -37,6 +37,17 @@
 "(objectclass=krbprincipal))" \
   "(krbprincipalname=%s))"
 
+#define PRINC_TGS_SEARCH_FILTER_EXTRA "(&(|(objectclass=krbprincipalaux)" \
+  "(objectclass=krbprincipal)" \
+  "(objectclass=ipakrbprincipal))" \
+"(|(ipakrbprincipalalias=%s)" \
+  "(krbprincipalname:caseIgnoreIA5Match:=%s))" \
+ "%s)"
+
+#define PRINC_SEARCH_FILTER_EXTRA "(&(|(objectclass=krbprincipalaux)" \
+  "(objectclass=krbprincipal))" \
+"(krbprincipalname=%s)" \
+"%s)"
 static char *std_principal_attrs[] = {
 "krbPrincipalName",
 "krbCanonicalName",
@@ -864,10 +875,12 @@ static krb5_error_code ipadb_parse_ldap_entry(krb5_context kcontext,
 return kerr;
 }
 
-static krb5_error_code ipadb_fetch_principals(struct ipadb_context *ipactx,
-  unsigned int flags,
-  char *principal,
-  LDAPMessage **result)
+krb5_error_code
+ipadb_fetch_principals_with_extra_filter(struct ipadb_context *ipactx,
+ unsigned int flags,
+ const char *principal,
+ const char *filter,
+ LDAPMessage **result)
 {
 krb5_error_code kerr;
 char *src_filter = NULL;
@@ -890,11 +903,21 @@ static krb5_error_code ipadb_fetch_principals(struct ipadb_context *ipactx,
 goto done;
 }
 
-if (flags & KRB5_KDB_FLAG_ALIAS_OK) {
-ret = asprintf(&src_filter, PRINC_TGS_SEARCH_FILTER,
-   esc_original_princ, esc_original_princ);
+if (filter == NULL) {
+if (flags & KRB5_KDB_FLAG_ALIAS_OK) {
+ret = asprintf(&src_filter, PRINC_TGS_SEARCH_FILTER,
+   esc_original_princ, esc_original_princ);
+} else {
+ret = asprintf(&src_filter, PRINC_SEARCH_FILTER, esc_original_princ);
+}
 } else {
-ret = asprintf(&src_filter, PRINC_SEARCH_FILTER, esc_original_princ);
+if (flags & KRB5_KDB_FLAG_ALIAS_OK) {
+ret = asprintf(&src_filter, PRINC_TGS_SEARCH_FILTER_EXTRA,
+   esc_original_princ, esc_original_princ, filter);
+} else {
+ 

[Freeipa-devel] [freeipa PR#644][synchronized] extdom: improve certificate request

[sumit-bose]

   URL: https://github.com/freeipa/freeipa/pull/644
Author: sumit-bose
 Title: #644: extdom: improve certificate request
Action: synchronized

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/644/head:pr644
git checkout pr644
From 90e000fbccf8be924520f7cb480ce115ed74c983 Mon Sep 17 00:00:00 2001
From: Sumit Bose 
Date: Fri, 17 Mar 2017 14:10:52 +0100
Subject: [PATCH 1/3] extdom: do reverse search for domain separator

To avoid issues which @-signs in the short user or group names it is
better to search for the domain separator starting at the end of the
fully-qualified name.
---
 daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c
index e629247..aa1ff10 100644
--- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c
+++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c
@@ -515,7 +515,7 @@ int pack_ber_user(struct ipa_extdom_ctx *ctx,
 char *short_user_name = NULL;
 
 short_user_name = strdup(user_name);
-if ((locat = strchr(short_user_name, SSSD_DOMAIN_SEPARATOR)) != NULL) {
+if ((locat = strrchr(short_user_name, SSSD_DOMAIN_SEPARATOR)) != NULL) {
 if (strcasecmp(locat+1, domain_name) == 0  ) {
 locat[0] = '\0';
 } else {
@@ -626,7 +626,7 @@ int pack_ber_group(enum response_types response_type,
 char *short_group_name = NULL;
 
 short_group_name = strdup(group_name);
-if ((locat = strchr(short_group_name, SSSD_DOMAIN_SEPARATOR)) != NULL) {
+if ((locat = strrchr(short_group_name, SSSD_DOMAIN_SEPARATOR)) != NULL) {
 if (strcasecmp(locat+1, domain_name) == 0  ) {
 locat[0] = '\0';
 } else {
@@ -901,7 +901,7 @@ static int handle_sid_or_cert_request(struct ipa_extdom_ctx *ctx,
 goto done;
 }
 
-sep = strchr(fq_name, SSSD_DOMAIN_SEPARATOR);
+sep = strrchr(fq_name, SSSD_DOMAIN_SEPARATOR);
 if (sep == NULL) {
 set_err_msg(req, "Failed to split fully qualified name");
 ret = LDAP_OPERATIONS_ERROR;

From ed8703fa99fd31997d6a0fcfcf10e5fe487a0f7a Mon Sep 17 00:00:00 2001
From: Sumit Bose 
Date: Fri, 17 Mar 2017 14:48:50 +0100
Subject: [PATCH 2/3] extdom: improve cert request

Certificates can be assigned to multiple user so the extdom plugin must
use sss_nss_getlistbycert() instead of sss_nss_getnamebycert() and
return a list of fully-qualified user names.

Due to issues on the SSSD side the current version of lookups by
certificates didn't work at all and the changes here won't break
existing clients.

Related to https://pagure.io/freeipa/issue/6646
---
 .../ipa-extdom-extop/ipa_extdom.h  |   3 +-
 .../ipa-extdom-extop/ipa_extdom_common.c   | 157 ++---
 server.m4  |   2 +-
 3 files changed, 143 insertions(+), 19 deletions(-)

diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h
index 34e2d3c..bc29f06 100644
--- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h
+++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h
@@ -95,7 +95,8 @@ enum response_types {
 RESP_USER,
 RESP_GROUP,
 RESP_USER_GROUPLIST,
-RESP_GROUP_MEMBERS
+RESP_GROUP_MEMBERS,
+RESP_NAME_LIST
 };
 
 struct extdom_req {
diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c
index aa1ff10..fe225fa 100644
--- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c
+++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c
@@ -698,6 +698,90 @@ int pack_ber_group(enum response_types response_type,
 return ret;
 }
 
+int pack_ber_name_list(struct extdom_req *req, char **fq_name_list,
+   struct berval **berval)
+{
+BerElement *ber = NULL;
+int ret;
+char *sep;
+size_t c;
+size_t len;
+size_t name_len;
+
+/* count the names */
+for (c = 0; fq_name_list[c] != NULL; c++);
+if (c == 0) {
+set_err_msg(req, "Empty name list");
+return LDAP_NO_SUCH_OBJECT;
+}
+
+ber = ber_alloc_t( LBER_USE_DER );
+if (ber == NULL) {
+set_err_msg(req, "BER alloc failed");
+return LDAP_OPERATIONS_ERROR;
+}
+
+
+ret = ber_printf(ber,"{e{", RESP_NAME_LIST);
+if (ret == -1) {
+set_err_msg(req, "BER start failed");
+ber_free(ber, 1);
+return LDAP_OPERATIONS_ERROR;
+}
+
+for (c = 0; fq_name_list[c] != NULL; c++) {
+len = strlen(fq_name_list[c]);
+if (len < 3) {
+set_err_msg(req, "Fully qualified na

[Freeipa-devel] [freeipa PR#575][synchronized] IPA certauth plugin

[sumit-bose]

   URL: https://github.com/freeipa/freeipa/pull/575
Author: sumit-bose
 Title: #575: IPA certauth plugin
Action: synchronized

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/575/head:pr575
git checkout pr575
From e84f70cceec2421968977e4012bbf747e060b5f4 Mon Sep 17 00:00:00 2001
From: Sumit Bose 
Date: Wed, 15 Feb 2017 12:09:20 +0100
Subject: [PATCH 1/3] ipa-kdb: add ipadb_fetch_principals_with_extra_filter()

Additionally make ipadb_find_principal public.

Related to https://pagure.io/freeipa/issue/4905
---
 daemons/ipa-kdb/ipa_kdb.h| 11 +++
 daemons/ipa-kdb/ipa_kdb_principals.c | 58 
 2 files changed, 56 insertions(+), 13 deletions(-)

diff --git a/daemons/ipa-kdb/ipa_kdb.h b/daemons/ipa-kdb/ipa_kdb.h
index 8a3f7d3..72f2675 100644
--- a/daemons/ipa-kdb/ipa_kdb.h
+++ b/daemons/ipa-kdb/ipa_kdb.h
@@ -198,6 +198,17 @@ krb5_error_code ipadb_put_principal(krb5_context kcontext,
 char **db_args);
 krb5_error_code ipadb_delete_principal(krb5_context kcontext,
krb5_const_principal search_for);
+krb5_error_code
+ipadb_fetch_principals_with_extra_filter(struct ipadb_context *ipactx,
+ unsigned int flags,
+ const char *principal,
+ const char *filter,
+ LDAPMessage **result);
+krb5_error_code ipadb_find_principal(krb5_context kcontext,
+ unsigned int flags,
+ LDAPMessage *res,
+ char **principal,
+ LDAPMessage **entry);
 #if KRB5_KDB_API_VERSION < 8
 krb5_error_code ipadb_iterate(krb5_context kcontext,
   char *match_entry,
diff --git a/daemons/ipa-kdb/ipa_kdb_principals.c b/daemons/ipa-kdb/ipa_kdb_principals.c
index 3bd8fb8..82c8574 100644
--- a/daemons/ipa-kdb/ipa_kdb_principals.c
+++ b/daemons/ipa-kdb/ipa_kdb_principals.c
@@ -37,6 +37,17 @@
 "(objectclass=krbprincipal))" \
   "(krbprincipalname=%s))"
 
+#define PRINC_TGS_SEARCH_FILTER_EXTRA "(&(|(objectclass=krbprincipalaux)" \
+  "(objectclass=krbprincipal)" \
+  "(objectclass=ipakrbprincipal))" \
+"(|(ipakrbprincipalalias=%s)" \
+  "(krbprincipalname:caseIgnoreIA5Match:=%s))" \
+ "%s)"
+
+#define PRINC_SEARCH_FILTER_EXTRA "(&(|(objectclass=krbprincipalaux)" \
+  "(objectclass=krbprincipal))" \
+"(krbprincipalname=%s)" \
+"%s)"
 static char *std_principal_attrs[] = {
 "krbPrincipalName",
 "krbCanonicalName",
@@ -864,10 +875,12 @@ static krb5_error_code ipadb_parse_ldap_entry(krb5_context kcontext,
 return kerr;
 }
 
-static krb5_error_code ipadb_fetch_principals(struct ipadb_context *ipactx,
-  unsigned int flags,
-  char *principal,
-  LDAPMessage **result)
+krb5_error_code
+ipadb_fetch_principals_with_extra_filter(struct ipadb_context *ipactx,
+ unsigned int flags,
+ const char *principal,
+ const char *filter,
+ LDAPMessage **result)
 {
 krb5_error_code kerr;
 char *src_filter = NULL;
@@ -890,11 +903,21 @@ static krb5_error_code ipadb_fetch_principals(struct ipadb_context *ipactx,
 goto done;
 }
 
-if (flags & KRB5_KDB_FLAG_ALIAS_OK) {
-ret = asprintf(&src_filter, PRINC_TGS_SEARCH_FILTER,
-   esc_original_princ, esc_original_princ);
+if (filter == NULL) {
+if (flags & KRB5_KDB_FLAG_ALIAS_OK) {
+ret = asprintf(&src_filter, PRINC_TGS_SEARCH_FILTER,
+   esc_original_princ, esc_original_princ);
+} else {
+ret = asprintf(&src_filter, PRINC_SEARCH_FILTER, esc_original_princ);
+}
 } else {
-ret = asprintf(&src_filter, PRINC_SEARCH_FILTER, esc_original_princ);
+if (flags & KRB5_KDB_FLAG_ALIAS_OK) {
+ret = asprintf(&src_filter, PRINC_TGS_SEARCH_FILTER_EXTRA,
+   esc_original_princ, esc_original_princ, filter);
+} else {
+ 

[Freeipa-devel] [freeipa PR#575][synchronized] IPA certauth plugin

[sumit-bose]

   URL: https://github.com/freeipa/freeipa/pull/575
Author: sumit-bose
 Title: #575: IPA certauth plugin
Action: synchronized

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/575/head:pr575
git checkout pr575
From e84f70cceec2421968977e4012bbf747e060b5f4 Mon Sep 17 00:00:00 2001
From: Sumit Bose 
Date: Wed, 15 Feb 2017 12:09:20 +0100
Subject: [PATCH 1/2] ipa-kdb: add ipadb_fetch_principals_with_extra_filter()

Additionally make ipadb_find_principal public.

Related to https://pagure.io/freeipa/issue/4905
---
 daemons/ipa-kdb/ipa_kdb.h| 11 +++
 daemons/ipa-kdb/ipa_kdb_principals.c | 58 
 2 files changed, 56 insertions(+), 13 deletions(-)

diff --git a/daemons/ipa-kdb/ipa_kdb.h b/daemons/ipa-kdb/ipa_kdb.h
index 8a3f7d3..72f2675 100644
--- a/daemons/ipa-kdb/ipa_kdb.h
+++ b/daemons/ipa-kdb/ipa_kdb.h
@@ -198,6 +198,17 @@ krb5_error_code ipadb_put_principal(krb5_context kcontext,
 char **db_args);
 krb5_error_code ipadb_delete_principal(krb5_context kcontext,
krb5_const_principal search_for);
+krb5_error_code
+ipadb_fetch_principals_with_extra_filter(struct ipadb_context *ipactx,
+ unsigned int flags,
+ const char *principal,
+ const char *filter,
+ LDAPMessage **result);
+krb5_error_code ipadb_find_principal(krb5_context kcontext,
+ unsigned int flags,
+ LDAPMessage *res,
+ char **principal,
+ LDAPMessage **entry);
 #if KRB5_KDB_API_VERSION < 8
 krb5_error_code ipadb_iterate(krb5_context kcontext,
   char *match_entry,
diff --git a/daemons/ipa-kdb/ipa_kdb_principals.c b/daemons/ipa-kdb/ipa_kdb_principals.c
index 3bd8fb8..82c8574 100644
--- a/daemons/ipa-kdb/ipa_kdb_principals.c
+++ b/daemons/ipa-kdb/ipa_kdb_principals.c
@@ -37,6 +37,17 @@
 "(objectclass=krbprincipal))" \
   "(krbprincipalname=%s))"
 
+#define PRINC_TGS_SEARCH_FILTER_EXTRA "(&(|(objectclass=krbprincipalaux)" \
+  "(objectclass=krbprincipal)" \
+  "(objectclass=ipakrbprincipal))" \
+"(|(ipakrbprincipalalias=%s)" \
+  "(krbprincipalname:caseIgnoreIA5Match:=%s))" \
+ "%s)"
+
+#define PRINC_SEARCH_FILTER_EXTRA "(&(|(objectclass=krbprincipalaux)" \
+  "(objectclass=krbprincipal))" \
+"(krbprincipalname=%s)" \
+"%s)"
 static char *std_principal_attrs[] = {
 "krbPrincipalName",
 "krbCanonicalName",
@@ -864,10 +875,12 @@ static krb5_error_code ipadb_parse_ldap_entry(krb5_context kcontext,
 return kerr;
 }
 
-static krb5_error_code ipadb_fetch_principals(struct ipadb_context *ipactx,
-  unsigned int flags,
-  char *principal,
-  LDAPMessage **result)
+krb5_error_code
+ipadb_fetch_principals_with_extra_filter(struct ipadb_context *ipactx,
+ unsigned int flags,
+ const char *principal,
+ const char *filter,
+ LDAPMessage **result)
 {
 krb5_error_code kerr;
 char *src_filter = NULL;
@@ -890,11 +903,21 @@ static krb5_error_code ipadb_fetch_principals(struct ipadb_context *ipactx,
 goto done;
 }
 
-if (flags & KRB5_KDB_FLAG_ALIAS_OK) {
-ret = asprintf(&src_filter, PRINC_TGS_SEARCH_FILTER,
-   esc_original_princ, esc_original_princ);
+if (filter == NULL) {
+if (flags & KRB5_KDB_FLAG_ALIAS_OK) {
+ret = asprintf(&src_filter, PRINC_TGS_SEARCH_FILTER,
+   esc_original_princ, esc_original_princ);
+} else {
+ret = asprintf(&src_filter, PRINC_SEARCH_FILTER, esc_original_princ);
+}
 } else {
-ret = asprintf(&src_filter, PRINC_SEARCH_FILTER, esc_original_princ);
+if (flags & KRB5_KDB_FLAG_ALIAS_OK) {
+ret = asprintf(&src_filter, PRINC_TGS_SEARCH_FILTER_EXTRA,
+   esc_original_princ, esc_original_princ, filter);
+} else {
+ 

[Freeipa-devel] [freeipa PR#644][opened] extdom: improve certificate request

[sumit-bose]

   URL: https://github.com/freeipa/freeipa/pull/644
Author: sumit-bose
 Title: #644: extdom: improve certificate request
Action: opened

PR body:
"""
Certificates can be assigned to multiple user so the extdom plugin must use
sss_nss_getlistbycert() instead of sss_nss_getnamebycert() and return a
list of fully-qualified user names.

Due to issues on the SSSD side the current version of lookups by
certificates didn't work at all and the changes here won't break existing
clients.

Related to https://pagure.io/freeipa/issue/6646

Since I used the revers lookup for the domain separator in patch I added a
second patch which does this where needed in the reminder of the code as well
to be consistent. Allthough using @-signs in short names is not common practice
it might happen as can be see in https://pagure.io/SSSD/sssd/issue/3219.

The sss_nss_getlistbycert() call is added to SSSD in
https://github.com/SSSD/sssd/pull/207.
"""

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/644/head:pr644
git checkout pr644
From ae483eff6cd3db7309e60090334c17aac7c88947 Mon Sep 17 00:00:00 2001
From: Sumit Bose 
Date: Fri, 17 Mar 2017 14:10:52 +0100
Subject: [PATCH 1/2] extdom: do reverse search for domain separator

To avoid issues which @-signs in the short user or group names it is
better to search for the domain separator starting at the end of the
fully-qualified name.
---
 daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c
index e629247..aa1ff10 100644
--- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c
+++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c
@@ -515,7 +515,7 @@ int pack_ber_user(struct ipa_extdom_ctx *ctx,
 char *short_user_name = NULL;
 
 short_user_name = strdup(user_name);
-if ((locat = strchr(short_user_name, SSSD_DOMAIN_SEPARATOR)) != NULL) {
+if ((locat = strrchr(short_user_name, SSSD_DOMAIN_SEPARATOR)) != NULL) {
 if (strcasecmp(locat+1, domain_name) == 0  ) {
 locat[0] = '\0';
 } else {
@@ -626,7 +626,7 @@ int pack_ber_group(enum response_types response_type,
 char *short_group_name = NULL;
 
 short_group_name = strdup(group_name);
-if ((locat = strchr(short_group_name, SSSD_DOMAIN_SEPARATOR)) != NULL) {
+if ((locat = strrchr(short_group_name, SSSD_DOMAIN_SEPARATOR)) != NULL) {
 if (strcasecmp(locat+1, domain_name) == 0  ) {
 locat[0] = '\0';
 } else {
@@ -901,7 +901,7 @@ static int handle_sid_or_cert_request(struct ipa_extdom_ctx *ctx,
 goto done;
 }
 
-sep = strchr(fq_name, SSSD_DOMAIN_SEPARATOR);
+sep = strrchr(fq_name, SSSD_DOMAIN_SEPARATOR);
 if (sep == NULL) {
 set_err_msg(req, "Failed to split fully qualified name");
 ret = LDAP_OPERATIONS_ERROR;

From 7d0c6a9358602331721213a921ccf39e112245f3 Mon Sep 17 00:00:00 2001
From: Sumit Bose 
Date: Fri, 17 Mar 2017 14:48:50 +0100
Subject: [PATCH 2/2] extdom: improve cert request

Certificates can be assigned to multiple user so the extdom plugin must
use sss_nss_getlistbycert() instead of sss_nss_getnamebycert() and
return a list of fully-qualified user names.

Due to issues on the SSSD side the current version of lookups by
certificates didn't work at all and the changes here won't break
existing clients.

Related to https://pagure.io/freeipa/issue/6646
---
 .../ipa-extdom-extop/ipa_extdom.h  |   3 +-
 .../ipa-extdom-extop/ipa_extdom_common.c   | 157 ++---
 server.m4  |   2 +-
 3 files changed, 143 insertions(+), 19 deletions(-)

diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h
index 34e2d3c..bc29f06 100644
--- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h
+++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h
@@ -95,7 +95,8 @@ enum response_types {
 RESP_USER,
 RESP_GROUP,
 RESP_USER_GROUPLIST,
-RESP_GROUP_MEMBERS
+RESP_GROUP_MEMBERS,
+RESP_NAME_LIST
 };
 
 struct extdom_req {
diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c
index aa1ff10..fe225fa 100644
--- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c
+++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c
@@ -698,6 +698,90 @@ int pack_ber_group(enum response_types response_type,
 return ret;
 }
 
+int pack_ber_name_list(struct extdom_req *req, char **fq_name_list,
+   struct berval **berval)
+{
+BerElement *ber = NULL;
+ 

[Freeipa-devel] [freeipa PR#575][comment] IPA certauth plugin

[sumit-bose]

  URL: https://github.com/freeipa/freeipa/pull/575
Title: #575: IPA certauth plugin

sumit-bose commented:
"""
I updated the code to reflect the latest changes in the interface from 
https://github.com/krb5/krb5/pull/610.
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/575#issuecomment-286373480
-- 
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#575][synchronized] IPA certauth plugin

[sumit-bose]

   URL: https://github.com/freeipa/freeipa/pull/575
Author: sumit-bose
 Title: #575: IPA certauth plugin
Action: synchronized

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/575/head:pr575
git checkout pr575
From 27bcf2baab5129ce3f49e1ff74d9489753211c93 Mon Sep 17 00:00:00 2001
From: Sumit Bose 
Date: Wed, 15 Feb 2017 12:09:20 +0100
Subject: [PATCH 1/2] ipa-kdb: add ipadb_fetch_principals_with_extra_filter()

Additionally make ipadb_find_principal public.

Related to https://pagure.io/freeipa/issue/4905
---
 daemons/ipa-kdb/ipa_kdb.h| 11 +++
 daemons/ipa-kdb/ipa_kdb_principals.c | 58 
 2 files changed, 56 insertions(+), 13 deletions(-)

diff --git a/daemons/ipa-kdb/ipa_kdb.h b/daemons/ipa-kdb/ipa_kdb.h
index 8a3f7d3..72f2675 100644
--- a/daemons/ipa-kdb/ipa_kdb.h
+++ b/daemons/ipa-kdb/ipa_kdb.h
@@ -198,6 +198,17 @@ krb5_error_code ipadb_put_principal(krb5_context kcontext,
 char **db_args);
 krb5_error_code ipadb_delete_principal(krb5_context kcontext,
krb5_const_principal search_for);
+krb5_error_code
+ipadb_fetch_principals_with_extra_filter(struct ipadb_context *ipactx,
+ unsigned int flags,
+ const char *principal,
+ const char *filter,
+ LDAPMessage **result);
+krb5_error_code ipadb_find_principal(krb5_context kcontext,
+ unsigned int flags,
+ LDAPMessage *res,
+ char **principal,
+ LDAPMessage **entry);
 #if KRB5_KDB_API_VERSION < 8
 krb5_error_code ipadb_iterate(krb5_context kcontext,
   char *match_entry,
diff --git a/daemons/ipa-kdb/ipa_kdb_principals.c b/daemons/ipa-kdb/ipa_kdb_principals.c
index 3bd8fb8..82c8574 100644
--- a/daemons/ipa-kdb/ipa_kdb_principals.c
+++ b/daemons/ipa-kdb/ipa_kdb_principals.c
@@ -37,6 +37,17 @@
 "(objectclass=krbprincipal))" \
   "(krbprincipalname=%s))"
 
+#define PRINC_TGS_SEARCH_FILTER_EXTRA "(&(|(objectclass=krbprincipalaux)" \
+  "(objectclass=krbprincipal)" \
+  "(objectclass=ipakrbprincipal))" \
+"(|(ipakrbprincipalalias=%s)" \
+  "(krbprincipalname:caseIgnoreIA5Match:=%s))" \
+ "%s)"
+
+#define PRINC_SEARCH_FILTER_EXTRA "(&(|(objectclass=krbprincipalaux)" \
+  "(objectclass=krbprincipal))" \
+"(krbprincipalname=%s)" \
+"%s)"
 static char *std_principal_attrs[] = {
 "krbPrincipalName",
 "krbCanonicalName",
@@ -864,10 +875,12 @@ static krb5_error_code ipadb_parse_ldap_entry(krb5_context kcontext,
 return kerr;
 }
 
-static krb5_error_code ipadb_fetch_principals(struct ipadb_context *ipactx,
-  unsigned int flags,
-  char *principal,
-  LDAPMessage **result)
+krb5_error_code
+ipadb_fetch_principals_with_extra_filter(struct ipadb_context *ipactx,
+ unsigned int flags,
+ const char *principal,
+ const char *filter,
+ LDAPMessage **result)
 {
 krb5_error_code kerr;
 char *src_filter = NULL;
@@ -890,11 +903,21 @@ static krb5_error_code ipadb_fetch_principals(struct ipadb_context *ipactx,
 goto done;
 }
 
-if (flags & KRB5_KDB_FLAG_ALIAS_OK) {
-ret = asprintf(&src_filter, PRINC_TGS_SEARCH_FILTER,
-   esc_original_princ, esc_original_princ);
+if (filter == NULL) {
+if (flags & KRB5_KDB_FLAG_ALIAS_OK) {
+ret = asprintf(&src_filter, PRINC_TGS_SEARCH_FILTER,
+   esc_original_princ, esc_original_princ);
+} else {
+ret = asprintf(&src_filter, PRINC_SEARCH_FILTER, esc_original_princ);
+}
 } else {
-ret = asprintf(&src_filter, PRINC_SEARCH_FILTER, esc_original_princ);
+if (flags & KRB5_KDB_FLAG_ALIAS_OK) {
+ret = asprintf(&src_filter, PRINC_TGS_SEARCH_FILTER_EXTRA,
+   esc_original_princ, esc_original_princ, filter);
+} else {
+ 

[Freeipa-devel] [freeipa PR#575][comment] IPA certauth plugin

[sumit-bose]

  URL: https://github.com/freeipa/freeipa/pull/575
Title: #575: IPA certauth plugin

sumit-bose commented:
"""
This patch depends on https://github.com/SSSD/sssd/pull/192 (SSSD's certmap 
library) and https://github.com/krb5/krb5/pull/610 (MIT Kerberos certauth 
plugin support)
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/575#issuecomment-286137210
-- 
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#575][opened] IPA certauth plugin

[sumit-bose]

   URL: https://github.com/freeipa/freeipa/pull/575
Author: sumit-bose
 Title: #575: IPA certauth plugin
Action: opened

PR body:
"""
This patch add a certauth plugin which allows the IPA server to support
PKINIT for certificates which do not include a special SAN extension which
contains a Kerberos principal but allow other mappings with the help of
SSSD's certmap library.

Related to https://pagure.io/freeipa/issue/4905
"""

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/575/head:pr575
git checkout pr575
From 32482b96b07b4076bb14f9e52c7c493af3d7b1aa Mon Sep 17 00:00:00 2001
From: Sumit Bose 
Date: Wed, 15 Feb 2017 12:09:20 +0100
Subject: [PATCH 1/2] ipa-kdb: add ipadb_fetch_principals_with_extra_filter()

Additionally make ipadb_find_principal public.

Related to https://pagure.io/freeipa/issue/4905
---
 daemons/ipa-kdb/ipa_kdb.h| 11 +++
 daemons/ipa-kdb/ipa_kdb_principals.c | 58 
 2 files changed, 56 insertions(+), 13 deletions(-)

diff --git a/daemons/ipa-kdb/ipa_kdb.h b/daemons/ipa-kdb/ipa_kdb.h
index 8a3f7d3..72f2675 100644
--- a/daemons/ipa-kdb/ipa_kdb.h
+++ b/daemons/ipa-kdb/ipa_kdb.h
@@ -198,6 +198,17 @@ krb5_error_code ipadb_put_principal(krb5_context kcontext,
 char **db_args);
 krb5_error_code ipadb_delete_principal(krb5_context kcontext,
krb5_const_principal search_for);
+krb5_error_code
+ipadb_fetch_principals_with_extra_filter(struct ipadb_context *ipactx,
+ unsigned int flags,
+ const char *principal,
+ const char *filter,
+ LDAPMessage **result);
+krb5_error_code ipadb_find_principal(krb5_context kcontext,
+ unsigned int flags,
+ LDAPMessage *res,
+ char **principal,
+ LDAPMessage **entry);
 #if KRB5_KDB_API_VERSION < 8
 krb5_error_code ipadb_iterate(krb5_context kcontext,
   char *match_entry,
diff --git a/daemons/ipa-kdb/ipa_kdb_principals.c b/daemons/ipa-kdb/ipa_kdb_principals.c
index 3bd8fb8..82c8574 100644
--- a/daemons/ipa-kdb/ipa_kdb_principals.c
+++ b/daemons/ipa-kdb/ipa_kdb_principals.c
@@ -37,6 +37,17 @@
 "(objectclass=krbprincipal))" \
   "(krbprincipalname=%s))"
 
+#define PRINC_TGS_SEARCH_FILTER_EXTRA "(&(|(objectclass=krbprincipalaux)" \
+  "(objectclass=krbprincipal)" \
+  "(objectclass=ipakrbprincipal))" \
+"(|(ipakrbprincipalalias=%s)" \
+  "(krbprincipalname:caseIgnoreIA5Match:=%s))" \
+ "%s)"
+
+#define PRINC_SEARCH_FILTER_EXTRA "(&(|(objectclass=krbprincipalaux)" \
+  "(objectclass=krbprincipal))" \
+"(krbprincipalname=%s)" \
+"%s)"
 static char *std_principal_attrs[] = {
 "krbPrincipalName",
 "krbCanonicalName",
@@ -864,10 +875,12 @@ static krb5_error_code ipadb_parse_ldap_entry(krb5_context kcontext,
 return kerr;
 }
 
-static krb5_error_code ipadb_fetch_principals(struct ipadb_context *ipactx,
-  unsigned int flags,
-  char *principal,
-  LDAPMessage **result)
+krb5_error_code
+ipadb_fetch_principals_with_extra_filter(struct ipadb_context *ipactx,
+ unsigned int flags,
+ const char *principal,
+ const char *filter,
+ LDAPMessage **result)
 {
 krb5_error_code kerr;
 char *src_filter = NULL;
@@ -890,11 +903,21 @@ static krb5_error_code ipadb_fetch_principals(struct ipadb_context *ipactx,
 goto done;
 }
 
-if (flags & KRB5_KDB_FLAG_ALIAS_OK) {
-ret = asprintf(&src_filter, PRINC_TGS_SEARCH_FILTER,
-   esc_original_princ, esc_original_princ);
+if (filter == NULL) {
+if (flags & KRB5_KDB_FLAG_ALIAS_OK) {
+ret = asprintf(&src_filter, PRINC_TGS_SEARCH_FILTER,
+   esc_original_princ, esc_original_princ);
+} else {
+ret = asprintf(&src_filter, PRINC_SEARCH_FILTER, esc_o

Re: [Freeipa-devel] [RFC] Smartcard authentication with PKINIT and local authentication

[Sumit Bose]

On Fri, Mar 10, 2017 at 01:39:27PM +0200, Alexander Bokovoy wrote:
> On pe, 10 maalis 2017, Sumit Bose wrote:
> > On Fri, Mar 10, 2017 at 11:58:25AM +0200, Alexander Bokovoy wrote:
> > > On pe, 10 maalis 2017, Sumit Bose wrote:
> > > > Hi,
> > > >
> > > > with the recent addition of PKINIT support there is now a second method
> > > > available to Smartcard authentication besides local authentication.
> > > >
> > > > I was about to add some sssd.conf option which can control the fallback
> > > > to local authentication if PKINIT fails. Currently there is only a
> > > > fallback to local authentication if the backend is offline or if PKINIT
> > > > is not available because either the client or the server side do not
> > > > support it.
> > > >
> > > > It came to my mind that it might be more flexible to add the fallback
> > > > scheme to the certificate matching rules discussed earlier on this list.
> > > > With this it would be possible e.g. to require PKINIT for a set of
> > > > certificates and allow local authentication to a different set.
> > > >
> > > > Do you think this would make sense or is it sufficient an option in
> > > > sssd.conf which covers all certificates?
> > > Interesting idea. If we were to define it as a part of a certificate
> > > matching rule, would we be able to deny using a matching certificate for
> > > local authentication in case only PKINIT is allowed?
> > 
> > Yes, SSSD first checks in the backend if PKINIT is available and tries
> > it. If this fails the backend can tell the frontend to try local
> > authentication or fail.
> Ok. I'd prefer to have this possibility then -- a certificate matching
> rule including a flag to require PKINIT.

I think it should be a bit more than a single flag.

- PKINIT and newer fall back to local authentication
- PKINIT and fall back to local authentication when offline or PKINIT is
  not available
- PKINIT and fall back in all errors 
- no PKINIT only local authentication.

bye,
Sumit

> 
> -- 
> / 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] [RFC] Smartcard authentication with PKINIT and local authentication

[Sumit Bose]

On Fri, Mar 10, 2017 at 11:58:25AM +0200, Alexander Bokovoy wrote:
> On pe, 10 maalis 2017, Sumit Bose wrote:
> > Hi,
> > 
> > with the recent addition of PKINIT support there is now a second method
> > available to Smartcard authentication besides local authentication.
> > 
> > I was about to add some sssd.conf option which can control the fallback
> > to local authentication if PKINIT fails. Currently there is only a
> > fallback to local authentication if the backend is offline or if PKINIT
> > is not available because either the client or the server side do not
> > support it.
> > 
> > It came to my mind that it might be more flexible to add the fallback
> > scheme to the certificate matching rules discussed earlier on this list.
> > With this it would be possible e.g. to require PKINIT for a set of
> > certificates and allow local authentication to a different set.
> > 
> > Do you think this would make sense or is it sufficient an option in
> > sssd.conf which covers all certificates?
> Interesting idea. If we were to define it as a part of a certificate
> matching rule, would we be able to deny using a matching certificate for
> local authentication in case only PKINIT is allowed?

Yes, SSSD first checks in the backend if PKINIT is available and tries
it. If this fails the backend can tell the frontend to try local
authentication or fail.

bye,
Sumit

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

[Freeipa-devel] [RFC] Smartcard authentication with PKINIT and local authentication

[Sumit Bose]

Hi,

with the recent addition of PKINIT support there is now a second method
available to Smartcard authentication besides local authentication.

I was about to add some sssd.conf option which can control the fallback
to local authentication if PKINIT fails. Currently there is only a
fallback to local authentication if the backend is offline or if PKINIT
is not available because either the client or the server side do not
support it.

It came to my mind that it might be more flexible to add the fallback
scheme to the certificate matching rules discussed earlier on this list.
With this it would be possible e.g. to require PKINIT for a set of
certificates and allow local authentication to a different set.

Do you think this would make sense or is it sufficient an option in
sssd.conf which covers all certificates?

bye,
Sumit

-- 
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#516][comment] IdM Server: list all Employees with matching Smart Card

[sumit-bose]

  URL: https://github.com/freeipa/freeipa/pull/516
Title: #516: IdM Server: list all Employees with matching Smart Card

sumit-bose commented:
"""
I agree, it would be good if the help text can mention that cached data is used 
and maybe even mention the sss_cache utility to invalidate the entry. If the 
doc team can add this to the official documentation it would be even better.
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/516#issuecomment-284976922
-- 
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#516][comment] IdM Server: list all Employees with matching Smart Card

[sumit-bose]

  URL: https://github.com/freeipa/freeipa/pull/516
Title: #516: IdM Server: list all Employees with matching Smart Card

sumit-bose commented:
"""
Yes, a hint aka user name will be used during authentication. But this PR here 
is about to get an idea which user is allowed to authenticate based on the 
current certificate mapping configuration. Since the certificate mapping 
configuration requires remote domains to be added explicitly to admin can 
control which domains are included in the search.
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/516#issuecomment-283440367
-- 
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#398][comment] Support for Certificate Identity Mapping

[sumit-bose]

  URL: https://github.com/freeipa/freeipa/pull/398
Title: #398: Support for Certificate Identity Mapping

sumit-bose commented:
"""
Ok, sorry for the noise, I tested on a fresh install again and now it is 
working as expected. I guess I shouldn't have tried to update from an older 
version of your patch to a newer one.
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/398#issuecomment-281939524
-- 
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#398][comment] Support for Certificate Identity Mapping

[sumit-bose]

  URL: https://github.com/freeipa/freeipa/pull/398
Title: #398: Support for Certificate Identity Mapping

sumit-bose commented:
"""
It looks like the ACis on the latest version do not allow hosts to access the 
rules. When I do 'kinit -k' on the IPA server or a client and call

ldapsearch -H ldap://ipa-server.ipa.devel 
'(&(objectClass=ipaCertMapRule)(ipaEnabledFlag=TRUE))' -Y GSSAPI

I do not get any results. When I call 'kinit admin' and use the same ldapsearch 
I get my rule returned. Can you confirm this or is my test system broken?
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/398#issuecomment-281788601
-- 
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 - new API to retrieve matching users

[Sumit Bose]

On Wed, Feb 22, 2017 at 10:02:24AM +0100, Petr Vobornik wrote:
> On 02/22/2017 12:43 AM, Fraser Tweedale wrote:
> > On Tue, Feb 21, 2017 at 06:12:23PM +0100, Petr Vobornik wrote:
> > > On 02/21/2017 05:15 PM, Florence Blanc-Renaud wrote:
> > > > Hi,
> > > > 
> > > > related to the Certificate Identity Mapping feature, a new CLI will be
> > > > needed to find all the users matching a given certificate.
> > > > 
> > > > I propose to provide this as:
> > > > 
> > > > ipa certmaptest --certificate 
> > > > ---
> > > > 2 users matched
> > > > ---
> > > >   Matched user login: test1
> > > >   Matched user login: test2
> > > > 
> > > > Number of entries returned 2
> > > > 
> > > > 
> > > > 
> > > > Please provide any comments, suggestions on the CLI or the output.
> > > > Thanks,
> > > > Flo.
> > > > 
> > > 
> > > Thanks Flo for sharing it.
> > > 
> > > I don't like the command name. It is not self explanatory. It says it is
> > > testing something, it is not clear what and the actual result is users who
> > > match the map configuration or have the cert in their user's entry.
> > > 
> > > Better would be:
> > >   $ ipa certmap-match --certificate
> > > 
> > How about `ipa certmap-find-user ...'?  Doesn't get more obvious
> > than that, IMO.
> 
> Was thinking about that as well but I think that the command might, in
> future, return also something else then user object, e.g. ID override.

No, since the ID override is related to a user the user should be
returned not the override.

bye,
Sumit

> 
> > 
> > > 
> > > Pasting user story to give context if somebody is not familiar with it:
> > > """
> > > As a Security Officer, I want to present IdM Server with an Employee Smart
> > > Card certificate and list all Employees with a matching role account, so
> > > that I can validate the configuration is correct
> > > 
> > > Note: In FreeIPA 4.4, user-find --certificate can already find users 
> > > linked
> > > with a certificate blob
> > > 
> > > Acceptance criteria:
> > > * I can perform the administrative task both via IdM Web UI and CLI
> > > * When asking IdM for the information, I should always receive the same 
> > > list
> > > that would be matched in client authentication workflows (by SSSD)
> > > * The list of users should include both users linked via standard
> > > certificate blob and other generically mapped users
> > > """
> > > --
> > > Petr Vobornik
> > > 
> > > Associate Manager, Engineering, Identity Management
> > > Red Hat, Inc.
> > > 
> > > --
> > > 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
> 
> 
> -- 
> Petr Vobornik
> 
> Associate Manager, Engineering, Identity Management
> Red Hat, Inc.
> 
> -- 
> 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

-- 
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#410][comment] ipa-kdb: support KDB DAL version 6.1

[sumit-bose]

  URL: https://github.com/freeipa/freeipa/pull/410
Title: #410: ipa-kdb: support KDB DAL version 6.1

sumit-bose commented:
"""
Are there any plans how to handle 6.0? Should configure at least show a warning 
if KRB5_KDB_DAL_MAJOR_VERSION == 6 but no free e_data callback was found?

Should the .min_ver in the kdb_function_table be set to '1' if there is a free 
e_data callback?
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/410#issuecomment-274743181
-- 
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

[Sumit Bose]

On Mon, Jan 09, 2017 at 08:46:22AM +0100, Jan Cholasta wrote:
> On 6.1.2017 10:30, Sumit Bose wrote:
> > On Fri, Jan 06, 2017 at 08:50:14AM +0100, Jan Cholasta wrote:
> > > On 5.1.2017 10:39, Sumit Bose wrote:
> > > > On Mon, Jan 02, 2017 at 09:18:47AM +0100, Jan Cholasta wrote:
> > > > > On 18.10.2016 07:34, Jan Cholasta wrote:
> > > > > > 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.
> > > > > > 
> > > > > 
> > > > > Bump. Sumit, what is your opinion on this?
> > > > 
> > > > I'm fine with an optional(?) priority as well. Since priorities are
> > > > already used in the pwpolicies this should be already known to the
> > > > experienced admin. I guess we just have stick with "A lower value
> > &

Re: [Freeipa-devel] Certificate Identity Mapping

[Sumit Bose]

On Wed, Jan 18, 2017 at 09:59:49AM +0100, David Kupka wrote:
> Hello everyone!
> I would like to bring your attention to just published PRs implementing
> FreeIPA part of Certificate Identity Mapping feature [0]:
> 
> - certmap plugin [1] by Flo
> - WebUI for certmap plugin [3] by Pavel
> - tests for certmap plugin [2] by me
> 
> Also please think about names of the commands, parameters, entries and
> attributes. We've figured them somehow but if you have any suggestion that
> would improve the understanding please share.

Hi,

thank you for the patches.

Just a general comment about an open question in the design. Honza
suggested to use a priority instead of an issuer name to make sure that
only specific rules are used for a given issuer. The latest mail in the
thread about it is
https://www.redhat.com/archives/freeipa-devel/2017-January/msg00229.html.

Do you have any opinions here?

I think it won't change much in your patches but we should find an
agreement before e.g. the OID are registered.

bye,
Sumit

> 
> Please review them thoroughly, thanks!
> 
> [0] https://www.freeipa.org/page/V4/Certificate_Identity_Mapping
> [1] https://github.com/freeipa/freeipa/pull/398
> [2] https://github.com/freeipa/freeipa/pull/399
> [3] https://github.com/freeipa/freeipa/pull/400
> 
> -- 
> David Kupka
> 
> -- 
> 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

-- 
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 Fri, Jan 06, 2017 at 08:40:31AM +0100, Jan Cholasta wrote:
> On 5.1.2017 13:15, Sumit Bose wrote:
> > On Mon, Jan 02, 2017 at 08:06:04AM +0100, Jan Cholasta wrote:
> > > On 19.12.2016 12:13, Sumit Bose wrote:
> > > > 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 authent

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

[Sumit Bose]

On Fri, Jan 06, 2017 at 08:50:14AM +0100, Jan Cholasta wrote:
> On 5.1.2017 10:39, Sumit Bose wrote:
> > On Mon, Jan 02, 2017 at 09:18:47AM +0100, Jan Cholasta wrote:
> > > On 18.10.2016 07:34, Jan Cholasta wrote:
> > > > 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.
> > > > 
> > > 
> > > Bump. Sumit, what is your opinion on this?
> > 
> > I'm fine with an optional(?) priority as well. Since priorities are
> > already used in the pwpolicies this should be already known to the
> > experienced admin. I guess we just have stick with "A lower value
> > indicates a higher priority" to not confuse users. That's why I think
> > that the priority should be optional here and a missing value indicates
> > the lowest priority (default rules).
> 
> In pwpolicy and sudorule, the priority is required and has to be unique.
> Maybe we should do this for certificate mapping rules as well?

I think there is no requirement that only a single rule should match
hence I think the priority here must not be unique.

> 
> > 
> > Are you thinking of using the CoS scheme here as well would a priority
> > attribute be sufficient because we do not want to reference internal
> > objects in the mapping rules?
> 
> I'm not sure how CoS would be helpful here, I think a simple interger
> attribute would be perfectly sufficient.

I agree.

bye,
Sumit

> 
> > 
> > bye,
> > Sumit
> > 
> > > 
> > > --
> > > Jan Cholasta
> 
> 
> -- 
> Jan Cholasta

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

Re: [Freeipa-devel] Certificate Identity Mapping

[Sumit Bose]

On Tue, Dec 20, 2016 at 10:10:29AM +0100, Florence Blanc-Renaud wrote:
> Hi Sumit and Jan,
> 
> thanks to both of you for providing detailed comments. Please find answers
> inline.
> 
> On 12/19/2016 12:13 PM, Sumit Bose wrote:
> > 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.
> I saw this option as a convenient way to disable all the rules with a single
> command, but I agree it's redundant with the mapping rules and we can live
> without it.
> 
> > > > 
> > > > * --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.
> > > > 
> Agree, force-1-to-1-mapping is clearer.

Please don't get me wrong, I just wanted to point out that switching on
and off the username prompt (or hint) is not the same as forcing a 1:1
mapping.

I think it is good to have the --prompt-username option to tell
applications which by default might not prompt for a user name when
doing Smartcard authentication, like gdm or web apps, to show a user
name. This allows to reach a similar behaviour as the 'username hint'
GPO in AD.

I think we currently do not have a requirement to force a 1:1 mappping.

bye,
Sumit

> 
> > > > * --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.
> OK, thanks for the heads-up.
> 
> > > > 
> > > > * --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

Re: [Freeipa-devel] Certificate Identity Mapping

[Sumit Bose]

On Mon, Jan 02, 2017 at 08:06:04AM +0100, Jan Cholasta wrote:
> On 19.12.2016 12:13, Sumit Bose wrote:
> > 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 wa

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

[Sumit Bose]

On Mon, Jan 02, 2017 at 09:18:47AM +0100, Jan Cholasta wrote:
> On 18.10.2016 07:34, Jan Cholasta wrote:
> > 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.
> > 
> 
> Bump. Sumit, what is your opinion on this?

I'm fine with an optional(?) priority as well. Since priorities are
already used in the pwpolicies this should be already known to the
experienced admin. I guess we just have stick with "A lower value
indicates a higher priority" to not confuse users. That's why I think
that the priority should be optional here and a missing value indicates
the lowest priority (default rules).

Are you thinking of using the CoS scheme here as well would a priority
attribute be sufficient because we do not want to reference internal
objects in the mapping rules?

bye,
Sumit

> 
> -- 
> Jan Cholasta

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

Re: [Freeipa-devel] 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

Re: [Freeipa-devel] Certificate Identity Mapping

[Sumit Bose]

cal LDAP tree I
  think the UTF-8 version fits better.

* nsslapd-certmap-basedn, see DOMAINDN above

* altSecurityIdentities example: X.500 ordering is used by AD here and
  unfortunately I think we have to adopt it at least for this specific
  usage, here is an ldapsearch output from AD:

altSecurityIdentities:
X509:DC=devel,DC=ad,CN=ad-AD-SERVER-CADC=devel,DC
 =ad,CN=Users,CN=t u,E=test.user@email.domain
altSecurityIdentities: X509:O=Red Hat,OU=prod,CN=Certificate
AuthorityDC
 =com,DC=redhat,OU=users,OID.0.9.2342.19200300.100.1.1=sbose,E=sb...@redhat.co
 m,CN=Sumit Bose Sumit Bose

* Certificate Mapping Administrators or re-use Certificate
  Administrators: I would prefer a new 'Certificate Mapping
  Administrators'

* Users can manage their own X.509 certificate mappings? I'm not sure
  here, at the first glance I would say no. How are OTP tokens handled?
  Maybe this would be a candidate for certmappingconfig-* option?

That's all :-)

bye,
Sumit

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

[Sumit Bose]

On Fri, Nov 25, 2016 at 02:19:10PM +0100, Jan Cholasta wrote:
> Bump, Sumit, have you seen my comments? I haven't heard back from you.

Yes, I've seen it and added a comment about it on the page
https://fedorahosted.org/sssd/wiki/DesignDocs/MatchingAndMappingCertificates#Matching-alternativeRFC4523syntax
To cut it short I would prefer to use a standard, but I think RFC4523
currently does nit meet out needs. But I would be happy if there are
ways to mitigate my concerns.

I'm working on updating and changing other sections as well and planned
to reply when I'm done with the other sections as well.

bye,
Sumit

> 
> On 17.10.2016 09:50, Jan Cholasta wrote:
> > 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&version=9&old_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&version=10&old_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 trus

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

[Sumit Bose]

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&version=9&old_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&version=10&old_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.


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

 and  in MIT Kerberos only accept certain string values related to 
some allowed values in those field as defined in 
https://www.ietf.org/rfc/rfc3280.txt . The selection is basically determined by 
what is supported on server side of the pkinit plugin of MIT Kerberos. Since we 
plan to extend pkinit and support local authentication without pkinit as well I 
would suggest to allow OID strings for those components as well (the comparison 
is done on the OID level nonetheless).

The  component in MIT Kerberos only che

Re: [Freeipa-devel] FleetCommander integration

[Sumit Bose]

On Tue, Sep 06, 2016 at 01:18:14PM +0300, Alexander Bokovoy wrote:
> Hi,
> 
> Now that FreeIPA 4.4.1 is out, I've pushed to github my prototype for
> FleetCommander integration: https://github.com/abbra/freeipa-desktop-profile/
> 
> You can read the design page:
> https://github.com/abbra/freeipa-desktop-profile/blob/master/plugin/Feature.mediawiki

Hi Alexander,

if I understand it correctly each profile has a priority which is used
by FleetCommander on the client side to order the different profiles if
for a given user and host multiple rules matches.

To make this work smoothly each priority value should be only assigned
once to avoid a tie. Are you planning to use the uniqueness plugin on
the priority value or are there other ways to solve ties reliable in
FleetCommander?

bye,
Sumit

> 
> The design was mostly figured out in discussions with Alberto, Fabiano,
> Nathaniel, and Jakub, so we are more or less on the common ground here
> between SSSD and FleetCommander. You can send pull requests to me on
> github to update the design. ;)
> 
> You can cut a tarball using
> git archive --format=tar.gz --prefix=freeipa-desktop-profile-0.0.1/ \
>   --output ~/rpmbuild/SOURCES/freeipa-desktop-profile-0.0.1.tar.gz \
>   freeipa-desktop-profile-0.0.1
> 
> And then build the package with
> rpmbuild -ta freeipa-desktop-profile-0.0.1.tar.gz
> 
> When installed, the package does not run ipa-server-upgrade by itself,
> yet. So you need to run ipa-server-upgrade manually. Once ran,
> deskprofile/deskprofilerule topics would become available and can be
> used for testing purposes. For Fedora 24 one can use FreeIPA 4.4.1 from
> COPR, for Fedora 25 we have FreeIPA 4.4.1 in updates stable as of today.
> 
> UI plugin is not ready yet and is disabled in the spec file as it breaks
> loading the whole UI.
> 
> -- 
> / 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

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

[Sumit Bose]

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&version=9&old_version=6

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

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.


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

 and  in MIT Kerberos only accept certain string values related to 
some allowed values in those field as defined in 
https://www.ietf.org/rfc/rfc3280.txt . The selection is basically determined by 
what is supported on server side of the pkinit plugin of MIT Kerberos. Since we 
plan to extend pkinit and support local authentication without pkinit as well I 
would suggest to allow OID strings for those components as well (the comparison 
is done on the OID level nonetheless).

The  component in MIT Kerberos only checks the otherName SAN component for 
the id-pkinit-san OID as defined in https://www.ietf.org/rfc/rfc4556.txt or the 
szOID_NT_PRINCIPAL_NAME OID as mentioned in 
https://support.microsoft.com/en-us/kb/287547. While this is sufficient for the 
default pkinit user case of MIT Kerberos I would suggest to extend this 
component by allowing to specific an OID with 

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

Re: [Freeipa-devel] kinit: Cannot contact any KDC for realm... from Freeipa clinet (Active Directory trust setup)

[Sumit Bose]

On Mon, Oct 10, 2016 at 09:43:24AM +0200, rajat gupta wrote:
> https://access.redhat.com/documentation/en-US/Red_Hat_
> Enterprise_Linux/7/html/Windows_Integration_Guide/
> trust-requirements.html#trust-req-ports
> 
> these port are required for trust. Is port 88 required to open from ipa
> client to AD?

Yes, in general the clients need to talk directly to the AD DC because
you do not want a man-in-the-middle during authentication.

For special environments it is possible to setup a KDC proxy, see
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System-Level_Authentication_Guide/Configuring_a_Kerberos_5_Server.html#KKDCP
for details.

HTH

bye,
Sumit

> 
> 
> On Mon, Oct 10, 2016 at 5:23 AM, rajat gupta  wrote:
> 
> > Hi,
> >
> > I am trying to setup the freeipa  Active Directory trust setup and i am
> > following
> > the http://www.freeipa.org/page/Active_Directory_trust_setup
> > documentation.
> >
> > I am able to login on freeipa Server with AD users.
> >
> > But when i am trying to login with some other IPA client machine I am not
> > able to to login with AD user.
> >
> > Required firewall port is opened between freeipa server to AD server and
> > freeipa server to freeipa clinets
> >
> > There is no firewall port is opened between from  freeipa client to AD
> > server.
> >
> > =
> > against addomain from ipaserver :-
> >
> > ipa01 ~]# KRB5_TRACE=/dev/stdout kinit raja...@ad.addomain.com
> > [24633] 1476069033.462976: Resolving unique ccache of type KEYRING
> > [24633] 1476069033.463027: Getting initial credentials for
> > raja...@ad.addomain.com
> > [24633] 1476069033.465229: Sending request (183 bytes) to AD.ADDOMAIN.COM
> > [24633] 1476069033.471891: Resolving hostname ad1.ad.addomain.com
> > [24633] 1476069033.474439: Sending initial UDP request to dgram
> > 192.168.20.100:88
> > [24633] 1476069033.487765: Received answer (212 bytes) from dgram
> > 192.168.20.100:88
> > [24633] 1476069033.488098: Response was not from master KDC
> > [24633] 1476069033.488136: Received error from KDC: -1765328359/Additional
> > pre-authentication required
> > [24633] 1476069033.488179: Processing preauth types: 16, 15, 19, 2
> > [24633] 1476069033.488192: Selected etype info: etype aes256-cts, salt
> > "AD.ADDOMAIN.COMRajat.Gupta", params ""
> > [24633] 1476069033.488215: PKINIT client has no configured identity;
> > giving up
> > [24633] 1476069033.488233: PKINIT client has no configured identity;
> > giving up
> > [24633] 1476069033.488242: Preauth module pkinit (16) (real) returned:
> > 22/Invalid argument
> > [24633] 1476069033.488250: PKINIT client has no configured identity;
> > giving up
> > [24633] 1476069033.488255: Preauth module pkinit (14) (real) returned:
> > 22/Invalid argument
> > Password for raja...@ad.addomain.com:
> >
> > this is working fine.
> > =
> >
> >
> > =
> > against addomain from ipaclinet :-
> >
> > *ipaclinet ~] #  KRB5_TRACE=/dev/stdout kinit  raja...@ad.addomain.com
> > [4133] 1476067599.43421: Getting initial
> > credentials for raja...@ad.addomain.com [4133]
> > 1476067599.43599: Sending request (183 bytes) to AD.ADDOMAIN.COM
> > *
> > *[4133] 1476067599.49544: Resolving hostname *
> > *ad1.ad.addomain.com .*
> > *[4133] 1476067599.53762: Sending initial UDP request to dgram
> > 192.168.20.100*
> >
> > NOT WORKING
> > =
> >
> > =
> > against ipdomain from ipaclinet
> >
> > # KRB5_TRACE=/dev/stdout kinit  admin@IPA.IPASERVER.LOCAL
> > [4914] 1476068067.763574: Getting initial credentials for
> > admin@IPA.IPASERVER.LOCAL
> > [4914] 1476068067.763889: Sending request (177 bytes) to
> > IPA.IPASERVER.LOCAL
> > [4914] 1476068067.764033: Initiating TCP connection to stream
> > 10.246.104.14:88
> > [4914] 1476068067.765089: Sending TCP request to stream 192.168.100.100:88
> > [4914] 1476068067.767593: Received answer (356 bytes) from stream
> > 192.168.100.100:88
> > [4914] 1476068067.767603: Terminating TCP connection to stream
> > 192.168.100.100:88
> > [4914] 1476068067.767661: Response was from master KDC
> > [4914] 1476068067.767685: Received error from KDC: -1765328359/Additional
> > pre-authentication required
> > [4914] 1476068067.767730: Processing preauth types: 136, 19, 2, 133
> > [4914] 1476068067.767742: Selected etype info: etype aes256-cts, salt
> > "k},(k&+qA)Mosf6z", params ""
> > [4914] 1476068067.767747: Received cookie: MIT
> > Password for admin@IPA.IPASERVER.LOCAL:
> >
> > this is working fine.
> > =
> >
> >
> > it looks for password-based authentication requests, the IPA clients
> > 

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

[Sumit Bose]

On Thu, Oct 06, 2016 at 10:33:48AM -0400, Rob Crittenden wrote:
> Sumit Bose wrote:
> > Hi,
> > 
> > 
> 
> Wow, this is really great.

Hi Rob,

thank you for the feedback.

> 
> I think I'd pre-plan to support different configuration per issuer subject,
> with one named default. It shouldn't be a lot more work and will
> future-proof things for you, particularly in how the rules are stored in
> LDAP.
> 
> I worry a bit about matching without comparing the certificate for the case
> where you don't examine issuer.
> 

Do I understand it correctly that you are looking for rules which will
always and only match for certificate from a given issuer? E.g. if all
matching rules will have the  set like

CN=ca,DC=abd,DC=comclientAuth
CN=ca,DC=def,DC=commsScLogin

certificates from the abc issue must have clientAuth set to be valid for
authentication and certificates from issuer def must have msScLogin set.
But you are right, if one rule does not have issuer set like

CN=ca,DC=abd,DC=comclientAuth
msScLogin

then a certificate from issuer abc which does not have clientAuth set
but msScLogin would be accepted as well.

Do you think it would help to make  a required field but allow
that the lazy admin can just enter a '*' to match any issuer?

> You may want to have an option to require that the presented cert match the
> one stored in LDAP (off by default). I realize that you specifically mention
> this can be problematic, but it can also be quite useful. It can be used,
> for example, to disable a login by removing the certificate from the user's
> entry. It also ensures that some carefully crafted certificate doesn't allow
> a bad actor to map to a user account.

This happens when no mapping rule is given. Then SSSD will fall
back to search/map the user with the whole certificate. And if the
certificate is removed from the LDAP entry of the user Smartcard
authentication will fail as soon as the user entry in the cache of SSSD
is expired.

bye,
Sumit

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

[Sumit Bose]

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

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


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

 and  in MIT Kerberos only accept certain string values related to 
some allowed values in those field as defined in 
https://www.ietf.org/rfc/rfc3280.txt . The selection is basically determined by 
what is supported on server side of the pkinit plugin of MIT Kerberos. Since we 
plan to extend pkinit and support local authentication without pkinit as well I 
would suggest to allow OID strings for those components as well (the comparison 
is done on the OID level nonetheless).

The  component in MIT Kerberos only checks the otherName SAN component for 
the id-pkinit-san OID as defined in https://www.ietf.org/rfc/rfc4556.txt or the 
szOID_NT_PRINCIPAL_NAME OID as mentioned in 
https://support.microsoft.com/en-us/kb/287547. While this is sufficient for the 
default pkinit user case of MIT Kerberos I would suggest to extend this 
component by allowing to specific an OID with 

 Mapping 
Since different certificates, e.g. issued by different CAs, might have 
different mapping rule, a matching rule must be added if there are more than 1 
mapping rule. A single mapping rule without a matching rule might be used as 
default/catch-all rule in this case.

If multiple rules matches the derived LDAP filter components can be grouped 
with the or-operator "|".

A mapping rule can use a similar syntax like the matching rule where the LDAP 
attribute can be added with a ':', e.g.
* 
* 

Currently I see no usage for ,  and  in mapping rules because 
they do not contain any user-specific data. If at some point we will have 
personal CAs we might consider to add  based mappings.


'''Question, do we need search-and-replace at all (or at this stage)? Most of 
the interesting values from the SAN should be directly map-able to LDAP 
attributes. And processing the string representation of  might be 
tricky as discussed below. Nevertheless the following mig

Re: [Freeipa-devel] [Test][Patch-0049, 0050] Certs in ID overrides test

[Sumit Bose]

On Wed, Sep 14, 2016 at 06:03:37PM +0200, Martin Basti wrote:
> 
> 
> On 14.09.2016 17:53, Alexander Bokovoy wrote:
> > On Wed, 14 Sep 2016, Martin Basti wrote:
> > > 
> > > 
> > > On 14.09.2016 17:41, Alexander Bokovoy wrote:
> > > > On Wed, 14 Sep 2016, Martin Basti wrote:
> > > > > 1)
> > > > > I still don't see the reason why AD trust is needed. Default
> > > > > trust ID view is added just by ipa-adtrust-install, adding
> > > > > trust is not needed for current implementation. You don't
> > > > > need AD for this, IDviews is generic feature not just for
> > > > > AD. Is that user configured on AD side?
> > > > You cannot add non-AD user to 'default trust view', so you will not be
> > > > able to set up certificates to ID override which does not exist.
> > > > 
> > > > For non-'default trust view' you can add both IPA and AD users,
> > > > so using
> > > > some other view and then assign certificate for a ID override in that
> > > > one.
> > > > 
> > > 
> > > Ok then, but anyway I would like to see API/CLI tests for this
> > > feature with proper output validation.
> > > 
> > > 
> > > How can be this tested with SSSD?
> > You need to log into the system with a certificate...
> Is this possible from test? We are logged remotely as root, is there any
> cmdline util which allows us to test certificate against AD user?


You can use 'sss_ssh_authorizedkeys aduser@ad.domain' which should
return the ssh key derived from the public key in the certificate. This
should work for certificate stored in AD as well as for overrides.

You can also you the DBus lookup by certificate as described in
https://fedorahosted.org/sssd/wiki/DesignDocs/LookupUsersByCertificate .

HTH

bye,
Sumit

> 
> Martin^2
> 
> -- 
> 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

-- 
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] [Testplan] Support of UPN for trusted domains

[Sumit Bose]

On Mon, Jul 11, 2016 at 09:44:46AM +0200, Lenka Doudova wrote:
> 
> 
> On 07/07/2016 11:13 AM, Sumit Bose wrote:
> > On Fri, May 27, 2016 at 11:24:24AM +0300, Alexander Bokovoy wrote:
> > > On Fri, 27 May 2016, Sumit Bose wrote:
> > > > On Fri, May 27, 2016 at 09:57:37AM +0200, Lenka Doudova wrote:
> > > > > Hi all,
> > > > > 
> > > > > 
> > > > > here [1] is a draft of test plan for V4 RFE Support of UPN for trusted
> > > > > domains.
> > > > > 
> > > > > Please review this and let me know if there's something missing or 
> > > > > wrong.
> > > > Hi Lenka,
> > > > 
> > > > thank you for the test plan.
> > > > 
> > > > About the TBD, Alexander and I agreed to store the alternative domain
> > > > suffixes read from AD in a new attribute in the LDAP object of the
> > > > forest root of the trusted domain.
> > > > 
> > > > About the kinit tests. Please note that it is expected that the -E
> > > > option of kinit must be used when alternative suffixes are used.
> > > > 
> > > > I'm not sure if SSSD tests are in the scope here as well. If they are I
> > > > would suggest to add authentication tests with SSSD where e.g. the name
> > > > with an alternative domain suffix is used as login name. This in general
> > > > already works with SSSD but is disabled by default for IPA because of
> > > > the missing server-side support so far. Since SSSD must be able to work
> > > > with old and new IPA server https://fedorahosted.org/sssd/ticket/3018
> > > > was created so that SSSD can detect at runtime if the server supports
> > > > this or not.
> > > Right, I think we should make sure SSSD is tested against IPA UPN
> > > support because otherwise we might get regressions.
> > Hi Lenka,
> > 
> > I would like to ask you to add test where 'kinit -E' is used with an IPA
> > user as well to avoid regression, because currently 'kinit -E
> > ipauser@IPA.DOMAIN' does not work.
> > 
> > Please note that the full principal must be used with kinit in this case
> > because when just using
> > 
> >  kinit -E ipauser
> > 
> > kinit is smart enough to see that it makes no sense to add the
> > default_realm twice and internally just does 'kinit ipauser@IPA.DOMAIN'.
> > 
> > If you think this test is better suited in a different test plan please
> > let me know, then I'll ask there.
> > 
> > bye,
> > Sumit
> Hi Sumit,
> 
> this test should be covered in basic trust test suite, but I think it's not
> in the code of the test (I was busy with providing coverage for new features
> and didn't manage to go through old coverage). I'll check this and update
> ASAP.
> 
> Thanks for catching it!

Thank you for taking care of it.

bye,
Sumit

> Lenka
> 
> > > 
> > > -- 
> > > / Alexander Bokovoy
> 

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

Re: [Freeipa-devel] [PATCH] kdb: check for local realm in enterprise principals

[Sumit Bose]

On Thu, Jul 07, 2016 at 01:31:03PM +0200, Petr Vobornik wrote:
> On 07/06/2016 07:01 PM, Sumit Bose wrote:
> > Hi,
> > 
> > although enterprise principals for trusted domains now are working as
> > expected they do not work for the local domain:
> > 
> > # kinit -E admin@IPA.DEVEL
> > kinit: Client 'admin\@IPA.DEVEL@IPA.DEVEL' not found in Kerberos 
> > database while getting initial credentials
> > 
> > Attached patch handles this case. It is not that nice because of the
> > duplication of ipadb_fetch_principals() and ipadb_find_principal(). But
> > I think there was a reason I do not remember why we didn't check for
> > enterprise principals before checking the local database. If there is no
> > such reason it might make sense to check for enterprise principals
> > before doing the lookup. Please let me know if I should change the patch
> > accordingly or if the current version is ok,
> > 
> > bye,
> > Sumit
> > 
> 
> Hi Sumit,
> 
> thanks for the patch. This patch should have a ticket. It will help
> downstream planning.

sure, I created https://fedorahosted.org/freeipa/ticket/6036. Please
clone it to suitable downstream tickets.

Please note that we didn't released a patch for SSSD to enable enterprise
principals automatically if the IPA server (should) support them because
of this issues. Since 4.4.0 is already released I think we have to wait
on the SSSD side until a new FreeIPA version with a fix is released.

bye,
Sumit

> 
> -- 
> Petr Vobornik

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

Re: [Freeipa-devel] [Testplan] Support of UPN for trusted domains

[Sumit Bose]

On Fri, May 27, 2016 at 11:24:24AM +0300, Alexander Bokovoy wrote:
> On Fri, 27 May 2016, Sumit Bose wrote:
> > On Fri, May 27, 2016 at 09:57:37AM +0200, Lenka Doudova wrote:
> > > Hi all,
> > > 
> > > 
> > > here [1] is a draft of test plan for V4 RFE Support of UPN for trusted
> > > domains.
> > > 
> > > Please review this and let me know if there's something missing or wrong.
> > 
> > Hi Lenka,
> > 
> > thank you for the test plan.
> > 
> > About the TBD, Alexander and I agreed to store the alternative domain
> > suffixes read from AD in a new attribute in the LDAP object of the
> > forest root of the trusted domain.
> > 
> > About the kinit tests. Please note that it is expected that the -E
> > option of kinit must be used when alternative suffixes are used.
> > 
> > I'm not sure if SSSD tests are in the scope here as well. If they are I
> > would suggest to add authentication tests with SSSD where e.g. the name
> > with an alternative domain suffix is used as login name. This in general
> > already works with SSSD but is disabled by default for IPA because of
> > the missing server-side support so far. Since SSSD must be able to work
> > with old and new IPA server https://fedorahosted.org/sssd/ticket/3018
> > was created so that SSSD can detect at runtime if the server supports
> > this or not.
> Right, I think we should make sure SSSD is tested against IPA UPN
> support because otherwise we might get regressions.

Hi Lenka,

I would like to ask you to add test where 'kinit -E' is used with an IPA
user as well to avoid regression, because currently 'kinit -E
ipauser@IPA.DOMAIN' does not work. 

Please note that the full principal must be used with kinit in this case
because when just using

kinit -E ipauser

kinit is smart enough to see that it makes no sense to add the
default_realm twice and internally just does 'kinit ipauser@IPA.DOMAIN'.

If you think this test is better suited in a different test plan please
let me know, then I'll ask there.

bye,
Sumit

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

[Freeipa-devel] [PATCH] kdb: check for local realm in enterprise principals

[Sumit Bose]

Hi,

although enterprise principals for trusted domains now are working as
expected they do not work for the local domain:

# kinit -E admin@IPA.DEVEL  


kinit: Client 'admin\@IPA.DEVEL@IPA.DEVEL' not found in Kerberos database 
while getting initial credentials

Attached patch handles this case. It is not that nice because of the
duplication of ipadb_fetch_principals() and ipadb_find_principal(). But
I think there was a reason I do not remember why we didn't check for
enterprise principals before checking the local database. If there is no
such reason it might make sense to check for enterprise principals
before doing the lookup. Please let me know if I should change the patch
accordingly or if the current version is ok,

bye,
Sumit

From a1ca7928148a58a1ac61f6d418750200866a4a63 Mon Sep 17 00:00:00 2001
From: Sumit Bose 
Date: Wed, 6 Jul 2016 17:29:37 +0200
Subject: [PATCH] kdb: check for local realm in enterprise principals

---
 daemons/ipa-kdb/ipa_kdb_principals.c | 52 +++-
 1 file changed, 40 insertions(+), 12 deletions(-)

diff --git a/daemons/ipa-kdb/ipa_kdb_principals.c 
b/daemons/ipa-kdb/ipa_kdb_principals.c
index 
6cdfa909452a4b55912b2a5a74648abd2053482a..5b80909475565d6bb4fa8cba67629094daf51eb3
 100644
--- a/daemons/ipa-kdb/ipa_kdb_principals.c
+++ b/daemons/ipa-kdb/ipa_kdb_principals.c
@@ -1198,30 +1198,58 @@ krb5_error_code ipadb_get_principal(krb5_context 
kcontext,
 /* skip '@' and use part after '@' as an enterprise realm for 
comparison */
 realm++;
 
-kerr = ipadb_is_princ_from_trusted_realm(kcontext,
- realm,
- upn->length - (realm - 
upn->data),
- &trusted_realm);
-if (kerr == 0) {
-kentry = calloc(1, sizeof(krb5_db_entry));
-if (!kentry) {
+/* check for our realm */
+if (strncasecmp(ipactx->realm, realm,
+upn->length - (realm - upn->data)) == 0) {
+/* it looks like it is ok to use malloc'ed strings as 
principal */
+krb5_free_unparsed_name(kcontext, principal);
+principal = strndup((const char *) upn->data, upn->length);
+if (principal == NULL) {
 kerr = ENOMEM;
 goto done;
 }
-kerr = krb5_parse_name(kcontext, principal,
-   &kentry->princ);
+
+ldap_msgfree(res);
+res = NULL;
+kerr = ipadb_fetch_principals(ipactx, flags, principal, &res);
 if (kerr != 0) {
 goto done;
 }
 
-kerr = krb5_set_principal_realm(kcontext, kentry->princ, 
trusted_realm);
+kerr = ipadb_find_principal(kcontext, flags, res, &principal,
+&lentry);
 if (kerr != 0) {
 goto done;
 }
-*entry = kentry;
+} else {
+
+kerr = ipadb_is_princ_from_trusted_realm(kcontext,
+ realm,
+ upn->length - (realm 
- upn->data),
+ &trusted_realm);
+if (kerr == 0) {
+kentry = calloc(1, sizeof(krb5_db_entry));
+if (!kentry) {
+kerr = ENOMEM;
+goto done;
+}
+kerr = krb5_parse_name(kcontext, principal,
+   &kentry->princ);
+if (kerr != 0) {
+goto done;
+}
+
+kerr = krb5_set_principal_realm(kcontext, kentry->princ, 
trusted_realm);
+if (kerr != 0) {
+goto done;
+}
+*entry = kentry;
+}
+goto done;
 }
+} else {
+goto done;
 }
-goto done;
 }
 
 kerr = ipadb_parse_ldap_entry(kcontext, principal, lentry, entry, &pol);
-- 
2.4.11

-- 
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] [Testplan Review] Certs in ID overrides

[Sumit Bose]

On Tue, Jun 28, 2016 at 10:43:00AM +0200, Oleg Fayans wrote:
> Hi Sumit,
> 
> The testplan is updated according to your second note. The WebUI part
> I'll test once Pavel's patch is merged.

Thank you.

bye,
Sumit

> 
> On 06/27/2016 10:28 AM, Sumit Bose wrote:
> > On Mon, Jun 27, 2016 at 10:06:23AM +0200, Oleg Fayans wrote:
> >> Hi Sumit,
> >>
> >> I've updated the testplan. (Thank you for the link to Fraser's blogpost,
> >> it was really very useful!). All the operations described  were
> >> performed manually and succeed. Could you please review it again in case
> >> I forgot something?
> > 
> > Thank you, the tests are looking good.
> > 
> > I have two comments. First, for your information, I#m not sure if WebUI
> > is in the scope of this tests, Pavel already send '0058 WebUI:
> > certificate widget on ID override user page' to the freeipa-devel list,
> > so adding certificates to idoverrides with the WebUI should work soon as
> > well.
> > 
> > Second, the LDAP attribute used to store the certificates is a
> > multi-value attribute. Adding a test where a second certificate is added
> > to the override and removed (without deleting the other certificate)
> > might be useful here.
> > 
> > bye,
> > Sumit
> > 
> >>
> >>
> >> On 06/09/2016 05:06 PM, Sumit Bose wrote:
> >>> On Thu, Jun 09, 2016 at 04:48:57PM +0200, Oleg Fayans wrote:
> >>>> Hi guys,
> >>>>
> >>>> Here is the first somewhat skeletal and pretty short version of the
> >>>> testplan. Could you please review it anyone?
> >>>>
> >>>> http://www.freeipa.org/page/V4/Certs_in_ID_overrides/Test_Plan
> >>>
> >>> Hi Oleg,
> >>>
> >>> 'Make sure the id view is applied to ipa master host' the IPA
> >>> masters/servers will always and only have the 'Default Trust View'. But
> >>> it is ok to use the 'Default Trust View' for testing the certificates in
> >>> the ID override.
> >>>
> >>> The 'openssl req ...' call will only generate a certificate request and
> >>> not the certificate itself. The request must still be signed by e.g. the
> >>> IPA CA. Please see the blog posts of Fraser
> >>> (https://blog-ftweedal.rhcloud.com/2015/08/user-certificates-and-custom-profiles-with-freeipa-4-2/)
> >>> and Nathan (https://blog-nkinder.rhcloud.com/?p=184) for details.
> >>>
> >>> Since you want to test certificates in overrides you should use
> >>> idoverrideuser-add-cert and idoverrideuser-remove-cert instead of
> >>> user-add-cert and user-remove-cert.
> >>>
> >>> bye,
> >>> Sumit
> >>>
> >>>> -- 
> >>>> Oleg Fayans
> >>>> Quality Engineer
> >>>> FreeIPA team
> >>>> RedHat.
> >>>>
> >>>> -- 
> >>>> 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
> >>
> >> -- 
> >> Oleg Fayans
> >> Quality Engineer
> >> FreeIPA team
> >> RedHat.
> 
> -- 
> Oleg Fayans
> Quality Engineer
> FreeIPA team
> RedHat.

-- 
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] [Testplan Review] Certs in ID overrides

[Sumit Bose]

On Mon, Jun 27, 2016 at 10:06:23AM +0200, Oleg Fayans wrote:
> Hi Sumit,
> 
> I've updated the testplan. (Thank you for the link to Fraser's blogpost,
> it was really very useful!). All the operations described  were
> performed manually and succeed. Could you please review it again in case
> I forgot something?

Thank you, the tests are looking good.

I have two comments. First, for your information, I#m not sure if WebUI
is in the scope of this tests, Pavel already send '0058 WebUI:
certificate widget on ID override user page' to the freeipa-devel list,
so adding certificates to idoverrides with the WebUI should work soon as
well.

Second, the LDAP attribute used to store the certificates is a
multi-value attribute. Adding a test where a second certificate is added
to the override and removed (without deleting the other certificate)
might be useful here.

bye,
Sumit

> 
> 
> On 06/09/2016 05:06 PM, Sumit Bose wrote:
> > On Thu, Jun 09, 2016 at 04:48:57PM +0200, Oleg Fayans wrote:
> >> Hi guys,
> >>
> >> Here is the first somewhat skeletal and pretty short version of the
> >> testplan. Could you please review it anyone?
> >>
> >> http://www.freeipa.org/page/V4/Certs_in_ID_overrides/Test_Plan
> > 
> > Hi Oleg,
> > 
> > 'Make sure the id view is applied to ipa master host' the IPA
> > masters/servers will always and only have the 'Default Trust View'. But
> > it is ok to use the 'Default Trust View' for testing the certificates in
> > the ID override.
> > 
> > The 'openssl req ...' call will only generate a certificate request and
> > not the certificate itself. The request must still be signed by e.g. the
> > IPA CA. Please see the blog posts of Fraser
> > (https://blog-ftweedal.rhcloud.com/2015/08/user-certificates-and-custom-profiles-with-freeipa-4-2/)
> > and Nathan (https://blog-nkinder.rhcloud.com/?p=184) for details.
> > 
> > Since you want to test certificates in overrides you should use
> > idoverrideuser-add-cert and idoverrideuser-remove-cert instead of
> > user-add-cert and user-remove-cert.
> > 
> > bye,
> > Sumit
> > 
> >> -- 
> >> Oleg Fayans
> >> Quality Engineer
> >> FreeIPA team
> >> RedHat.
> >>
> >> -- 
> >> 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
> 
> -- 
> Oleg Fayans
> Quality Engineer
> FreeIPA team
> RedHat.

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

Re: [Freeipa-devel] [PATCH] 0156 extdom: add certificate request

[Sumit Bose]

On Fri, Jun 24, 2016 at 05:53:27PM +0200, Martin Basti wrote:
> 
> 
> On 24.06.2016 15:09, Martin Basti wrote:
> > 
> > 
> > On 24.06.2016 14:59, Sumit Bose wrote:
> > > On Fri, Jun 24, 2016 at 02:00:24PM +0200, Martin Basti wrote:
> > > > 
> > > > On 22.06.2016 23:20, Lukas Slebodnik wrote:
> > > > > On (22/06/16 11:57), Martin Basti wrote:
> > > > > > On 09.06.2016 21:02, Martin Basti wrote:
> > > > > > > On 09.06.2016 14:45, Martin Basti wrote:
> > > > > > > > On 09.06.2016 14:42, Martin Basti wrote:
> > > > > > > > > On 09.06.2016 14:38, Lukas Slebodnik wrote:
> > > > > > > > > > On (09/06/16 14:29), Martin Basti wrote:
> > > > > > > > > > > On 09.06.2016 14:22, Alexander Bokovoy wrote:
> > > > > > > > > > > > On Thu, 09 Jun 2016, Jakub Hrozek wrote:
> > > > > > > > > > > > > On Fri, May 20, 2016 at 09:23:46PM +0200, Sumit Bose 
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > this patch allows the extom plugin to lookup
> > > > > > > > > > > > > > users by certificate which
> > > > > > > > > > > > > > is needed in the case where a IPA client
> > > > > > > > > > > > > > wants to lookup an AD user who
> > > > > > > > > > > > > > has the certificate stored in AD. To make
> > > > > > > > > > > > > > this work the related patches
> > > > > > > > > > > > > > I just send to sssd-devel are needed as well.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Currently the patches miss the change in the
> > > > > > > > > > > > > > required version of SSSD.
> > > > > > > > > > > > > > since the SSSD patches are not committed. But
> > > > > > > > > > > > > > the patches are needed to
> > > > > > > > > > > > > > fully test the SSSD patches. I will send a
> > > > > > > > > > > > > > new version with the needed
> > > > > > > > > > > > > > changes to the minimal SSSD version when the SSSD 
> > > > > > > > > > > > > > patches are
> > > > > > > > > > > > > > committed.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > bye,
> > > > > > > > > > > > > > Sumit
> > > > > > > > > > > > > The patch works fine (tested
> > > > > > > > > > > > > together with the
> > > > > > > > > > > > > corresponding SSSD
> > > > > > > > > > > > > patches), so ACK from me. The code also looks
> > > > > > > > > > > > > good to me, but I'm not
> > > > > > > > > > > > > sure if reviewing an IPA patch requires something
> > > > > > > > > > > > > more (CI? Coverity?)
> > > > > > > > > > > > ACK from me as well, I forgot to send email about it,
> > > > > > > > > > > > though I reviewed
> > > > > > > > > > > > this patch a week ago.
> > > > > > > > > > > > 
> > > > > > > > > > > Pushed to master: aa734da49440c5d12c0f8d4566505adaeef254e8
> > > > > > > > > > > 
> > > > > > > > > > It's very likey that this commit will break build of
> > > > > > > > > > freeipa-master. I didn't try.
> > > > > > > > > > 
> > > > > > > > > > Because it uses new function sss_nss_getnamebycert
> > > > > > > > > > from the library libsss_nss_idmap which is not in fedora.
> > > > > >

Re: [Freeipa-devel] [PATCH 0096] Add authentication indicators support to Host objects

[Sumit Bose]

On Tue, Jun 21, 2016 at 02:25:49PM -0400, Nathaniel McCallum wrote:
> https://fedorahosted.org/freeipa/ticket/433

The patch works for me as expected, but the API.txt update is missing in
the patch.

bye,
Sumit


> From c7254a9dd182b34665b50c45c5ece42a3cbc56e2 Mon Sep 17 00:00:00 2001
> From: Nathaniel McCallum 
> Date: Tue, 21 Jun 2016 14:19:03 -0400
> Subject: [PATCH] Add authentication indicators support to Host objects
> 
> https://fedorahosted.org/freeipa/ticket/433
> ---
>  ipaserver/plugins/host.py | 17 -
>  1 file changed, 16 insertions(+), 1 deletion(-)
> 
> diff --git a/ipaserver/plugins/host.py b/ipaserver/plugins/host.py
> index 
> 15805a3d2292dcf176ec52afdd3885563eea1210..905116e9c4d12c9e35bb82a5ff2c7bd8b920e80d
>  100644
> --- a/ipaserver/plugins/host.py
> +++ b/ipaserver/plugins/host.py
> @@ -294,7 +294,7 @@ class host(LDAPObject):
>  'fqdn', 'description', 'l', 'nshostlocation', 'krbprincipalname',
>  'nshardwareplatform', 'nsosversion', 'usercertificate', 'memberof',
>  'managedby', 'memberofindirect', 'macaddress',
> -'userclass', 'ipaallowedtoperform', 'ipaassignedidview',
> +'userclass', 'ipaallowedtoperform', 'ipaassignedidview', 
> 'krbprincipalauthind'
>  ]
>  uuid_attribute = 'ipauniqueid'
>  attribute_members = {
> @@ -529,6 +529,14 @@ class host(LDAPObject):
>  label=_('Assigned ID View'),
>  flags=['no_option'],
>  ),
> +Str('krbprincipalauthind*',
> +cli_name='auth_ind',
> +label=_('Authentication Indicators'),
> +doc=_("Defines a whitelist for Authentication Indicators."
> +  " Use 'otp' to allow OTP-based 2FA authentications."
> +  " Use 'radius' to allow RADIUS-based 2FA authentications."
> +  " Other values may be used for custom configurations."),
> +),
>  ) + ticket_flags_params
>  
>  def get_dn(self, *keys, **options):
> @@ -910,6 +918,13 @@ class host_mod(LDAPUpdate):
>  if 'krbticketpolicyaux' not in entry_attrs['objectclass']:
>  entry_attrs['objectclass'].append('krbticketpolicyaux')
>  
> +if 'krbprincipalauthind' in entry_attrs:
> +if 'objectclass' not in entry_attrs:
> +entry_attrs_old = ldap.get_entry(dn, ['objectclass'])
> +entry_attrs['objectclass'] = entry_attrs_old['objectclass']
> +if 'krbprincipalaux' not in entry_attrs['objectclass']:
> +entry_attrs['objectclass'].append('krbprincipalaux')
> +
>  add_sshpubkey_to_attrs_pre(self.context, attrs_list)
>  
>  return dn
> -- 
> 2.9.0
> 

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

Re: [Freeipa-devel] [PATCH] 0156 extdom: add certificate request

[Sumit Bose]

On Fri, Jun 24, 2016 at 02:00:24PM +0200, Martin Basti wrote:
> 
> 
> On 22.06.2016 23:20, Lukas Slebodnik wrote:
> > On (22/06/16 11:57), Martin Basti wrote:
> > > 
> > > On 09.06.2016 21:02, Martin Basti wrote:
> > > > 
> > > > On 09.06.2016 14:45, Martin Basti wrote:
> > > > > 
> > > > > On 09.06.2016 14:42, Martin Basti wrote:
> > > > > > 
> > > > > > On 09.06.2016 14:38, Lukas Slebodnik wrote:
> > > > > > > On (09/06/16 14:29), Martin Basti wrote:
> > > > > > > > On 09.06.2016 14:22, Alexander Bokovoy wrote:
> > > > > > > > > On Thu, 09 Jun 2016, Jakub Hrozek wrote:
> > > > > > > > > > On Fri, May 20, 2016 at 09:23:46PM +0200, Sumit Bose wrote:
> > > > > > > > > > > Hi,
> > > > > > > > > > > 
> > > > > > > > > > > this patch allows the extom plugin to lookup
> > > > > > > > > > > users by certificate which
> > > > > > > > > > > is needed in the case where a IPA client
> > > > > > > > > > > wants to lookup an AD user who
> > > > > > > > > > > has the certificate stored in AD. To make
> > > > > > > > > > > this work the related patches
> > > > > > > > > > > I just send to sssd-devel are needed as well.
> > > > > > > > > > > 
> > > > > > > > > > > Currently the patches miss the change in the
> > > > > > > > > > > required version of SSSD.
> > > > > > > > > > > since the SSSD patches are not committed. But
> > > > > > > > > > > the patches are needed to
> > > > > > > > > > > fully test the SSSD patches. I will send a
> > > > > > > > > > > new version with the needed
> > > > > > > > > > > changes to the minimal SSSD version when the SSSD patches 
> > > > > > > > > > > are
> > > > > > > > > > > committed.
> > > > > > > > > > > 
> > > > > > > > > > > bye,
> > > > > > > > > > > Sumit
> > > > > > > > > > The patch works fine (tested together with the 
> > > > > > > > > > corresponding SSSD
> > > > > > > > > > patches), so ACK from me. The code also looks
> > > > > > > > > > good to me, but I'm not
> > > > > > > > > > sure if reviewing an IPA patch requires something
> > > > > > > > > > more (CI? Coverity?)
> > > > > > > > > ACK from me as well, I forgot to send email about it,
> > > > > > > > > though I reviewed
> > > > > > > > > this patch a week ago.
> > > > > > > > > 
> > > > > > > > Pushed to master: aa734da49440c5d12c0f8d4566505adaeef254e8
> > > > > > > > 
> > > > > > > It's very likey that this commit will break build of
> > > > > > > freeipa-master. I didn't try.
> > > > > > > 
> > > > > > > Because it uses new function sss_nss_getnamebycert
> > > > > > > from the library libsss_nss_idmap which is not in fedora.
> > > > > > > It was pushed to sssd master just today.
> > > > > > > 
> > > > > > > LS
> > > > > > If this is true, can you/somebody provide the SRPM of SSSD with
> > > > > > the required functionality please? We may need to add it to
> > > > > > @freeipa/freeipa-master copr and bump required version of SSSD.
> > > > > > 
> > > > > > Martin^2
> > > > > > 
> > > > > Yes, you were right, master build is broken.
> > > > > Martin^2
> > > > > 
> > > > SSSD master build has been added to @freeipa/freeipa-master copr as a
> > > > workaround (to unblock automatic testing an developers)
> > > > 
> > > > Please bump version in specfile accordingly (I don't know in which
> > > > version of SSSD will be required function)
> > > > 
> &

Re: [Freeipa-devel] [Testplan Review] Certs in ID overrides

[Sumit Bose]

On Thu, Jun 09, 2016 at 04:48:57PM +0200, Oleg Fayans wrote:
> Hi guys,
> 
> Here is the first somewhat skeletal and pretty short version of the
> testplan. Could you please review it anyone?
> 
> http://www.freeipa.org/page/V4/Certs_in_ID_overrides/Test_Plan

Hi Oleg,

'Make sure the id view is applied to ipa master host' the IPA
masters/servers will always and only have the 'Default Trust View'. But
it is ok to use the 'Default Trust View' for testing the certificates in
the ID override.

The 'openssl req ...' call will only generate a certificate request and
not the certificate itself. The request must still be signed by e.g. the
IPA CA. Please see the blog posts of Fraser
(https://blog-ftweedal.rhcloud.com/2015/08/user-certificates-and-custom-profiles-with-freeipa-4-2/)
and Nathan (https://blog-nkinder.rhcloud.com/?p=184) for details.

Since you want to test certificates in overrides you should use
idoverrideuser-add-cert and idoverrideuser-remove-cert instead of
user-add-cert and user-remove-cert.

bye,
Sumit

> -- 
> Oleg Fayans
> Quality Engineer
> FreeIPA team
> RedHat.
> 
> -- 
> 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

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

Re: [Freeipa-devel] [PATCH] 0208-0209 webUI changes for external trust and UPN suffixes

[Sumit Bose]

On Thu, Jun 09, 2016 at 02:30:52PM +0300, Alexander Bokovoy wrote:
> Hi,
> 
> webUI changes to support external trust and showing UPN suffixes are
> attached.
> 
> UPN Suffixes defined on AD side and fetched with 'ipa trust-fetch-domains'.
> They cannot be disabled individually as they come from AD side and are
> forest-wide, so we only show them, not allowing to modify anything.
> 
> External forest is a flag and is shown in the trust-add dialog.
> The result would be visible as trust type of 'Non-transitive external
> trust to a domain in another Active Directory forest'
> 
> These patches functionally depend on 0201 and 0202.
> 
> -- 
> / Alexander Bokovoy

> From 4da33f5e82c83617ccfb2da7c3b70e5e66ac49d9 Mon Sep 17 00:00:00 2001
> From: Alexander Bokovoy 
> Date: Thu, 9 Jun 2016 12:04:05 +0300
> Subject: [PATCH 7/8] webui: show UPN suffixes in trust properties
> 
> Part of https://fedorahosted.org/freeipa/ticket/5354
> 
> ---
>  install/ui/src/freeipa/trust.js | 11 +++
>  ipaserver/plugins/internal.py   |  2 ++
>  2 files changed, 13 insertions(+)
> 
...
> diff --git a/ipaserver/plugins/internal.py b/ipaserver/plugins/internal.py
> index 4804f64..ea29b16 100644
> --- a/ipaserver/plugins/internal.py
> +++ b/ipaserver/plugins/internal.py
> @@ -747,6 +747,8 @@ class i18n_messages(Command):
>  "trustdirection": _("Trust direction"),
>  "truststatus": _("Trust status"),
>  "trusttype": _("Trust type"),
> +"suffixes": _("UPN suffixes"),
> +"ipantadditionalsuffixes": _("UPN suffixes"),

The AD gui calls the latter 'Alternative UPN suffixes'. Maybe we should
use the same description here as well to avoid irritations?

bye,
Sumit

>  },
>  "trustconfig": {
>  "options": _("Options"),
> -- 
> 2.7.4
> 

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

Re: [Freeipa-devel] [Testplan] Support of UPN for trusted domains

[Sumit Bose]

On Fri, May 27, 2016 at 09:57:37AM +0200, Lenka Doudova wrote:
> Hi all,
> 
> 
> here [1] is a draft of test plan for V4 RFE Support of UPN for trusted
> domains.
> 
> Please review this and let me know if there's something missing or wrong.

Hi Lenka,

thank you for the test plan.

About the TBD, Alexander and I agreed to store the alternative domain
suffixes read from AD in a new attribute in the LDAP object of the
forest root of the trusted domain.

About the kinit tests. Please note that it is expected that the -E
option of kinit must be used when alternative suffixes are used.

I'm not sure if SSSD tests are in the scope here as well. If they are I
would suggest to add authentication tests with SSSD where e.g. the name
with an alternative domain suffix is used as login name. This in general
already works with SSSD but is disabled by default for IPA because of
the missing server-side support so far. Since SSSD must be able to work
with old and new IPA server https://fedorahosted.org/sssd/ticket/3018
was created so that SSSD can detect at runtime if the server supports
this or not.

bye,
Sumit


> 
> 
> Thanks,
> 
> Lenka
> 
> 
> [1]
> http://www.freeipa.org/page/V4/Support_of_UPN_for_trusted_domains/Test_Plan
> 
> -- 
> 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

-- 
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] [PATCHES 0089-0093] Authentication Indicators

[Sumit Bose]

On Tue, May 24, 2016 at 12:21:43PM -0400, Nathaniel McCallum wrote:
> New versions again. This time I just removed the stray "TODO: assign
> OID" line in the commit as it no longer applies.

ACK to patches 1-4.

Patch 5 can be committed independently and needs some additional
discussion, see below.

bye,
Sumit

> 
> On Tue, 2016-05-24 at 12:08 -0400, Nathaniel McCallum wrote:
> > I have attached new versions of the patches. Comments below.
> > 
> > On Tue, 2016-05-24 at 15:25 +0200, Sumit Bose wrote:
> > > On Thu, May 12, 2016 at 05:33:26PM -0400, Nathaniel McCallum wrote:
> > > > On Fri, 2016-05-06 at 14:44 +0200, Sumit Bose wrote:
> > > > > On Wed, May 04, 2016 at 05:33:55PM -0400, Nathaniel McCallum
> > > > > wrote:

...

> > > > From c9e2b50248493fb5a283cf8c88c8e20c312d6348 Mon Sep 17 00:00:00
> > > > 2001
> > > > From: Nathaniel McCallum 
> > > > Date: Wed, 4 May 2016 17:08:45 -0400
> > > > Subject: [PATCH 5/5] Enable service authentication indicator
> > > > management
> > > > 
> > > 
> > > For me the patch looks good, but it would be nice if someone more
> > > used
> > > to our usage of python can have a short look to see if all
> > > conventioens
> > > are met. ACK for the functionality.
> > 
> > I would like for us to merge the first four patches first and then
> > concentrate on this one.
> > 
> > In particular, the following issue needs to be discussed. We
> > currently
> > only have two, hard-coded indicator values: otp and radius. Thus, we
> > use a StrEnum for this property. However, in the long-term, I'd like
> > to
> > have more flexibility; such as per-token indicators. This implies
> > String.
> > 
> > Is there some way to do StrEnum now and easily migrate to String
> > later?
> > I think this will break API. Thoughts?
> > 

-- 
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] [PATCHES 0089-0093] Authentication Indicators

[Sumit Bose]

On Thu, May 12, 2016 at 05:33:26PM -0400, Nathaniel McCallum wrote:
> On Fri, 2016-05-06 at 14:44 +0200, Sumit Bose wrote:
> > On Wed, May 04, 2016 at 05:33:55PM -0400, Nathaniel McCallum wrote:
> > > This series of patches implements authentication indicator
> > > insertion,
> > > evaluation and management in FreeIPA. Besides these patches, two
> > > other
> > > patches are needed to round out support.
> > > 
> > > First, we need a UI patch: https://fedorahosted.org/freeipa/ticket/
> > > 5872
> > > 
> > > Second, we need a SSSD patch to handle the new case where multiple
> > > responders are set (when either 1FA or 2FA can be used).
> > 
> > I've already some initial work done here and will continue with your
> > patches.
> > 
> > > 
> > > Please note that the last patch in this series (0093) is untested
> > > and
> > > simply represents my desire to get these patches off of my hard
> > > disk
> > > before I take a long weekend. This patch also requires mrogers'
> > > patch
> > > 0001 (already merged to master).
> > > 
> > > Also worthy of note is the need for an OID for the authentication
> > > control. Hopefully Simo can assign this after we agree that this
> > > control method is sufficient. One question I had was whether or not
> > > it
> > > would be possible to send the control only on UNIX sockets (0089;
> > > report_auth_method()).
> > > 
> > > Please review the approaches taken here. I plan to hit this hard on
> > > Monday.
> > 
> > I'm on a conference next week and currently busy preparing my
> > presentation. I will give you feedback in the following week.
> 
> Thanks!

sorry for the delay, I was distracted because on some of my VMs OTP in
general does not work anymore. I assume some issue, maybe with libverto
on 32bit systems, but I'm still debugging.

Nevertheless I was able to successfully test the patches in 64bits.

Simo, please see OID assignment request below.

> 
> The attached patches offer the latest version of the work. The only
> major outstanding item that I see is OID assignment (which we can do
> just before committing).
> 
> I have tested the full stack both for appropriate approvals and denials
> across all possible scenarios. In short it works.
> 
> The easiest way to test this is as following:
> 
> # After Clean Install of FreeIPA
> $ kinit admin
> 
> # Add a service allowed by either 1FA or 2FA
> $ ipa service-add ANY/ipa.example.com
> $ ipa-getkeytab -p ANY/ipa.example.com -k /tmp/any.keytab
> 
> # Add a service allowed only by 2FA
> $ ipa service-add OTP/ipa.example.com --auth-ind=otp
> $ ipa-getkeytab -p OTP/ipa.example.com -k /tmp/otp.keytab
> 
> # Add the test user
> $ ipa user-add test --user-auth-type=otp --user-auth-type=password
> $ ipa passwd test
> $ kinit test
> 
> # Try to get tickets for the services
> $ kvno ANY/ipa.example.com # Expected success
> $ kvno OTP/ipa.example.com # Expected failure
> 
> # Add a token and login with 2FA
> $ ipa otptoken-add
> $ kinit -T  test # Log in with 2FA
> 
> # Try to get tickets for the services
> $ kvno ANY/ipa.example.com #
> Expected success
> $ kvno OTP/ipa.example.com # Expected success

> From c9e2b50248493fb5a283cf8c88c8e20c312d6348 Mon Sep 17 00:00:00 2001
> From: Nathaniel McCallum 
> Date: Wed, 4 May 2016 17:08:45 -0400
> Subject: [PATCH 5/5] Enable service authentication indicator management
> 

For me the patch looks good, but it would be nice if someone more used
to our usage of python can have a short look to see if all conventioens
are met. ACK for the functionality.

> From 356daafb001bd868f37f6f0b58338bd0c4da135c Mon Sep 17 00:00:00 2001
> From: Nathaniel McCallum 
> Date: Sun, 21 Feb 2016 19:44:19 -0500
> Subject: [PATCH 4/5] Enable authentication indicators for OTP and RADIUS
> 

ACK

> From c33d0d2af5284a6eb5e50a4f5864f94fa8b3cf21 Mon Sep 17 00:00:00 2001
> From: Nathaniel McCallum 
> Date: Sun, 21 Feb 2016 19:43:52 -0500
> Subject: [PATCH 3/5] Return password-only preauth if passwords are allowed
> 

ACK, on the client krb5_responder_list_questions() return both
"password" and "otp" if the user is configured for both.

Btw, what is the right way for a client to skip "otp" and only do
"password" should something like krb5_responder_otp_set_answer(ctx,
rctx, i, NULL, NULL); work ?

> From 42768f63cdfd47ff3ac0bcdc228fb363b421e2b2 Mon Sep 17 00:00:00 2001
> From: Nathaniel McCallum 
> Date: Thu, 12 May 2016 15:10:47 -0400
> Subject: [PATCH 2/5] Ensure that ipa-otpd

[Freeipa-devel] [PATCH] 0156 extdom: add certificate request

[Sumit Bose]

Hi,

this patch allows the extom plugin to lookup users by certificate which
is needed in the case where a IPA client wants to lookup an AD user who
has the certificate stored in AD. To make this work the related patches
I just send to sssd-devel are needed as well.

Currently the patches miss the change in the required version of SSSD.
since the SSSD patches are not committed. But the patches are needed to
fully test the SSSD patches. I will send a new version with the needed
changes to the minimal SSSD version when the SSSD patches are committed.

bye,
Sumit
From b7b84fb4192af70e784c4cee18ff4be532d0f83f Mon Sep 17 00:00:00 2001
From: Sumit Bose 
Date: Tue, 26 Apr 2016 13:22:40 +0200
Subject: [PATCH] extdom: add certificate request

Related to https://fedorahosted.org/freeipa/ticket/4955
---
 .../ipa-extdom-extop/ipa_extdom.h  |  4 ++-
 .../ipa-extdom-extop/ipa_extdom_common.c   | 31 +-
 2 files changed, 27 insertions(+), 8 deletions(-)

diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h 
b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h
index 
a77711977186b702caafa2729dc13090c6031791..aa7855650789448ae4220b33cc2de858883fe302
 100644
--- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h
+++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h
@@ -80,7 +80,8 @@ enum input_types {
 INP_SID = 1,
 INP_NAME,
 INP_POSIX_UID,
-INP_POSIX_GID
+INP_POSIX_GID,
+INP_CERT
 };
 
 enum request_types {
@@ -115,6 +116,7 @@ struct extdom_req {
 char *domain_name;
 gid_t gid;
 } posix_gid;
+char *cert;
 } data;
 char *err_msg;
 };
diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c 
b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c
index 
823c05c810361f121cb46831fb2d4e846729d792..e629247fd771e374d50486d836cd3b0d8d32a78a
 100644
--- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c
+++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c
@@ -349,6 +349,9 @@ int parse_request_data(struct berval *req_val, struct 
extdom_req **_req)
 &id);
 req->data.posix_gid.gid = (gid_t) id;
 break;
+case INP_CERT:
+tag = ber_scanf(ber, "a}", &req->data.cert);
+break;
 default:
 ber_free(ber, 1);
 set_err_msg(req, "Unknown input type");
@@ -383,6 +386,9 @@ void free_req_data(struct extdom_req *req)
 case INP_POSIX_GID:
 ber_memfree(req->data.posix_gid.domain_name);
 break;
+case INP_CERT:
+ber_memfree(req->data.cert);
+break;
 }
 
 free(req->err_msg);
@@ -861,10 +867,12 @@ done:
 return ret;
 }
 
-static int handle_sid_request(struct ipa_extdom_ctx *ctx,
-  struct extdom_req *req,
-  enum request_types request_type, const char *sid,
-  struct berval **berval)
+static int handle_sid_or_cert_request(struct ipa_extdom_ctx *ctx,
+  struct extdom_req *req,
+  enum request_types request_type,
+  enum input_types input_type,
+  const char *input,
+  struct berval **berval)
 {
 int ret;
 struct passwd pwd;
@@ -878,7 +886,11 @@ static int handle_sid_request(struct ipa_extdom_ctx *ctx,
 enum sss_id_type id_type;
 struct sss_nss_kv *kv_list = NULL;
 
-ret = sss_nss_getnamebysid(sid, &fq_name, &id_type);
+if (input_type == INP_SID) {
+ret = sss_nss_getnamebysid(input, &fq_name, &id_type);
+} else {
+ret = sss_nss_getnamebycert(input, &fq_name, &id_type);
+}
 if (ret != 0) {
 if (ret == ENOENT) {
 ret = LDAP_NO_SUCH_OBJECT;
@@ -1135,8 +1147,13 @@ int handle_request(struct ipa_extdom_ctx *ctx, struct 
extdom_req *req,
 
 break;
 case INP_SID:
-ret = handle_sid_request(ctx, req, req->request_type, req->data.sid,
- berval);
+case INP_CERT:
+ret = handle_sid_or_cert_request(ctx, req, req->request_type,
+ req->input_type,
+ req->input_type == INP_SID ?
+ req->data.sid 
:
+ 
req->data.cert,
+ berval);
 break;
 case INP_NAME:
 ret = handle_name_request(ctx, req, req->request_type,
-- 
2.4.11

-- 
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] [PATCHES 0089-0093] Authentication Indicators

[Sumit Bose]

On Wed, May 04, 2016 at 05:33:55PM -0400, Nathaniel McCallum wrote:
> This series of patches implements authentication indicator insertion,
> evaluation and management in FreeIPA. Besides these patches, two other
> patches are needed to round out support.
> 
> First, we need a UI patch: https://fedorahosted.org/freeipa/ticket/5872
> 
> Second, we need a SSSD patch to handle the new case where multiple
> responders are set (when either 1FA or 2FA can be used).

I've already some initial work done here and will continue with your
patches.

> 
> Please note that the last patch in this series (0093) is untested and
> simply represents my desire to get these patches off of my hard disk
> before I take a long weekend. This patch also requires mrogers' patch
> 0001 (already merged to master).
> 
> Also worthy of note is the need for an OID for the authentication
> control. Hopefully Simo can assign this after we agree that this
> control method is sufficient. One question I had was whether or not it
> would be possible to send the control only on UNIX sockets (0089;
> report_auth_method()).
> 
> Please review the approaches taken here. I plan to hit this hard on
> Monday.

I'm on a conference next week and currently busy preparing my
presentation. I will give you feedback in the following week.

bye,
Sumit

> 
> Nathaniel

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

Re: [Freeipa-devel] [PATCH] 0001 ipa_kdb add krbPrincipalAuthInd handling

[Sumit Bose]

On Mon, May 02, 2016 at 11:47:41AM -0400, Matt Rogers wrote:
> On 05/02, Sumit Bose wrote:
> > On Thu, Apr 28, 2016 at 02:58:07PM -0400, Matt Rogers wrote:
> > > On 04/27, Matt Rogers wrote:
> > > > On 04/27, Sumit Bose wrote:
> > > > > On Tue, Apr 26, 2016 at 02:02:04PM -0400, Matt Rogers wrote:
> > > > > > On 04/26, Sumit Bose wrote:
> > > > > > > On Thu, Apr 14, 2016 at 12:59:55PM -0400, Matt Rogers wrote:
> > > > > > > > 
> > > > > > > > 
> > > > > > > > - Original Message -
> > > > > > > > > From: "Nathaniel McCallum" 
> > > > > > > > > To: "Matt Rogers" , 
> > > > > > > > > freeipa-devel@redhat.com
> > > > > > > > > Sent: Thursday, April 14, 2016 10:32:15 AM
> > > > > > > > > Subject: Re: [Freeipa-devel] [PATCH] 0001 ipa_kdb add 
> > > > > > > > > krbPrincipalAuthInd handling
> > > > > > > > > 
> > > > > > > > > On Mon, 2016-04-11 at 10:41 -0400, Matt Rogers wrote:
> > > > > > > > > > Hi,
> > > > > > > > > > 
> > > > > > > > > > The attached patch is a part of the authentication indicator
> > > > > > > > > > enhancements,
> > > > > > > > > > adding indicator value storage and retrieval for the KDB 
> > > > > > > > > > driver.
> > > > > > > > > > 
> > > > > > > > > > https://fedorahosted.org/freeipa/ticket/5782
> > > > > > > > > 
> > > > > > > > > Can you add some whitespace in next_attr()? The density of 
> > > > > > > > > the code
> > > > > > > > > there hurts readability.
> > > > > > > > > 
> > > > > > > > Sure, I've attached the revised patch.
> > > > > > > 
> > > > > > > Hi Matt,
> > > > > > > 
> > > > > > > thank you for the patch. Currently I have the following question.
> > > > > > > 
> > > > > > > You call krb5_dbe_set_string to remove the 'require_auth' data 
> > > > > > > before
> > > > > > > calling ipadb_get_ldap_mod_extra_data()
> > > > > > > 
> > > > > > 
> > > > > > > > +/* Delete authinds from tl_data so it is not included 
> > > > > > > > in krbExtraData. */
> > > > > > > > +kerr = krb5_dbe_set_string(kcontext, entry, 
> > > > > > > > "require_auth", NULL);
> > > > > > > > +if (kerr) {
> > > > > > > > +goto done;
> > > > > > > > +}
> > > > > > > > +
> > > > > > > >  kerr = ipadb_get_ldap_mod_extra_data(imods,
> > > > > > > >   entry->tl_data,
> > > > > > > >   mod_op);
> > > > > > > > 
> > > > > > > 
> > > > > > > Why it is needed to filter this data again in
> > > > > > > ipadb_get_ldap_mod_extra_data()?
> > > > > > > 
> > > > > > 
> > > > > > Hi Sumit, thanks for looking. The above krb5_dbe_set_string() call I
> > > > > > believe I left there in error - We decided to operate on a filtered 
> > > > > > copy
> > > > > > of the tl_data (which filter_authind_str_attrs() handles) rather 
> > > > > > than
> > > > > > removing it completely with krb5_dbe_set_string(). I had tested 
> > > > > > with the
> > > > > > above code commented out but forgot to remove it with the submitted 
> > > > > > patch.
> > > > > 
> > > > > ok, makes sense.
> > > > > 
> > > > > Nevertheless, comments in kdb.h like:
> > > > > 
> > > > > /* String attributes (currently stored inside tl-data) map C string 
> > > > > keys to
> > > > >  * values.  They can be set via kadmin and consumed by KDC plugin

Re: [Freeipa-devel] [PATCH] 0001 ipa_kdb add krbPrincipalAuthInd handling

[Sumit Bose]

On Thu, Apr 28, 2016 at 02:58:07PM -0400, Matt Rogers wrote:
> On 04/27, Matt Rogers wrote:
> > On 04/27, Sumit Bose wrote:
> > > On Tue, Apr 26, 2016 at 02:02:04PM -0400, Matt Rogers wrote:
> > > > On 04/26, Sumit Bose wrote:
> > > > > On Thu, Apr 14, 2016 at 12:59:55PM -0400, Matt Rogers wrote:
> > > > > > 
> > > > > > 
> > > > > > - Original Message -
> > > > > > > From: "Nathaniel McCallum" 
> > > > > > > To: "Matt Rogers" , freeipa-devel@redhat.com
> > > > > > > Sent: Thursday, April 14, 2016 10:32:15 AM
> > > > > > > Subject: Re: [Freeipa-devel] [PATCH] 0001 ipa_kdb add 
> > > > > > > krbPrincipalAuthInd handling
> > > > > > > 
> > > > > > > On Mon, 2016-04-11 at 10:41 -0400, Matt Rogers wrote:
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > The attached patch is a part of the authentication indicator
> > > > > > > > enhancements,
> > > > > > > > adding indicator value storage and retrieval for the KDB driver.
> > > > > > > > 
> > > > > > > > https://fedorahosted.org/freeipa/ticket/5782
> > > > > > > 
> > > > > > > Can you add some whitespace in next_attr()? The density of the 
> > > > > > > code
> > > > > > > there hurts readability.
> > > > > > > 
> > > > > > Sure, I've attached the revised patch.
> > > > > 
> > > > > Hi Matt,
> > > > > 
> > > > > thank you for the patch. Currently I have the following question.
> > > > > 
> > > > > You call krb5_dbe_set_string to remove the 'require_auth' data before
> > > > > calling ipadb_get_ldap_mod_extra_data()
> > > > > 
> > > > 
> > > > > > +/* Delete authinds from tl_data so it is not included in 
> > > > > > krbExtraData. */
> > > > > > +kerr = krb5_dbe_set_string(kcontext, entry, 
> > > > > > "require_auth", NULL);
> > > > > > +if (kerr) {
> > > > > > +goto done;
> > > > > > +}
> > > > > > +
> > > > > >  kerr = ipadb_get_ldap_mod_extra_data(imods,
> > > > > >   entry->tl_data,
> > > > > >   mod_op);
> > > > > > 
> > > > > 
> > > > > Why it is needed to filter this data again in
> > > > > ipadb_get_ldap_mod_extra_data()?
> > > > > 
> > > > 
> > > > Hi Sumit, thanks for looking. The above krb5_dbe_set_string() call I
> > > > believe I left there in error - We decided to operate on a filtered copy
> > > > of the tl_data (which filter_authind_str_attrs() handles) rather than
> > > > removing it completely with krb5_dbe_set_string(). I had tested with the
> > > > above code commented out but forgot to remove it with the submitted 
> > > > patch.
> > > 
> > > ok, makes sense.
> > > 
> > > Nevertheless, comments in kdb.h like:
> > > 
> > > /* String attributes (currently stored inside tl-data) map C string keys 
> > > to
> > >  * values.  They can be set via kadmin and consumed by KDC plugins. */
> > > 
> > > and
> > > 
> > > /* String attributes may not always be represented in tl-data.  kadmin 
> > > clients
> > >  * must use the get_strings and set_string RPCs. */
> > > 
> > > make me wonder if it is a good idea to operate on the tl-data of type
> > > KRB5_TL_STRING_ATTRS directly? I know we do this in other places as well
> > > so I'm not insisting to change it, I'm just wondering about the reasons.
> > > 
> > > Would something like (error checks are missing)
> > > 
> > > kerr = krb5_dbe_get_string(kcontext, entry, "require_auth",
> > >&require_auth_str);
> > > 
> > > if (require_auth_str != NULL) {
> > > kerr = krb5_dbe_set_string(kcontext, entry, "require_auth", NULL);
> > > }
> > > 
> > > kerr = ipa

Re: [Freeipa-devel] [PATCH] 0001 ipa_kdb add krbPrincipalAuthInd handling

[Sumit Bose]

On Tue, Apr 26, 2016 at 02:02:04PM -0400, Matt Rogers wrote:
> On 04/26, Sumit Bose wrote:
> > On Thu, Apr 14, 2016 at 12:59:55PM -0400, Matt Rogers wrote:
> > > 
> > > 
> > > - Original Message -
> > > > From: "Nathaniel McCallum" 
> > > > To: "Matt Rogers" , freeipa-devel@redhat.com
> > > > Sent: Thursday, April 14, 2016 10:32:15 AM
> > > > Subject: Re: [Freeipa-devel] [PATCH] 0001 ipa_kdb add 
> > > > krbPrincipalAuthInd handling
> > > > 
> > > > On Mon, 2016-04-11 at 10:41 -0400, Matt Rogers wrote:
> > > > > Hi,
> > > > > 
> > > > > The attached patch is a part of the authentication indicator
> > > > > enhancements,
> > > > > adding indicator value storage and retrieval for the KDB driver.
> > > > > 
> > > > > https://fedorahosted.org/freeipa/ticket/5782
> > > > 
> > > > Can you add some whitespace in next_attr()? The density of the code
> > > > there hurts readability.
> > > > 
> > > Sure, I've attached the revised patch.
> > 
> > Hi Matt,
> > 
> > thank you for the patch. Currently I have the following question.
> > 
> > You call krb5_dbe_set_string to remove the 'require_auth' data before
> > calling ipadb_get_ldap_mod_extra_data()
> > 
> 
> > > +/* Delete authinds from tl_data so it is not included in 
> > > krbExtraData. */
> > > +kerr = krb5_dbe_set_string(kcontext, entry, "require_auth", 
> > > NULL);
> > > +if (kerr) {
> > > +goto done;
> > > +}
> > > +
> > >  kerr = ipadb_get_ldap_mod_extra_data(imods,
> > >   entry->tl_data,
> > >   mod_op);
> > > 
> > 
> > Why it is needed to filter this data again in
> > ipadb_get_ldap_mod_extra_data()?
> > 
> 
> Hi Sumit, thanks for looking. The above krb5_dbe_set_string() call I
> believe I left there in error - We decided to operate on a filtered copy
> of the tl_data (which filter_authind_str_attrs() handles) rather than
> removing it completely with krb5_dbe_set_string(). I had tested with the
> above code commented out but forgot to remove it with the submitted patch.

ok, makes sense.

Nevertheless, comments in kdb.h like:

/* String attributes (currently stored inside tl-data) map C string keys to
 * values.  They can be set via kadmin and consumed by KDC plugins. */

and

/* String attributes may not always be represented in tl-data.  kadmin clients
 * must use the get_strings and set_string RPCs. */

make me wonder if it is a good idea to operate on the tl-data of type
KRB5_TL_STRING_ATTRS directly? I know we do this in other places as well
so I'm not insisting to change it, I'm just wondering about the reasons.

Would something like (error checks are missing)

kerr = krb5_dbe_get_string(kcontext, entry, "require_auth",
   &require_auth_str);

if (require_auth_str != NULL) {
kerr = krb5_dbe_set_string(kcontext, entry, "require_auth", NULL);
}

kerr = ipadb_get_ldap_mod_extra_data(imods,
 entry->tl_data,
 mod_op);

if (require_auth_str != NULL) {
kerr = krb5_dbe_set_string(kcontext, entry, "require_auth",
   require_auth_str);
}

have the same effect with only using the recommended API (and making the
patch smaller)?

bye,
Sumit

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

Re: [Freeipa-devel] [PATCH] 0001 ipa_kdb add krbPrincipalAuthInd handling

[Sumit Bose]

On Thu, Apr 14, 2016 at 12:59:55PM -0400, Matt Rogers wrote:
> 
> 
> - Original Message -
> > From: "Nathaniel McCallum" 
> > To: "Matt Rogers" , freeipa-devel@redhat.com
> > Sent: Thursday, April 14, 2016 10:32:15 AM
> > Subject: Re: [Freeipa-devel] [PATCH] 0001 ipa_kdb add krbPrincipalAuthInd 
> > handling
> > 
> > On Mon, 2016-04-11 at 10:41 -0400, Matt Rogers wrote:
> > > Hi,
> > > 
> > > The attached patch is a part of the authentication indicator
> > > enhancements,
> > > adding indicator value storage and retrieval for the KDB driver.
> > > 
> > > https://fedorahosted.org/freeipa/ticket/5782
> > 
> > Can you add some whitespace in next_attr()? The density of the code
> > there hurts readability.
> > 
> Sure, I've attached the revised patch.

Hi Matt,

thank you for the patch. Currently I have the following question.

You call krb5_dbe_set_string to remove the 'require_auth' data before
calling ipadb_get_ldap_mod_extra_data()

> +/* Delete authinds from tl_data so it is not included in 
> krbExtraData. */
> +kerr = krb5_dbe_set_string(kcontext, entry, "require_auth", NULL);
> +if (kerr) {
> +goto done;
> +}
> +
>  kerr = ipadb_get_ldap_mod_extra_data(imods,
>   entry->tl_data,
>   mod_op);
> 

Why it is needed to filter this data again in
ipadb_get_ldap_mod_extra_data()?

> +
>  static krb5_error_code ipadb_get_ldap_mod_extra_data(struct ipadb_mods 
> *imods,
>   krb5_tl_data *tl_data,
>   int mod_op)
>  {
>  krb5_error_code kerr;
>  krb5_tl_data *data;
> +krb5_tl_data *data_tmp = NULL;
>  struct berval **bvs = NULL;
>  krb5_int16 be_type;
>  int n, i;
> @@ -1463,6 +1663,20 @@ static krb5_error_code 
> ipadb_get_ldap_mod_extra_data(struct ipadb_mods *imods,
>  continue;
>  }
>  
> +/* Exclude any auth indicators from krbExtraData */
> +kerr = filter_authind_str_attrs(data, &data_tmp);
> +if (kerr) {
> +goto done;
> +}
> +if (data_tmp != NULL) {
> +if (data_tmp->tl_data_contents == NULL) {
> +free(data_tmp);
> +data_tmp = NULL;
> +continue;
> +}
> +data = data_tmp;
> +}
> +
>  be_type = htons(data->tl_data_type);
>  
>  bvs[i] = calloc(1, sizeof(struct berval));

bye,
Sumit

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

Re: [Freeipa-devel] [PATCH 0405] idviews: Add user certificate attribute to user ID overrides

[Sumit Bose]

On Mon, Apr 04, 2016 at 04:27:02PM +0200, Jan Cholasta wrote:
> Hi,
> 
> On 1.4.2016 16:53, Tomas Babej wrote:
> >Hi,
> >
> >this extends the user ID overrides with capability to store the user
> >certificate.
> >
> >https://fedorahosted.org/freeipa/ticket/4955
> 
> The preferred way of managing certificates nowadays is using $OBJ-add-cert
> and $OBJ-remove-cert commands, you should add them here as well.
> 
> I would even go as far as not allowing to modify certificates using
> idoverrideuser-mod - in user-mod and host-mod, it's there just for backward
> compatibility, which is not the case here. But I don't have a strong opinion
> on that.
> 
> For consistency with user-find and host-find, the full certificate blob
> should not be shown in idoverrideuser-find. You can do that by setting
> search_display_attributes attribute on the idoverrideuser class
> appropriately.

I tested the current patch with my related patches for SSSD and all is
working as expected.

bye,
Sumit

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

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

Re: [Freeipa-devel] [PATCH] SPEC: Remove unused build dependency on libwbclient

[Sumit Bose]

On Wed, Mar 09, 2016 at 09:59:06AM +0100, Lukas Slebodnik wrote:
> ehlo,
> 
> simple patch is attached.
> 
> LS

> >From 3fe91e54c11245c3a773bc2cff5504b7a5f6ad16 Mon Sep 17 00:00:00 2001
> From: Lukas Slebodnik 
> Date: Wed, 9 Mar 2016 09:53:07 +0100
> Subject: [PATCH] SPEC: Remove unused build dependency on libwbclient
> 
> The string "wbclient" is not mentioned anywhere in
> source code and there isn't any issue with building
> freeipa packages without this package.

ACK

This is a left-over form the times where we used winbind to look up AD
users. With the ipa server mode of SSSD this is not needed anymore.

bye,
Sumit

> ---
>  BUILD.txt   | 2 +-
>  freeipa.spec.in | 1 -
>  2 files changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/BUILD.txt b/BUILD.txt
> index 
> fb1a7996b6b0c69c5431b180eec65c2549448d91..d9484956dc4449fa43ff0a1146ca9cdf5b3e021e
>  100644
> --- a/BUILD.txt
> +++ b/BUILD.txt
> @@ -16,7 +16,7 @@ or
>  This is currently (2015-05-07):
>  
>  yum install rpm-build 389-ds-base-devel svrcore-devel policycoreutils \
> -systemd-units samba-devel samba-python libwbclient-devel libtalloc-devel \
> +systemd-units samba-devel samba-python libtalloc-devel \
>  libtevent-devel nspr-devel nss-devel openssl-devel openldap-devel krb5-devel 
> \
>  krb5-workstation libuuid-devel libcurl-devel xmlrpc-c-devel popt-devel \
>  autoconf automake m4 libtool gettext python-devel python-ldap \
> diff --git a/freeipa.spec.in b/freeipa.spec.in
> index 
> bc47df4c916bd8f091fc2f70330d95bd116ad187..9e277020d70215e052ab6c905b1c6a29ae6cdd4d
>  100644
> --- a/freeipa.spec.in
> +++ b/freeipa.spec.in
> @@ -48,7 +48,6 @@ BuildRequires:  policycoreutils >= 2.1.12-5
>  BuildRequires:  systemd-units
>  BuildRequires:  samba-devel >= %{samba_version}
>  BuildRequires:  samba-python
> -BuildRequires:  libwbclient-devel
>  BuildRequires:  libtalloc-devel
>  BuildRequires:  libtevent-devel
>  %endif # ONLY_CLIENT
> -- 
> 2.7.2
> 

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

-- 
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] Supporting UPNs of trusted forests

[Sumit Bose]

On Wed, Mar 02, 2016 at 05:24:55PM +0200, Alexander Bokovoy wrote:
> On Wed, 02 Mar 2016, Petr Vobornik wrote:
> >On 03/02/2016 11:55 AM, Alexander Bokovoy wrote:
> >>Hi,
> >>
> >>http://www.freeipa.org/page/V4/Support_of_UPN_for_trusted_domains
> >>describes a design page to support name suffixes from trusted Active
> >>Directory domains.
> >>
> >>A prototype code exists (written by me and Sumit) and was tested by Sumit
> >>against recent releases of SSSD.
> >>
> >>Text is provided below for easier commenting.
> >>-
> >>{{Feature|version=TODO|ticket=TODO|author=Ab}}
> >>
> >>== Overview ==
> >>User principal name (UPN) in Active Directory is the primary form of
> >>addressing users. UPN has structure of 'user name@suffix' where both
> >>user name and suffix parts may vary. By default the suffix is the same
> >>as the Active Directory domain name but AD administrators may create
> >>additional name suffixes and associate them with specific users. These
> >>additional UPNs for users may then be used for Kerberos authentication
> >>against Active Directory domains.
> >>
> >>Alternative UPNs are often used when several companies with Active
> >>Directory deployments merge and want to provide unified logon namespace.
> >>
> >>The purpose of this feature is to allow using alternative UPNs
> >>associated with the Active Directory users when accessing resources in
> >>FreeIPA domain.
> >>
> >>== Use Cases ==
> >>
> >>As an Active Directory user, I want to login using my user@EXAMPLE user
> >>principal name even if my Active Directory domain is named
> >>REGION.EXAMPLE.COM.
> >>== Design==
> >>Support for UPNs is split to three different components:
> >>;Client-side
> >>: SSSD already supports logon with UPN by asking a KDC to accept
> >>enterprise logon names.  By default, the use of enterprise principals is
> >>disabled, therefore, krb5_use_enterprise_principal = True
> >>needs to be added to sssd.conf to enable it.
> >>
> >>;KDC
> >>: IPA KDC does understand multiple domains associated with the trusted
> >>AD forest. However, since no information about name suffixes associated
> >>with the forest is available, it cannot take them into account when
> >>processing enteprise logon names to issue referrals to the correct
> >>realm. Support needs to be added to allow IPA KDC to look up name
> >>suffixes associated with a trusted forest.
> >>
> >>; IPA framework
> >>: Changes needed on IPA framework side to fetch from Active Directory a
> >>list of name suffixes and store them in the trusted domain objects.
> >>
> >>== Implementation ==
> >>For retrieving name suffixes, IPA framework needs to move to use
> >>NETLOGON netr_DsRGetForestTrustInformation function instead of
> >>netr_DsrEnumerateDomainTrusts. This allows to retrieve both domains and
> >>top level names associated with the forest.
> >>
> >>As top level names (TLNs) have only a single string as a name suffix,
> >>they cannot be stored as trusted domains (they lack SID and NetBIOS
> >>name). Thus, either IPA KDB driver needs to be extended to understand
> >>trusted domains without SID and NetBIOS name, or TLNs need to be stored
> >>as a property of tree root domains of the forest.
> >>
> >>== Feature Management ==
> >>
> >>=== UI ===
> >>If TLNs are added as a property of tree root domains of the forest,
> >>appropriate panel needs to be extended to display them.
> >>
> >>=== CLI ===
> >>If TLNs are added as a property of tree root domains of the forest,
> >>appropriate attribute need to be handled by '''trust-show''' command. If
> >>TLNs represented as separate 'trusted domains' of the trusted forest, no
> >>work is needed on CLI other than being able to support 'trusted domains'
> >>without SID and NetBIOS name.
> >
> >What is meant by 'tree root domains of the forest' in IPA context? The
> >trust object?
> Yes. A forest might have multiple tree roots. We establish trust with
> one of them (forest root domain) but you can have distinct tree roots
> too. For a forest example.com a separate tree root could be ad.test
> which is still a part of the forest. In Windows' UI for domains and
> forests trust you'll see it as a separate entry at the top level. Each
> tree root may have associated name suffixes.

But I thought they still can be used across the whole forest, e.g. if
you assign an alternative domain suffix in the UI of ad.test you can use
this suffix for users from example.com as well?


bye,
Sumit

> 
> There are actually two different approaches we discussed with Sumit
> -- one is to store TLNs as attributes of TDO, another is to create
> separate TDOs, building on the fact you noticed:
> >Btw trustdomain object has ipantflatname and ipanttrusteddomainsid
> >attributes as optional so it is possible to store it there assuming
> >modification of KDB driver.
> This is what I did already in the prototype: 
> https://abbra.fedorapeople.org/.paste/0001-WIP-support-UPNs-for-trusted-domain-users

Re: [Freeipa-devel] Supporting UPNs of trusted forests

[Sumit Bose]

On Wed, Mar 02, 2016 at 04:06:24PM +0100, Petr Vobornik wrote:
> On 03/02/2016 11:55 AM, Alexander Bokovoy wrote:
> >Hi,
> >
> >http://www.freeipa.org/page/V4/Support_of_UPN_for_trusted_domains
> >describes a design page to support name suffixes from trusted Active
> >Directory domains.
> >
> >A prototype code exists (written by me and Sumit) and was tested by Sumit
> >against recent releases of SSSD.
> >
> >Text is provided below for easier commenting.
> >-
> >{{Feature|version=TODO|ticket=TODO|author=Ab}}
> >
> >== Overview ==
> >User principal name (UPN) in Active Directory is the primary form of
> >addressing users. UPN has structure of 'user name@suffix' where both
> >user name and suffix parts may vary. By default the suffix is the same
> >as the Active Directory domain name but AD administrators may create
> >additional name suffixes and associate them with specific users. These
> >additional UPNs for users may then be used for Kerberos authentication
> >against Active Directory domains.
> >
> >Alternative UPNs are often used when several companies with Active
> >Directory deployments merge and want to provide unified logon namespace.
> >
> >The purpose of this feature is to allow using alternative UPNs
> >associated with the Active Directory users when accessing resources in
> >FreeIPA domain.
> >
> >== Use Cases ==
> >
> >As an Active Directory user, I want to login using my user@EXAMPLE user
> >principal name even if my Active Directory domain is named
> >REGION.EXAMPLE.COM.
> >== Design==
> >Support for UPNs is split to three different components:
> >;Client-side
> >: SSSD already supports logon with UPN by asking a KDC to accept
> >enterprise logon names.  By default, the use of enterprise principals is
> >disabled, therefore, krb5_use_enterprise_principal = True
> >needs to be added to sssd.conf to enable it.
> >
> >;KDC
> >: IPA KDC does understand multiple domains associated with the trusted
> >AD forest. However, since no information about name suffixes associated
> >with the forest is available, it cannot take them into account when
> >processing enteprise logon names to issue referrals to the correct
> >realm. Support needs to be added to allow IPA KDC to look up name
> >suffixes associated with a trusted forest.
> >
> >; IPA framework
> >: Changes needed on IPA framework side to fetch from Active Directory a
> >list of name suffixes and store them in the trusted domain objects.
> >
> >== Implementation ==
> >For retrieving name suffixes, IPA framework needs to move to use
> >NETLOGON netr_DsRGetForestTrustInformation function instead of
> >netr_DsrEnumerateDomainTrusts. This allows to retrieve both domains and
> >top level names associated with the forest.
> >
> >As top level names (TLNs) have only a single string as a name suffix,
> >they cannot be stored as trusted domains (they lack SID and NetBIOS
> >name). Thus, either IPA KDB driver needs to be extended to understand
> >trusted domains without SID and NetBIOS name, or TLNs need to be stored
> >as a property of tree root domains of the forest.
> >
> >== Feature Management ==
> >
> >=== UI ===
> >If TLNs are added as a property of tree root domains of the forest,
> >appropriate panel needs to be extended to display them.
> >
> >=== CLI ===
> >If TLNs are added as a property of tree root domains of the forest,
> >appropriate attribute need to be handled by '''trust-show''' command. If
> >TLNs represented as separate 'trusted domains' of the trusted forest, no
> >work is needed on CLI other than being able to support 'trusted domains'
> >without SID and NetBIOS name.
> 
> What is meant by 'tree root domains of the forest' in IPA context? The trust
> object?

yes

> 
> Btw trustdomain object has ipantflatname and ipanttrusteddomainsid
> attributes as optional so it is possible to store it there assuming
> modification of KDB driver.

yes, Alexander has a POC patch which does exactly that. Nevertheless I
would prefer to store the list in the ipaNTTrustedDomain object of the
forest root where we also store the SID blacklist. I think this makes
sense because the alternative domain suffixes are a feature of the whole
forest. Any domain in the forest can use them and they basically have no
meaning on their own.

Additionally I think it is more clear the have them in properly named
attributes than adding some heuristics like:

ipaNTTrustedDomain with no SID and flat name == alternative domain
suffix
ipaNTTrustedDomain with SID and flat name and nothing else == member
  domain in
  the trusted forest

ipaNTTrustedDomain with SID, flat name and more == forest root

bye,
Sumit

> 
> >
> >=== Configuration ===
> >No configuration options.
> >
> >== Upgrade ==
> >No impact to upgrade.
> >
> >== How to Test ==
> >In orde

Re: [Freeipa-devel] IPA client realm/domain autodiscovery improvements

[Sumit Bose]

On Wed, Feb 24, 2016 at 04:08:14PM +0100, David Kupka wrote:
> On 24/02/16 15:55, Sumit Bose wrote:
> >On Wed, Feb 24, 2016 at 03:30:40PM +0100, Martin Babinsky wrote:
> >>On 02/24/2016 03:20 PM, Sumit Bose wrote:
> >>>On Wed, Feb 24, 2016 at 01:31:55PM +0100, Petr Vobornik wrote:
> >>>>On 02/16/2016 02:23 PM, Martin Babinsky wrote:
> >>>>>Hi list,
> >>>>>
> >>>>>WARNING: huge brain dump ahead.
> >>>>>
> >>>>>During investigation of https://fedorahosted.org/freeipa/ticket/4305 me
> >>>>>and Petr Spaced (CC'ed) came to a conclusion that the IPA realm
> >>>>>autodiscovery code used by ipa-client-install is so convoluted, complex
> >>>>>and hard to understand that the cost of fixing a bug/adding a behavioral
> >>>>>change (there are some other tickets dealing with ipadiscovery, e.g. see
> >>>>>https://fedorahosted.org/freeipa/ticket/5270
> >>>>>https://fedorahosted.org/freeipa/ticket/3912 ) can potentially be higher
> >>>>>that a more large-scale rewrite of the module and related codebase.
> >>>>>
> >>>>>Since we plan to do some general refactoring work anyway, I would like
> >>>>>to discuss the possible course of action we may take to tackle this
> >>>>>issue. I would like to present the following options we have been
> >>>>>discussing so far:
> >>>>>
> >>>>>1.) Do a substantial rewrite of existing code 
> >>>>>("ipaclient/ipadiscovery.py")
> >>>>>
> >>>>>We may take the existing IPADiscovery class and try rewrite it in order
> >>>>>to get a more concise and deterministic code, which will:
> >>>>>
> >>>>>* rely more on python-dns and answers provided by resolver (e.g. we are
> >>>>>directly parsing resolv.conf for available domains when we can ask the
> >>>>>resolver to get domains for us)
> >>>>>* be more pythonic (replace error codes with thrown exceptions, clean up
> >>>>>numerous C-isms etc.)
> >>>>>* not try to outsmart user when server/realm/domain is specified
> >>>>>beforehand. Currently, even if you specify all three options, there is
> >>>>>still some DNS discovery performed, hence bug #4305. I think that one
> >>>>>you specify server(s), not magic should be performed and the discovery
> >>>>>process should be reduced to checking whether they are IPA servers and
> >>>>>pull all other info (like realm) from them.
> >>>>>
> >>>>>This may be a considerable effort requiring some time to implement and
> >>>>>get right, but IMHO still comparable to the time spent iteratively
> >>>>>placing 'if' statements into the existing code and hoping to not break
> >>>>>anything. I would even argue it is not worth the effort because we can
> >>>>>
> >>>>>2.) Use realmd dbus interface to do DNS discovery
> >>>>>
> >>>>>I have attached aquick and dirty script I have slapped together to
> >>>>>leverage 'org.freedesktop.realmd.Discover' interface to do IPA realm
> >>>>>discovery for us. This has a lot of appeal to me since we are leveraging
> >>>>>existing codebase for DNS discovery and will have to handle only cases
> >>>>>when the user manually specifies a list of IPA servers for the client.
> >>>>>
> >>>>>This however pulls in realmd as a (potentially circular) dependency for
> >>>>>ipa client, and when we find bug in the discovery code, we will have to
> >>>>>poke upstream (Stef or Sumit I think) to fix it.
> >>>>>
> >>>>>So from the long-term point of view, Jan Cholasta's (CC'ed) suggestion 
> >>>>>to:
> >>>>>
> >>>>>3.) Split out IPA discovery portion of realmd to a separate C library
> >>>>>shared between IPA and realmd
> >>>>>
> >>>>>may be best. Both projects will have shared codebase (maintained either
> >>>>>by us or realmd devs), which can be reused also by other people to
> >>>>>create their own discovery/enrollment solution. This would however
> >>>>>require sustained and concerted efforts of both teams

Re: [Freeipa-devel] IPA client realm/domain autodiscovery improvements

[Sumit Bose]

On Wed, Feb 24, 2016 at 03:30:40PM +0100, Martin Babinsky wrote:
> On 02/24/2016 03:20 PM, Sumit Bose wrote:
> >On Wed, Feb 24, 2016 at 01:31:55PM +0100, Petr Vobornik wrote:
> >>On 02/16/2016 02:23 PM, Martin Babinsky wrote:
> >>>Hi list,
> >>>
> >>>WARNING: huge brain dump ahead.
> >>>
> >>>During investigation of https://fedorahosted.org/freeipa/ticket/4305 me
> >>>and Petr Spaced (CC'ed) came to a conclusion that the IPA realm
> >>>autodiscovery code used by ipa-client-install is so convoluted, complex
> >>>and hard to understand that the cost of fixing a bug/adding a behavioral
> >>>change (there are some other tickets dealing with ipadiscovery, e.g. see
> >>>https://fedorahosted.org/freeipa/ticket/5270
> >>>https://fedorahosted.org/freeipa/ticket/3912 ) can potentially be higher
> >>>that a more large-scale rewrite of the module and related codebase.
> >>>
> >>>Since we plan to do some general refactoring work anyway, I would like
> >>>to discuss the possible course of action we may take to tackle this
> >>>issue. I would like to present the following options we have been
> >>>discussing so far:
> >>>
> >>>1.) Do a substantial rewrite of existing code ("ipaclient/ipadiscovery.py")
> >>>
> >>>We may take the existing IPADiscovery class and try rewrite it in order
> >>>to get a more concise and deterministic code, which will:
> >>>
> >>>* rely more on python-dns and answers provided by resolver (e.g. we are
> >>>directly parsing resolv.conf for available domains when we can ask the
> >>>resolver to get domains for us)
> >>>* be more pythonic (replace error codes with thrown exceptions, clean up
> >>>numerous C-isms etc.)
> >>>* not try to outsmart user when server/realm/domain is specified
> >>>beforehand. Currently, even if you specify all three options, there is
> >>>still some DNS discovery performed, hence bug #4305. I think that one
> >>>you specify server(s), not magic should be performed and the discovery
> >>>process should be reduced to checking whether they are IPA servers and
> >>>pull all other info (like realm) from them.
> >>>
> >>>This may be a considerable effort requiring some time to implement and
> >>>get right, but IMHO still comparable to the time spent iteratively
> >>>placing 'if' statements into the existing code and hoping to not break
> >>>anything. I would even argue it is not worth the effort because we can
> >>>
> >>>2.) Use realmd dbus interface to do DNS discovery
> >>>
> >>>I have attached aquick and dirty script I have slapped together to
> >>>leverage 'org.freedesktop.realmd.Discover' interface to do IPA realm
> >>>discovery for us. This has a lot of appeal to me since we are leveraging
> >>>existing codebase for DNS discovery and will have to handle only cases
> >>>when the user manually specifies a list of IPA servers for the client.
> >>>
> >>>This however pulls in realmd as a (potentially circular) dependency for
> >>>ipa client, and when we find bug in the discovery code, we will have to
> >>>poke upstream (Stef or Sumit I think) to fix it.
> >>>
> >>>So from the long-term point of view, Jan Cholasta's (CC'ed) suggestion to:
> >>>
> >>>3.) Split out IPA discovery portion of realmd to a separate C library
> >>>shared between IPA and realmd
> >>>
> >>>may be best. Both projects will have shared codebase (maintained either
> >>>by us or realmd devs), which can be reused also by other people to
> >>>create their own discovery/enrollment solution. This would however
> >>>require sustained and concerted efforts of both teams to create the
> >>>library and possibly rewrite realmd to accommodate this change.
> >>>
> >>>There may be some other options viable for us, if so please mention them
> >>>in a reply. Also please correct any piece of information I got wrong.
> >>>
> >>>TL;DR: IPA realm/domain discovery is a mess, please suggest a way to fix
> >>>it.
> >>>
> >>
> >>#3 sounds good from long term perspective.
> >>
> >>In short term, i.e., #4305, we should skip discovery when --on-master is
> >>used.
> >
> >I would prefer #2. Because a

Re: [Freeipa-devel] IPA client realm/domain autodiscovery improvements

[Sumit Bose]

On Wed, Feb 24, 2016 at 01:31:55PM +0100, Petr Vobornik wrote:
> On 02/16/2016 02:23 PM, Martin Babinsky wrote:
> >Hi list,
> >
> >WARNING: huge brain dump ahead.
> >
> >During investigation of https://fedorahosted.org/freeipa/ticket/4305 me
> >and Petr Spaced (CC'ed) came to a conclusion that the IPA realm
> >autodiscovery code used by ipa-client-install is so convoluted, complex
> >and hard to understand that the cost of fixing a bug/adding a behavioral
> >change (there are some other tickets dealing with ipadiscovery, e.g. see
> >https://fedorahosted.org/freeipa/ticket/5270
> >https://fedorahosted.org/freeipa/ticket/3912 ) can potentially be higher
> >that a more large-scale rewrite of the module and related codebase.
> >
> >Since we plan to do some general refactoring work anyway, I would like
> >to discuss the possible course of action we may take to tackle this
> >issue. I would like to present the following options we have been
> >discussing so far:
> >
> >1.) Do a substantial rewrite of existing code ("ipaclient/ipadiscovery.py")
> >
> >We may take the existing IPADiscovery class and try rewrite it in order
> >to get a more concise and deterministic code, which will:
> >
> >* rely more on python-dns and answers provided by resolver (e.g. we are
> >directly parsing resolv.conf for available domains when we can ask the
> >resolver to get domains for us)
> >* be more pythonic (replace error codes with thrown exceptions, clean up
> >numerous C-isms etc.)
> >* not try to outsmart user when server/realm/domain is specified
> >beforehand. Currently, even if you specify all three options, there is
> >still some DNS discovery performed, hence bug #4305. I think that one
> >you specify server(s), not magic should be performed and the discovery
> >process should be reduced to checking whether they are IPA servers and
> >pull all other info (like realm) from them.
> >
> >This may be a considerable effort requiring some time to implement and
> >get right, but IMHO still comparable to the time spent iteratively
> >placing 'if' statements into the existing code and hoping to not break
> >anything. I would even argue it is not worth the effort because we can
> >
> >2.) Use realmd dbus interface to do DNS discovery
> >
> >I have attached aquick and dirty script I have slapped together to
> >leverage 'org.freedesktop.realmd.Discover' interface to do IPA realm
> >discovery for us. This has a lot of appeal to me since we are leveraging
> >existing codebase for DNS discovery and will have to handle only cases
> >when the user manually specifies a list of IPA servers for the client.
> >
> >This however pulls in realmd as a (potentially circular) dependency for
> >ipa client, and when we find bug in the discovery code, we will have to
> >poke upstream (Stef or Sumit I think) to fix it.
> >
> >So from the long-term point of view, Jan Cholasta's (CC'ed) suggestion to:
> >
> >3.) Split out IPA discovery portion of realmd to a separate C library
> >shared between IPA and realmd
> >
> >may be best. Both projects will have shared codebase (maintained either
> >by us or realmd devs), which can be reused also by other people to
> >create their own discovery/enrollment solution. This would however
> >require sustained and concerted efforts of both teams to create the
> >library and possibly rewrite realmd to accommodate this change.
> >
> >There may be some other options viable for us, if so please mention them
> >in a reply. Also please correct any piece of information I got wrong.
> >
> >TL;DR: IPA realm/domain discovery is a mess, please suggest a way to fix
> >it.
> >
> 
> #3 sounds good from long term perspective.
> 
> In short term, i.e., #4305, we should skip discovery when --on-master is
> used.

I would prefer #2. Because as seen from the patch it is already working
and can easily be used from python. I think this was also one of the
reasons why Stef used a DBus service for this instead of a C library
which then needs various bindings for python, Java, ruby, Go you name
it.

About the concerns. rpm-wise realmd has no dependencies on its
underlying tools, it will tell which packages must be installed to do
the join or will use packagekit to install them on its own. So it is
safe to add a realmd dependency to the ipa-client package. And as long
as you only use the Discover method realmd would not try to call
ipa-client-install, so there is no logical circle either. To avoid an
un-needed second discovery when ipa-client-install is not run from the
command line but from realmd directly ipa-client-install can skip the
realmd call if domain and realm are already given on the command line
because realmd will set both options when calling ipa-client-install.

And if there is a bug you have to poke the maintainer of the library or
realmd either way.



bye,
Sumit


> -- 
> Petr Vobornik
> 
> -- 
> Manage your subscription for the Freeipa-devel mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-devel
> Contribute to F

Re: [Freeipa-devel] [PATCH] extdom: Remove unused macro

[Sumit Bose]

On Fri, Jan 29, 2016 at 01:11:32PM +0100, Lukas Slebodnik wrote:
> ehlo,
> 
> Last usage of the macro SSSD_SYSDB_SID_STR was removed
> in the commit 0ee8fe11aea9811c724182def3f50960d5dd87b3
> 
> LS

ACK

bye,
Sumit

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

[Freeipa-devel] [PATCH 155] ipa-kdb: get_authz_data_types() make sure entry can be NULL

[Sumit Bose]

Hi,

this patch fixes and issue found by Simo when he called
get_authz_data_types() with the second argument being NULL.
This function determines which type of authorization data should be
added to the Kerberos ticket. There are global default and it is
possible to configure this per service as well. The second argument is
the data base entry of a service. If no service is given it makes sens
to return the global defaults and most parts of get_authz_data_types()
handle this case well and this patch fixes the remain issue and adds a
test for this as well.

Please note that currently get_authz_data_types() is used in a code path
where the service entry is expected to be not NULL and it turned out
that in Simo's case it will be non-NULL as well. Nevertheless the patch
makes the code more robust and makes the future use of
get_authz_data_types() more safe.

bye,
Sumit
From ac3468375a71da08d1437362caabae4504c87386 Mon Sep 17 00:00:00 2001
From: Sumit Bose 
Date: Wed, 16 Dec 2015 12:37:50 +0100
Subject: [PATCH] ipa-kdb: get_authz_data_types() make sure entry can be NULL

---
 daemons/ipa-kdb/ipa_kdb_mspac.c   | 2 +-
 daemons/ipa-kdb/tests/ipa_kdb_tests.c | 8 
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c
index 
8594309dbd27b45abda68de5f7ebf0c31e16904d..daa42e369014f2ed401742474453ebb1aadef07c
 100644
--- a/daemons/ipa-kdb/ipa_kdb_mspac.c
+++ b/daemons/ipa-kdb/ipa_kdb_mspac.c
@@ -2005,7 +2005,7 @@ void get_authz_data_types(krb5_context context, 
krb5_db_entry *entry,
 service_specific = false;
 authz_data_type = authz_data_list[c];
 sep = strchr(authz_data_list[c], ':');
-if (sep != NULL) {
+if (sep != NULL && entry != NULL) {
 if (entry->princ == NULL) {
 krb5_klog_syslog(LOG_ERR, "Missing principal in database "
   "entry, no authorization data will " 
\
diff --git a/daemons/ipa-kdb/tests/ipa_kdb_tests.c 
b/daemons/ipa-kdb/tests/ipa_kdb_tests.c
index 
0811972d3bb306e86a97d3c979a8e5cd0182cadd..1220d889ef76929161846dd41fa49df79b7b46f3
 100644
--- a/daemons/ipa-kdb/tests/ipa_kdb_tests.c
+++ b/daemons/ipa-kdb/tests/ipa_kdb_tests.c
@@ -410,6 +410,14 @@ void test_get_authz_data_types(void **state)
 get_authz_data_types(test_ctx->krb5_ctx, entry, &with_pac, &with_pad);
 assert_true(with_pad == test_set[c].exp_with_pad);
 assert_true(with_pac == test_set[c].exp_with_pac);
+
+/* test if global default are returned if there is no server entry */
+if (test_set[c].authz_data == NULL && test_set[c].princ == NULL) {
+get_authz_data_types(test_ctx->krb5_ctx, NULL, &with_pac,
+   &with_pad);
+assert_true(with_pad == test_set[c].exp_with_pad);
+assert_true(with_pac == test_set[c].exp_with_pac);
+}
 }
 
 free(ied);
-- 
2.4.3

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

[Freeipa-devel] [PATCH 154] ipa-kdb: map_groups() consider all results

[Sumit Bose]

Hi,

to find out to which local group a external user is mapped we do a
dereference search over the external groups with the SIDs related to the
external user. If a SID is mapped to more than one external group we
currently consider only the first returned match. With this patch all
results are taken into account. This makes sure all expected local group
memberships are added to the PAC which resolves
https://fedorahosted.org/freeipa/ticket/5573.

bye,
Sumit
From 60748d2da05261df937eba85cee27c2ea0d7e893 Mon Sep 17 00:00:00 2001
From: Sumit Bose 
Date: Wed, 16 Dec 2015 12:38:16 +0100
Subject: [PATCH] ipa-kdb: map_groups() consider all results

Resolves https://fedorahosted.org/freeipa/ticket/5573
---
 daemons/ipa-kdb/ipa_kdb_mspac.c | 118 +---
 1 file changed, 61 insertions(+), 57 deletions(-)

diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c
index 
daa42e369014f2ed401742474453ebb1aadef07c..45721f0dc06d90479f8fc2858c462c3647f7a3c6
 100644
--- a/daemons/ipa-kdb/ipa_kdb_mspac.c
+++ b/daemons/ipa-kdb/ipa_kdb_mspac.c
@@ -1082,68 +1082,72 @@ static int map_groups(TALLOC_CTX *memctx, krb5_context 
kcontext,
 continue;
 }
 
-ldap_derefresponse_free(deref_results);
-ret = ipadb_ldap_deref_results(ipactx->lcontext, lentry, 
&deref_results);
-switch (ret) {
-case ENOENT:
-/* No entry found, try next SID */
-break;
-case 0:
-if (deref_results == NULL) {
-krb5_klog_syslog(LOG_ERR, "No results.");
+do {
+ldap_derefresponse_free(deref_results);
+ret = ipadb_ldap_deref_results(ipactx->lcontext, lentry, 
&deref_results);
+switch (ret) {
+case ENOENT:
+/* No entry found, try next SID */
 break;
-}
+case 0:
+if (deref_results == NULL) {
+krb5_klog_syslog(LOG_ERR, "No results.");
+break;
+}
 
-for (dres = deref_results; dres; dres = dres->next) {
-count++;
-}
+for (dres = deref_results; dres; dres = dres->next) {
+count++;
+}
 
-sids = talloc_realloc(memctx, sids, struct dom_sid, count);
-if (sids == NULL) {
-krb5_klog_syslog(LOG_ERR, "talloc_realloc failed.");
-kerr = ENOMEM;
+sids = talloc_realloc(memctx, sids, struct dom_sid, count);
+if (sids == NULL) {
+krb5_klog_syslog(LOG_ERR, "talloc_realloc failed.");
+kerr = ENOMEM;
+goto done;
+}
+
+for (dres = deref_results; dres; dres = dres->next) {
+gid = 0;
+memset(&sid, '\0', sizeof(struct dom_sid));
+for (dval = dres->attrVals; dval; dval = dval->next) {
+if (strcasecmp(dval->type, "gidNumber") == 0) {
+errno = 0;
+gid = strtoul((char *)dval->vals[0].bv_val,
+  &endptr,10);
+if (gid == 0 || gid >= UINT32_MAX || errno != 
0 ||
+*endptr != '\0') {
+continue;
+}
+}
+if (strcasecmp(dval->type,
+   "ipaNTSecurityIdentifier") == 0) {
+kerr = string_to_sid((char 
*)dval->vals[0].bv_val, &sid);
+if (kerr != 0) {
+continue;
+}
+}
+}
+if (gid != 0 && sid.sid_rev_num != 0) {
+/* TODO: check if gid maps to sid */
+if (sid_index >= count) {
+krb5_klog_syslog(LOG_ERR, "Index larger than "
+  "array, this shoould 
"
+  "never happen.");
+kerr = EFAULT;
+goto done;
+}
+memcpy(&sids[sid_index], &sid, sizeof(struct 
dom_sid));
+sid_index++;
+}
+}

Re: [Freeipa-devel] limiting SyncRepl's scope

[Sumit Bose]

On Wed, Dec 16, 2015 at 08:49:04AM +0100, Petr Spacek wrote:
> On 15.12.2015 19:10, Christian Heimes wrote:
> > Hi,
> > 
> > in ticket https://fedorahosted.org/freeipa/ticket/5538 Ludwig has
> > suggested to exclude Dogtag's o=ipaca tree from the changelog. Sometimes
> > vault-archive fails because of a failed write to the Retro Changelog.
> > The RetroCL was enabled in https://fedorahosted.org/freeipa/ticket/3967
> > for the bind-dyndb-ldap plugin. Otherwise it is not needed under normal
> > circumstances because 389 doesn't use SyncRepl for replication. In #3967
> > Nathan has expressed his concerns for possible performance issues, too.
> > 
> > Petr, Ludwig,
> > would it makes sense to restrict RetroCL to cn=dns,$SUFFIX rather than
> > excluding o=ipaca? The plugin supports both includes and exclude,
> > http://directory.fedoraproject.org/docs/389ds/design/retrocl-scoping.html.
> 
> >From IPA DNS perspective it is okay to limit SyncRepl to cn=dns,$SUFFIX.
> 
> One other thing to consider is theoretical use of SyncRepl for future versions
> of slapi-nis, Alexander can tell you more about it.
> 
> In any case, if we decide to limit scope where SyncRepl is applicable, I would
> like to see checks in SyncRepl plugin which will ensure that error
> UNWILLING_TO_PERFORM is returned when somebody attempts to use SyncRepl in a
> 'wrong' scope.
> 

There are discussions about using SyncRepl in SSSD as well which would
include users, groups, sudo and HBAC rules, trusted domains, ... But
afaik no work in the direction has been started yet, so it might be ok
to limit the scope for now and add it when there are patches for SSSD
which really try to use it.

bye,
Sumit

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

Re: [Freeipa-devel] [PATCH] Add option to disable setkeytab extended operations

[Sumit Bose]

On Wed, Nov 25, 2015 at 09:54:13AM -0500, Simo Sorce wrote:
> On Wed, 2015-11-25 at 10:24 +0100, Sumit Bose wrote:
> > On Tue, Nov 24, 2015 at 02:42:32PM -0500, Simo Sorce wrote:
> > > Since some time we use the getkeytab operation to fetch keytabs on newer
> > > clients. According to bug #232 setkeytab can be used to circumvent
> > > password quality controls so it needs to be slowly retired.
> > 
> > ipasam uses this exop to create the cross-realm TGT principal objects,
> > krbtgt/DOM.A@DOM.B. What should be used instead to make sure that
> > setkeytab can safely be disabled?
> 
> It must use the new getkeytab extended operation.
> 
> Can you open a ticket to fix this and assign it to me ?

Here you are

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

bye,
Sumit

> 
> Simo.
> 
> > bye,
> > Sumit
> > 
> > > 
> > > The attached patches implement #5485 in 2 parts.
> > > 
> > > The first introduces the option DisableSetKeytab which globally disables
> > > the setkeytab extended operation. This is set to false by default for
> > > backwards compatibility.
> > > 
> > > The second introduces an option called DisableUserSetKeytab, which is
> > > active by default in new installs (but not in upgraded ones), and only
> > > disables the use of setkeytab for ipa suers, but not for hosts/services.
> > > This is because user's are the ones that may abuse the interface to
> > > escape password policies and users also normally do not acquire keytabs,
> > > so it is a safe bet to disable just them by default in new installs.
> > > 
> > > (Testing in progress)
> > > 
> > > Simo.
> > > 
> > > -- 
> > > Simo Sorce * Red Hat, Inc * New York
> 
> 
> -- 
> Simo Sorce * Red Hat, Inc * New York
> 

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

Re: [Freeipa-devel] [PATCH] Add option to disable setkeytab extended operations

[Sumit Bose]

On Tue, Nov 24, 2015 at 02:42:32PM -0500, Simo Sorce wrote:
> Since some time we use the getkeytab operation to fetch keytabs on newer
> clients. According to bug #232 setkeytab can be used to circumvent
> password quality controls so it needs to be slowly retired.

ipasam uses this exop to create the cross-realm TGT principal objects,
krbtgt/DOM.A@DOM.B. What should be used instead to make sure that
setkeytab can safely be disabled?

bye,
Sumit

> 
> The attached patches implement #5485 in 2 parts.
> 
> The first introduces the option DisableSetKeytab which globally disables
> the setkeytab extended operation. This is set to false by default for
> backwards compatibility.
> 
> The second introduces an option called DisableUserSetKeytab, which is
> active by default in new installs (but not in upgraded ones), and only
> disables the use of setkeytab for ipa suers, but not for hosts/services.
> This is because user's are the ones that may abuse the interface to
> escape password policies and users also normally do not acquire keytabs,
> so it is a safe bet to disable just them by default in new installs.
> 
> (Testing in progress)
> 
> 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] [PATCHES 151-153] ipasam: fix wrong usage of talloc_new()

[Sumit Bose]

Hi,

please find attached 3 small patches for ipasam. The first fixes
https://fedorahosted.org/freeipa/ticket/5457 . The second is related
because if the compat tree is enabled the lookup will still fails
because the group is found twice.

The third patch fixes an issue valgrind found while I was checking the
other issue.

bye,
Sumit
From 8b4025136271f158ae50172cdbc6dca4fbe2ee65 Mon Sep 17 00:00:00 2001
From: Sumit Bose 
Date: Wed, 18 Nov 2015 12:29:43 +0100
Subject: [PATCH 151/153] ipasam: fix wrong usage of talloc_new()

Fixes https://fedorahosted.org/freeipa/ticket/5457
---
 daemons/ipa-sam/ipa_sam.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/daemons/ipa-sam/ipa_sam.c b/daemons/ipa-sam/ipa_sam.c
index 
96452302f31e7a102b0ae2c17f343c75014b987b..37b5cf9140b9507e189363bff4c56cb33a82a89b
 100644
--- a/daemons/ipa-sam/ipa_sam.c
+++ b/daemons/ipa-sam/ipa_sam.c
@@ -3029,7 +3029,7 @@ static int ipasam_get_sid_by_gid(struct ldapsam_privates 
*ldap_state,
enum idmap_error_code err;
struct unixid id;
 
-   tmp_ctx = talloc_new("ipasam_get_sid_by_gid");
+   tmp_ctx = talloc_init("ipasam_get_sid_by_gid");
if (tmp_ctx == NULL) {
return ENOMEM;
}
-- 
2.4.3

From deea949d98bff62493dd9048f0de3b5986103534 Mon Sep 17 00:00:00 2001
From: Sumit Bose 
Date: Wed, 18 Nov 2015 12:31:26 +0100
Subject: [PATCH 152/153] ipasam: use more restrictive search filter for group
 lookup

Since we are interested in looking up the SID of a group it makes sense
to include the objectclass which contains the SID attribute in the
search filter. This makes sure the group is not accidentally found a
second time in the compat tree.

Related to https://fedorahosted.org/freeipa/ticket/5457
---
 daemons/ipa-sam/ipa_sam.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/daemons/ipa-sam/ipa_sam.c b/daemons/ipa-sam/ipa_sam.c
index 
37b5cf9140b9507e189363bff4c56cb33a82a89b..60e73374df6c3e1cda8287069bc062101439fc64
 100644
--- a/daemons/ipa-sam/ipa_sam.c
+++ b/daemons/ipa-sam/ipa_sam.c
@@ -3034,9 +3034,11 @@ static int ipasam_get_sid_by_gid(struct ldapsam_privates 
*ldap_state,
return ENOMEM;
}
 
-   filter = talloc_asprintf(tmp_ctx, "(&(%s=%s)(%s=%lu))",
+   filter = talloc_asprintf(tmp_ctx, "(&(%s=%s)(%s=%s)(%s=%lu))",
  LDAP_ATTRIBUTE_OBJECTCLASS,
  LDAP_OBJ_POSIXGROUP,
+ LDAP_ATTRIBUTE_OBJECTCLASS,
+ LDAP_OBJ_GROUPMAP,
  LDAP_ATTRIBUTE_GIDNUMBER,
  (unsigned long) gid);
if (filter == NULL) {
-- 
2.4.3

From 08195df7a456cacd6438b8e75be8dc215c6c780c Mon Sep 17 00:00:00 2001
From: Sumit Bose 
Date: Wed, 18 Nov 2015 12:34:49 +0100
Subject: [PATCH 153/153] ipasam: fix a use-after-free issue

Since endptr points to a location inside of dummy, dummy should be freed
only after dereferencing endptr.
---
 daemons/ipa-sam/ipa_sam.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/daemons/ipa-sam/ipa_sam.c b/daemons/ipa-sam/ipa_sam.c
index 
60e73374df6c3e1cda8287069bc062101439fc64..c51316757a80994a3992ab29f52e21b5a2c5673c
 100644
--- a/daemons/ipa-sam/ipa_sam.c
+++ b/daemons/ipa-sam/ipa_sam.c
@@ -2105,11 +2105,12 @@ static bool get_uint32_t_from_ldap_msg(struct 
ldapsam_privates *ldap_state,
}
 
l = strtoul(dummy, &endptr, 10);
-   TALLOC_FREE(dummy);
 
if (l < 0 || l > UINT32_MAX || *endptr != '\0') {
+   TALLOC_FREE(dummy);
return false;
}
+   TALLOC_FREE(dummy);
 
*val = l;
 
-- 
2.4.3

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

Re: [Freeipa-devel] [PATCH] 0197 client referral support for trusted domain principal

[Sumit Bose]

On Thu, Oct 08, 2015 at 01:36:23PM +0300, Alexander Bokovoy wrote:
> On Mon, 05 Oct 2015, Sumit Bose wrote:
> >On Thu, Sep 03, 2015 at 06:22:05PM +0300, Alexander Bokovoy wrote:
> >>On Thu, 03 Sep 2015, Alexander Bokovoy wrote:
> >>>Hi,
> >>>
> >>>attached patch adds support for issuing client referrals when FreeIPA
> >>>KDC is asked to give a TGT for a principal from a trusted forest.
> >>>
> >>>We return a matching forest name as a realm and KDC then returns an
> >>>error pointing a client to a direction of that realm. You can see how it
> >>>looks with http://fpaste.org/263064/14412849/ -- it shows behavior for
> >>>both 'kinit -E -C' and 'kinit -E'.
> >>>
> >>>Note that current MIT Kerberos KDC has a bug that prevents us from
> >>>responding with a correct client referral. A patched version for Fedora
> >>>22 is available in COPR abbra/krb5-test, a fix to upstream krb5 is
> >>>https://github.com/krb5/krb5/pull/323/ and I'm working on filing bugs to
> >>>Fedora and RHEL versions.
> >>>
> >>>With the version in my abbra/krb5-test COPR you can test the patch with
> >>>the help of kinit like fpaste URL above shows.
> >>After discussing with Simo and Sumit, here is updated patch that
> >>operates directly on 'search_for' krb5_principal and avoids
> >>strchr()/strrchr() and additional memory allocations -- it uses
> >>memrchr() to find '@' in the last component of the search_for principal
> >>and considers the part of the component after '@' as an enterprise realm
> >>to check.
> >
> >The patch looks good and works as advertised. I've tested in a IPA
> >domain which trusts two different forests. All requests to the forest
> >roots and child domains where properly redirected. I tested with your
> >krb5 test build and with MIT Kerberos 1.14 which contains the needed
> >fix.
> >
> >Nevertheless there are a view points I want to discuss:
> >
> >- missing support for AD's Alternative Domain Suffixes, this is
> > important to allow AD users to login in with their "Email-Address"
> > (which is the typical reference for a user name with an alternative
> > domain suffix). I think this is not strictly related to the given
> > ticket, so it can be solved in the context of a new ticket, do you
> > agree?
> Yes, please add a separate ticket. We need to do a bit more here:
> - extend schema to allow adding the attribute for alternative domain
>   suffixes
> - switch to use different DCE RPC call to retrieve forest trust
>   information. We can do it now that we have a call-out mechanism and
>   can isolate access to TDO credentials (this is long standing issue
>   first identified by Metze as part of cross-forest trust support for
>   Samba 4.3)
> - Make possible to associate alternative domain suffixes with IPA
>   realm. We have support for realm domains already but we don't allow
>   to use them yet for the same call as in the above item.

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

> 
> >- referrals from outside. If I call 'kinit -E admin@IPA.DOMAIN' from a
> > client in a trusted AD forest I get a 'Client not found in database'
> > error because AD tends to use lower case domain names in the referal
> > response. The request is still properly send to the IPA KDC because
> > DNS does not care about the case. The IPA KDC processes the request
> > with the principal 'user\@IPA.DOMAIN@ipa.domain' until
> > ipadb_is_princ_from_trusted_realm() returns KRB5_KDB_NOENTRY becasue
> > it detects that the principal is from the local realm. I think it
> > would be good to enhance your patch to handle this case.
> This is a separate bug too. Please file a ticket.

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

> 
> 
> >- S4U2Self. MIT Kerberos 1.14 can now properly handle S4U2Self across
> > domain and forest boundaries (I tested this in a setup with 2 AD
> > forests with request going from a child domain to a child domain in
> > the other forest. Unfortunately it is currently not working with IPA
> > in neither direction (I guess the case issue from above might be the
> > reason for the incoming request to fail). Here I think a new ticket
> > would to good as well because some research might be needed and the
> > issue might even be in the MIT code. (If you want to run some tests I
> > can give you access to my test environment.)
> I think we want to have this working, thus a ticket is due here. This is
> something we'll most likely require for some advanced 2FA operations for
> AD users.

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

bye,
Sumit

> 
> >Let me know if you prefer to handle the issues with other tickets, then
> >I would ACK the patch as it is.
> Please file separate tickets.
> 
> -- 
> / Alexander Bokovoy

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

Re: [Freeipa-devel] [PATCH] 0197 client referral support for trusted domain principal

[Sumit Bose]

On Thu, Oct 08, 2015 at 01:12:56PM +0200, Martin Basti wrote:
> 
> 
> On 10/08/2015 12:36 PM, Alexander Bokovoy wrote:
> >On Mon, 05 Oct 2015, Sumit Bose wrote:
> >>On Thu, Sep 03, 2015 at 06:22:05PM +0300, Alexander Bokovoy wrote:
> >>>On Thu, 03 Sep 2015, Alexander Bokovoy wrote:
> >>>>Hi,
> >>>>
> >>>>attached patch adds support for issuing client referrals when FreeIPA
> >>>>KDC is asked to give a TGT for a principal from a trusted forest.
> >>>>
> >>>>We return a matching forest name as a realm and KDC then returns an
> >>>>error pointing a client to a direction of that realm. You can see how
> >>>it
> >>>>looks with http://fpaste.org/263064/14412849/ -- it shows behavior for
> >>>>both 'kinit -E -C' and 'kinit -E'.
> >>>>
> >>>>Note that current MIT Kerberos KDC has a bug that prevents us from
> >>>>responding with a correct client referral. A patched version for
> >>>Fedora
> >>>>22 is available in COPR abbra/krb5-test, a fix to upstream krb5 is
> >>>>https://github.com/krb5/krb5/pull/323/ and I'm working on filing bugs
> >>>to
> >>>>Fedora and RHEL versions.
> >>>>
> >>>>With the version in my abbra/krb5-test COPR you can test the patch
> >>>with
> >>>>the help of kinit like fpaste URL above shows.
> >>>After discussing with Simo and Sumit, here is updated patch that
> >>>operates directly on 'search_for' krb5_principal and avoids
> >>>strchr()/strrchr() and additional memory allocations -- it uses
> >>>memrchr() to find '@' in the last component of the search_for principal
> >>>and considers the part of the component after '@' as an enterprise
> >>>realm
> >>>to check.
> >>
> >>The patch looks good and works as advertised. I've tested in a IPA
> >>domain which trusts two different forests. All requests to the forest
> >>roots and child domains where properly redirected. I tested with your
> >>krb5 test build and with MIT Kerberos 1.14 which contains the needed
> >>fix.
> >>
> >>Nevertheless there are a view points I want to discuss:
> >>
> >>- missing support for AD's Alternative Domain Suffixes, this is
> >> important to allow AD users to login in with their "Email-Address"
> >> (which is the typical reference for a user name with an alternative
> >> domain suffix). I think this is not strictly related to the given
> >> ticket, so it can be solved in the context of a new ticket, do you
> >> agree?
> >Yes, please add a separate ticket. We need to do a bit more here:
> >- extend schema to allow adding the attribute for alternative domain
> >  suffixes
> >- switch to use different DCE RPC call to retrieve forest trust
> >  information. We can do it now that we have a call-out mechanism and
> >  can isolate access to TDO credentials (this is long standing issue
> >  first identified by Metze as part of cross-forest trust support for
> >  Samba 4.3)
> >- Make possible to associate alternative domain suffixes with IPA
> >  realm. We have support for realm domains already but we don't allow
> >  to use them yet for the same call as in the above item.
> >
> >>- referrals from outside. If I call 'kinit -E admin@IPA.DOMAIN' from a
> >> client in a trusted AD forest I get a 'Client not found in database'
> >> error because AD tends to use lower case domain names in the referal
> >> response. The request is still properly send to the IPA KDC because
> >> DNS does not care about the case. The IPA KDC processes the request
> >> with the principal 'user\@IPA.DOMAIN@ipa.domain' until
> >> ipadb_is_princ_from_trusted_realm() returns KRB5_KDB_NOENTRY becasue
> >> it detects that the principal is from the local realm. I think it
> >> would be good to enhance your patch to handle this case.
> >This is a separate bug too. Please file a ticket.
> >
> >
> >>- S4U2Self. MIT Kerberos 1.14 can now properly handle S4U2Self across
> >> domain and forest boundaries (I tested this in a setup with 2 AD
> >> forests with request going from a child domain to a child domain in
> >> the other forest. Unfortunately it is currently not working with IPA
> >> in neither direction (I guess the case issue from above might be the
> >> reason for the incoming request to fail). Here I think a new ticket
> >> would to good as well because some research might be needed and the
> >> issue might even be in the MIT code. (If you want to run some tests I
> >> can give you access to my test environment.)
> >I think we want to have this working, thus a ticket is due here. This is
> >something we'll most likely require for some advanced 2FA operations for
> >AD users.
> >
> >>Let me know if you prefer to handle the issues with other tickets, then
> >>I would ACK the patch as it is.
> >Please file separate tickets.
> >
> 
> Summit, Alexander, is this patch ACKed or not?

yes, ACK, I'll file the tickets mentioned above.

bye,
Sumit

> 
> Martin

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

Re: [Freeipa-devel] [PATCH] 0197 client referral support for trusted domain principal

[Sumit Bose]

On Thu, Sep 03, 2015 at 06:22:05PM +0300, Alexander Bokovoy wrote:
> On Thu, 03 Sep 2015, Alexander Bokovoy wrote:
> >Hi,
> >
> >attached patch adds support for issuing client referrals when FreeIPA
> >KDC is asked to give a TGT for a principal from a trusted forest.
> >
> >We return a matching forest name as a realm and KDC then returns an
> >error pointing a client to a direction of that realm. You can see how it
> >looks with http://fpaste.org/263064/14412849/ -- it shows behavior for
> >both 'kinit -E -C' and 'kinit -E'.
> >
> >Note that current MIT Kerberos KDC has a bug that prevents us from
> >responding with a correct client referral. A patched version for Fedora
> >22 is available in COPR abbra/krb5-test, a fix to upstream krb5 is
> >https://github.com/krb5/krb5/pull/323/ and I'm working on filing bugs to
> >Fedora and RHEL versions.
> >
> >With the version in my abbra/krb5-test COPR you can test the patch with
> >the help of kinit like fpaste URL above shows.
> After discussing with Simo and Sumit, here is updated patch that
> operates directly on 'search_for' krb5_principal and avoids
> strchr()/strrchr() and additional memory allocations -- it uses
> memrchr() to find '@' in the last component of the search_for principal
> and considers the part of the component after '@' as an enterprise realm
> to check.

The patch looks good and works as advertised. I've tested in a IPA
domain which trusts two different forests. All requests to the forest
roots and child domains where properly redirected. I tested with your
krb5 test build and with MIT Kerberos 1.14 which contains the needed
fix.

Nevertheless there are a view points I want to discuss:

- missing support for AD's Alternative Domain Suffixes, this is
  important to allow AD users to login in with their "Email-Address"
  (which is the typical reference for a user name with an alternative
  domain suffix). I think this is not strictly related to the given
  ticket, so it can be solved in the context of a new ticket, do you
  agree?

- referrals from outside. If I call 'kinit -E admin@IPA.DOMAIN' from a
  client in a trusted AD forest I get a 'Client not found in database'
  error because AD tends to use lower case domain names in the referal
  response. The request is still properly send to the IPA KDC because
  DNS does not care about the case. The IPA KDC processes the request
  with the principal 'user\@IPA.DOMAIN@ipa.domain' until
  ipadb_is_princ_from_trusted_realm() returns KRB5_KDB_NOENTRY becasue
  it detects that the principal is from the local realm. I think it
  would be good to enhance your patch to handle this case.

- S4U2Self. MIT Kerberos 1.14 can now properly handle S4U2Self across
  domain and forest boundaries (I tested this in a setup with 2 AD
  forests with request going from a child domain to a child domain in
  the other forest. Unfortunately it is currently not working with IPA
  in neither direction (I guess the case issue from above might be the
  reason for the incoming request to fail). Here I think a new ticket
  would to good as well because some research might be needed and the
  issue might even be in the MIT code. (If you want to run some tests I
  can give you access to my test environment.)

Let me know if you prefer to handle the issues with other tickets, then
I would ACK the patch as it is.

bye,
Sumit

> 
> -- 
> / 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] fixing Kerberos principal aliases handling in IPA

[Sumit Bose]

On Wed, Sep 02, 2015 at 02:10:52PM +0200, Martin Kosek wrote:
> On 09/01/2015 04:53 PM, Simo Sorce wrote:
> > On Tue, 2015-09-01 at 16:39 +0200, Martin Babinsky wrote:
> >> Hi list,
> >>
> >> I own the following ticket https://fedorahosted.org/freeipa/ticket/3864 
> >> and I would like to clarify what needs to be done in order to make IPA 
> >> to fully support multiple aliases per entry.
> >>
> >> So far I have identified these task based on the ticket comments and 
> >> discussion with Simo way back in the past:
> >>
> >> 1.) mark 'ipaKrbPrincipalAlias' attribute as deprecated so that it is 
> >> not used in the new code.
> >>
> >> 2.) fix ACIs that do not permit setting multiple values of 
> >> 'krbPrincipalName' attribute per entry (see 
> >> https://fedorahosted.org/freeipa/ticket/3961)
> >>
> >> 3.) Modify KDB backend (namely 'ipadb_fetch_principal' and 
> >> 'ipadb_find_principal' functions) to correctly perform lookup of 
> >> krbprincipalname/krbcanonicalname, i.e. search krbprincipalname 
> >> case-insensitively and krbcanonicalname case-sensitively, return 
> >> krbcanonicalname when canonicalization is requested.
> >>
> >> 4.) Modify KDB backend and IPA framework to handle creation of both 
> >> krbprincipalname and krbcanonicalname. I am not quite sure what cases 
> >> should be covered here (I remember that we should create 
> >> krbcanonicalname when we add another aliases to krbprincipalname), so it 
> >> would be nice if you could comment on this.
> >>
> >> 5.) write tests which cover all this stuff so that we don't shoot 
> >> ourselves in the foot.
> >>
> >> I am not very well versed in Kerberos so I might get some of this stuff 
> >> wrong. If that's the case please point me to the right direction. Also 
> >> please write me some additional stuff which I have fogot and needs to be 
> >> done.
> >>
> > 
> > I think the summary is correct, the only thing we need to be careful is
> > to keep handling entries that have only a single valued krbprincipalname
> > correctly as that will happen in upgrade paths and potentially if
> > someone uses external tools.
> > 
> > The tricky part for point 3 is to implement it *without* changing the
> > schema. KrbPrincipalName is case-sensitive, however I think we can solve
> > the issue of "searching case-insensitively" by always lower-casing the
> > principal name components and always upper casing the realm part on
> > storage. If we always store a krbCanonicalName we get the "correct" case
> > there anyway so out mucking with the krbPrincipalName case will not be a
> > problem for any new entry.
> > 
> > This *may* cause issues with upgrades though, so we may need fallback
> > code that searches with the case sent by the client if we determine the
> > entry has no krbCanonicalName attribute (sign that it was created before
> > we started adding krbCanonicalName and never "updated").
> > 
> > Note that we also need to think what will happen during and upgrade when
> > some servers still use the current code and some servers will use the
> > new code. So I guess it would be nice if you could write down a table
> > with all possible forms a principal can be in on rows, and old/new
> > server states in columns, and mark what will happen for various
> > operations in each case.
> > 
> > Simo.
> 
> The list looks OK. Do we also plan to change the default RDN for new services
> or other objects that use krbPrincipalName as RDN at the moment?
> 
> AFAIU, we are supposed to always use krbCanonicalName as the primary RDN and
> then only allow krbPrincipalName to be added for the aliases. Of course, the
> framework needs to still work with old services having krbPrincipalName.

no, I think we can/should keep krbPrincipalName e.g. becasue krbCanonicalName
is only optional according to the scheme.

bye,
Sumit

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

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

Re: [Freeipa-devel] [PATCH 149] IPA KDB: allow case in-sensitive realm in AS request

[Sumit Bose]

On Tue, Jul 28, 2015 at 01:42:29PM +0200, Sumit Bose wrote:
> On Tue, Jul 28, 2015 at 02:26:34PM +0300, Alexander Bokovoy wrote:
> > On Tue, 28 Jul 2015, Simo Sorce wrote:
> > >On Tue, 2015-07-28 at 12:15 +0200, Sumit Bose wrote:
> > >>On Wed, Jul 22, 2015 at 09:41:51AM -0400, Simo Sorce wrote:
> > >>> - Original Message -
> > >>> > From: "Sumit Bose" 
> > >>> > To: "freeipa-devel" 
> > >>> > Sent: Tuesday, July 21, 2015 7:41:14 AM
> > >>> > Subject: [Freeipa-devel] [PATCH 149] IPA KDB: allow case in-sensitive 
> > >>> > realm   in AS request
> > >>> >
> > >>> > Hi,
> > >>> >
> > >>> > this patch is my suggestion to solve
> > >>> > https://fedorahosted.org/freeipa/ticket/4844 .
> > >>> >
> > >>> > The original issue in the ticket has two part. One is a loop in 
> > >>> > libkrb5
> > >>> > which is already fixed. The other is to handle canonicalization 
> > >>> > better.
> > >>>
> > >>> Sorry Sumit,
> > >>> I see several issues with this patck.
> > >>>
> > >>> first of all you should really not change ipadb_get_principal(), that's 
> > >>> the
> > >>> wrong place to apply your logic.
> > >>>
> > >>> To support searching for the realm name case-insensitively all we 
> > >>> should do
> > >>> is to always forcibly upper case the realm name at the same time we 
> > >>> build the
> > >>> filter (in ipadb_fetch_principals(), if canonicalization was requested.
> > >>> Because we will never store (code to prevent that should probably be 
> > >>> dded with
> > >>> this patch) a realm name that is not all caps.
> > >>> Then the post search matches should be done straight within 
> > >>> ipadb_find_principal().
> > >>>
> > >>> > The general way to allow canonicalization on a principal is to add the
> > >>> > attributes 'krbcanonicalname'[1] and 'ipakrbprincipalalias' together
> > >>> > with the objectclass 'ipaKrbPrincipal' to the user object.
> > >>>
> > >>> We have already a ticket open since long to remove krbprincipalalias, 
> > >>> it was
> > >>> a mistake to add it and any patch that depends on it will be nacked by 
> > >>> me.
> > >>> We need to use krbPrincipalName and krbCanonicalName.
> > >>>
> > >>> > Then the IPA
> > >>> > KDB backend will use 'ipakrbprincipalalias' for case in-sensitive
> > >>> > matches and  the principal from 'krbcanonicalname' will be the 
> > >>> > canonical
> > >>> > principal used further on. The 'krbPrincipalName' is not suitable for
> > >>> > either because it has caseExact* matching rules and is a multivalue
> > >>> > attribute [2].
> > >>>
> > >>> Case-exact match is a problem only if we do not canonicalize names when 
> > >>> storing
> > >>> them, otherwise all you need to do is store a "search form" in 
> > >>> krbPrincipalName
> > >>> and always change searches to that form (forcibly upper case realm, 
> > >>> forcibly
> > >>> lowercase components) when canonicalization is requested.
> > >>>
> > >>> Additionally in the patch you are using stcasecmp(), that function is 
> > >>> not
> > >>> acceptable, look at ipadb_find_principal() and you'll see we use 
> > >>> ulc_casecmp()
> > >>> there.
> > >>> Also modyfing the principal before searching is done wrong (you use 
> > >>> strchr()
> > >>> to find the @ sign, but you could find an @ in the components this way, 
> > >>> you
> > >>> should use strrchr() at the very least), and is dangerous if done 
> > >>> outside of
> > >>> the inner functions because then we never have a way to know the 
> > >>> original
> > >>> form should it be needed. In any case as said above realm should be 
> > >>> forcibly
> > >>> uppercase, given a flag in the escape function instead.
> > >>
>

Re: [Freeipa-devel] [PATCH 149] IPA KDB: allow case in-sensitive realm in AS request

[Sumit Bose]

On Tue, Jul 28, 2015 at 02:26:34PM +0300, Alexander Bokovoy wrote:
> On Tue, 28 Jul 2015, Simo Sorce wrote:
> >On Tue, 2015-07-28 at 12:15 +0200, Sumit Bose wrote:
> >>On Wed, Jul 22, 2015 at 09:41:51AM -0400, Simo Sorce wrote:
> >>> - Original Message -
> >>> > From: "Sumit Bose" 
> >>> > To: "freeipa-devel" 
> >>> > Sent: Tuesday, July 21, 2015 7:41:14 AM
> >>> > Subject: [Freeipa-devel] [PATCH 149] IPA KDB: allow case in-sensitive 
> >>> > realm in AS request
> >>> >
> >>> > Hi,
> >>> >
> >>> > this patch is my suggestion to solve
> >>> > https://fedorahosted.org/freeipa/ticket/4844 .
> >>> >
> >>> > The original issue in the ticket has two part. One is a loop in libkrb5
> >>> > which is already fixed. The other is to handle canonicalization better.
> >>>
> >>> Sorry Sumit,
> >>> I see several issues with this patck.
> >>>
> >>> first of all you should really not change ipadb_get_principal(), that's 
> >>> the
> >>> wrong place to apply your logic.
> >>>
> >>> To support searching for the realm name case-insensitively all we should 
> >>> do
> >>> is to always forcibly upper case the realm name at the same time we build 
> >>> the
> >>> filter (in ipadb_fetch_principals(), if canonicalization was requested.
> >>> Because we will never store (code to prevent that should probably be dded 
> >>> with
> >>> this patch) a realm name that is not all caps.
> >>> Then the post search matches should be done straight within 
> >>> ipadb_find_principal().
> >>>
> >>> > The general way to allow canonicalization on a principal is to add the
> >>> > attributes 'krbcanonicalname'[1] and 'ipakrbprincipalalias' together
> >>> > with the objectclass 'ipaKrbPrincipal' to the user object.
> >>>
> >>> We have already a ticket open since long to remove krbprincipalalias, it 
> >>> was
> >>> a mistake to add it and any patch that depends on it will be nacked by me.
> >>> We need to use krbPrincipalName and krbCanonicalName.
> >>>
> >>> > Then the IPA
> >>> > KDB backend will use 'ipakrbprincipalalias' for case in-sensitive
> >>> > matches and  the principal from 'krbcanonicalname' will be the canonical
> >>> > principal used further on. The 'krbPrincipalName' is not suitable for
> >>> > either because it has caseExact* matching rules and is a multivalue
> >>> > attribute [2].
> >>>
> >>> Case-exact match is a problem only if we do not canonicalize names when 
> >>> storing
> >>> them, otherwise all you need to do is store a "search form" in 
> >>> krbPrincipalName
> >>> and always change searches to that form (forcibly upper case realm, 
> >>> forcibly
> >>> lowercase components) when canonicalization is requested.
> >>>
> >>> Additionally in the patch you are using stcasecmp(), that function is not
> >>> acceptable, look at ipadb_find_principal() and you'll see we use 
> >>> ulc_casecmp()
> >>> there.
> >>> Also modyfing the principal before searching is done wrong (you use 
> >>> strchr()
> >>> to find the @ sign, but you could find an @ in the components this way, 
> >>> you
> >>> should use strrchr() at the very least), and is dangerous if done outside 
> >>> of
> >>> the inner functions because then we never have a way to know the original
> >>> form should it be needed. In any case as said above realm should be 
> >>> forcibly
> >>> uppercase, given a flag in the escape function instead.
> >>
> >>Thank for for the review and the comments.
> >>
> >>I changed the patch as you suggested to upper-case the realm in the
> >>escape function if the flag is set.
> >>
> >>I didn't add any checks to make sure that the realm of newly added
> >>principal attributes is always upper case. Since the attributes can be
> >>added via various ways I think the check should happen on the DS level
> >
> >We should indeed intercept add/modify operations and see if they try to
> >set krbPrincipalName/krbCanonicalN

Re: [Freeipa-devel] [PATCH 149] IPA KDB: allow case in-sensitive realm in AS request

[Sumit Bose]

On Wed, Jul 22, 2015 at 09:41:51AM -0400, Simo Sorce wrote:
> - Original Message -
> > From: "Sumit Bose" 
> > To: "freeipa-devel" 
> > Sent: Tuesday, July 21, 2015 7:41:14 AM
> > Subject: [Freeipa-devel] [PATCH 149] IPA KDB: allow case in-sensitive realm 
> > in AS request
> > 
> > Hi,
> > 
> > this patch is my suggestion to solve
> > https://fedorahosted.org/freeipa/ticket/4844 .
> > 
> > The original issue in the ticket has two part. One is a loop in libkrb5
> > which is already fixed. The other is to handle canonicalization better.
> 
> Sorry Sumit,
> I see several issues with this patck.
> 
> first of all you should really not change ipadb_get_principal(), that's the
> wrong place to apply your logic.
> 
> To support searching for the realm name case-insensitively all we should do
> is to always forcibly upper case the realm name at the same time we build the
> filter (in ipadb_fetch_principals(), if canonicalization was requested. 
> Because we will never store (code to prevent that should probably be dded with
> this patch) a realm name that is not all caps.
> Then the post search matches should be done straight within 
> ipadb_find_principal().
> 
> > The general way to allow canonicalization on a principal is to add the
> > attributes 'krbcanonicalname'[1] and 'ipakrbprincipalalias' together
> > with the objectclass 'ipaKrbPrincipal' to the user object.
> 
> We have already a ticket open since long to remove krbprincipalalias, it was
> a mistake to add it and any patch that depends on it will be nacked by me.
> We need to use krbPrincipalName and krbCanonicalName.
> 
> > Then the IPA
> > KDB backend will use 'ipakrbprincipalalias' for case in-sensitive
> > matches and  the principal from 'krbcanonicalname' will be the canonical
> > principal used further on. The 'krbPrincipalName' is not suitable for
> > either because it has caseExact* matching rules and is a multivalue
> > attribute [2].
> 
> Case-exact match is a problem only if we do not canonicalize names when 
> storing
> them, otherwise all you need to do is store a "search form" in 
> krbPrincipalName
> and always change searches to that form (forcibly upper case realm, forcibly
> lowercase components) when canonicalization is requested.
> 
> Additionally in the patch you are using stcasecmp(), that function is not
> acceptable, look at ipadb_find_principal() and you'll see we use ulc_casecmp()
> there.
> Also modyfing the principal before searching is done wrong (you use strchr()
> to find the @ sign, but you could find an @ in the components this way, you
> should use strrchr() at the very least), and is dangerous if done outside of
> the inner functions because then we never have a way to know the original
> form should it be needed. In any case as said above realm should be forcibly
> uppercase, given a flag in the escape function instead.

Thank for for the review and the comments.

I changed the patch as you suggested to upper-case the realm in the
escape function if the flag is set.

I didn't add any checks to make sure that the realm of newly added
principal attributes is always upper case. Since the attributes can be
added via various ways I think the check should happen on the DS level
but I see this more in the context of full canonicalization fix covered
by https://fedorahosted.org/freeipa/ticket/3864 . If you think this is a
requirement for the patch attached I would suggest to drop
https://fedorahosted.org/freeipa/ticket/4844 and solve it together with
#3864.

I added a second patch which makes the unit test a bit more robust if
the krb5.conf on the system running the tests is broken.

bye,
Sumit

> 
> > What I got from the comments in the ticket and the related bugzilla
> > ticket is that it should be possible to get a TGT for a user even if the
> > realm is given in lower-case if canonicalization is enabled. Please note
> > that the client can only send such request because we have
> > 'dns_lookup_kdc = true' in krb.conf and DNS is case in-sensitive. If you
> > set 'dns_lookup_kdc = false' the client will fail immediately without
> > sending a request at all, because it is not able to find a KDC for the
> > lower-case realm.
> > 
> > On the server-side the request is processed because of
> > http://k5wiki.kerberos.org/wiki/Projects/Aliases which made parts of
> > processing case in-sensitive.
> > 
> > With the attached patch a second lookup is done if the lookup with the
> > original input returned no result, canonicalization is
> > enabled and the realm

Re: [Freeipa-devel] [PATCH 149] IPA KDB: allow case in-sensitive realm in AS request

[Sumit Bose]

On Tue, Jul 21, 2015 at 01:41:14PM +0200, Sumit Bose wrote:
> Hi,
> 
> this patch is my suggestion to solve
> https://fedorahosted.org/freeipa/ticket/4844 .
> 
> The original issue in the ticket has two part. One is a loop in libkrb5
> which is already fixed. The other is to handle canonicalization better.
> 
> The general way to allow canonicalization on a principal is to add the
> attributes 'krbcanonicalname'[1] and 'ipakrbprincipalalias' together
> with the objectclass 'ipaKrbPrincipal' to the user object. Then the IPA
> KDB backend will use 'ipakrbprincipalalias' for case in-sensitive
> matches and  the principal from 'krbcanonicalname' will be the canonical
> principal used further on. The 'krbPrincipalName' is not suitable for
> either because it has caseExact* matching rules and is a multivalue
> attribute [2].
> 
> What I got from the comments in the ticket and the related bugzilla
> ticket is that it should be possible to get a TGT for a user even if the
> realm is given in lower-case if canonicalization is enabled. Please note
> that the client can only send such request because we have
> 'dns_lookup_kdc = true' in krb.conf and DNS is case in-sensitive. If you
> set 'dns_lookup_kdc = false' the client will fail immediately without
> sending a request at all, because it is not able to find a KDC for the
> lower-case realm.
> 
> On the server-side the request is processed because of
> http://k5wiki.kerberos.org/wiki/Projects/Aliases which made parts of
> processing case in-sensitive.
> 
> With the attached patch a second lookup is done if the lookup with the
> original input returned no result, canonicalization is
> enabled and the realm from the original input matches the IPA realm case
> in-sensitive. For the second lookup the realm is replace with the IPA
> realm. This approach adds a bit redundant code but does not add extra
> processing requests which would be successful before.
> 
> Without the patch
> kinitipauser@IPA.REALM -> success
> kinit -C ipauser@IPA.REALM -> success
> kinitipauser@ipa.realm -> failure
> kinit -C ipauser@ipa.realm -> failure
> 
> With the patch
> kinitipauser@IPA.REALM -> success
> kinit -C ipauser@IPA.REALM -> success
> kinitipauser@ipa.realm -> success

ah, sorry, copy-and-paste error, this will of course still fail. Even if
we would automatically canonicalize it on the server the client wouldn't
accept the changed principal without the -C option.

bye,
Sumit


> kinit -C ipauser@ipa.realm -> success
> 
> where 'ipa.realm' can be replace by mixed case version like 'iPa.ReAlM'
> as well.
> 
> bye,
> Sumit
> 
> [1] I was not able to add 'krbcanonicalname' as admin user because of an
> ACI denial. I wonder if this is expected or if the ACI rules should be
> extended here?
> 
> [2] We might to skip the requirement that 'krbcanonicalname' must exists
> if 'ipaKrbPrincipal' only has a single value but canonicalization will
> fail immediately if someone adds a second value so I guess it would be
> more safe to keep it as it is.
> 

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

[Freeipa-devel] [PATCH 149] IPA KDB: allow case in-sensitive realm in AS request

[Sumit Bose]

Hi,

this patch is my suggestion to solve
https://fedorahosted.org/freeipa/ticket/4844 .

The original issue in the ticket has two part. One is a loop in libkrb5
which is already fixed. The other is to handle canonicalization better.

The general way to allow canonicalization on a principal is to add the
attributes 'krbcanonicalname'[1] and 'ipakrbprincipalalias' together
with the objectclass 'ipaKrbPrincipal' to the user object. Then the IPA
KDB backend will use 'ipakrbprincipalalias' for case in-sensitive
matches and  the principal from 'krbcanonicalname' will be the canonical
principal used further on. The 'krbPrincipalName' is not suitable for
either because it has caseExact* matching rules and is a multivalue
attribute [2].

What I got from the comments in the ticket and the related bugzilla
ticket is that it should be possible to get a TGT for a user even if the
realm is given in lower-case if canonicalization is enabled. Please note
that the client can only send such request because we have
'dns_lookup_kdc = true' in krb.conf and DNS is case in-sensitive. If you
set 'dns_lookup_kdc = false' the client will fail immediately without
sending a request at all, because it is not able to find a KDC for the
lower-case realm.

On the server-side the request is processed because of
http://k5wiki.kerberos.org/wiki/Projects/Aliases which made parts of
processing case in-sensitive.

With the attached patch a second lookup is done if the lookup with the
original input returned no result, canonicalization is
enabled and the realm from the original input matches the IPA realm case
in-sensitive. For the second lookup the realm is replace with the IPA
realm. This approach adds a bit redundant code but does not add extra
processing requests which would be successful before.

Without the patch
kinitipauser@IPA.REALM -> success
kinit -C ipauser@IPA.REALM -> success
kinitipauser@ipa.realm -> failure
kinit -C ipauser@ipa.realm -> failure

With the patch
kinitipauser@IPA.REALM -> success
kinit -C ipauser@IPA.REALM -> success
kinitipauser@ipa.realm -> success
kinit -C ipauser@ipa.realm -> success

where 'ipa.realm' can be replace by mixed case version like 'iPa.ReAlM'
as well.

bye,
Sumit

[1] I was not able to add 'krbcanonicalname' as admin user because of an
ACI denial. I wonder if this is expected or if the ACI rules should be
extended here?

[2] We might to skip the requirement that 'krbcanonicalname' must exists
if 'ipaKrbPrincipal' only has a single value but canonicalization will
fail immediately if someone adds a second value so I guess it would be
more safe to keep it as it is.

From 39744160f1779cf8e5ff00531b432c88fc53200b Mon Sep 17 00:00:00 2001
From: Sumit Bose 
Date: Tue, 21 Jul 2015 12:12:56 +0200
Subject: [PATCH] IPA KDB: allow case in-sensitive realm in AS request

If the canonicalization flag is set the realm of the client principal in
an AS request (kinit) may only match case in-sensitive.

Resolves https://fedorahosted.org/freeipa/ticket/4844
---
 daemons/ipa-kdb/ipa_kdb_principals.c | 31 ++-
 1 file changed, 30 insertions(+), 1 deletion(-)

diff --git a/daemons/ipa-kdb/ipa_kdb_principals.c 
b/daemons/ipa-kdb/ipa_kdb_principals.c
index 
b3f8b1ad7784f55f55b4d6edd05f778a9389de27..344d44fb9b20f74615993a561b8b39f34f57cf25
 100644
--- a/daemons/ipa-kdb/ipa_kdb_principals.c
+++ b/daemons/ipa-kdb/ipa_kdb_principals.c
@@ -1026,6 +1026,8 @@ krb5_error_code ipadb_get_principal(krb5_context kcontext,
 LDAPMessage *res = NULL;
 LDAPMessage *lentry;
 uint32_t pol;
+size_t realm_len;
+char *p;
 
 ipactx = ipadb_get_context(kcontext);
 if (!ipactx) {
@@ -1044,7 +1046,34 @@ krb5_error_code ipadb_get_principal(krb5_context 
kcontext,
 
 kerr = ipadb_find_principal(kcontext, flags, res, &principal, &lentry);
 if (kerr != 0) {
-goto done;
+realm_len = strlen(ipactx->realm);
+
+/* If canonicalization is enabled and the realm only differs in case
+ * from the IPA realm retry with the correct case. */
+if (kerr == KRB5_KDB_NOENTRY
+&& (flags & KRB5_KDB_FLAG_ALIAS_OK) != 0
+&& krb5_princ_realm(kcontext, search_for)->length == realm_len
+&& strncasecmp(krb5_princ_realm(kcontext,search_for)->data,
+   ipactx->realm, realm_len) == 0) {
+p = strchr(principal, '@');
+if (p == NULL || *(++p + realm_len) != '\0') {
+goto done;
+}
+memcpy(p, ipactx->realm, realm_len);
+
+kerr = ipadb_fetch_principals(ipactx, flags, principal, &res);
+if (kerr != 0) {
+goto done;
+}
+
+ 

Re: [Freeipa-devel] [PATCHES 145-148] ipa-kdb: add unit-test for filter_logon_info()

[Sumit Bose]

On Tue, May 26, 2015 at 01:36:35PM +0200, Martin Kosek wrote:
> On 05/26/2015 01:33 PM, Sumit Bose wrote:
> >Hi,
> >
> >these patches add some unit tests and some additional improvements
> >related to the issues described in
> >https://bugzilla.redhat.com/show_bug.cgi?id=1222475 . The original issue
> >is fixed by a patch from Alexander attached to the ticket.
> >
> >The first patch converts the existing check-based test to cmocka. If I
> >see it correctly all check-based test are converted now.
> 
> Cool! Before pushing, we should also reference ticket
> https://fedorahosted.org/freeipa/ticket/4922
> in the patch (no need to rebase right now).
> 
> >
> >The second adds tests for filter_logon_info() where the original issue
> >occurred. The wrong behavior in filter_logon_info() caused a crash in
> >dom_sid_string() which is made a bit more robust together with
> >string_to_sid() in the 3rd patch. The last patch add unit tests for
> >those two calls as well.

New version rebased on one-way trust patches attached.

Please note that the unit-test will fail with the initial version of the
one-way trust patches which does not allow an empty group list in the
PAC.

bye,
Sumit
From 4a31cfdd848e0ef51ee32817e634340d1e90c97f Mon Sep 17 00:00:00 2001
From: Sumit Bose 
Date: Wed, 20 May 2015 18:31:19 +0200
Subject: [PATCH 145/148] ipa-kdb: convert test to cmocka

---
 daemons/ipa-kdb/Makefile.am   |   6 +-
 daemons/ipa-kdb/tests/ipa_kdb_tests.c | 129 --
 2 files changed, 48 insertions(+), 87 deletions(-)

diff --git a/daemons/ipa-kdb/Makefile.am b/daemons/ipa-kdb/Makefile.am
index 
80747491f8315a9cb0b38965423ba5d160946278..a4ea366b01b248d3f0fbc0b694e02d00c2e4c3d1
 100644
--- a/daemons/ipa-kdb/Makefile.am
+++ b/daemons/ipa-kdb/Makefile.am
@@ -55,7 +55,7 @@ ipadb_la_LIBADD = \
$(NSS_LIBS) \
$(NULL)
 
-if HAVE_CHECK
+if HAVE_CMOCKA
 TESTS = ipa_kdb_tests
 check_PROGRAMS = ipa_kdb_tests
 endif
@@ -73,9 +73,9 @@ ipa_kdb_tests_SOURCES =\
ipa_kdb_audit_as.c  \
$(KRB5_UTIL_SRCS)   \
$(NULL)
-ipa_kdb_tests_CFLAGS = $(CHECK_CFLAGS)
+ipa_kdb_tests_CFLAGS = $(CMOCKA_CFLAGS)
 ipa_kdb_tests_LDADD =  \
-   $(CHECK_LIBS)   \
+   $(CMOCKA_LIBS)  \
$(KRB5_LIBS)\
$(LDAP_LIBS)\
$(NDRPAC_LIBS)  \
diff --git a/daemons/ipa-kdb/tests/ipa_kdb_tests.c 
b/daemons/ipa-kdb/tests/ipa_kdb_tests.c
index 
e1ae06a6e359e65873241116581f028f1a4e1bf3..1ff1cd49a4e409545ee908f0f7842520ae82e0a0
 100644
--- a/daemons/ipa-kdb/tests/ipa_kdb_tests.c
+++ b/daemons/ipa-kdb/tests/ipa_kdb_tests.c
@@ -1,49 +1,30 @@
-/** BEGIN COPYRIGHT BLOCK
- * 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 <http://www.gnu.org/licenses/>.
- *
- * Additional permission under GPLv3 section 7:
- *
- * In the following paragraph, "GPL" means the GNU General Public
- * License, version 3 or any later version, and "Non-GPL Code" means
- * code that is governed neither by the GPL nor a license
- * compatible with the GPL.
- *
- * You may link the code of this Program with Non-GPL Code and convey
- * linked combinations including the two, provided that such Non-GPL
- * Code only links to the code of this Program through those well
- * defined interfaces identified in the file named EXCEPTION found in
- * the source code files (the "Approved Interfaces"). The files of
- * Non-GPL Code may instantiate templates or use macros or inline
- * functions from the Approved Interfaces without causing the resulting
- * work to be covered by the GPL. Only the copyright holders of this
- * Program may make changes or additions to the list of Approved
- * Interfaces.
- *
- * Authors:
- * Sumit Bose 
- *
- * Copyright (C) 2013 Red Hat, Inc.
- * All rights reserved.
- * END COPYRIGHT BLOCK **/
+/*
+Authors:
+Sumit Bose 
 
-#include 
-#include 
+Copyright (C) 2015 Red Hat
+
+ipa-kdb tests
+
+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 distribut

Re: [Freeipa-devel] [PATCH 144] extdom: add unit-test for get_user_grouplist()

[Sumit Bose]

On Tue, May 26, 2015 at 02:47:02PM +0300, Alexander Bokovoy wrote:
> On Tue, 26 May 2015, Sumit Bose wrote:
> >On Tue, May 26, 2015 at 01:24:30PM +0200, Petr Vobornik wrote:
> >>On 05/26/2015 01:21 PM, Sumit Bose wrote:
> >>>Hi,
> >>>
> >>>this tests should have gone together with
> >>>c1114ef82516002de08e004a930b5ba4a1791b25 but got lost somehow during the
> >>>bugzilla processing.
> >>>
> >>>bye,
> >>>Sumit
> >>>
> >>
> >>So it has been acked? And we can push it?
> >
> >I have to admit that I'm not sure, there were just to many related
> >tickets. Alexander, do you remember seeing this patch? If not, I think
> >it would be good if someone can review it. Since it is "only" a
> >unit-test, it is not urgent.
> I've seen this patch and I thought I've acked it by the time...

New version rebased on one-way trust patches is attached.

bye,
Sumit

> -- 
> / Alexander Bokovoy
From 5b5c9250416bf1e55a453c5430ac6be914054aa9 Mon Sep 17 00:00:00 2001
From: Sumit Bose 
Date: Thu, 26 Feb 2015 14:08:06 +0100
Subject: [PATCH 144/148] extdom: add unit-test for get_user_grouplist()

---
 .../ipa-extdom-extop/ipa_extdom.h  |2 +
 .../ipa-extdom-extop/ipa_extdom_cmocka_tests.c |   41 +
 .../ipa-extdom-extop/ipa_extdom_common.c   |4 +-
 .../ipa-extdom-extop/test_data/group   | 1000 
 4 files changed, 1045 insertions(+), 2 deletions(-)

diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h 
b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h
index 
65dd43ea35726db6231386a0fcbba9be1bd71412..a77711977186b702caafa2729dc13090c6031791
 100644
--- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h
+++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h
@@ -185,6 +185,8 @@ int getgrnam_r_wrapper(size_t buf_max, const char *name,
struct group *grp, char **_buf, size_t *_buf_len);
 int getgrgid_r_wrapper(size_t buf_max, gid_t gid,
struct group *grp, char **_buf, size_t *_buf_len);
+int get_user_grouplist(const char *name, gid_t gid,
+   size_t *_ngroups, gid_t **_groups);
 int pack_ber_sid(const char *sid, struct berval **berval);
 int pack_ber_name(const char *domain_name, const char *name,
   struct berval **berval);
diff --git 
a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_cmocka_tests.c 
b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_cmocka_tests.c
index 
42d588d08a96f8a26345f85aade9523e05f6f56e..ec553fe62c27738f258defc267fe761c72157df0
 100644
--- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_cmocka_tests.c
+++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_cmocka_tests.c
@@ -213,6 +213,46 @@ void test_getgrgid_r_wrapper(void **state)
 free(buf);
 }
 
+void test_get_user_grouplist(void **state)
+{
+int ret;
+size_t ngroups;
+gid_t *groups;
+size_t c;
+
+/* This is a bit odd behaviour of getgrouplist() it does not check if the
+ * user exists, only if memberships of the user can be found. */
+ret = get_user_grouplist("non_exisiting_user", 23456, &ngroups, &groups);
+assert_int_equal(ret, LDAP_SUCCESS);
+assert_int_equal(ngroups, 1);
+assert_int_equal(groups[0], 23456);
+free(groups);
+
+ret = get_user_grouplist("member0001", 23456, &ngroups, &groups);
+assert_int_equal(ret, LDAP_SUCCESS);
+assert_int_equal(ngroups, 3);
+assert_int_equal(groups[0], 23456);
+assert_int_equal(groups[1], 1);
+assert_int_equal(groups[2], 2);
+free(groups);
+
+ret = get_user_grouplist("member0003", 23456, &ngroups, &groups);
+assert_int_equal(ret, LDAP_SUCCESS);
+assert_int_equal(ngroups, 2);
+assert_int_equal(groups[0], 23456);
+assert_int_equal(groups[1], 2);
+free(groups);
+
+ret = get_user_grouplist("user_big", 23456, &ngroups, &groups);
+assert_int_equal(ret, LDAP_SUCCESS);
+assert_int_equal(ngroups, 1001);
+assert_int_equal(groups[0], 23456);
+for (c = 1; c < ngroups; c++) {
+assert_int_equal(groups[c], 2 + c);
+}
+free(groups);
+}
+
 struct test_data {
 struct extdom_req *req;
 struct ipa_extdom_ctx *ctx;
@@ -398,6 +438,7 @@ int main(int argc, const char *argv[])
 unit_test(test_getpwuid_r_wrapper),
 unit_test(test_getgrnam_r_wrapper),
 unit_test(test_getgrgid_r_wrapper),
+unit_test(test_get_user_grouplist),
 unit_test_setup_teardown(test_set_err_msg,
  extdom_req_setup, extdom_req_teardown),
 unit_test_setup_teardown(test_encode,
diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.

Re: [Freeipa-devel] #4905: [RFE] Allow Kerberos authentication for users with certificates on smart cards (pkinit)

[Sumit Bose]

On Fri, May 29, 2015 at 12:54:13PM +0200, Martin Kosek wrote:
> On 05/29/2015 12:33 PM, Sumit Bose wrote:
> >On Fri, May 29, 2015 at 12:10:24PM +0200, Martin Kosek wrote:
> >>On 05/29/2015 11:26 AM, Sumit Bose wrote:
> >>>On Fri, May 29, 2015 at 10:38:41AM +0200, Martin Kosek wrote:
> >>>>Hello all,
> >>>>
> >>>>I would like to discuss the scope needed for ticket 4905 [1]. This is 
> >>>>mostly
> >>>>question for Sumit as he is working on the SSSD SC support. The main 
> >>>>minimal
> >>>>target is to allow SSSD get a ticket for a user once he authenticates with
> >>>>his SC with certificates tracked in FreeIPA as agreed in [2].
> >>>>
> >>>>Sumit, Simo or others, what changes are required in order to do this? In
> >>>>[1], I so far identified:
> >>>>
> >>>>* Support of Smart Cards in SSSD (​upstream ticket)
> >>>>* API/CLI for configuring the trusted CA certificate in KDC (related - 
> >>>>#616)
> >>>>
> >>>>as the base. What else is needed? Any krb5.conf changes on the
> >>>>server/clients? Or even generating the certs/keys as mentioned in [3]?
> >>>
> >>>currently I would say krb5.conf both on IPA clients and servers already
> >>>have all the needed entries.
> >>
> >>Doesn't FreeIPA KDC need a list of CAs issuing the Smart Cards that it can 
> >>trust?
> >
> >in general yes. If there are certificate which are not created by the
> >IPA CA and have the id-pkinit-san entry we currently would need a
> >pkinit_anchors in krb5.conf pointing to the CA cert.
> 
> This would need to be set on all IPA masters or the clients too? Would it be
> possible to update our KDC driver to tell KDC what is the location of these
> certs or anyhow feed it with the certs when they are available?

After reading the man pages again it looks that pkinit_anchors is only
needed to validate the certificate of the KDC itself. As long as this is
issued by the IPA CA all should be fine. The user certificates are
checked by the pkinit plugin via OpenSSL with the help of the CA certs
that are accessible to OpenSSL. So if the user certificate is signed by
a CA which is currently not known it has to be distributed to all hosts.

But I checked the IPA install code as well and realized that there is
'options.setup_pkinit = False' in ipa-server-install. I will check at
the beginning of next week if this can be removed.

> 
> >But I guess this
> >should go into the documentation because the cert of the other CA might
> >not be available at installation time.
> 
> Right, it wouldn't be. We would need to have an API to add/remove those
> external CA certificates.
> 
> >
> >Since we have to touch the Kerberos pkinit code anyway to support
> >certificates without the id-pkinit-san entry we might add other ways to
> >make the CA cert available, e.g. by storing it at some place in the
> >directory tree.
> 
> Would the id-pkinit-san entry be needed if we implement the client lookup
> within SSSD?

no

> 
> >
> >>
> >>>>In current code base, we still have the disabled pkinit plugin [4], but I
> >>>>assume this is not what we want.
> >>>
> >>>I think this is only for anonymous pkinit. The general pkinit preauth
> >>>plugin is automatically available as long as the krb5-pkinit package is
> >>>installed. The package contains both client and server side of the
> >>>plugin, so it must be available on IPA clients and servers.
> >>
> >>Ok. This can be added to Requires, that's a simple change.
> >>
> >>>>Thanks for help and advise. Based on what is found out in this thread, we
> >>>>will see what's realistic for FreeIPA 4.2 or FreeIPA 4.2.x.
> >>>
> >>>My understanding is that the current version of the MIT Kerberos pkinit
> >>>plugin needs a id-pkinit-san entry in the Subject Alternatives Names of
> >>>the certificate with the Kerberos principal of the given user.
> >>>
> >>>I think it would be good to add this entry to user certificates IPA
> >>>generates on its own. The pkinit RFC 4556 mentioned that the KDC can do
> >>>the mapping between the certificate and the user principal on its own.
> >>
> >>Can SSSD aid the mapping anyhow? It will know what is the user principal,
> >>based on FreeIPA special mapping.
> >
> >Sure, as soon as the 'Certificate Identity Mappi

Re: [Freeipa-devel] #4905: [RFE] Allow Kerberos authentication for users with certificates on smart cards (pkinit)

[Sumit Bose]

On Fri, May 29, 2015 at 12:10:24PM +0200, Martin Kosek wrote:
> On 05/29/2015 11:26 AM, Sumit Bose wrote:
> >On Fri, May 29, 2015 at 10:38:41AM +0200, Martin Kosek wrote:
> >>Hello all,
> >>
> >>I would like to discuss the scope needed for ticket 4905 [1]. This is mostly
> >>question for Sumit as he is working on the SSSD SC support. The main minimal
> >>target is to allow SSSD get a ticket for a user once he authenticates with
> >>his SC with certificates tracked in FreeIPA as agreed in [2].
> >>
> >>Sumit, Simo or others, what changes are required in order to do this? In
> >>[1], I so far identified:
> >>
> >>* Support of Smart Cards in SSSD (​upstream ticket)
> >>* API/CLI for configuring the trusted CA certificate in KDC (related - #616)
> >>
> >>as the base. What else is needed? Any krb5.conf changes on the
> >>server/clients? Or even generating the certs/keys as mentioned in [3]?
> >
> >currently I would say krb5.conf both on IPA clients and servers already
> >have all the needed entries.
> 
> Doesn't FreeIPA KDC need a list of CAs issuing the Smart Cards that it can 
> trust?

in general yes. If there are certificate which are not created by the
IPA CA and have the id-pkinit-san entry we currently would need a
pkinit_anchors in krb5.conf pointing to the CA cert. But I guess this
should go into the documentation because the cert of the other CA might
not be available at installation time.

Since we have to touch the Kerberos pkinit code anyway to support
certificates without the id-pkinit-san entry we might add other ways to
make the CA cert available, e.g. by storing it at some place in the
directory tree.

> 
> >>In current code base, we still have the disabled pkinit plugin [4], but I
> >>assume this is not what we want.
> >
> >I think this is only for anonymous pkinit. The general pkinit preauth
> >plugin is automatically available as long as the krb5-pkinit package is
> >installed. The package contains both client and server side of the
> >plugin, so it must be available on IPA clients and servers.
> 
> Ok. This can be added to Requires, that's a simple change.
> 
> >>Thanks for help and advise. Based on what is found out in this thread, we
> >>will see what's realistic for FreeIPA 4.2 or FreeIPA 4.2.x.
> >
> >My understanding is that the current version of the MIT Kerberos pkinit
> >plugin needs a id-pkinit-san entry in the Subject Alternatives Names of
> >the certificate with the Kerberos principal of the given user.
> >
> >I think it would be good to add this entry to user certificates IPA
> >generates on its own. The pkinit RFC 4556 mentioned that the KDC can do
> >the mapping between the certificate and the user principal on its own.
> 
> Can SSSD aid the mapping anyhow? It will know what is the user principal,
> based on FreeIPA special mapping.

Sure, as soon as the 'Certificate Identity Mapping' is specified I can
implement the lookups in SSSD which do not require that the certificate
is stored in the directory tree. We have to determine what would be the
best way for the KDC/pkinit plugin to access SSSD for this. Currently
only InfoPipe/D-BUS supports certificate lookups which might not be the
best choice here.

HTH

bye,
Sumit

> 
> >But given that afaik there is currently no support for this scheme in
> >the MIT pkinit plugin and hence it would require enhancements in the MIT
> >code and maybe in the IPA KDB backend as well I think the support for
> >certificates without a id-pkinit-san entry is out-of-scope for 4.2.
> 
> I see.
> 
> >Nevertheless client side authentication would still work only the user
> >will not have a valid Kerberos TGT after logging in.
> >
> >HTH
> >
> >bye,
> >Sumit
> >
> >>
> >>[1] https://fedorahosted.org/freeipa/ticket/4905
> >>[2] http://www.freeipa.org/page/V4/User_Certificates
> >>[3] https://fedorahosted.org/freeipa/ticket/55#comment:3
> >>[4] 
> >>https://git.fedorahosted.org/cgit/freeipa.git/tree/ipalib/plugins/pkinit.py
> >>
> >>--
> >>Martin Kosek 
> >>Supervisor, Software Engineering - Identity Management Team
> >>Red Hat Inc.
> 

-- 
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] #4905: [RFE] Allow Kerberos authentication for users with certificates on smart cards (pkinit)

[Sumit Bose]

On Fri, May 29, 2015 at 10:38:41AM +0200, Martin Kosek wrote:
> Hello all,
> 
> I would like to discuss the scope needed for ticket 4905 [1]. This is mostly
> question for Sumit as he is working on the SSSD SC support. The main minimal
> target is to allow SSSD get a ticket for a user once he authenticates with
> his SC with certificates tracked in FreeIPA as agreed in [2].
> 
> Sumit, Simo or others, what changes are required in order to do this? In
> [1], I so far identified:
> 
> * Support of Smart Cards in SSSD (​upstream ticket)
> * API/CLI for configuring the trusted CA certificate in KDC (related - #616)
> 
> as the base. What else is needed? Any krb5.conf changes on the
> server/clients? Or even generating the certs/keys as mentioned in [3]?

currently I would say krb5.conf both on IPA clients and servers already
have all the needed entries.

> 
> In current code base, we still have the disabled pkinit plugin [4], but I
> assume this is not what we want.

I think this is only for anonymous pkinit. The general pkinit preauth
plugin is automatically available as long as the krb5-pkinit package is
installed. The package contains both client and server side of the
plugin, so it must be available on IPA clients and servers.

> 
> Thanks for help and advise. Based on what is found out in this thread, we
> will see what's realistic for FreeIPA 4.2 or FreeIPA 4.2.x.

My understanding is that the current version of the MIT Kerberos pkinit
plugin needs a id-pkinit-san entry in the Subject Alternatives Names of
the certificate with the Kerberos principal of the given user. 

I think it would be good to add this entry to user certificates IPA
generates on its own. The pkinit RFC 4556 mentioned that the KDC can do
the mapping between the certificate and the user principal on its own.
But given that afaik there is currently no support for this scheme in
the MIT pkinit plugin and hence it would require enhancements in the MIT
code and maybe in the IPA KDB backend as well I think the support for
certificates without a id-pkinit-san entry is out-of-scope for 4.2.
Nevertheless client side authentication would still work only the user
will not have a valid Kerberos TGT after logging in.

HTH

bye,
Sumit

> 
> [1] https://fedorahosted.org/freeipa/ticket/4905
> [2] http://www.freeipa.org/page/V4/User_Certificates
> [3] https://fedorahosted.org/freeipa/ticket/55#comment:3
> [4] 
> https://git.fedorahosted.org/cgit/freeipa.git/tree/ipalib/plugins/pkinit.py
> 
> -- 
> Martin Kosek 
> Supervisor, Software Engineering - Identity Management Team
> Red Hat Inc.

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

Re: [Freeipa-devel] [PATCH 0014] Support multiple user and host certificates

[Sumit Bose]

On Wed, May 27, 2015 at 06:12:50PM +0200, Martin Basti wrote:
> On 27/05/15 15:53, Fraser Tweedale wrote:
> >This patch adds supports for multiple user / host certificates.  No
> >schema change is needed ('usercertificate' attribute is already
> >multi-value).  The revoke-previous-cert behaviour of host-mod and
> >user-mod has been removed but revocation behaviour of -del and
> >-disable is preserved.
> >
> >The latest profiles/caacl patchset (0001..0013 v5) depends on this
> >patch for correct cert-request behaviour.
> >
> >There is one design question (or maybe more, let me know): the
> >`--out=FILENAME' option to {host,service} show saves ONE certificate
> >to the named file.  I propose to either:
> >
> >a) write all certs, suffixing suggested filename with either a
> >sequential numerical index, e.g. "cert.pem" becomes
> >"cert.pem.1", "cert.pem.2", and so on; or
> >
> >b) as above, but suffix with serial number and, if there are
> >different issues, some issuer-identifying information.
> >
> >Let me know your thoughts.
> >
> >Thanks,
> >Fraser
> >
> >
> Is there a possible way how to store certificates into one file?
> I read about possibilities to have multiple certs in one .pem file, but I'm
> not cert guru :)

It is possible, check e.g. /etc/pki/tls/cert.pem.

bye,
Sumit

> 
> I personally vote for serial number in case there are multiple certificates,
> if ^ is no possible.
> 
> 
> 1)
> +if len(certs) > 0:
> 
> please use only,
> if certs:
> 
> 2)
> You need to re-generate API/ACI.txt in this patch
> 
> 3)
> syntax error:
> +for dercert in certs_der
> 
> 
> 4)
> command
> ipa user-mod ca_user --certificate=
> 
> removes the current certificate from the LDAP, by design.
> Should be the old certificate(s) revoked? You removed that part in the code.
> 
> only the --addattr='usercertificate=' appends new value there
> 
> -- 
> Martin Basti
> 

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

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

Re: [Freeipa-devel] [PATCH 144] extdom: add unit-test for get_user_grouplist()

[Sumit Bose]

On Tue, May 26, 2015 at 01:24:30PM +0200, Petr Vobornik wrote:
> On 05/26/2015 01:21 PM, Sumit Bose wrote:
> >Hi,
> >
> >this tests should have gone together with
> >c1114ef82516002de08e004a930b5ba4a1791b25 but got lost somehow during the
> >bugzilla processing.
> >
> >bye,
> >Sumit
> >
> 
> So it has been acked? And we can push it?

I have to admit that I'm not sure, there were just to many related
tickets. Alexander, do you remember seeing this patch? If not, I think
it would be good if someone can review it. Since it is "only" a
unit-test, it is not urgent.

bye,
Sumit

> -- 
> Petr Vobornik

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

[Freeipa-devel] [PATCHES 145-148] ipa-kdb: add unit-test for filter_logon_info()

[Sumit Bose]

Hi,

these patches add some unit tests and some additional improvements
related to the issues described in
https://bugzilla.redhat.com/show_bug.cgi?id=1222475 . The original issue
is fixed by a patch from Alexander attached to the ticket.

The first patch converts the existing check-based test to cmocka. If I
see it correctly all check-based test are converted now.

The second adds tests for filter_logon_info() where the original issue
occurred. The wrong behavior in filter_logon_info() caused a crash in
dom_sid_string() which is made a bit more robust together with
string_to_sid() in the 3rd patch. The last patch add unit tests for
those two calls as well.

bye,
Sumit
From ddd3ac0a38521ae9450f9dee46fbd8434ac85870 Mon Sep 17 00:00:00 2001
From: Sumit Bose 
Date: Wed, 20 May 2015 18:31:19 +0200
Subject: [PATCH 145/148] ipa-kdb: convert test to cmocka

---
 daemons/ipa-kdb/Makefile.am   |   6 +-
 daemons/ipa-kdb/tests/ipa_kdb_tests.c | 129 --
 2 files changed, 48 insertions(+), 87 deletions(-)

diff --git a/daemons/ipa-kdb/Makefile.am b/daemons/ipa-kdb/Makefile.am
index 
80747491f8315a9cb0b38965423ba5d160946278..a4ea366b01b248d3f0fbc0b694e02d00c2e4c3d1
 100644
--- a/daemons/ipa-kdb/Makefile.am
+++ b/daemons/ipa-kdb/Makefile.am
@@ -55,7 +55,7 @@ ipadb_la_LIBADD = \
$(NSS_LIBS) \
$(NULL)
 
-if HAVE_CHECK
+if HAVE_CMOCKA
 TESTS = ipa_kdb_tests
 check_PROGRAMS = ipa_kdb_tests
 endif
@@ -73,9 +73,9 @@ ipa_kdb_tests_SOURCES =\
ipa_kdb_audit_as.c  \
$(KRB5_UTIL_SRCS)   \
$(NULL)
-ipa_kdb_tests_CFLAGS = $(CHECK_CFLAGS)
+ipa_kdb_tests_CFLAGS = $(CMOCKA_CFLAGS)
 ipa_kdb_tests_LDADD =  \
-   $(CHECK_LIBS)   \
+   $(CMOCKA_LIBS)  \
$(KRB5_LIBS)\
$(LDAP_LIBS)\
$(NDRPAC_LIBS)  \
diff --git a/daemons/ipa-kdb/tests/ipa_kdb_tests.c 
b/daemons/ipa-kdb/tests/ipa_kdb_tests.c
index 
e1ae06a6e359e65873241116581f028f1a4e1bf3..1ff1cd49a4e409545ee908f0f7842520ae82e0a0
 100644
--- a/daemons/ipa-kdb/tests/ipa_kdb_tests.c
+++ b/daemons/ipa-kdb/tests/ipa_kdb_tests.c
@@ -1,49 +1,30 @@
-/** BEGIN COPYRIGHT BLOCK
- * 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 <http://www.gnu.org/licenses/>.
- *
- * Additional permission under GPLv3 section 7:
- *
- * In the following paragraph, "GPL" means the GNU General Public
- * License, version 3 or any later version, and "Non-GPL Code" means
- * code that is governed neither by the GPL nor a license
- * compatible with the GPL.
- *
- * You may link the code of this Program with Non-GPL Code and convey
- * linked combinations including the two, provided that such Non-GPL
- * Code only links to the code of this Program through those well
- * defined interfaces identified in the file named EXCEPTION found in
- * the source code files (the "Approved Interfaces"). The files of
- * Non-GPL Code may instantiate templates or use macros or inline
- * functions from the Approved Interfaces without causing the resulting
- * work to be covered by the GPL. Only the copyright holders of this
- * Program may make changes or additions to the list of Approved
- * Interfaces.
- *
- * Authors:
- * Sumit Bose 
- *
- * Copyright (C) 2013 Red Hat, Inc.
- * All rights reserved.
- * END COPYRIGHT BLOCK **/
+/*
+Authors:
+Sumit Bose 
 
-#include 
-#include 
+Copyright (C) 2015 Red Hat
+
+ipa-kdb tests
+
+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 <http://www.gnu.org/licenses/>.
+*/
+
+#include 
 #include 
-#include 
-#include 
-#include 
-#include 
+#include 
+#include 
+#include 
 
 #include "ipa-kdb/ipa_kdb.h"
 
@@ -74,7 +55,7 @@ int krb5_klog_syslog(int l, const char *format, ...)
 extern void get_

[Freeipa-devel] [PATCH 144] extdom: add unit-test for get_user_grouplist()

[Sumit Bose]

Hi,

this tests should have gone together with
c1114ef82516002de08e004a930b5ba4a1791b25 but got lost somehow during the
bugzilla processing.

bye,
Sumit
From 724258fc3eff2872cf95a5401f25b8134233ee68 Mon Sep 17 00:00:00 2001
From: Sumit Bose 
Date: Thu, 26 Feb 2015 14:08:06 +0100
Subject: [PATCH] extdom: add unit-test for get_user_grouplist()

---
 .../ipa-extdom-extop/ipa_extdom.h  |2 +
 .../ipa-extdom-extop/ipa_extdom_cmocka_tests.c |   41 +
 .../ipa-extdom-extop/ipa_extdom_common.c   |4 +-
 .../ipa-extdom-extop/test_data/group   | 1000 
 4 files changed, 1045 insertions(+), 2 deletions(-)

diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h 
b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h
index 
65dd43ea35726db6231386a0fcbba9be1bd71412..a77711977186b702caafa2729dc13090c6031791
 100644
--- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h
+++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h
@@ -185,6 +185,8 @@ int getgrnam_r_wrapper(size_t buf_max, const char *name,
struct group *grp, char **_buf, size_t *_buf_len);
 int getgrgid_r_wrapper(size_t buf_max, gid_t gid,
struct group *grp, char **_buf, size_t *_buf_len);
+int get_user_grouplist(const char *name, gid_t gid,
+   size_t *_ngroups, gid_t **_groups);
 int pack_ber_sid(const char *sid, struct berval **berval);
 int pack_ber_name(const char *domain_name, const char *name,
   struct berval **berval);
diff --git 
a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_cmocka_tests.c 
b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_cmocka_tests.c
index 
42d588d08a96f8a26345f85aade9523e05f6f56e..ec553fe62c27738f258defc267fe761c72157df0
 100644
--- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_cmocka_tests.c
+++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_cmocka_tests.c
@@ -213,6 +213,46 @@ void test_getgrgid_r_wrapper(void **state)
 free(buf);
 }
 
+void test_get_user_grouplist(void **state)
+{
+int ret;
+size_t ngroups;
+gid_t *groups;
+size_t c;
+
+/* This is a bit odd behaviour of getgrouplist() it does not check if the
+ * user exists, only if memberships of the user can be found. */
+ret = get_user_grouplist("non_exisiting_user", 23456, &ngroups, &groups);
+assert_int_equal(ret, LDAP_SUCCESS);
+assert_int_equal(ngroups, 1);
+assert_int_equal(groups[0], 23456);
+free(groups);
+
+ret = get_user_grouplist("member0001", 23456, &ngroups, &groups);
+assert_int_equal(ret, LDAP_SUCCESS);
+assert_int_equal(ngroups, 3);
+assert_int_equal(groups[0], 23456);
+assert_int_equal(groups[1], 1);
+assert_int_equal(groups[2], 2);
+free(groups);
+
+ret = get_user_grouplist("member0003", 23456, &ngroups, &groups);
+assert_int_equal(ret, LDAP_SUCCESS);
+assert_int_equal(ngroups, 2);
+assert_int_equal(groups[0], 23456);
+assert_int_equal(groups[1], 2);
+free(groups);
+
+ret = get_user_grouplist("user_big", 23456, &ngroups, &groups);
+assert_int_equal(ret, LDAP_SUCCESS);
+assert_int_equal(ngroups, 1001);
+assert_int_equal(groups[0], 23456);
+for (c = 1; c < ngroups; c++) {
+assert_int_equal(groups[c], 2 + c);
+}
+free(groups);
+}
+
 struct test_data {
 struct extdom_req *req;
 struct ipa_extdom_ctx *ctx;
@@ -398,6 +438,7 @@ int main(int argc, const char *argv[])
 unit_test(test_getpwuid_r_wrapper),
 unit_test(test_getgrnam_r_wrapper),
 unit_test(test_getgrgid_r_wrapper),
+unit_test(test_get_user_grouplist),
 unit_test_setup_teardown(test_set_err_msg,
  extdom_req_setup, extdom_req_teardown),
 unit_test_setup_teardown(test_encode,
diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c 
b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c
index 
b2e690471cd045154454a26aa6756c2628bbc262..f5905c78e5f6eb635fcd0acf0afeda3bdb3b9baa
 100644
--- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c
+++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c
@@ -400,8 +400,8 @@ int check_request(struct extdom_req *req, enum 
extdom_version version)
 return LDAP_SUCCESS;
 }
 
-static int get_user_grouplist(const char *name, gid_t gid,
-  size_t *_ngroups, gid_t **_groups )
+int get_user_grouplist(const char *name, gid_t gid,
+   size_t *_ngroups, gid_t **_groups)
 {
 int ret;
 int ngroups;
diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/test_data/group 
b/daemons/ipa-slapi-plugins/ipa-extdom-extop/test_data/group
index 
8d1b012871b21cc9d5ffdba2168f35ef3e8a5f81..8394789f9ab89cda928af7a3e2b03de1f2a98395
 100644
--- a/daemons/ipa-sla

[Freeipa-devel] [PATCH 143] ipa-sam: use proper domain GUID

[Sumit Bose]

Hi,

I came across this very old code. Before there was a domain GUID
attribute for the IPA domain in the directory tree ipa-sam used a
auto generated one. Since we now have that attribute and deliver it e.g.
via CLDAP ipa-sam should use the same.

bye,
Sumit
From 45af7302b80bff25892bb6629689dbf4dfa3b37d Mon Sep 17 00:00:00 2001
From: Sumit Bose 
Date: Fri, 16 Jan 2015 12:35:57 +0100
Subject: [PATCH] ipa-sam: use proper domain GUID

---
 daemons/ipa-sam/ipa_sam.c | 28 
 1 file changed, 16 insertions(+), 12 deletions(-)

diff --git a/daemons/ipa-sam/ipa_sam.c b/daemons/ipa-sam/ipa_sam.c
index 
07249fd27b362ed6499e372d651192dfc31b5173..f514546fd3152bda65062a8c236dedd787f7a5d8
 100644
--- a/daemons/ipa-sam/ipa_sam.c
+++ b/daemons/ipa-sam/ipa_sam.c
@@ -126,6 +126,7 @@ void idmap_cache_set_sid2unixid(const struct dom_sid *sid, 
struct unixid *unix_i
 #define LDAP_ATTRIBUTE_SUPPORTED_ENC_TYPE "ipaNTSupportedEncryptionTypes"
 #define LDAP_ATTRIBUTE_TRUST_PARTNER "ipaNTTrustPartner"
 #define LDAP_ATTRIBUTE_FLAT_NAME "ipaNTFlatName"
+#define LDAP_ATTRIBUTE_DOMAIN_GUID "ipaNTDomainGUID"
 #define LDAP_ATTRIBUTE_TRUST_AUTH_OUTGOING "ipaNTTrustAuthOutgoing"
 #define LDAP_ATTRIBUTE_TRUST_AUTH_INCOMING "ipaNTTrustAuthIncoming"
 #define LDAP_ATTRIBUTE_SECURITY_IDENTIFIER "ipaNTSecurityIdentifier"
@@ -179,6 +180,7 @@ struct ipasam_privates {
char *base_dn;
char *trust_dn;
char *flat_name;
+   char *guid;
struct dom_sid fallback_primary_group;
char *server_princ;
char *client_princ;
@@ -3473,8 +3475,6 @@ static struct pdb_domain_info 
*pdb_ipasam_get_domain_info(struct pdb_methods *pd
struct pdb_domain_info *info;
struct ldapsam_privates *ldap_state =
(struct ldapsam_privates *)pdb_methods->private_data;
-   char sid_buf[24];
-   DATA_BLOB sid_blob;
NTSTATUS status;
 
info = talloc(mem_ctx, struct pdb_domain_info);
@@ -3502,16 +3502,7 @@ static struct pdb_domain_info 
*pdb_ipasam_get_domain_info(struct pdb_methods *pd
 
sid_copy(&info->sid, &ldap_state->domain_sid);
 
-   if (!sid_linearize(sid_buf, sizeof(sid_buf), &info->sid)) {
-   goto fail;
-   }
-
-   /* the first 8 bytes of the linearized SID are not random,
-* so we skip them */
-   sid_blob.data = (uint8_t *) sid_buf + 8 ;
-   sid_blob.length = 16;
-
-   status = GUID_from_ndr_blob(&sid_blob, &info->guid);
+   status = GUID_from_string(ldap_state->ipasam_privates->guid, 
&info->guid);
if (!NT_STATUS_IS_OK(status)) {
goto fail;
}
@@ -3612,6 +3603,7 @@ static NTSTATUS ipasam_search_domain_info(struct 
smbldap_state *ldap_state,
const char *filter = "objectClass=ipaNTDomainAttrs";
const char *attr_list[] = {
LDAP_ATTRIBUTE_FLAT_NAME,
+   LDAP_ATTRIBUTE_DOMAIN_GUID,
LDAP_ATTRIBUTE_SID,
LDAP_ATTRIBUTE_FALLBACK_PRIMARY_GROUP,
LDAP_ATTRIBUTE_OBJECTCLASS,
@@ -4525,6 +4517,18 @@ static NTSTATUS pdb_init_ipasam(struct pdb_methods 
**pdb_method,
return NT_STATUS_INVALID_PARAMETER;
}
 
+   ldap_state->ipasam_privates->guid = get_single_attribute(
+   ldap_state,
+   ldap_state->smbldap_state->ldap_struct,
+   entry,
+   LDAP_ATTRIBUTE_DOMAIN_GUID);
+   if (ldap_state->ipasam_privates->guid == NULL) {
+   DEBUG(0, ("Missing mandatory attribute %s.\n",
+ LDAP_ATTRIBUTE_DOMAIN_GUID));
+   ldap_msgfree(result);
+   return NT_STATUS_INVALID_PARAMETER;
+   }
+
err = sss_idmap_init(idmap_talloc, ldap_state->ipasam_privates,
 idmap_talloc_free,
 &ldap_state->ipasam_privates->idmap_ctx);
-- 
2.1.0

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

Re: [Freeipa-devel] [PATCH] extop: For printf formatting warning

[Sumit Bose]

On Thu, Mar 26, 2015 at 07:40:16PM +0100, Lukas Slebodnik wrote:
> On (18/03/15 12:33), Jakub Hrozek wrote:
> >On Wed, Mar 18, 2015 at 11:39:15AM +0100, Sumit Bose wrote:
> >> On Wed, Mar 18, 2015 at 11:25:14AM +0100, Jakub Hrozek wrote:
> >> > I could swear I sent the patch last time when I was reviewing Sumit's
> >> > patches but apparently not.
> >> > 
> >> > It's better to use %zu instead of %d for size_t formatting with recent
> >> > compilers.
> >> 
> >> > >From a088e8c8a9bd29b4c22f1579f2c3705652bf2730 Mon Sep 17 00:00:00 2001
> >> > From: Jakub Hrozek 
> >> > Date: Wed, 18 Mar 2015 11:20:38 +0100
> >> > Subject: [PATCH] extop: For printf formatting warning
> >> > 
> >> > ---
> >> >  daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c | 2 +-
> >> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >> > 
> >> > diff --git 
> >> > a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c 
> >> > b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c
> >> > index 
> >> > 708d0e4a2fc9da4f87a24a49c945587049f7280f..bc25e7643cdebe0eadc0cee4dcba3a392fdc33be
> >> >  100644
> >> > --- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c
> >> > +++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c
> >> > @@ -200,7 +200,7 @@ static int ipa_extdom_init_ctx(Slapi_PBlock *pb, 
> >> > struct ipa_extdom_ctx **_ctx)
> >> >  if (ctx->max_nss_buf_size == 0) {
> >> >  ctx->max_nss_buf_size = DEFAULT_MAX_NSS_BUFFER;
> >> >  }
> >> > -LOG("Maximal nss buffer size set to [%d]!\n", 
> >> > ctx->max_nss_buf_size);
> >> > +LOG("Maximal nss buffer size set to [%zu]!\n", 
> >> > ctx->max_nss_buf_size);
> >> 
> >> I tried this some time ago and found the here not the glibc printf
> >> version is used but I guess some NSPR implementation which does not
> >> support the z specifier. So I would assum that this is not working as
> >> expected. Have you tried to trigger the error message or called LOG
> >> unconditionally with '%zu' ?
> >
> >No, I only tried compiling the code. I haven't expected non-standard
> >printf to be used. sorry.
> >
> >Then what about casting max_nss_buf_size to something large that the NSPR
> >implementation can handle (unsigned long?)
> >
> You can use th modifier "j" and cast to uintmax_t or intmax_t
> 
> man 3 printf says:
>   j  A  following  integer  conversion  corresponds to an intmax_t or
>   uintmax_t argument, or a following n conversion corresponds to a
>   pointer to an intmax_t argument.

looks like NSPR only knows about 'h', 'l' and 'll', see
http://www-archive.mozilla.org/projects/nspr/reference/html/prprf.html#23299
for details.

bye,
Sumit

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

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