from:"sumit\-bose"

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

2017-04-07 Thread 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

2017-03-29 Thread 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 <sb...@redhat.com>
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

2017-03-28 Thread 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 <sb...@redhat.com>
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 <sb...@redhat.com>
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 qualifie

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

2017-03-27 Thread 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 <sb...@redhat.com>
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 <sb...@redhat.com>
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

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

2017-03-27 Thread 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 <sb...@redhat.com>
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

2017-03-27 Thread 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 <sb...@redhat.com>
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

2017-03-27 Thread 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

2017-03-27 Thread 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][reopened] IPA certauth plugin

2017-03-27 Thread 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#575][closed] IPA certauth plugin

2017-03-27 Thread 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#644][synchronized] extdom: improve certificate request

2017-03-27 Thread 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 <sb...@redhat.com>
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 <sb...@redhat.com>
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 qualifie

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

2017-03-27 Thread 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 <sb...@redhat.com>
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(_filter, PRINC_TGS_SEARCH_FILTER,
-   esc_original_princ, esc_original_princ);
+if (filter == NULL) {
+if (flags & KRB5_KDB_FLAG_ALIAS_OK) {
+ret = asprintf(_filter, PRINC_TGS_SEARCH_FILTER,
+   esc_original_princ, esc_original_princ);
+} else {
+ret = asprintf(_filter, PRINC_SEARCH_FILTER, esc_original_princ);
+}
 } else {
-ret = asprintf(_filter, PRINC_SEARCH_FILTER, esc_original_princ);
+if (flags & KRB5_KDB_FLAG_ALIAS_OK) {
+ret = asprintf(_filter, PRINC_TGS_SEARCH_FILTER_EXTRA,
+   esc_original_princ, esc_original_princ, filter);
+} else {
+

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

2017-03-24 Thread 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 <sb...@redhat.com>
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 <sb...@redhat.com>
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 qualifie

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

2017-03-24 Thread 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 <sb...@redhat.com>
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(_filter, PRINC_TGS_SEARCH_FILTER,
-   esc_original_princ, esc_original_princ);
+if (filter == NULL) {
+if (flags & KRB5_KDB_FLAG_ALIAS_OK) {
+ret = asprintf(_filter, PRINC_TGS_SEARCH_FILTER,
+   esc_original_princ, esc_original_princ);
+} else {
+ret = asprintf(_filter, PRINC_SEARCH_FILTER, esc_original_princ);
+}
 } else {
-ret = asprintf(_filter, PRINC_SEARCH_FILTER, esc_original_princ);
+if (flags & KRB5_KDB_FLAG_ALIAS_OK) {
+ret = asprintf(_filter, PRINC_TGS_SEARCH_FILTER_EXTRA,
+   esc_original_princ, esc_original_princ, filter);
+} else {
+

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

2017-03-23 Thread 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 <sb...@redhat.com>
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(_filter, PRINC_TGS_SEARCH_FILTER,
-   esc_original_princ, esc_original_princ);
+if (filter == NULL) {
+if (flags & KRB5_KDB_FLAG_ALIAS_OK) {
+ret = asprintf(_filter, PRINC_TGS_SEARCH_FILTER,
+   esc_original_princ, esc_original_princ);
+} else {
+ret = asprintf(_filter, PRINC_SEARCH_FILTER, esc_original_princ);
+}
 } else {
-ret = asprintf(_filter, PRINC_SEARCH_FILTER, esc_original_princ);
+if (flags & KRB5_KDB_FLAG_ALIAS_OK) {
+ret = asprintf(_filter, PRINC_TGS_SEARCH_FILTER_EXTRA,
+   esc_original_princ, esc_original_princ, filter);
+} else {
+

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

2017-03-23 Thread 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 <sb...@redhat.com>
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 <sb...@redhat.com>
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

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

2017-03-14 Thread 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

2017-03-14 Thread 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 <sb...@redhat.com>
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(_filter, PRINC_TGS_SEARCH_FILTER,
-   esc_original_princ, esc_original_princ);
+if (filter == NULL) {
+if (flags & KRB5_KDB_FLAG_ALIAS_OK) {
+ret = asprintf(_filter, PRINC_TGS_SEARCH_FILTER,
+   esc_original_princ, esc_original_princ);
+} else {
+ret = asprintf(_filter, PRINC_SEARCH_FILTER, esc_original_princ);
+}
 } else {
-ret = asprintf(_filter, PRINC_SEARCH_FILTER, esc_original_princ);
+if (flags & KRB5_KDB_FLAG_ALIAS_OK) {
+ret = asprintf(_filter, PRINC_TGS_SEARCH_FILTER_EXTRA,
+   esc_original_princ, esc_original_princ, filter);
+} else {
+

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

2017-03-13 Thread 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

2017-03-13 Thread 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 <sb...@redhat.com>
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(_filter, PRINC_TGS_SEARCH_FILTER,
-   esc_original_princ, esc_original_princ);
+if (filter == NULL) {
+if (flags & KRB5_KDB_FLAG_ALIAS_OK) {
+ret = asprintf(_filter, PRINC_TGS_SEARCH_FILTER,
+   esc_original_princ, esc_original_princ);
+} else {
+ret = asprintf(_filter, PRINC_SEARCH_FILTER, esc_orig

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

2017-03-10 Thread 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

2017-03-10 Thread 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

2017-03-10 Thread 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

2017-03-08 Thread 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

2017-03-01 Thread 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

2017-02-23 Thread 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

2017-02-22 Thread 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

2017-02-22 Thread 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

2017-01-24 Thread 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] Certificate Identity Mapping

2017-01-18 Thread 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

2017-01-06 Thread 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 authentication fa

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

2017-01-06 Thread 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

2017-01-05 Thread 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. On the client side the
> >

Re: [Freeipa-devel] Certificate Identity Mapping

2017-01-05 Thread 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 was to spe

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

2017-01-05 Thread 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

2016-12-19 Thread Sumit Bose

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

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

>

Re: [Freeipa-devel] Certificate Identity Mapping

2016-12-16 Thread Sumit Bose

 local 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

2016-10-13 Thread 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=9_version=6
> 
> The updated version can be found below as well. Of course more comments and
> suggestions are still very welcome.
> 

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

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

Please let me know your comments and suggestions.

bye,
Sumit

= Matching and Mapping Certificates =

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

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

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

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

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

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

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

Re: [Freeipa-devel] FleetCommander integration

2016-10-13 Thread 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

2016-10-11 Thread 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=9_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 default rules should not apply. To make this possible with the 
above scheme the defa

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

2016-10-10 Thread 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

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

2016-10-06 Thread 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

2016-10-06 Thread 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

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

2016-09-14 Thread 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

2016-07-11 Thread 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

2016-07-07 Thread 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

2016-07-07 Thread 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

2016-07-06 Thread 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 <sb...@redhat.com>
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),
- _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,
-   >princ);
+
+ldap_msgfree(res);
+res = NULL;
+kerr = ipadb_fetch_principals(ipactx, flags, principal, );
 if (kerr != 0) {
 goto done;
 }
 
-kerr = krb5_set_principal_realm(kcontext, kentry->princ, 
trusted_realm);
+kerr = ipadb_find_principal(kcontext, flags, res, ,
+);
 if (kerr != 0) {
 goto done;
 }
-*entry = kentry;
+} else {
+
+kerr = ipadb_is_princ_from_trusted_realm(kcontext,
+ realm,
+ upn->length - (realm 
- upn->data),
+ _realm);
+if (kerr == 0) {
+kentry = calloc(1, sizeof(krb5_db_entry));
+if (!kentry) {
+kerr = ENOMEM;
+goto done;
+}
+kerr = krb5_parse_name(kcontext, principal,
+   >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, );
-- 
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

2016-06-28 Thread 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

2016-06-27 Thread 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 0096] Add authentication indicators support to Host objects

2016-06-24 Thread 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

2016-06-24 Thread 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)
> > > > 
> > > > Mart

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

2016-06-09 Thread 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

2016-06-09 Thread 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

2016-05-27 Thread 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

2016-05-25 Thread 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 <npmccal...@redhat.com>
> > > > 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

2016-05-24 Thread 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 <npmccal...@redhat.com>
> 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 <npmccal...@redhat.com>
> 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 <npmccal...@redhat.com>
> 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 <npmccal...@redhat.com>

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

2016-05-20 Thread 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 <sb...@redhat.com>
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)
 );
 req->data.posix_gid.gid = (gid_t) id;
 break;
+case INP_CERT:
+tag = ber_scanf(ber, "a}", >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, _name, _type);
+if (input_type == INP_SID) {
+ret = sss_nss_getnamebysid(input, _name, _type);
+} else {
+ret = sss_nss_getnamebycert(input, _name, _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

2016-05-06 Thread 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

2016-05-02 Thread 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" <npmccal...@redhat.com>
> > > > > > > > > To: "Matt Rogers" <mrog...@redhat.com>, 
> > > > > > > > > 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 s

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

2016-05-02 Thread 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" <npmccal...@redhat.com>
> > > > > > > To: "Matt Rogers" <mrog...@redhat.com>, 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",
> > >_auth_str);
> > > 
> > > if (require_auth_str != NULL) {
> > > kerr = krb5_dbe_set_string(kcontext, entry, "require_auth", NULL);
> > > }
> > > 
> > &

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

2016-04-27 Thread 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" <npmccal...@redhat.com>
> > > > To: "Matt Rogers" <mrog...@redhat.com>, 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",
   _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

2016-04-26 Thread 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, _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

2016-04-07 Thread 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] Supporting UPNs of trusted forests

2016-03-02 Thread 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: 
>

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

2016-02-24 Thread 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 to create the
> >>>

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

2016-02-24 Thread 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 as seen from the patch it is already

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

2016-02-24 Thread 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

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

2016-01-29 Thread 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

2016-01-06 Thread 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 <sb...@redhat.com>
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, _pac, _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, _pac,
+   _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

2016-01-05 Thread 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 <sb...@redhat.com>
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, 
_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, 
_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(, '\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,
+  ,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, );
+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([sid_index], , sizeof(struct 
dom_sid));
+sid_index++;
+}
+}
+
+break;
+d

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

2015-12-16 Thread 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

2015-11-25 Thread 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()

2015-11-18 Thread 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 <sb...@redhat.com>
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 <sb...@redhat.com>
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 <sb...@redhat.com>
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, , 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

2015-10-09 Thread 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

2015-10-05 Thread 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

2015-09-02 Thread 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

2015-07-28 Thread Sumit Bose

On Wed, Jul 22, 2015 at 09:41:51AM -0400, Simo Sorce wrote:
 - Original Message -
  From: Sumit Bose sb...@redhat.com
  To: freeipa-devel freeipa-devel@redhat.com
  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 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

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

2015-07-28 Thread 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 sb...@redhat.com
   To: freeipa-devel freeipa-devel@redhat.com
   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/krbCanonicalName and then validate the name.
 Return unwilling to perform if the case of the realm is different (or
 fix it on the fly, up for discussion) from the default case as
 configured in the server.
 Will break trusts -- ipasam does add these principals for krbtgt/IPA@AD.

 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.

 We should clsoe 4844 as fixed upstream (there *was* a bug in libkrb5).
 I commented on #3864 about what we can do, and we can also avoid
 changing the schema.
 Yep.

 So on the new patches, what does unify means ? I do not get what it
 means (so probably it is a poor name), I guess you may want to call it
 canonicalization ? (or even 'canon' to shorten it a bit).
 I have same question. I tried to understand why it is called unify and
 failed.

I didn't want to use 'canonical' because the result will not be the
canonical name in the general case but only a name we use for searching.
I was thinking about 'normalized' bit this has a special meaning with
unicode. So I came up with 'unify'. But if you prefer 'canon' I can
change it.

 I think the worst case for a utf8 string is more then length*2, probably
 more like length*6, unless there is some guarantee around case changes

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

2015-07-21 Thread 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 sb...@redhat.com
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;
+}
+
+kerr = ipadb_find_principal(kcontext, flags, res, principal,
+lentry);
+if (kerr != 0) {
+goto done;
+}
+} else {
+goto done;
+}
 }
 
 kerr

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

2015-07-21 Thread 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

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

2015-07-07 Thread 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 sb...@redhat.com
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 sb...@redhat.com
- *
- * Copyright (C) 2013 Red Hat, Inc.
- * All rights reserved.
- * END COPYRIGHT BLOCK **/
+/*
+Authors:
+Sumit Bose sb...@redhat.com
 
-#include check.h
-#include stdlib.h
+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

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

2015-07-07 Thread 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 sb...@redhat.com
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.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

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

2015-05-29 Thread 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 mko...@redhat.com
 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)

2015-05-29 Thread 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 mko...@redhat.com
 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)

2015-05-29 Thread 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 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.
 
 I see, thanks. In any case what you wrote above does seem as something post 
 4.2.

yes. My plan would be to add everything what is needed to make SSSD work
with what is already available in MIT Kerberos first and then try to
enhance the pkinit plugin.

bye,
Sumit

 
 
 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

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

2015-05-27 Thread 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=ceritifcate
 
 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=cert' 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

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

2015-05-26 Thread 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 sb...@redhat.com
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 sb...@redhat.com
- *
- * Copyright (C) 2013 Red Hat, Inc.
- * All rights reserved.
- * END COPYRIGHT BLOCK **/
+/*
+Authors:
+Sumit Bose sb...@redhat.com
 
-#include check.h
-#include stdlib.h
+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 errno.h
 #include stdarg.h
-#include stdio.h
-#include stdbool.h
-#include krb5/krb5.h
-#include kdb.h
+#include stddef.h
+#include setjmp.h
+#include cmocka.h
 
 #include ipa-kdb/ipa_kdb.h
 
@@ -74,7 +55,7 @@ int

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

2015-05-26 Thread 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 sb...@ipa-devel.ipa.devel
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

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

2015-05-26 Thread 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 sb...@redhat.com
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-slapi-plugins/ipa-extdom-extop/test_data/group
+++ b/daemons/ipa-slapi-plugins/ipa

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

2015-05-26 Thread 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

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

2015-03-27 Thread 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 jhro...@redhat.com
   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

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

2015-03-18 Thread Sumit Bose

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 jhro...@redhat.com
 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' ?

bye,
Sumit

  
  ret = 0;
  
 -- 
 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

-- 
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 140] extdom: migrate check-based test to cmocka

2015-03-18 Thread Sumit Bose

On Fri, Mar 13, 2015 at 03:14:55PM +0100, Jakub Hrozek wrote:
 On Fri, Mar 13, 2015 at 11:56:46AM +0100, Sumit Bose wrote:
  On Wed, Mar 04, 2015 at 06:42:05PM +0100, Sumit Bose wrote:
   Hi,
   
   this is the first patch for https://fedorahosted.org/freeipa/ticket/4922
   which converts the check-based tests of the extdom plugin to cmocka.
   
   bye,
   Sumit
  
  Rebased version attached.
  
  bye,
  Sumit
 
 The test itself is fine, but did freeipa consider moving to cmocka-1.0+
 to avoid warnings like:
 ipa_extdom_cmocka_tests.c: In function ‘main’:
 ipa_extdom_cmocka_tests.c:408:5: warning: ‘_run_tests’ is deprecated
 (declared at /usr/include/cmocka.h:2001) [-Wdeprecated-declarations]
  return run_tests(tests);
 
 But I'm fine with ACKing this patch, the conversion should be done
 separately.

yes, I found it more flexible to use the old style now because it works
with all versions of cmocka. When I converted the remaining check based
test to cmocka I will provide a patch which will switch all to the new
version.

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] [PATCHES 137-139] extdom: add err_msg member to request context

2015-03-18 Thread Sumit Bose

On Fri, Mar 13, 2015 at 03:17:10PM +0100, Jakub Hrozek wrote:
 On Fri, Mar 13, 2015 at 11:55:09AM +0100, Sumit Bose wrote:
  On Wed, Mar 04, 2015 at 06:35:22PM +0100, Sumit Bose wrote:
   Hi,
   
   this patch series improves error reporting of the extdom plugin
   especially on the client side. Currently there is only SSSD ticket
   https://fedorahosted.org/sssd/ticket/2463 . Shall I create a
   corresponding FreeIPA ticket as well?
   
   In the third patch I already added a handful of new error messages.
   Suggestions for more messages are welcome.
   
   bye,
   Sumit
  
  Rebased versions attached.
  
  bye,
  Sumit
 
 The patches look good and work fine. I admit I cheated a bit and
 modified the code to return a failure. Then I saw on the client:
 
 [sssd[be[ipa.example.com]]] [ipa_s2n_exop_send] (0x0400): Executing extended 
 operation
 [sssd[be[ipa.example.com]]] [ipa_s2n_exop_done] (0x0040): 
 ldap_extended_operation result: Operations
 error(1), Failed to create fully qualified name.
 [sssd[be[ipa.example.com]]] [ipa_s2n_exop_done] (0x0040): 
 ldap_extended_operation failed, server logs might contain more details.
 [sssd[be[ipa.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n exop 
 request failed.
 
 I just saw one typo:
 
  @@ -918,6 +934,7 @@ static int handle_sid_request(struct ipa_extdom_ctx 
  *ctx,
   ret = sss_nss_getorigbyname(pwd.pw_name, kv_list, id_type);
   if (ret != 0 || !(id_type == SSS_ID_TYPE_UID
   || id_type == SSS_ID_TYPE_BOTH)) {
  +set_err_msg(req, Failed ot read original data);
  ~
   if (ret == ENOENT) {
   ret = LDAP_NO_SUCH_OBJECT;
   } else {
 
 And a compilation warning caused by previous patches.
 
 So ACK provided the typo is fixed prior to pushing the patch.
 

Please find attached a new version where the typo is fixed.

bye,
Sumit
From 9638b0a61144a481a0a2c8757d4e3a10e1f44b12 Mon Sep 17 00:00:00 2001
From: Sumit Bose sb...@redhat.com
Date: Mon, 2 Feb 2015 00:52:10 +0100
Subject: [PATCH 137/139] extdom: add err_msg member to request context

---
 daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h| 1 +
 daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c | 1 +
 daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c  | 5 -
 3 files changed, 6 insertions(+), 1 deletion(-)

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 
d4c851169ddadc869a59c53075f9fc7f33321085..421f6c6ea625aba2db7e9ffc84115b3647673699
 100644
--- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h
+++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h
@@ -116,6 +116,7 @@ struct extdom_req {
 gid_t gid;
 } posix_gid;
 } data;
+char *err_msg;
 };
 
 struct extdom_res {
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 
47bcb179f04e08c64d92f55809b84f2d59622344..c2fd42f13fca97587ddc4c12b560e590462f121b
 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
@@ -356,6 +356,7 @@ void free_req_data(struct extdom_req *req)
 break;
 }
 
+free(req-err_msg);
 free(req);
 }
 
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 
dc7785877fc321ddaa5b6967d1c1b06cb454bbbf..708d0e4a2fc9da4f87a24a49c945587049f7280f
 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
@@ -149,12 +149,15 @@ static int ipa_extdom_extop(Slapi_PBlock *pb)
 rc = LDAP_SUCCESS;
 
 done:
-free_req_data(req);
+if (req-err_msg != NULL) {
+err_msg = req-err_msg;
+}
 if (err_msg != NULL) {
 LOG(%s, err_msg);
 }
 slapi_send_ldap_result(pb, rc, NULL, err_msg, 0, NULL);
 ber_bvfree(ret_val);
+free_req_data(req);
 return SLAPI_PLUGIN_EXTENDED_SENT_RESULT;
 }
 
-- 
2.1.0

From b52bc91cf9e10a779446bf399f138eb3929cfb55 Mon Sep 17 00:00:00 2001
From: Sumit Bose sb...@redhat.com
Date: Mon, 2 Feb 2015 00:53:06 +0100
Subject: [PATCH 138/139] extdom: add add_err_msg() with test

---
 .../ipa-extdom-extop/ipa_extdom.h  |  1 +
 .../ipa-extdom-extop/ipa_extdom_cmocka_tests.c | 43 ++
 .../ipa-extdom-extop/ipa_extdom_common.c   | 23 
 3 files changed, 67 insertions(+)

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 
421f6c6ea625aba2db7e9ffc84115b3647673699..0d5d55d2fb0ece95466b0225b145a4edeef18efa
 100644
--- a/daemons/ipa-slapi-plugins/ipa-extdom

Re: [Freeipa-devel] [PATCH 140] extdom: migrate check-based test to cmocka

2015-03-18 Thread Sumit Bose

On Wed, Mar 18, 2015 at 12:53:04PM +0100, Martin Kosek wrote:
 On 03/18/2015 11:22 AM, Jakub Hrozek wrote:
  On Wed, Mar 18, 2015 at 11:01:35AM +0100, Sumit Bose wrote:
  On Fri, Mar 13, 2015 at 03:14:55PM +0100, Jakub Hrozek wrote:
  On Fri, Mar 13, 2015 at 11:56:46AM +0100, Sumit Bose wrote:
  On Wed, Mar 04, 2015 at 06:42:05PM +0100, Sumit Bose wrote:
  Hi,
 
  this is the first patch for https://fedorahosted.org/freeipa/ticket/4922
  which converts the check-based tests of the extdom plugin to cmocka.
 
  bye,
  Sumit
 
  Rebased version attached.
 
  bye,
  Sumit
 
  The test itself is fine, but did freeipa consider moving to cmocka-1.0+
  to avoid warnings like:
  ipa_extdom_cmocka_tests.c: In function ‘main’:
  ipa_extdom_cmocka_tests.c:408:5: warning: ‘_run_tests’ is deprecated
  (declared at /usr/include/cmocka.h:2001) [-Wdeprecated-declarations]
   return run_tests(tests);
 
  But I'm fine with ACKing this patch, the conversion should be done
  separately.
 
  yes, I found it more flexible to use the old style now because it works
  with all versions of cmocka. When I converted the remaining check based
  test to cmocka I will provide a patch which will switch all to the new
  version.
 
  bye,
  Sumit
  
  Sure, ACK
  
  (sorry, from my point of view it was obvious I was OK with pushing even
  the previous version. Hopefully it's even clearer now :-))
  
 
 Thanks for this work guys! I would push it, but there is a conflict in 
 ipa_extdom.

Rebased version attached.

bye,
Sumit

From cedaaba614dad266e5f5e90eafedf2b173b96c12 Mon Sep 17 00:00:00 2001
From: Sumit Bose sb...@redhat.com
Date: Mon, 9 Feb 2015 18:12:01 +0100
Subject: [PATCH] extdom: migrate check-based test to cmocka

Besides moving the existing tests to cmocka two new tests are added
which were missing from the old tests.

Related to https://fedorahosted.org/freeipa/ticket/4922
---
 .../ipa-slapi-plugins/ipa-extdom-extop/Makefile.am |  20 --
 .../ipa-extdom-extop/ipa_extdom.h  |  14 ++
 .../ipa-extdom-extop/ipa_extdom_cmocka_tests.c | 156 +++-
 .../ipa-extdom-extop/ipa_extdom_common.c   |  28 +--
 .../ipa-extdom-extop/ipa_extdom_tests.c| 203 -
 5 files changed, 176 insertions(+), 245 deletions(-)
 delete mode 100644 
daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_tests.c

diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/Makefile.am 
b/daemons/ipa-slapi-plugins/ipa-extdom-extop/Makefile.am
index 
a1679812ef3c5de8c6e18433cbb991a99ad0b6c8..9c2fa1c6a5f95ba06b33c0a5b560939863a88f0e
 100644
--- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/Makefile.am
+++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/Makefile.am
@@ -38,11 +38,6 @@ libipa_extdom_extop_la_LIBADD =  \
 TESTS =
 check_PROGRAMS =
 
-if HAVE_CHECK
-TESTS += extdom_tests
-check_PROGRAMS += extdom_tests
-endif
-
 if HAVE_CMOCKA
 if HAVE_NSS_WRAPPER
 TESTS_ENVIRONMENT = . ./test_data/test_setup.sh;
@@ -51,21 +46,6 @@ check_PROGRAMS += extdom_cmocka_tests
 endif
 endif
 
-extdom_tests_SOURCES = \
-   ipa_extdom_tests.c  \
-   ipa_extdom_common.c \
-   $(NULL)
-extdom_tests_CFLAGS = $(CHECK_CFLAGS)
-extdom_tests_LDFLAGS = \
-   -rpath $(shell pkg-config --libs-only-L dirsrv | sed -e 's/-L//') \
-   $(NULL)
-extdom_tests_LDADD =   \
-   $(CHECK_LIBS)   \
-   $(LDAP_LIBS)\
-   $(DIRSRV_LIBS)  \
-   $(SSSNSSIDMAP_LIBS) \
-   $(NULL)
-
 extdom_cmocka_tests_SOURCES =  \
ipa_extdom_cmocka_tests.c   \
ipa_extdom_common.c \
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 
0d5d55d2fb0ece95466b0225b145a4edeef18efa..65dd43ea35726db6231386a0fcbba9be1bd71412
 100644
--- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h
+++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h
@@ -185,5 +185,19 @@ 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 pack_ber_sid(const char *sid, struct berval **berval);
+int pack_ber_name(const char *domain_name, const char *name,
+  struct berval **berval);
+int pack_ber_user(struct ipa_extdom_ctx *ctx,
+  enum response_types response_type,
+  const char *domain_name, const char *user_name,
+  uid_t uid, gid_t gid,
+  const char *gecos, const char *homedir,
+  const char *shell, struct sss_nss_kv *kv_list,
+  struct berval **berval);
+int pack_ber_group(enum response_types response_type,
+   const char *domain_name, const char *group_name,
+   gid_t gid, char **members, struct sss_nss_kv

Re: [Freeipa-devel] [PATCH 140] extdom: migrate check-based test to cmocka

2015-03-18 Thread Sumit Bose

On Wed, Mar 18, 2015 at 01:36:44PM +0100, Martin Kosek wrote:
 On 03/18/2015 01:32 PM, Sumit Bose wrote:
  On Wed, Mar 18, 2015 at 12:53:04PM +0100, Martin Kosek wrote:
  On 03/18/2015 11:22 AM, Jakub Hrozek wrote:
  On Wed, Mar 18, 2015 at 11:01:35AM +0100, Sumit Bose wrote:
  On Fri, Mar 13, 2015 at 03:14:55PM +0100, Jakub Hrozek wrote:
  On Fri, Mar 13, 2015 at 11:56:46AM +0100, Sumit Bose wrote:
  On Wed, Mar 04, 2015 at 06:42:05PM +0100, Sumit Bose wrote:
  Hi,
 
  this is the first patch for 
  https://fedorahosted.org/freeipa/ticket/4922
  which converts the check-based tests of the extdom plugin to cmocka.
 
  bye,
  Sumit
 
  Rebased version attached.
 
  bye,
  Sumit
 
  The test itself is fine, but did freeipa consider moving to cmocka-1.0+
  to avoid warnings like:
  ipa_extdom_cmocka_tests.c: In function ‘main’:
  ipa_extdom_cmocka_tests.c:408:5: warning: ‘_run_tests’ is deprecated
  (declared at /usr/include/cmocka.h:2001) [-Wdeprecated-declarations]
   return run_tests(tests);
 
  But I'm fine with ACKing this patch, the conversion should be done
  separately.
 
  yes, I found it more flexible to use the old style now because it works
  with all versions of cmocka. When I converted the remaining check based
  test to cmocka I will provide a patch which will switch all to the new
  version.
 
  bye,
  Sumit
 
  Sure, ACK
 
  (sorry, from my point of view it was obvious I was OK with pushing even
  the previous version. Hopefully it's even clearer now :-))
 
 
  Thanks for this work guys! I would push it, but there is a conflict in 
  ipa_extdom.
  
  Rebased version attached.
  
  bye,
  Sumit
  
 
 Thanks! Pushed to master: d0d79ada379ab809c26a7dc0bbc88b47ab85f744
 
 What are your next steps for https://fedorahosted.org/freeipa/ticket/4922,
 replace BuildRequires: check with cmocka BuildRequires in the FreeIPA
 referential spec file?

yes, the next patch here would be to migrate
ipa-kdb/tests/ipa_kdb_tests.c to cmocka and replace the BuildRequires.

As a last step, if no related issues have shown up on the SSSD side,
make the tests compile with cmocka 1.0 without warnings and add the
version to the BuildRequires.

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 140] extdom: migrate check-based test to cmocka

2015-03-13 Thread Sumit Bose

On Wed, Mar 04, 2015 at 06:42:05PM +0100, Sumit Bose wrote:
 Hi,
 
 this is the first patch for https://fedorahosted.org/freeipa/ticket/4922
 which converts the check-based tests of the extdom plugin to cmocka.
 
 bye,
 Sumit

Rebased version attached.

bye,
Sumit
From c801df101baa41146a06a70ff4075e308905577b Mon Sep 17 00:00:00 2001
From: Sumit Bose sb...@redhat.com
Date: Mon, 9 Feb 2015 18:12:01 +0100
Subject: [PATCH] extdom: migrate check-based test to cmocka

Besides moving the existing tests to cmocka two new tests are added
which were missing from the old tests.

Related to https://fedorahosted.org/freeipa/ticket/4922
---
 .../ipa-slapi-plugins/ipa-extdom-extop/Makefile.am |  20 --
 .../ipa-extdom-extop/ipa_extdom.h  |  14 ++
 .../ipa-extdom-extop/ipa_extdom_cmocka_tests.c | 156 +++-
 .../ipa-extdom-extop/ipa_extdom_common.c   |  28 +--
 .../ipa-extdom-extop/ipa_extdom_tests.c| 203 -
 5 files changed, 176 insertions(+), 245 deletions(-)
 delete mode 100644 
daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_tests.c

diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/Makefile.am 
b/daemons/ipa-slapi-plugins/ipa-extdom-extop/Makefile.am
index 
a1679812ef3c5de8c6e18433cbb991a99ad0b6c8..9c2fa1c6a5f95ba06b33c0a5b560939863a88f0e
 100644
--- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/Makefile.am
+++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/Makefile.am
@@ -38,11 +38,6 @@ libipa_extdom_extop_la_LIBADD =  \
 TESTS =
 check_PROGRAMS =
 
-if HAVE_CHECK
-TESTS += extdom_tests
-check_PROGRAMS += extdom_tests
-endif
-
 if HAVE_CMOCKA
 if HAVE_NSS_WRAPPER
 TESTS_ENVIRONMENT = . ./test_data/test_setup.sh;
@@ -51,21 +46,6 @@ check_PROGRAMS += extdom_cmocka_tests
 endif
 endif
 
-extdom_tests_SOURCES = \
-   ipa_extdom_tests.c  \
-   ipa_extdom_common.c \
-   $(NULL)
-extdom_tests_CFLAGS = $(CHECK_CFLAGS)
-extdom_tests_LDFLAGS = \
-   -rpath $(shell pkg-config --libs-only-L dirsrv | sed -e 's/-L//') \
-   $(NULL)
-extdom_tests_LDADD =   \
-   $(CHECK_LIBS)   \
-   $(LDAP_LIBS)\
-   $(DIRSRV_LIBS)  \
-   $(SSSNSSIDMAP_LIBS) \
-   $(NULL)
-
 extdom_cmocka_tests_SOURCES =  \
ipa_extdom_cmocka_tests.c   \
ipa_extdom_common.c \
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 
0d5d55d2fb0ece95466b0225b145a4edeef18efa..65dd43ea35726db6231386a0fcbba9be1bd71412
 100644
--- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h
+++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h
@@ -185,5 +185,19 @@ 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 pack_ber_sid(const char *sid, struct berval **berval);
+int pack_ber_name(const char *domain_name, const char *name,
+  struct berval **berval);
+int pack_ber_user(struct ipa_extdom_ctx *ctx,
+  enum response_types response_type,
+  const char *domain_name, const char *user_name,
+  uid_t uid, gid_t gid,
+  const char *gecos, const char *homedir,
+  const char *shell, struct sss_nss_kv *kv_list,
+  struct berval **berval);
+int pack_ber_group(enum response_types response_type,
+   const char *domain_name, const char *group_name,
+   gid_t gid, char **members, struct sss_nss_kv *kv_list,
+   struct berval **berval);
 void set_err_msg(struct extdom_req *req, const char *format, ...);
 #endif /* _IPA_EXTDOM_H_ */
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 
586b58b0fd4c7610e9cb4643b6dae04f9d22b8ab..42d588d08a96f8a26345f85aade9523e05f6f56e
 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,30 +213,46 @@ void test_getgrgid_r_wrapper(void **state)
 free(buf);
 }
 
+struct test_data {
+struct extdom_req *req;
+struct ipa_extdom_ctx *ctx;
+};
+
 void extdom_req_setup(void **state)
 {
-struct extdom_req *req;
+struct test_data *test_data;
 
-req = calloc(sizeof(struct extdom_req), 1);
-assert_non_null(req);
+test_data = calloc(sizeof(struct test_data), 1);
+assert_non_null(test_data);
 
-*state = req;
+test_data-req = calloc(sizeof(struct extdom_req), 1);
+assert_non_null(test_data-req);
+
+test_data-ctx = calloc(sizeof(struct ipa_extdom_ctx), 1);
+assert_non_null(test_data-req);
+
+*state = test_data;
 }
 
 void

Re: [Freeipa-devel] [PATCHES 137-139] extdom: add err_msg member to request context

2015-03-13 Thread Sumit Bose

On Wed, Mar 04, 2015 at 06:35:22PM +0100, Sumit Bose wrote:
 Hi,
 
 this patch series improves error reporting of the extdom plugin
 especially on the client side. Currently there is only SSSD ticket
 https://fedorahosted.org/sssd/ticket/2463 . Shall I create a
 corresponding FreeIPA ticket as well?
 
 In the third patch I already added a handful of new error messages.
 Suggestions for more messages are welcome.
 
 bye,
 Sumit

Rebased versions attached.

bye,
Sumit
From e402a733322c68db0f808d3386a27e5fd9bc177b Mon Sep 17 00:00:00 2001
From: Sumit Bose sb...@redhat.com
Date: Mon, 2 Feb 2015 00:52:10 +0100
Subject: [PATCH 137/139] extdom: add err_msg member to request context

---
 daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h| 1 +
 daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c | 1 +
 daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c  | 5 -
 3 files changed, 6 insertions(+), 1 deletion(-)

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 
d4c851169ddadc869a59c53075f9fc7f33321085..421f6c6ea625aba2db7e9ffc84115b3647673699
 100644
--- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h
+++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h
@@ -116,6 +116,7 @@ struct extdom_req {
 gid_t gid;
 } posix_gid;
 } data;
+char *err_msg;
 };
 
 struct extdom_res {
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 
47bcb179f04e08c64d92f55809b84f2d59622344..c2fd42f13fca97587ddc4c12b560e590462f121b
 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
@@ -356,6 +356,7 @@ void free_req_data(struct extdom_req *req)
 break;
 }
 
+free(req-err_msg);
 free(req);
 }
 
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 
dc7785877fc321ddaa5b6967d1c1b06cb454bbbf..708d0e4a2fc9da4f87a24a49c945587049f7280f
 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
@@ -149,12 +149,15 @@ static int ipa_extdom_extop(Slapi_PBlock *pb)
 rc = LDAP_SUCCESS;
 
 done:
-free_req_data(req);
+if (req-err_msg != NULL) {
+err_msg = req-err_msg;
+}
 if (err_msg != NULL) {
 LOG(%s, err_msg);
 }
 slapi_send_ldap_result(pb, rc, NULL, err_msg, 0, NULL);
 ber_bvfree(ret_val);
+free_req_data(req);
 return SLAPI_PLUGIN_EXTENDED_SENT_RESULT;
 }
 
-- 
2.1.0

From 6a6a18313745e5e50b629009a74f7b0ad1975fe2 Mon Sep 17 00:00:00 2001
From: Sumit Bose sb...@redhat.com
Date: Mon, 2 Feb 2015 00:53:06 +0100
Subject: [PATCH 138/139] extdom: add add_err_msg() with test

---
 .../ipa-extdom-extop/ipa_extdom.h  |  1 +
 .../ipa-extdom-extop/ipa_extdom_cmocka_tests.c | 43 ++
 .../ipa-extdom-extop/ipa_extdom_common.c   | 23 
 3 files changed, 67 insertions(+)

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 
421f6c6ea625aba2db7e9ffc84115b3647673699..0d5d55d2fb0ece95466b0225b145a4edeef18efa
 100644
--- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h
+++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom.h
@@ -185,4 +185,5 @@ 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);
+void set_err_msg(struct extdom_req *req, const char *format, ...);
 #endif /* _IPA_EXTDOM_H_ */
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 
d5bacd7e8c9dc0a71eea70162406c7e5b67384ad..586b58b0fd4c7610e9cb4643b6dae04f9d22b8ab
 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,47 @@ void test_getgrgid_r_wrapper(void **state)
 free(buf);
 }
 
+void extdom_req_setup(void **state)
+{
+struct extdom_req *req;
+
+req = calloc(sizeof(struct extdom_req), 1);
+assert_non_null(req);
+
+*state = req;
+}
+
+void extdom_req_teardown(void **state)
+{
+struct extdom_req *req;
+
+req = (struct extdom_req *) *state;
+
+free_req_data(req);
+}
+
+void test_set_err_msg(void **state)
+{
+struct extdom_req *req;
+
+req = (struct extdom_req *) *state;
+assert_null(req-err_msg);
+
+set_err_msg(NULL, NULL);
+assert_null(req-err_msg);
+
+set_err_msg(req, NULL

Re: [Freeipa-devel] [PATCH 142] extdom: fix memory leak

2015-03-10 Thread Sumit Bose

On Tue, Mar 10, 2015 at 11:59:45AM +0100, Tomas Babej wrote:
 
 On 03/05/2015 08:00 AM, Alexander Bokovoy wrote:
 On Wed, 04 Mar 2015, Nathan Kinder wrote:
 
 
 On 03/04/2015 10:34 PM, Alexander Bokovoy wrote:
 On Wed, 04 Mar 2015, Sumit Bose wrote:
 Hi,
 
 while running 389ds with valgrind to see if my other patches
 introduced
 a memory leak I found an older one which is fixed by this patch.
 
 bye,
 Sumit
 
 From bb02cdc135fecc1766b17edd61554dbde9bccd0b Mon Sep 17 00:00:00 2001
 From: Sumit Bose sb...@redhat.com
 Date: Wed, 4 Mar 2015 17:53:08 +0100
 Subject: [PATCH] extdom: fix memory leak
 
 ---
 daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c | 1 +
 1 file changed, 1 insertion(+)
 
 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
 a040f2beba073d856053429face2f464347b2524..708d0e4a2fc9da4f87a24a49c945587049f7280f
 
 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
 @@ -156,6 +156,7 @@ done:
 LOG(%s, err_msg);
 }
 slapi_send_ldap_result(pb, rc, NULL, err_msg, 0, NULL);
 +ber_bvfree(ret_val);
 free_req_data(req);
 return SLAPI_PLUGIN_EXTENDED_SENT_RESULT;
 }
 I can see in 389-ds code that it actually tries to remove the value in
 the end of extended operation handling:
 
 This below code snippet is freeing the extended operation request value
 (SLAPI_EXT_OP_REQ_VALUE), not the return value (SLAPI_EXT_OP_RET_VAL).
 
 If you look at check_and_send_extended_result() in the 389-ds code,
 you'll see where the extended operation return value is sent, and it
 doesn't perform a free.  It is up to the plug-in to perform the free.  A
 good example of this in the 389-ds code is in the passwd_modify_extop()
 function.
 
 
 Sumit's code looks good to me.  ACK.
 Argh. Sorry for confusion of RET vs REQ. Morning, I need coffee!
 
 ACK.
 
 
 -NGK
 
slapi_pblock_set( pb, SLAPI_EXT_OP_REQ_OID, extoid );
slapi_pblock_set( pb, SLAPI_EXT_OP_REQ_VALUE, extval );
slapi_pblock_set( pb, SLAPI_REQUESTOR_ISROOT,
 pb-pb_op-o_isroot);
 
rc = plugin_call_exop_plugins( pb, extoid );
 
if ( SLAPI_PLUGIN_EXTENDED_SENT_RESULT != rc ) {
if ( SLAPI_PLUGIN_EXTENDED_NOT_HANDLED == rc ) {
lderr = LDAP_PROTOCOL_ERROR;/* no plugin
 handled the op */
errmsg = unsupported extended operation;
} else {
errmsg = NULL;
lderr = rc;
}
send_ldap_result( pb, lderr, NULL, errmsg, 0, NULL );
}
 free_and_return:
if (extoid)
slapi_ch_free((void **)extoid);
if (extval.bv_val)
slapi_ch_free((void **)extval.bv_val);
return;
 
 
 
 
 The patch does not apply to the current master branch.
 
 Sumit, can you send a updated version?

sure, new version attached.

bye,
Sumit

 
 Thanks,
 Tomas
From 2a14bb1a6c44a8c6f5730f97ad3239e9fca2392a Mon Sep 17 00:00:00 2001
From: Sumit Bose sb...@redhat.com
Date: Wed, 4 Mar 2015 17:53:08 +0100
Subject: [PATCH] extdom: fix memory leak

---
 daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_extop.c | 1 +
 1 file changed, 1 insertion(+)

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 
1ea0c1320accc66235d6f1a41055de434aeacab7..dc7785877fc321ddaa5b6967d1c1b06cb454bbbf
 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
@@ -154,6 +154,7 @@ done:
 LOG(%s, err_msg);
 }
 slapi_send_ldap_result(pb, rc, NULL, err_msg, 0, NULL);
+ber_bvfree(ret_val);
 return SLAPI_PLUGIN_EXTENDED_SENT_RESULT;
 }
 
-- 
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

1 2 3 4 >

1 - 100 of 377 matches

Mail list logo