Re: [Freeipa-devel] [PATCH] 455 Fallback to global policy in ipa-lockout plugin
On 01/30/2014 07:19 PM, Rob Crittenden wrote:
Martin Kosek wrote:
krbPwdPolicyReference is no longer filled default users. Instead, plugins
fallback to hardcoded global policy reference.
Fix ipa-lockout plugin to fallback to it instead of failing to apply
the policy.
https://fedorahosted.org/freeipa/ticket/4085
NACK.
I think you should include the value of krberr in error messages (we aren't
exactly consistent in this elsewhere in the code but we need to start
somewhere).
You check the wrong value after the krb5_get_default_realm() call.
It is probably better to use slapi_ch_free_string() than free().
At some point we'll need a common library where this sort of operation can be
done.
rob
Good catch, sending updated patch.
Martin
From 2392ccb4ff9f0310512a6313240749900567d831 Mon Sep 17 00:00:00 2001
From: Martin Kosek mko...@redhat.com
Date: Thu, 30 Jan 2014 16:58:25 +0100
Subject: [PATCH] Fallback to global policy in ipa-lockout plugin
krbPwdPolicyReference is no longer filled default users. Instead, plugins
fallback to hardcoded global policy reference.
Fix ipa-lockout plugin to fallback to it instead of failing to apply
the policy.
https://fedorahosted.org/freeipa/ticket/4085
---
.../ipa-slapi-plugins/ipa-lockout/ipa_lockout.c| 34 ++
1 file changed, 34 insertions(+)
diff --git a/daemons/ipa-slapi-plugins/ipa-lockout/ipa_lockout.c b/daemons/ipa-slapi-plugins/ipa-lockout/ipa_lockout.c
index fd6602fdee9b2fd95c154fd512fcba4f37e56bad..5a24359d319aaea28773daa01d268d2d46583270 100644
--- a/daemons/ipa-slapi-plugins/ipa-lockout/ipa_lockout.c
+++ b/daemons/ipa-slapi-plugins/ipa-lockout/ipa_lockout.c
@@ -49,6 +49,7 @@
#include time.h
#include slapi-plugin.h
#include nspr.h
+#include krb5.h
#include util.h
@@ -81,6 +82,8 @@ static int g_plugin_started = 0;
static struct ipa_context *global_ipactx = NULL;
+static char *ipa_global_policy = NULL;
+
#define GENERALIZED_TIME_LENGTH 15
/**
@@ -142,8 +145,11 @@ ipalockout_get_global_config(struct ipa_context *ipactx)
Slapi_Attr *attr = NULL;
char *dn = NULL;
char *basedn = NULL;
+char *realm = NULL;
Slapi_DN *sdn;
Slapi_Entry *config_entry;
+krb5_context krbctx = NULL;
+krb5_error_code krberr;
int ret;
/* Get cn=config so we can get the default naming context */
@@ -167,6 +173,28 @@ ipalockout_get_global_config(struct ipa_context *ipactx)
goto done;
}
+krberr = krb5_init_context(krbctx);
+if (krberr) {
+LOG_FATAL(krb5_init_context failed (%d)\n, krberr);
+ret = LDAP_OPERATIONS_ERROR;
+goto done;
+}
+
+krberr = krb5_get_default_realm(krbctx, realm);
+if (krberr) {
+LOG_FATAL(Failed to get default realm (%d)\n, krberr);
+ret = LDAP_OPERATIONS_ERROR;
+goto done;
+}
+
+ipa_global_policy = slapi_ch_smprintf(cn=global_policy,cn=%s,cn=kerberos,%s,
+ realm, basedn);
+if (!ipa_global_policy) {
+LOG_OOM();
+ret = LDAP_OPERATIONS_ERROR;
+goto done;
+}
+
ret = asprintf(dn, cn=ipaConfig,cn=etc,%s, basedn);
if (ret == -1) {
LOG_OOM();
@@ -221,6 +249,8 @@ ipalockout_get_global_config(struct ipa_context *ipactx)
done:
if (config_entry)
slapi_entry_free(config_entry);
+free(realm);
+krb5_free_context(krbctx);
free(dn);
free(basedn);
return ret;
@@ -248,6 +278,8 @@ int ipalockout_getpolicy(Slapi_Entry *target_entry, Slapi_Entry **policy_entry,
slapi_valueset_first_value(*values, sv);
*policy_dn = slapi_value_get_string(sv);
}
+} else {
+*policy_dn = ipa_global_policy;
}
if (*policy_dn == NULL) {
@@ -376,6 +408,8 @@ ipalockout_close(Slapi_PBlock * pb)
{
LOG_TRACE( --in--\n);
+slapi_ch_free_string(ipa_global_policy);
+
LOG_TRACE(--out--\n);
return EOK;
--
1.8.5.3
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 454 Migration does not add users to default group
On 01/28/2014 02:18 PM, Petr Viktorin wrote:
On 01/27/2014 12:32 PM, Martin Kosek wrote:
When users with missing default group were searched, IPA suffix was
not passed so these users were searched in a wrong base DN. Thus,
no user was detected and added to default group.
https://fedorahosted.org/freeipa/ticket/4141
This needs a rebase for the new LDAP API.
I tested primarily on ipa-3-3 branch, I will rebase when acked.
I don't see the need for the second change, caching of len(new_members). On
lists, len() is extremely fast.
If you want to optimize, convert the list of existing members to a set before
the for loop, instead of getting it from the entry and using the `in` operator
(which is O(N) on lists) every time.
Makes sense, done.
Nitpicks:
Instead of if len(container) 0: you should just use if container: (see
PEP8).
Fixed.
Instead of:
members = group_entry_attrs.get('member', [])
...
group_entry_attrs['member'] = members
you can use:
members = group_entry_attrs.setdefault('member', [])
...
Fixed.
New patch attached (tested).
Martin
From 77adc17f6ac6be5eb21c3a4658812c5172e456a4 Mon Sep 17 00:00:00 2001
From: Martin Kosek mko...@redhat.com
Date: Mon, 27 Jan 2014 12:28:12 +0100
Subject: [PATCH] Migration does not add users to default group
When users with missing default group were searched, IPA suffix was
not passed so these users were searched in a wrong base DN. Thus,
no user was detected and added to default group.
https://fedorahosted.org/freeipa/ticket/4141
---
ipalib/plugins/migration.py | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/ipalib/plugins/migration.py b/ipalib/plugins/migration.py
index 83bf40dbfa4cf2310b2501c28cf095299711331d..0ed65f7015f458aa1cf96efb0e36e28c5019cbd2 100644
--- a/ipalib/plugins/migration.py
+++ b/ipalib/plugins/migration.py
@@ -286,19 +286,21 @@ def _update_default_group(ldap, pkey, config, ctx, force):
searchfilter = ((objectclass=posixAccount)(!(memberof=%s))) % group_dn
try:
(result, truncated) = ldap.find_entries(searchfilter,
-[''], api.env.container_user, scope=ldap.SCOPE_SUBTREE,
-time_limit = -1)
+[''], DN(api.env.container_user, api.env.basedn),
+scope=ldap.SCOPE_SUBTREE, time_limit = -1)
except errors.NotFound:
+api.log.debug('All users have default group set')
return
new_members = []
(group_dn, group_entry_attrs) = ldap.get_entry(group_dn, ['member'])
+existing_members = set(group_entry_attrs.get('member', []))
for m in result:
-if m[0] not in group_entry_attrs.get('member', []):
+if m[0] not in existing_members:
new_members.append(m[0])
-if len(new_members) 0:
-members = group_entry_attrs.get('member', [])
+
+if new_members:
+members = group_entry_attrs.setdefault('member', [])
members.extend(new_members)
-group_entry_attrs['member'] = members
try:
ldap.update_entry(group_dn, group_entry_attrs)
@@ -308,7 +310,8 @@ def _update_default_group(ldap, pkey, config, ctx, force):
e = datetime.datetime.now()
d = e - s
mode = (forced) if force else
-api.log.debug('Adding %d users to group%s duration %s' % (len(new_members), mode, d))
+api.log.debug('Adding %d users to group%s duration %s',
+len(new_members), mode, d)
# GROUP MIGRATION CALLBACKS AND VARS
--
1.8.5.3
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] FreeIPA ConnId connector for usage with Apache Syncope
On 30/01/2014 19:25, Dmitri Pal wrote: On 01/30/2014 11:35 AM, Francesco Chicchiriccò wrote: Hi all, I am PMC chair at Apache Syncope [1], an Open Source system for managing digital identities in enterprise environments, implemented in JEE technology and released under Apache 2.0 license. Apache Syncope can be classified as provisioning engine, and its duty can be summarized as keeping synchronized account data across different identity datastores (RDBMS, LDAP, Active Directory, ). For the actual communication with such external identity datastores, Apache Syncope relies upon ConnId [2], an Open Source fork of Sun Microsystem's Identity Connectors framework [3], left dead after Sun's acquisition by Oracle. I am also project owner at ConnId. My company Tirasa is about to start the development of a FreeIPA ConnId connector [4] that would allow the integration of FreeIPA into Apache Syncope-based IdM architectures. We are currently installing and testing FreeIPA in order to understand what is the better way to implement the communication with Syncope: do you have any suggestion about where to start from? Thanks. Can you please list provisioning use cases that you want to support? Add user? Edit user? Reset password? Basically we are planning to implement all identity operations defined by the ConnId framework [5], e.g.: AUTHENTICATE CREATE UPDATE UPDATE_ATTRIBUTE_VALUES DELETE RESOLVE_USERNAME SCHEMA SEARCH SYNC TEST for ACCOUNTs and GROUPs; some of such operations (SYNC, for example) is usually more complex than others. It will be then Syncope's business to build high-level identity operations on top of these primitives, as it does with existing connectors, in a technology-agnostic way. Keep in mind that after password is set for a user user needs to change it on the first login. This is done to make sure that no one can impersonate user and password is not know outside the system. So this is one of the first hurdles you need to deal with, i.e. fire and forget and not try to use password for anything else in IPA use case. This seems to be the first custom requirement of this connector, if compared with existing ones: good to know :-) To call into IPA you can use ipa ... command line or use out API from python client. Since you are using Java calling into ipa command is probably the best option. Actually, a RESTful interface (HTTP/JSON) would better suit our development model and deployment scenarios. In future we plan to allow insertion of the users via an ldap command https://fedorahosted.org/freeipa/ticket/3911 it is on the roadmap for this spring. What are other use cases and workflows you have? Do you have a password reset self service? If you do it might be nice external addition to FreeIPA if it integrates into the UI seamlessly. The idea is to deploy the latest FreeIPA version in our lab, start playing with it and come to this list for asking for more information we are not able to find in the wiki (just to avoid some graceful RTFMs...). Then, every time we get something working, we will also check here whether we are heading into the right direction, if we are missing some important points, etc. Does it sound? Regards. [1] http://syncope.apache.org/ [2] http://tirasa.github.io/ConnId/ [3] http://java.net/projects/identityconnectors/ [4] https://github.com/Tirasa/ConnIdFreeIPABundle [5] http://tirasa.github.io/ConnId/apidocs/base/org/identityconnectors/framework/spi/operations/package-summary.html -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ Involved at The Apache Software Foundation: member, Syncope PMC chair, Cocoon PMC, Olingo PPMC http://people.apache.org/~ilgrosso/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] FreeIPA ConnId connector for usage with Apache Syncope
On 01/31/2014 10:45 AM, Francesco Chicchiriccò wrote: On 30/01/2014 19:25, Dmitri Pal wrote: On 01/30/2014 11:35 AM, Francesco Chicchiriccò wrote: ... To call into IPA you can use ipa ... command line or use out API from python client. Since you are using Java calling into ipa command is probably the best option. Actually, a RESTful interface (HTTP/JSON) would better suit our development model and deployment scenarios. FreeIPA does not have (currently) not RESTful interface (though it is being partially designed in [8]). However it has a Kerberos-protected JSON-RPC/XML-RPC interface used by clients or Web UI to communicate with the server. We do not, however, have a good (read none) documentation of the interface, see related discussion in freeipa-users list [6]. In future we plan to allow insertion of the users via an ldap command https://fedorahosted.org/freeipa/ticket/3911 it is on the roadmap for this spring. What are other use cases and workflows you have? Do you have a password reset self service? If you do it might be nice external addition to FreeIPA if it integrates into the UI seamlessly. The idea is to deploy the latest FreeIPA version in our lab, start playing with it and come to this list for asking for more information we are not able to find in the wiki (just to avoid some graceful RTFMs...). Then, every time we get something working, we will also check here whether we are heading into the right direction, if we are missing some important points, etc. Does it sound? Sounds good to me, you should be able to find all documentation links in [7]. Regards. [1] http://syncope.apache.org/ [2] http://tirasa.github.io/ConnId/ [3] http://java.net/projects/identityconnectors/ [4] https://github.com/Tirasa/ConnIdFreeIPABundle [5] http://tirasa.github.io/ConnId/apidocs/base/org/identityconnectors/framework/spi/operations/package-summary.html [6] https://www.redhat.com/archives/freeipa-users/2013-January/msg00109.html [7] http://www.freeipa.org/page/Documentation [8] http://www.freeipa.org/page/V3/Smart_Proxy Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] FreeIPA ConnId connector for usage with Apache Syncope
On 01/31/2014 05:03 AM, Martin Kosek wrote: On 01/31/2014 10:45 AM, Francesco Chicchiriccò wrote: On 30/01/2014 19:25, Dmitri Pal wrote: On 01/30/2014 11:35 AM, Francesco Chicchiriccò wrote: ... To call into IPA you can use ipa ... command line or use out API from python client. Since you are using Java calling into ipa command is probably the best option. Actually, a RESTful interface (HTTP/JSON) would better suit our development model and deployment scenarios. FreeIPA does not have (currently) not RESTful interface (though it is being partially designed in [8]). However it has a Kerberos-protected JSON-RPC/XML-RPC interface used by clients or Web UI to communicate with the server. I suggest that you look at the implementation of [8] and create a user provisioning smart proxy similar to it. This proxy would expose the REST API that can be consumed by your connector or some other system and will be a part of IPA. Internally proxy will call JSON RPC against IPA and have all the busyness logic. So the recommendation is to make your connector lightwight and leverage a proxy that can be reused by other systems. We do not, however, have a good (read none) documentation of the interface, see related discussion in freeipa-users list [6]. And would appreciate if you start a wiki page to record it as you go so that we can start documenting it. In future we plan to allow insertion of the users via an ldap command https://fedorahosted.org/freeipa/ticket/3911 it is on the roadmap for this spring. What are other use cases and workflows you have? Do you have a password reset self service? If you do it might be nice external addition to FreeIPA if it integrates into the UI seamlessly. The idea is to deploy the latest FreeIPA version in our lab, start playing with it and come to this list for asking for more information we are not able to find in the wiki (just to avoid some graceful RTFMs...). Then, every time we get something working, we will also check here whether we are heading into the right direction, if we are missing some important points, etc. Does it sound? Sounds good to me, you should be able to find all documentation links in [7]. +1 Regards. [1] http://syncope.apache.org/ [2] http://tirasa.github.io/ConnId/ [3] http://java.net/projects/identityconnectors/ [4] https://github.com/Tirasa/ConnIdFreeIPABundle [5] http://tirasa.github.io/ConnId/apidocs/base/org/identityconnectors/framework/spi/operations/package-summary.html [6] https://www.redhat.com/archives/freeipa-users/2013-January/msg00109.html [7] http://www.freeipa.org/page/Documentation [8] http://www.freeipa.org/page/V3/Smart_Proxy Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] 0455-0459 Add support for managed permissions
On 01/24/2014 04:48 PM, Petr Viktorin wrote:
On 01/23/2014 02:42 PM, Simo Sorce wrote:
On Thu, 2014-01-23 at 13:23 +0100, Petr Viktorin wrote:
On 01/23/2014 12:24 PM, Martin Kosek wrote:
On 01/22/2014 10:27 AM, Petr Viktorin wrote:
On 01/08/2014 04:49 PM, Petr Viktorin wrote:
Hello,
This adds managed permissions, the framework that will make our
default permissions merge IPA updates and user changes sanely.
There is no updater yet, nor does this add any actual managed
permissions, so there's no user-visible change (beyond help text and a
disabled option). To test the patch you might need to touch LDAP
directly.
Ticket: https://fedorahosted.org/freeipa/ticket/4033
Design (no updater plugin changes yet):
http://www.freeipa.org/page/V3/Managed_Read_permissions
0447 - Minor fixes.
0448 - Since you can't create managed permissions through the API, I
needed to get creative with the declarative tests. The tests will need a
custom function that adds a managed perm.
0449 - The change itself.
ping; any thoughts on this one?
1) 449, the comment:
+Deleting or renaming a managed permission, as well as changing its target,
+is not supported.
+) + _(
I am not sure that the phrase not supported is the right one. It sounds
to me
like this is something we want to allow, just not implemented yet. IMO is
not
allowed would be better.
Makes sense.
2) Can you add allow_mod_for_managed flag description to parameters.py?
+flags={'no_create', 'allow_mod_for_managed'},
So far we try to add all flag descriptions there.
OK
3) When I updated the test to not delete the testperm, I tried to show the
managed permission and it is not entirely clear, see:
# ipa permission-show testperm
Permission name: testperm
Permissions: write
* Attributes: cn, o, sn
* Excluded attributes: cn, sn
Bind rule type: all
Subtree: cn=users,cn=accounts,dc=example,dc=com
ACI target DN: uid=*,cn=users,cn=accounts,dc=example,dc=com
Type: user
* Default attributes: l, o, cn
* Effective attributes: l, o
Well, this is a tradeoff between presenting what's stored in LDAP and
what's in the ACI.
The Attributes mean actually attributes explicitly allowed by user, but
it is
not obvious from the output.
Maybe it would be better to return only Effective attributes by default
and
return the 3 source lists only when --all is passed. But this would
require us
to let Command override LDAPObject's default_attributes, which framework
cannot do.
Modifying default_attributes would not work because the 3 lists need to
be loaded from LDAP to determine the effective attributes.
It's possible to remove the extra attributes in the post_callback,
postprocess_result already does similar output manipulation.
Alternatively, we may choose to use the attributes differently with managed
permissions:
- we add the new attributeType ipaPermIncludedAttr. It would be used for
the
user-specified whitelist of attributes instead of ipaPermAllowedAttr
- we do not use the ipaPermAllowedAttr with managed attributes at all or
use it
for the Effective attributes list
My point is that the semantics of ipaPermAllowedAttr is different for
managed
and non-managed permission, so it may confuse people.
Well, the semantics are always the same (effective = (default | allowed)
- excluded). I agree that it can be confusing; perhaps I'm in too deep
to judge how it looks from the outside.
For example, you may want
to search for all permissions that allow attribute sn:
# ipa permission-find --attrs sn
-
4 permissions matched
-
Permission name: anon
Permissions: read
Attributes: sn
Bind rule type: anonymous
Subtree: cn=users,cn=accounts,dc=example,dc=com
ACI target DN: uid=*,cn=users,cn=accounts,dc=example,dc=com
Type: user
...
Permission name: testperm
Permissions: write
Attributes: cn, o, sn
Excluded attributes: cn, sn
Bind rule type: anonymous
Subtree: cn=users,cn=accounts,dc=example,dc=com
ACI target DN: uid=*,cn=users,cn=accounts,dc=example,dc=com
Type: user
Default attributes: l, o, cn
Effective attributes: l, o
...
As you see, it matched both testperm and anon even though testperm does not
really allow sn as it excluded.
Thoughts?
Well, we could have default, included, excluded attributes stored in
LDAP as now (using the name included instead of allowed), and make
effective attributes (--attrs) into an updatable virtual attribute: when
setting it, IPA would consult the default attributes and update
included/excluded accordingly. (With non-managed permissions
default is empty, so only included would be updated.) And searching
on --attrs would construct an appropriate filter.
I thought about this approach earlier but thought that it obscured
what's actually stored in LDAP. Given recent discussions I'm now
thinking I shouldn't
Re: [Freeipa-devel] FreeIPA ConnId connector for usage with Apache Syncope
On 31/01/2014 12:52, Dmitri Pal wrote: On 01/31/2014 05:03 AM, Martin Kosek wrote: On 01/31/2014 10:45 AM, Francesco Chicchiriccò wrote: On 30/01/2014 19:25, Dmitri Pal wrote: On 01/30/2014 11:35 AM, Francesco Chicchiriccò wrote: ... To call into IPA you can use ipa ... command line or use out API from python client. Since you are using Java calling into ipa command is probably the best option. Actually, a RESTful interface (HTTP/JSON) would better suit our development model and deployment scenarios. FreeIPA does not have (currently) not RESTful interface (though it is being partially designed in [8]). However it has a Kerberos-protected JSON-RPC/XML-RPC interface used by clients or Web UI to communicate with the server. I suggest that you look at the implementation of [8] and create a user provisioning smart proxy similar to it. This proxy would expose the REST API that can be consumed by your connector or some other system and will be a part of IPA. Internally proxy will call JSON RPC against IPA and have all the busyness logic. So the recommendation is to make your connector lightwight and leverage a proxy that can be reused by other systems. Are you saying that we should split our development in two: (1) smart proxy, exposing the RESTful interface, developed on the basis of [8] (2) actual ConnId connector, dealing with the proxy above for implementing its own logic If so, could you please point to the source code of [8]? Will then this eventually become part of FreeIPA? I am actually not sure if it is lightweight connector could actually be better than a loaded connector (e.g. without proxy), from a deployment point of view, unless you are saying either that (a) a smart proxy is already available that can be reused or that (b) incorporating the smart proxy that we are going to develop into FreeIPA will easily happen. We do not, however, have a good (read none) documentation of the interface, see related discussion in freeipa-users list [6]. And would appreciate if you start a wiki page to record it as you go so that we can start documenting it. In future we plan to allow insertion of the users via an ldap command https://fedorahosted.org/freeipa/ticket/3911 it is on the roadmap for this spring. What are other use cases and workflows you have? Do you have a password reset self service? If you do it might be nice external addition to FreeIPA if it integrates into the UI seamlessly. The idea is to deploy the latest FreeIPA version in our lab, start playing with it and come to this list for asking for more information we are not able to find in the wiki (just to avoid some graceful RTFMs...). Then, every time we get something working, we will also check here whether we are heading into the right direction, if we are missing some important points, etc. Does it sound? Sounds good to me, you should be able to find all documentation links in [7]. +1 [1] http://syncope.apache.org/ [2] http://tirasa.github.io/ConnId/ [3] http://java.net/projects/identityconnectors/ [4] https://github.com/Tirasa/ConnIdFreeIPABundle [5] http://tirasa.github.io/ConnId/apidocs/base/org/identityconnectors/framework/spi/operations/package-summary.html [6] https://www.redhat.com/archives/freeipa-users/2013-January/msg00109.html [7] http://www.freeipa.org/page/Documentation [8] http://www.freeipa.org/page/V3/Smart_Proxy -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ Involved at The Apache Software Foundation: member, Syncope PMC chair, Cocoon PMC, Olingo PPMC http://people.apache.org/~ilgrosso/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] FreeIPA ConnId connector for usage with Apache Syncope
On 31.1.2014 14:17, Francesco Chicchiriccò wrote: On 31/01/2014 12:52, Dmitri Pal wrote: On 01/31/2014 05:03 AM, Martin Kosek wrote: On 01/31/2014 10:45 AM, Francesco Chicchiriccò wrote: On 30/01/2014 19:25, Dmitri Pal wrote: On 01/30/2014 11:35 AM, Francesco Chicchiriccò wrote: ... To call into IPA you can use ipa ... command line or use out API from python client. Since you are using Java calling into ipa command is probably the best option. Actually, a RESTful interface (HTTP/JSON) would better suit our development model and deployment scenarios. FreeIPA does not have (currently) not RESTful interface (though it is being partially designed in [8]). However it has a Kerberos-protected JSON-RPC/XML-RPC interface used by clients or Web UI to communicate with the server. I suggest that you look at the implementation of [8] and create a user provisioning smart proxy similar to it. This proxy would expose the REST API that can be consumed by your connector or some other system and will be a part of IPA. Internally proxy will call JSON RPC against IPA and have all the busyness logic. So the recommendation is to make your connector lightwight and leverage a proxy that can be reused by other systems. Are you saying that we should split our development in two: (1) smart proxy, exposing the RESTful interface, developed on the basis of [8] (2) actual ConnId connector, dealing with the proxy above for implementing its own logic If so, could you please point to the source code of [8]? Will then this eventually become part of FreeIPA? I am actually not sure if it is lightweight connector could actually be better than a loaded connector (e.g. without proxy), from a deployment point of view, unless you are saying either that (a) a smart proxy is already available that can be reused or that (b) incorporating the smart proxy that we are going to develop into FreeIPA will easily happen. First patches with SmartProxy were posted to devel mailing list some time ago: https://www.redhat.com/archives/freeipa-devel/2014-January/msg00213.html We plan to integrate SmartProxy to the source main tree: See ticket https://fedorahosted.org/freeipa/ticket/4128 Petr^2 Spacek We do not, however, have a good (read none) documentation of the interface, see related discussion in freeipa-users list [6]. And would appreciate if you start a wiki page to record it as you go so that we can start documenting it. In future we plan to allow insertion of the users via an ldap command https://fedorahosted.org/freeipa/ticket/3911 it is on the roadmap for this spring. What are other use cases and workflows you have? Do you have a password reset self service? If you do it might be nice external addition to FreeIPA if it integrates into the UI seamlessly. The idea is to deploy the latest FreeIPA version in our lab, start playing with it and come to this list for asking for more information we are not able to find in the wiki (just to avoid some graceful RTFMs...). Then, every time we get something working, we will also check here whether we are heading into the right direction, if we are missing some important points, etc. Does it sound? Sounds good to me, you should be able to find all documentation links in [7]. +1 [1] http://syncope.apache.org/ [2] http://tirasa.github.io/ConnId/ [3] http://java.net/projects/identityconnectors/ [4] https://github.com/Tirasa/ConnIdFreeIPABundle [5] http://tirasa.github.io/ConnId/apidocs/base/org/identityconnectors/framework/spi/operations/package-summary.html [6] https://www.redhat.com/archives/freeipa-users/2013-January/msg00109.html [7] http://www.freeipa.org/page/Documentation [8] http://www.freeipa.org/page/V3/Smart_Proxy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCHES 0024, 0025] Classless support for reverse domains
Reverse domain names in form 0/28.0.10.10.in-addr.arpa. are now
allowed.
Ticket: https://fedorahosted.org/freeipa/ticket/4143
Patches attached.
--
Martin^2 Basti
From 052462c2aba165737d7fffe0a3dc2a846a008f5b Mon Sep 17 00:00:00 2001
From: Martin Basti mba...@redhat.com
Date: Fri, 31 Jan 2014 15:42:31 +0100
Subject: [PATCH] DNS classless support for reverse domains
Now users can adding reverse zones in classless form:
0/25.1.168.192.in-addr.arpa.
0-25.1.168.192.in-addr.arpa.
128/25 NS ns.example.com.
10 CNAME 10.128/25.1.168.192.in-addr.arpa.
Ticket: https://fedorahosted.org/freeipa/ticket/4143
---
ipalib/plugins/dns.py | 57 +--
ipalib/util.py| 32 -
2 files changed, 68 insertions(+), 21 deletions(-)
diff --git a/ipalib/plugins/dns.py b/ipalib/plugins/dns.py
index 57322e9bbd1ab9a9f09effc8a54fd73b5875c781..b00a84a4dcdea7fb87e67688f931108740914bcf 100644
--- a/ipalib/plugins/dns.py
+++ b/ipalib/plugins/dns.py
@@ -368,25 +368,31 @@ def _normalize_bind_aci(bind_acis):
acis += u';'
return acis
-def _bind_hostname_validator(ugettext, value):
+def _bind_hostname_validator(ugettext, value, allow_slash=False):
if value == _dns_zone_record:
return
try:
# Allow domain name which is not fully qualified. These are supported
# in bind and then translated as non-fqdn-name.domain.
-validate_hostname(value, check_fqdn=False, allow_underscore=True)
+validate_hostname(value, check_fqdn=False, allow_underscore=True, allow_slash=allow_slash)
except ValueError, e:
return _('invalid domain-name: %s') \
% unicode(e)
return None
+def _cname_hostname_validator(ugettext, value):
+
+Validator for CNAME allows classless domain names (25/0.0.10.in-addr.arpa.)
+
+return _bind_hostname_validator(ugettext, value, allow_slash=True)
+
def _dns_record_name_validator(ugettext, value):
if value == _dns_zone_record:
return
try:
-map(lambda label:validate_dns_label(label, allow_underscore=True), \
+map(lambda label:validate_dns_label(label, allow_underscore=True, allow_slash=True), \
value.split(u'.'))
except ValueError, e:
return unicode(e)
@@ -411,7 +417,7 @@ def _validate_bind_forwarder(ugettext, forwarder):
def _domain_name_validator(ugettext, value):
try:
-validate_domain_name(value)
+validate_domain_name(value, allow_slash=True)
except ValueError, e:
return unicode(e)
@@ -939,7 +945,7 @@ class CNAMERecord(DNSRecord):
rfc = 1035
parts = (
Str('hostname',
-_bind_hostname_validator,
+_cname_hostname_validator,
label=_('Hostname'),
doc=_('A hostname which this alias hostname points to'),
),
@@ -960,7 +966,7 @@ class DNAMERecord(DNSRecord):
rfc = 2672
parts = (
Str('target',
-_bind_hostname_validator,
+_cname_hostname_validator,
label=_('Target'),
),
)
@@ -1818,6 +1824,11 @@ class dnszone_add(LDAPCreate):
else:
record_in_zone = nameserver
+#classless reverse zones can contain slash '/'
+if not zone_is_reverse(normalized_zone) and (normalized_zone.count('/') 0):
+raise errors.ValidationError(name='name',
+error=_(Only reverse zones can contain '/' in labels))
+
if zone_is_reverse(normalized_zone):
if not nameserver.endswith('.'):
raise errors.ValidationError(name='name-server',
@@ -2131,6 +2142,22 @@ class dnsrecord(LDAPObject):
doc=_('Parse all raw DNS records and return them in a structured way'),
)
+def _reverse_zone_pre_callback(self, ldap, dn, entry_attrs, *keys, **options):
+#in reverse zone can record name contain /, (and -)
+
+if self.is_pkey_zone_record(*keys):
+addr = u''
+else:
+addr = keys[-1]
+
+zone = keys[-2]
+zone = normalize_zone(zone)
+if not zone_is_reverse(zone):
+if addr.count('/') 0:
+raise errors.ValidationError(name='name',
+error=unicode(_('Only domain names in reverse zones can contain \'/\'')) )
+
+
def _nsrecord_pre_callback(self, ldap, dn, entry_attrs, *keys, **options):
assert isinstance(dn, DN)
nsrecords = entry_attrs.get('nsrecord')
@@ -2144,6 +2171,7 @@ class dnsrecord(LDAPObject):
ptrrecords = entry_attrs.get('ptrrecord')
if ptrrecords is None:
return
+
zone = keys[-2]
if self.is_pkey_zone_record(*keys):
addr = u''
@@ -2162,16 +2190,23 @@ class dnsrecord(LDAPObject):
error=unicode(_('Reverse zone for PTR record should be a sub-zone of one the following fully
Re: [Freeipa-devel] [PATCH] 455 Fallback to global policy in ipa-lockout plugin
Martin Kosek wrote: On 01/30/2014 07:19 PM, Rob Crittenden wrote: Martin Kosek wrote: krbPwdPolicyReference is no longer filled default users. Instead, plugins fallback to hardcoded global policy reference. Fix ipa-lockout plugin to fallback to it instead of failing to apply the policy. https://fedorahosted.org/freeipa/ticket/4085 NACK. I think you should include the value of krberr in error messages (we aren't exactly consistent in this elsewhere in the code but we need to start somewhere). You check the wrong value after the krb5_get_default_realm() call. It is probably better to use slapi_ch_free_string() than free(). At some point we'll need a common library where this sort of operation can be done. rob Good catch, sending updated patch. Martin ACK ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH 0026] PTR records can be added without specify FQDN zone name
One liner. Ticket: https://fedorahosted.org/freeipa/ticket/4151 Patch attached. -- Martin^2 Basti From b346746e7596b8beda7812e6874fea88a657dfe9 Mon Sep 17 00:00:00 2001 From: Martin Basti mba...@redhat.com Date: Fri, 31 Jan 2014 16:30:31 +0100 Subject: [PATCH] PTR records can be added without specify FQDN zone name Now adding PTR records will accept zones both with and without end dot. Ticket: https://fedorahosted.org/freeipa/ticket/4151 --- ipalib/plugins/dns.py | 3 +++ 1 file changed, 3 insertions(+) diff --git a/ipalib/plugins/dns.py b/ipalib/plugins/dns.py index 57322e9bbd1ab9a9f09effc8a54fd73b5875c781..afd47be316b8b84fe281698af206b39fc1e1bf55 100644 --- a/ipalib/plugins/dns.py +++ b/ipalib/plugins/dns.py @@ -2149,6 +2149,9 @@ class dnsrecord(LDAPObject): addr = u'' else: addr = keys[-1] + +zone = normalize_zone(zone) + zone_len = 0 for valid_zone in REVERSE_DNS_ZONES: if zone.endswith(valid_zone): -- 1.8.3.1 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] FreeIPA ConnId connector for usage with Apache Syncope
On 01/31/2014 08:17 AM, Francesco Chicchiriccò wrote: Are you saying that we should split our development in two: (1) smart proxy, exposing the RESTful interface, developed on the basis of [8] (2) actual ConnId connector, dealing with the proxy above for implementing its own logic Correct If so, could you please point to the source code of [8]? Will then this eventually become part of FreeIPA? Quite soon. I would leave it to the team to suggest whether user and host provisioning smart proxies should be a same smart proxy or different so that they can be installed independently from each other but use the same approach. IMO haveing them separately but share the same code and approach will be more valuable to the project. But I am open to other ideas here. I am actually not sure if it is lightweight connector could actually be better than a loaded connector (e.g. without proxy), from a deployment point of view, unless you are saying either that (a) a smart proxy is already available that can be reused The idea can be reused as a starting point. IMO the easiest would be to look at the patches and use same machinery but implement different commands. or that (b) incorporating the smart proxy that we are going to develop into FreeIPA will easily happen. If done right: i.e. following process and style then yes. Please become familiar with the coding style [9] page on the wiki and other contributer guidelines [10]. Also having a design page created as a result of the preliminary investigation would go a long way towards acceptance and quality of the feature. We will gladly guide you on the way if you have specific questions [...] [2] http://tirasa.github.io/ConnId/ [3] http://java.net/projects/identityconnectors/ [4] https://github.com/Tirasa/ConnIdFreeIPABundle [5] http://tirasa.github.io/ConnId/apidocs/base/org/identityconnectors/framework/spi/operations/package-summary.html [6] https://www.redhat.com/archives/freeipa-users/2013-January/msg00109.html [7] http://www.freeipa.org/page/Documentation [8] http://www.freeipa.org/page/V3/Smart_Proxy [1] http://syncope.apache.org/ [9] http://www.freeipa.org/page/Coding_Style [10] http://www.freeipa.org/page/Contribute/Code -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH 0034] Teach ipa-pwd-extop to respect global ipaUserAuthType settings
This patch addresses bug #4105:
https://fedorahosted.org/freeipa/ticket/4105
It depends on all my previous OTP patches.
Nathaniel
From b06a2a35827dc16620e97cdb3681685f1796de92 Mon Sep 17 00:00:00 2001
From: Nathaniel McCallum npmccal...@redhat.com
Date: Fri, 31 Jan 2014 15:16:35 -0500
Subject: [PATCH] Teach ipa-pwd-extop to respect global ipaUserAuthType
settings
https://fedorahosted.org/freeipa/ticket/4105
---
.../ipa-slapi-plugins/ipa-pwd-extop/Makefile.am| 1 +
daemons/ipa-slapi-plugins/ipa-pwd-extop/authcfg.c | 280 +
daemons/ipa-slapi-plugins/ipa-pwd-extop/authcfg.h | 82 ++
daemons/ipa-slapi-plugins/ipa-pwd-extop/common.c | 127 --
.../ipa-pwd-extop/ipa_pwd_extop.c | 110 +---
daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd.h | 30 ---
daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c | 167 ++--
7 files changed, 398 insertions(+), 399 deletions(-)
create mode 100644 daemons/ipa-slapi-plugins/ipa-pwd-extop/authcfg.c
create mode 100644 daemons/ipa-slapi-plugins/ipa-pwd-extop/authcfg.h
diff --git a/daemons/ipa-slapi-plugins/ipa-pwd-extop/Makefile.am b/daemons/ipa-slapi-plugins/ipa-pwd-extop/Makefile.am
index b8d98785370bf9c1e7aff617ff76bc4b11acd3ad..4cf80ec802b40bb579a44fc9357c6a8119dab577 100644
--- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/Makefile.am
+++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/Makefile.am
@@ -40,6 +40,7 @@ plugindir = $(libdir)/dirsrv/plugins
plugin_LTLIBRARIES = libipa_pwd_extop.la
libipa_pwd_extop_la_LIBADD = $(builddir)/../libotp/libotp.la
libipa_pwd_extop_la_SOURCES = \
+ authcfg.c \
common.c \
encoding.c \
prepost.c \
diff --git a/daemons/ipa-slapi-plugins/ipa-pwd-extop/authcfg.c b/daemons/ipa-slapi-plugins/ipa-pwd-extop/authcfg.c
new file mode 100644
index ..3ab5668edd7edcb9eaf247c18b964f6584c9d439
--- /dev/null
+++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/authcfg.c
@@ -0,0 +1,280 @@
+/** 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:
+ * Nathaniel McCallum npmccal...@redhat.com
+ *
+ * Copyright (C) 2014 Red Hat, Inc.
+ * All rights reserved.
+ * END COPYRIGHT BLOCK **/
+
+#include authcfg.h
+#include ipapwd.h
+
+#include pratom.h
+
+static struct config {
+struct config *next;
+Slapi_DN *suffix;
+uint32_t config;
+} *config;
+
+static uint32_t string_to_config(const char *str)
+{
+static const struct {
+const char *string;
+uint32_t config;
+} map[] = {
+{ disabled, AUTHCFG_AUTH_TYPE_DISABLED },
+{ password, AUTHCFG_AUTH_TYPE_PASSWORD },
+{ otp, AUTHCFG_AUTH_TYPE_OTP },
+{ pkinit, AUTHCFG_AUTH_TYPE_PKINIT },
+{ radius, AUTHCFG_AUTH_TYPE_RADIUS },
+{}
+};
+
+for (uint32_t i = 0; map[i].string != NULL; i++) {
+if (strcasecmp(map[i].string, str) == 0)
+return map[i].config;
+}
+
+return AUTHCFG_AUTH_TYPE_NONE;
+}
+
+static uint32_t entry_to_config(Slapi_Entry *e)
+{
+char **auth_types = NULL;
+
+if (e == NULL)
+return AUTHCFG_AUTH_TYPE_NONE;
+
+/* Fetch the auth type values from the config entry. */
+auth_types = slapi_entry_attr_get_charray(e, ipaUserAuthType);
+if (auth_types == NULL)
+return AUTHCFG_AUTH_TYPE_NONE;
+
+uint32_t types = AUTHCFG_AUTH_TYPE_NONE;
+for (uint32_t i = 0; auth_types[i] != NULL; i++)
+types |=
