[Freeipa-devel] [PATCHES] 0555-0556 Add IPA version number to the install logs
Hello,
This fixes https://fedorahosted.org/freeipa/ticket/4219
AFAIK the vendor version (e.g. 4.0.0-0.fc20) was not available to IPA,
so I have it added to version.py when building packages. I wonder if
there's an easier way to do this.
The second patch logs the version in all the installation commands.
--
Petr³
From 05267604ae559135587b135fe9ac394617a70247 Mon Sep 17 00:00:00 2001
From: Petr Viktorin pvikt...@redhat.com
Date: Thu, 13 Mar 2014 14:39:03 +0100
Subject: [PATCH] ipalib.version: Add VENDOR_VERSION
This will allow us to make vendors' lives easier by embedding a
vendor tag to installation logs.
Part of the work for: https://fedorahosted.org/freeipa/ticket/4219
---
Makefile| 3 +++
freeipa.spec.in | 8 ++--
ipapython/version.py.in | 3 +++
3 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index ee10e3aa7c5fb03e76986e8eddb96be5c5a418ce..918c8e7f35b62f09a405d3f4b472e208be72dd82 100644
--- a/Makefile
+++ b/Makefile
@@ -38,6 +38,8 @@ endif # beta
endif # pre
endif # ipa_version
+IPA_VENDOR_VERSION=$(IPA_VERSION)$(IPA_VENDOR_VERSION_SUFFIX)
+
TARBALL_PREFIX=freeipa-$(IPA_VERSION)
TARBALL=$(TARBALL_PREFIX).tar.gz
@@ -133,6 +135,7 @@ version-update: release-update
sed -e s/__NUM_VERSION__/$(IPA_NUM_VERSION)/ install/ui/src/libs/loader.js.in \
install/ui/src/libs/loader.js
perl -pi -e s:__NUM_VERSION__:$(IPA_NUM_VERSION): ipapython/version.py
+ perl -pi -e s:__VENDOR_VERSION__:$(IPA_VENDOR_VERSION): ipapython/version.py
perl -pi -e s:__API_VERSION__:$(IPA_API_VERSION_MAJOR).$(IPA_API_VERSION_MINOR): ipapython/version.py
touch -r ipapython/version.py.in ipapython/version.py
sed -e s/__VERSION__/$(IPA_VERSION)/ daemons/ipa-version.h.in \
diff --git a/freeipa.spec.in b/freeipa.spec.in
index 23f3737cf4873eac0929b2979e4d1ac0798bfdb9..7ed989ec33a423646a5a3925894b52b85b101ec9 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -360,8 +360,10 @@ export SUPPORTED_PLATFORM=fedora18
export SUPPORTED_PLATFORM=fedora16
%endif
%endif
+
# Force re-generate of platform support
-rm -f ipapython/services.py
+export IPA_VENDOR_VERSION_SUFFIX=-%{release}
+rm -f ipapython/services.py ipapython/version.py
make version-update
cd ipa-client; ../autogen.sh --prefix=%{_usr} --sysconfdir=%{_sysconfdir} --localstatedir=%{_localstatedir} --libdir=%{_libdir} --mandir=%{_mandir}; cd ..
%if ! %{ONLY_CLIENT}
@@ -389,7 +391,9 @@ export SUPPORTED_PLATFORM=fedora16
%endif
%endif
# Force re-generate of platform support
-rm -f ipapython/services.py
+export IPA_VENDOR_VERSION_SUFFIX=-%{release}
+rm -f ipapython/services.py ipapython/version.py
+make version-update
%if ! %{ONLY_CLIENT}
make install DESTDIR=%{buildroot}
%else
diff --git a/ipapython/version.py.in b/ipapython/version.py.in
index 04cf5f81f4fa32168ba208dd9c872464e62003d7..74ee3b31add08534456a66aeeb3787eec1b64825 100644
--- a/ipapython/version.py.in
+++ b/ipapython/version.py.in
@@ -20,6 +20,9 @@
# The full version including strings
VERSION=__VERSION__
+# A fuller version including the vendor tag (e.g. 3.3.3-34.fc20)
+VENDOR_VERSION=__VENDOR_VERSION__
+
# Just the numeric portion of the version so one can do direct numeric
# comparisons to see if the API is compatible.
--
1.9.0
From e044044c8f4f08ad0d6cf6e7e279fa1a8168b82d Mon Sep 17 00:00:00 2001
From: Petr Viktorin pvikt...@redhat.com
Date: Wed, 19 Mar 2014 13:54:20 +0100
Subject: [PATCH] admin tools: Log IPA version
Add the IPA version, and vendor version if applicable, to the beginning
of admintool logs -- both framework and indivitual tools that don't yet
use the framework.
This will make debugging easier.
https://fedorahosted.org/freeipa/ticket/4219
---
install/tools/ipa-adtrust-install | 1 +
install/tools/ipa-ca-install | 1 +
install/tools/ipa-dns-install | 1 +
install/tools/ipa-replica-conncheck | 1 +
install/tools/ipa-replica-install | 1 +
install/tools/ipa-server-install | 1 +
install/tools/ipa-upgradeconfig | 1 +
ipa-client/ipa-install/ipa-client-install | 1 +
ipapython/admintool.py| 1 +
9 files changed, 9 insertions(+)
diff --git a/install/tools/ipa-adtrust-install b/install/tools/ipa-adtrust-install
index 3af6936b0a59213cdaff1ec969519e6313bc2b52..9b54abdaa09a2965e0ea4b42975f955dcd77cde4 100755
--- a/install/tools/ipa-adtrust-install
+++ b/install/tools/ipa-adtrust-install
@@ -217,6 +217,7 @@ def main():
root_logger.debug('%s was invoked with options: %s' % (sys.argv[0], safe_options))
root_logger.debug(missing options might be asked for interactively later\n)
+root_logger.debug('IPA version %s' % version.VENDOR_VERSION)
check_server_configuration()
diff --git a/install/tools/ipa-ca-install b/install/tools/ipa-ca-install
index 26f6993a0554ac569510f9875c5834870be867b1..18c81dc1fab4393c40119bfc969e629ce99019db 100755
--- a/install/tools/ipa-ca-install
+++
[Freeipa-devel] Supported Staged entries
Hello, Me again !!! Thanks to all your inputs, the discussion about User_life_cycle clarified a lot workflow/command verbs. Now I have a doubt about what would be an entry in staging (objectclass/attribute). Also I wonder if ipa CLI (ipa user-add --stage), would be the only support way to create stage entry. An active entry is looking like (with krb* attributes if the userpassword is defined): dn: uid=tb17,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com displayName: tb15 tb15 cn: tb15 tb15 objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson objectClass: inetuser objectClass: posixaccount objectClass: krbprincipalaux objectClass: krbticketpolicyaux objectClass: ipaobject objectClass: ipasshuser objectClass: ipaSshGroupOfPubKeys objectClass: mepOriginEntry loginShell: /bin/sh gecos: tb15 tb15 sn: tb15 homeDirectory: /home/tb17 uid: tb17 mail: t...@idm.lab.bos.redhat.com krbPrincipalName: t...@idm.lab.bos.redhat.com givenName: tb15 initials: tt ipaUniqueID: 3f1b5cce-e1b8-11e3-86fe-001a4a104ecd uidNumber: 64649 gidNumber: 64649 mepManagedEntry: cn=tb17,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat, dc=com memberOf: cn=ipausers,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc= com nsAccountLock: False A staged entry created by 'ipa user-add --stage' may look like the following. This kind of entry is easy to activate 'ipa user-unstage' dn: uid=tb20,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, dc=redhat,dc=com displayName: tb20 tb20 cn: tb20 tb20 objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson objectClass: inetuser objectClass: posixaccount objectClass: krbprincipalaux objectClass: krbticketpolicyaux objectClass: ipaobject objectClass: ipasshuser objectClass: ipaSshGroupOfPubKeys loginShell: /bin/sh uidNumber: -1 ipaUniqueID: autogenerate gidNumber: -1 gecos: tb20 tb20 sn: tb20 homeDirectory: /home/tb20 uid: tb20 mail: t...@idm.lab.bos.redhat.com krbPrincipalName: t...@idm.lab.bos.redhat.com givenName: tb20 initials: tt nsAccountLock: True Now are we going to support the following entries for 'ipa user-unstage' dn: cn=tb20,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, dc=redhat,dc=com objectClass: top objectClass: person sn: tb20 cn: tb20 nsAccountLock: True or dn: uid=tb20,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, dc=redhat,dc=com objectClass: top objectClass: person objectClass: posixAccount sn: tb20 cn: tb20 tb20 uid: tb20 uidNumber: -1 gidNumber: -1 homeDirectory: /home/tb20 nsAccountLock: True thanks thierry ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] 0555-0556 Add IPA version number to the install logs
On Tue, 27 May 2014, Petr Viktorin wrote: Hello, This fixes https://fedorahosted.org/freeipa/ticket/4219 AFAIK the vendor version (e.g. 4.0.0-0.fc20) was not available to IPA, so I have it added to version.py when building packages. I wonder if there's an easier way to do this. The second patch logs the version in all the installation commands. ACK to both, thanks! -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Supported Staged entries
On 27.5.2014 11:14, thierry bordaz wrote: Hello, Me again !!! Thanks to all your inputs, the discussion about User_life_cycle clarified a lot workflow/command verbs. Now I have a doubt about what would be an entry in staging (objectclass/attribute). Also I wonder if ipa CLI (ipa user-add --stage), would be the only support way to create stage entry. An active entry is looking like (with krb* attributes if the userpassword is defined): dn: uid=tb17,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com displayName: tb15 tb15 cn: tb15 tb15 objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson objectClass: inetuser objectClass: posixaccount objectClass: krbprincipalaux objectClass: krbticketpolicyaux objectClass: ipaobject objectClass: ipasshuser objectClass: ipaSshGroupOfPubKeys objectClass: mepOriginEntry loginShell: /bin/sh gecos: tb15 tb15 sn: tb15 homeDirectory: /home/tb17 uid: tb17 mail: t...@idm.lab.bos.redhat.com krbPrincipalName: t...@idm.lab.bos.redhat.com givenName: tb15 initials: tt ipaUniqueID: 3f1b5cce-e1b8-11e3-86fe-001a4a104ecd uidNumber: 64649 gidNumber: 64649 mepManagedEntry: cn=tb17,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat, dc=com memberOf: cn=ipausers,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc= com nsAccountLock: False A staged entry created by 'ipa user-add --stage' may look like the following. This kind of entry is easy to activate 'ipa user-unstage' dn: uid=tb20,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, dc=redhat,dc=com displayName: tb20 tb20 cn: tb20 tb20 objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson objectClass: inetuser objectClass: posixaccount objectClass: krbprincipalaux objectClass: krbticketpolicyaux objectClass: ipaobject objectClass: ipasshuser objectClass: ipaSshGroupOfPubKeys loginShell: /bin/sh uidNumber: -1 ipaUniqueID: autogenerate gidNumber: -1 gecos: tb20 tb20 sn: tb20 homeDirectory: /home/tb20 uid: tb20 mail: t...@idm.lab.bos.redhat.com krbPrincipalName: t...@idm.lab.bos.redhat.com givenName: tb20 initials: tt nsAccountLock: True Now are we going to support the following entries for 'ipa user-unstage' dn: cn=tb20,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, dc=redhat,dc=com objectClass: top objectClass: person sn: tb20 cn: tb20 nsAccountLock: True or dn: uid=tb20,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, dc=redhat,dc=com objectClass: top objectClass: person objectClass: posixAccount sn: tb20 cn: tb20 tb20 uid: tb20 uidNumber: -1 gidNumber: -1 homeDirectory: /home/tb20 nsAccountLock: True thanks thierry IIUC unstaging a user will do something like this: staged_user = ldap.get_entry(staged_dn, ['*']) api.Command.user_add(**staged_user) So IMO virtually any kind of entry should be supported in the staging tree. -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] User life cycle: question regarding the design
On 26.5.2014 10:18, Martin Kosek wrote: On 05/26/2014 09:33 AM, Jan Cholasta wrote: On 26.5.2014 07:49, Martin Kosek wrote: ... 5) modifying (in active) ipa user-mod tuser ... Ok. (in stage)ipa user-mod tuser --staged ... Simo did not like this command, I would personally add it. As long as we have ipa user-add --staged, we should also have an option to delete and modify user in staged area. +1 (in del) ipa user-mod tuser --deleted ... Not needed. Is this acceptable for everyone? If yes, the next step would be for Thierry to update the design page with new proposals. Martin Are users in different containers using the same uid allowed? Say you had a John Doe (uid jdoe) working in a company couple years ago. jdoe left and is now in deleted accounts tree. Jane Doe joins the company now and question is - do we want to allow Jane taking the same uid as John had? I am thinking we should not allow that. Maybe we should allow override with --force or having a global option. Another related topic is - do we want to enforce staged user to always have UID RDN? Isn't that limiting? When writing http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Create_a_User_-_by_provisioning_system I proposed that we should also be able to unstage a minimal record like this: dn: cn=Test User,cn=staged users,cn=accounts,cn=provisioning,dc=example,dc=com objectClass: top objectClass: organizationalperson cn: Test User sn: User nsAccountLock: True If not, do we need the --staged/--deleted flags on anything but user-add/user-find? I see your point, but I think we should make admins to be very explicit when manipulating users any area other than the active users area. As Simo noted, these are not real users, just incomplete user records. If they are not users, they should not be managed by the user plugin in the first place. (But I guess people are so used to abusing IPA's object model that they don't care. Oh well.) Martin -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] 0555-0556 Add IPA version number to the install logs
On 05/27/2014 11:16 AM, Alexander Bokovoy wrote: On Tue, 27 May 2014, Petr Viktorin wrote: Hello, This fixes https://fedorahosted.org/freeipa/ticket/4219 AFAIK the vendor version (e.g. 4.0.0-0.fc20) was not available to IPA, so I have it added to version.py when building packages. I wonder if there's an easier way to do this. The second patch logs the version in all the installation commands. ACK to both, thanks! Thanks for the review. Pushed to master: d6a4da30de37b2a3f1a3b4b8f8dd6dc0da3e1b50 -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] faster ways to build/test dogtag?
On 05/27/2014 09:00 AM, Fraser Tweedale wrote: Hi all, I've been working on a fix for a profile issue (https://fedorahosted.org/freeipa/ticket/2915). Unfortunately I find the scripts/compose_pki_core_packages - yum install - test cycle frustratingly slow on idm.lab.bos. Is there a quicker way to build and test the software - particularly as part of the larger IPA/certmonger/dogtag ecosystem? Cheers, Fraser I am not sure about dogtag - you would need to ask on pki-devel mailing list. As for FreeIPA - I use a home-grown synchronization script that puts modified python file in my local git directly into my test VM system so I do not need to compile and install FreeIPA rpms every time. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 645 webui: display only dialogs which belong to current facet
Dialog instances no longer directly call IPA.opened_dialog methods. It's
handled through events (decoupled from dialog's POV). IPA.open_dialogs
with assistance of ApplicationController makes sure that there is only
one dialog opened at the same time.
It also makes sure to hide all dialogs, which are not global dialogs and
did not originate from current facet, when switching facets.
https://fedorahosted.org/freeipa/ticket/4348
--
Petr Vobornik
From 3b01f6ddc98e2f769dd5e915ccd6d27fcf5f4886 Mon Sep 17 00:00:00 2001
From: Petr Vobornik pvobo...@redhat.com
Date: Tue, 20 May 2014 12:57:28 +0200
Subject: [PATCH] webui: display only dialogs which belong to current facet
Dialog instances no longer directly call IPA.opened_dialog methods. It's
handled through events (decoupled from dialog's POV). IPA.open_dialogs
with assistance of ApplicationController makes sure that there is only
one dialog opened at the same time.
It also makes sure to hide all dialogs, which are not global dialogs and
did not originate from current facet, when switching facets.
https://fedorahosted.org/freeipa/ticket/4348
---
install/ui/src/freeipa/Application_controller.js | 7 +-
install/ui/src/freeipa/dialog.js | 150 ---
2 files changed, 142 insertions(+), 15 deletions(-)
diff --git a/install/ui/src/freeipa/Application_controller.js b/install/ui/src/freeipa/Application_controller.js
index c166e36ee29db21c780e4e635caf90fdd87d7c17..f38a60dc375ac2d7fe31c58519ab6f44413f4093 100644
--- a/install/ui/src/freeipa/Application_controller.js
+++ b/install/ui/src/freeipa/Application_controller.js
@@ -116,6 +116,7 @@ define([
simple_container.hide();
var load_facet = reg.facet.get('load');
this.show_facet(load_facet);
+IPA.opened_dialogs.start_handling(this);
},
/**
@@ -320,9 +321,14 @@ define([
on(facet, 'facet-state-change', lang.hitch(this, this.on_facet_state_changed));
}
+if (this.current_facet !== facet) {
+IPA.opened_dialogs.hide();
+}
+
this.hide_facet();
this.current_facet = facet;
facet.show();
+IPA.opened_dialogs.focus_top();
},
hide_facet: function() {
@@ -455,7 +461,6 @@ define([
}
topic.publish('auth-successful');
});
-
this.show_facet(login_facet);
}
}
diff --git a/install/ui/src/freeipa/dialog.js b/install/ui/src/freeipa/dialog.js
index f71f23bb02b83a8280a46e30803450f6250121df..108d4dd39041b63c762d194a48c6580b27ad8b04 100644
--- a/install/ui/src/freeipa/dialog.js
+++ b/install/ui/src/freeipa/dialog.js
@@ -21,7 +21,10 @@
*/
define([
+ 'dojo/_base/lang',
'dojo/keys',
+ 'dojo/topic',
+ 'dojo/Evented',
'./builder',
'./ipa',
'./jquery',
@@ -30,11 +33,13 @@ define([
'./text',
'./field',
'./widget'],
- function(keys, builder, IPA, $, phases, reg, text) {
+ function(lang, keys, topic, Evented, builder, IPA, $, phases, reg, text) {
/**
* Opened dialogs
*
+ * For proper functionality requires started application(`app_container.app`)
+ *
* @class
* @singleton
*/
@@ -43,23 +48,65 @@ IPA.opened_dialogs = {
/** Opened dialogs */
dialogs: [],
-/** Get top dialog */
+/**
+ * Show only one dialog at a time
+ * @property {Boolean}
+ */
+show_only_one: true,
+
+/**
+ * Dialog topic handlers
+ * @property {Array}
+ * @protected
+ */
+handlers: [],
+
+/**
+ * Object which contains `current_facet`
+ * @property {ApplicationController}
+ */
+app: null,
+
+/**
+ * Get top dialog of target facet or a global one
+ * @return {IPA.dialog}
+ */
top_dialog: function() {
var top = null;
-if (this.dialogs.length) top = this.dialogs[this.dialogs.length - 1];
+for (var i=0,l=this.dialogs.length; il; i++) {
+var dialog = this.dialogs[i];
+if (!dialog.facet || dialog.facet === this.app.current_facet) {
+top = dialog;
+break;
+}
+}
return top;
},
-/** Focus to dialog */
+/** Focus and show top dialog */
focus_top: function() {
var top = this.top_dialog();
-if (top) {
+if (!top) return;
+
+function focus_first() {
top.focus_first_element();
}
+
+if (top.is_shown) {
+focus_first();
+} else {
+top.show(focus_first);
+}
},
/** Add dialog */
add_dialog: function(dialog) {
+if (this.show_only_one) {
+var top = this.top_dialog();
+if (top) {
+top.hide();
+}
+}
this.dialogs.push(dialog);
},
@@ -67,6
[Freeipa-devel] [PATCH] 646 webui: handle back button when unauthenticated
using browser history when unauthenticated causes transition to
the original and/or preceding facets. But nothing works since
all commands fail due to expired credentials in session.
These changes make sure that user stays on login screen if he misses
valid session credentials while he wants to switch to facet which
requires authentication.
https://fedorahosted.org/freeipa/ticket/4353
--
Petr Vobornik
From 0fcf3b84d603ac1769ba9f8806dfa2a4b6ccfd0a Mon Sep 17 00:00:00 2001
From: Petr Vobornik pvobo...@redhat.com
Date: Wed, 21 May 2014 10:07:19 +0200
Subject: [PATCH] webui: handle back button when unauthenticated
using browser history when unauthenticated causes transition to
the original and/or preceding facets. But nothing works since
all commands fail due to expired credentials in session.
These changes make sure that user stays on login screen if he misses
valid session credentials while he wants to switch to facet which
requires authentication.
https://fedorahosted.org/freeipa/ticket/4353
---
install/ui/src/freeipa/Application_controller.js | 10 -
install/ui/src/freeipa/facet.js | 48 +++-
install/ui/src/freeipa/facets/Facet.js | 9 +
install/ui/src/freeipa/plugins/load_page.js | 1 +
install/ui/src/freeipa/plugins/login.js | 3 +-
install/ui/src/freeipa/rpc.js| 2 +-
6 files changed, 52 insertions(+), 21 deletions(-)
diff --git a/install/ui/src/freeipa/Application_controller.js b/install/ui/src/freeipa/Application_controller.js
index f38a60dc375ac2d7fe31c58519ab6f44413f4093..7296aa4caa8667ad3c16dad3a3539d5e2ba02146 100644
--- a/install/ui/src/freeipa/Application_controller.js
+++ b/install/ui/src/freeipa/Application_controller.js
@@ -27,6 +27,7 @@ define([
'dojo/topic',
'dojo/query',
'dojo/dom-class',
+'./auth',
'./json2',
'./widgets/App',
'./widgets/FacetContainer',
@@ -36,7 +37,7 @@ define([
'./navigation/Router',
'./navigation/menu_spec'
],
- function(declare, lang, array, Deferred, on, topic, query, dom_class,
+ function(declare, lang, array, Deferred, on, topic, query, dom_class, auth,
JSON, App_widget, FacetContainer, IPA, reg, Menu, Router, menu_spec) {
/**
@@ -297,6 +298,12 @@ define([
show_facet: function(facet) {
+// prevent changing facet when authenticating
+if (this.current_facet this.current_facet.name === 'login'
+!auth.current.authenticated facet.requires_auth) {
+return;
+}
+
// choose container
var container = this.containers[facet.preferred_container];
if (!container) container = this.containers.main;
@@ -455,7 +462,6 @@ define([
var login_facet = reg.facet.get('login');
on.once(login_facet, logged_in, function() {
-
if (facet) {
self.show_facet(facet);
}
diff --git a/install/ui/src/freeipa/facet.js b/install/ui/src/freeipa/facet.js
index 46d72e7be4fc0738495dfed543a9f74556679641..419011627d3f453e98837378f77f88eb6c622219 100644
--- a/install/ui/src/freeipa/facet.js
+++ b/install/ui/src/freeipa/facet.js
@@ -220,6 +220,13 @@ exp.facet = IPA.facet = function(spec, no_init) {
*/
that._needs_update = spec.needs_update;
+
+/**
+ * Facet is shown
+ * @property {Boolean}
+ */
+that.is_shown = false;
+
/**
* Marks facet as expired - needs update
*
@@ -291,6 +298,13 @@ exp.facet = IPA.facet = function(spec, no_init) {
*/
that.redirect_info = spec.redirect_info;
+
+/**
+ * Facet requires authenticated user
+ * @type {Boolean}
+ */
+that.requires_auth = spec.requires_auth !== undefined ? spec.requires_auth : true;
+
/**
* Public state
* @property {facet.FacetState}
@@ -480,7 +494,7 @@ exp.facet = IPA.facet = function(spec, no_init) {
that.old_state = state;
// we don't have to reflect any changes if facet dom is not yet created
-if (!that.dom_node) {
+if (!that.dom_node || !that.is_shown) {
if (needs_update) that.set_expired_flag();
return;
}
@@ -651,30 +665,29 @@ exp.facet = IPA.facet = function(spec, no_init) {
*/
that.show = function() {
+if (that.is_shown) return;
+that.is_shown = true;
+
that.entity.facet = that; // FIXME: remove
if (!that.dom_node) {
that.create();
+}
-var state = that.state.clone();
-var needs_update = that.needs_update(state);
-that.old_state = state;
+var state = that.state.clone();
+var needs_update = that.needs_update(state);
+that.old_state = state;
-if (needs_update) {
-that.clear();
-}
+
Re: [Freeipa-devel] Supported Staged entries
On 05/27/2014 11:53 AM, Jan Cholasta wrote: On 27.5.2014 11:14, thierry bordaz wrote: Hello, Me again !!! Thanks to all your inputs, the discussion about User_life_cycle clarified a lot workflow/command verbs. Now I have a doubt about what would be an entry in staging (objectclass/attribute). Also I wonder if ipa CLI (ipa user-add --stage), would be the only support way to create stage entry. An active entry is looking like (with krb* attributes if the userpassword is defined): dn: uid=tb17,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com displayName: tb15 tb15 cn: tb15 tb15 objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson objectClass: inetuser objectClass: posixaccount objectClass: krbprincipalaux objectClass: krbticketpolicyaux objectClass: ipaobject objectClass: ipasshuser objectClass: ipaSshGroupOfPubKeys objectClass: mepOriginEntry loginShell: /bin/sh gecos: tb15 tb15 sn: tb15 homeDirectory: /home/tb17 uid: tb17 mail: t...@idm.lab.bos.redhat.com krbPrincipalName: t...@idm.lab.bos.redhat.com givenName: tb15 initials: tt ipaUniqueID: 3f1b5cce-e1b8-11e3-86fe-001a4a104ecd uidNumber: 64649 gidNumber: 64649 mepManagedEntry: cn=tb17,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat, dc=com memberOf: cn=ipausers,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc= com nsAccountLock: False A staged entry created by 'ipa user-add --stage' may look like the following. This kind of entry is easy to activate 'ipa user-unstage' dn: uid=tb20,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, dc=redhat,dc=com displayName: tb20 tb20 cn: tb20 tb20 objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson objectClass: inetuser objectClass: posixaccount objectClass: krbprincipalaux objectClass: krbticketpolicyaux objectClass: ipaobject objectClass: ipasshuser objectClass: ipaSshGroupOfPubKeys loginShell: /bin/sh uidNumber: -1 ipaUniqueID: autogenerate gidNumber: -1 gecos: tb20 tb20 sn: tb20 homeDirectory: /home/tb20 uid: tb20 mail: t...@idm.lab.bos.redhat.com krbPrincipalName: t...@idm.lab.bos.redhat.com givenName: tb20 initials: tt nsAccountLock: True Now are we going to support the following entries for 'ipa user-unstage' dn: cn=tb20,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, dc=redhat,dc=com objectClass: top objectClass: person sn: tb20 cn: tb20 nsAccountLock: True or dn: uid=tb20,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, dc=redhat,dc=com objectClass: top objectClass: person objectClass: posixAccount sn: tb20 cn: tb20 tb20 uid: tb20 uidNumber: -1 gidNumber: -1 homeDirectory: /home/tb20 nsAccountLock: True thanks thierry IIUC unstaging a user will do something like this: staged_user = ldap.get_entry(staged_dn, ['*']) api.Command.user_add(**staged_user) So IMO virtually any kind of entry should be supported in the staging tree. The workflow will be different from what Jan suggested, but yes, we should support wide range of entries. I suspect some provisioning systems may even write entries with different RDN - i.e. with CN for example. About the unstaging - we already spoke about it, we will need to consolidate current operations in user-add and user-mod in common functions that will be called by those commands and user-unstage command. I imagine user-unstage command would then do: 1) MODRDN from staged users to active users 2) Update user with the same default as user-add, if RDN is different than UID, it should be converted to UID I wonder how should be the step 2) authorized LDAP-wise. The easiest way to make it happen is to give the operator making unstage operator write permission/ACI to active users, but it may not be the ideal way - we would want to limit the write permission only to the actual unstage operation of the particular user... Simo, what is your take on this? Thanks, Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 647-651 [webui] Make utility section of navigation extensible
This is just a first draft of implementation of
https://fedorahosted.org/freeipa/ticket/4345
It introduces a `freeipa/extend` module which should serve as a more
stable API for Web UI plugins. I think it requires further discussion -
what to have there, the level of abstraction...
Other patches fixes navigation/router to support custom URL path patterns.
The usage of facet.create_hash(router) method in patch #649 is
questionable.
The WIP patch contains an example of a plugin which uses this functionality.
--
Petr Vobornik
From c7582a3fe8d26b51028e1da24642f2456ae0f7f4 Mon Sep 17 00:00:00 2001
From: Petr Vobornik pvobo...@redhat.com
Date: Fri, 16 May 2014 18:32:17 +0200
Subject: [PATCH] webui: plugin API
new `extend` module should serve as a stable API for plugin authors.
It should expose the most commonly used global calls.
https://fedorahosted.org/freeipa/ticket/4345
---
install/ui/src/freeipa/extend.js | 76
1 file changed, 76 insertions(+)
create mode 100644 install/ui/src/freeipa/extend.js
diff --git a/install/ui/src/freeipa/extend.js b/install/ui/src/freeipa/extend.js
new file mode 100644
index ..e081aaad60a448d213abe57fc19836d6439def65
--- /dev/null
+++ b/install/ui/src/freeipa/extend.js
@@ -0,0 +1,76 @@
+/* Authors:
+ *Petr Vobornik pvobo...@redhat.com
+ *
+ * Copyright (C) 2014 Red Hat
+ * see file 'COPYING' for use and warranty information
+ *
+ * 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/.
+*/
+
+define([
+'dojo/_base/lang',
+'./jquery',
+'./phases',
+'./app_container',
+'exports'
+],function(lang, $, phases, app, extend) {
+
+/**
+ * Extension interface
+ *
+ * This class provides interface for plugins and tries to hide underlying functionality
+ *
+ * @class extend
+ * @singleton
+ */
+lang.mixin(extend, {
+/**
+ * Adds element to utility section
+ *
+ * This method doesn't do any correction. Expended root node type to add is
+ * by default li.
+ *
+ * Preferred phase: any after `init`
+ *
+ * @param {HTMLElement|jQuery} element Element to add to utility section
+ * @return {HTMLElement} Utility node
+ */
+add_menu_utility: function(element) {
+
+// Should we check if we are in good stage or atleast report that app doesn't exist yet?
+
+var $utility = $(app.app.app_widget.nav_util_tool_node);
+$utility.prepend(element);
+return $utility.eq(0);
+},
+
+/**
+ * Add route to router
+ *
+ * Handle should expect an `event` param. Check `dojo/router` documentation
+ * for more details
+ *
+ * @param {String|RegExp} route A string or regular expression that should
+ * be used for matching hash changes.
+ * @param {Function} handler A callback function which is executed on
+ * match. It's context is the router.
+ */
+add_route: function(route, handler) {
+var router = app.app.router;
+router.register_route(route, handler);
+}
+});
+
+return extend;
+});
\ No newline at end of file
--
1.9.0
From 3c79ff2d2d51ade7d2807ad90f5ddadfb77741ed Mon Sep 17 00:00:00 2001
From: Petr Vobornik pvobo...@redhat.com
Date: Fri, 16 May 2014 18:25:04 +0200
Subject: [PATCH] webui: add parent link to widgets in ContainerMixin
Standard facets sets `facet` attribute to widgets. This one adds
similar, more generic `parent` attribute which should be used for going through
the hierarchy up to top.
---
install/ui/src/freeipa/widget.js | 1 +
install/ui/src/freeipa/widgets/ContainerMixin.js | 2 ++
2 files changed, 3 insertions(+)
diff --git a/install/ui/src/freeipa/widget.js b/install/ui/src/freeipa/widget.js
index 212fc1c445e05b5c20c2ccfc7ad4beae4fc5c15e..75bacf0c287750ff0e52e7da20ac804d310e8327 100644
--- a/install/ui/src/freeipa/widget.js
+++ b/install/ui/src/freeipa/widget.js
@@ -5665,6 +5665,7 @@ exp.activity_widget = IPA.activity_widget = function(spec) {
exp.pre_op = function(spec, context) {
if (context.facet) spec.facet = context.facet;
+if (context.parent) spec.parent = context.parent;
if (context.entity) spec.entity = context.entity;
return spec;
};
diff --git a/install/ui/src/freeipa/widgets/ContainerMixin.js
Re: [Freeipa-devel] [PATCH] 12 Call generate-rndc-key.sh during ipa-server-install
On 04/18/2014 04:01 PM, Misnyovszki Adam wrote: On Thu, 17 Apr 2014 16:21:19 +0200 Martin Kosek mko...@redhat.com wrote: On 04/17/2014 04:10 PM, Rob Crittenden wrote: Misnyovszki Adam wrote: Hi, this patch modifies ipa-server-install to warn the user, if there is a lack of entropy, also runs generate-rndc-key.sh before named restart, to ensure, that it can start before systemd timeouts. I think the exception should be logged in check_entropy() in case this every does fail (the file name changes, the format changes, etc). There should be a try/except around the run() call. I noticed that /etc/rndc.key isn't removed on uninstall, which I guess means the same key will be re-used. Should we be removing that? rob Also, bare exceptions are bad! +except: +service.print_msg(Could not determine entropy, possible long delays) Next, you do all the checks in ipa-server-install, while they should be in service files, like krbinstance.py so that it is also checked in other installers, like ipa-replica-install. Same for DNS, it should be a separate step in bindinstance.py so that when the installation is hanging, you can see [X/Y] Generating rndc key file and know that it is hanging on that part. I would not misuse service.print_msg for regular messages, I would only do the service.print_msg(WARNING: Your system is running out of entropy, expect long delays!) others can be either turn into separate installation step or debug log message. Martin Hi, according to personal discussion with Martin, see the corrected patch! Thanks Adam ACK. Pushed to master: 71c6d2f1eb9610a0e0a994a6cfd78fdf9bb9d1fa Given that Adam no longer works in the Adam and cannot update the patch, I did couple very minor fixes - description is in the commit message. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 0557 pwpolicy-mod: Fix crash when priority is changed
See the ticket commit message.
https://fedorahosted.org/freeipa/ticket/4309
--
Petr³
From 3e9f26a423af1db2fe15b326059f901f7bcca70e Mon Sep 17 00:00:00 2001
From: Petr Viktorin pvikt...@redhat.com
Date: Tue, 27 May 2014 12:21:33 +0200
Subject: [PATCH] pwpolicy-mod: Fix crash when priority is changed
The exc_callback was expecting the old update_entry signature,
(dn, attrs). This was changed to just (entry) for ticket #2660,
see http://www.freeipa.org/page/HowTo/Migrate_your_code_to_the_new_LDAP_API.
Update the exc_callback to expect the entry as first argument,
and add some tests.
https://fedorahosted.org/freeipa/ticket/4309
---
ipalib/plugins/pwpolicy.py | 2 +-
ipatests/test_xmlrpc/objectclasses.py| 6 +++
ipatests/test_xmlrpc/test_pwpolicy_plugin.py | 72 +++-
3 files changed, 77 insertions(+), 3 deletions(-)
diff --git a/ipalib/plugins/pwpolicy.py b/ipalib/plugins/pwpolicy.py
index 9c8b711b89db578d1dd771b5fe3ae89d1d88ccf3..ee7f388ba98964a79b0036d9e2b4b642def5edee 100644
--- a/ipalib/plugins/pwpolicy.py
+++ b/ipalib/plugins/pwpolicy.py
@@ -456,7 +456,7 @@ def post_callback(self, ldap, dn, entry_attrs, *keys, **options):
def exc_callback(self, keys, options, exc, call_func, *call_args, **call_kwargs):
if call_func.func_name == 'update_entry':
if isinstance(exc, errors.EmptyModlist):
-entry_attrs = call_args[1]
+entry_attrs = call_args[0]
cosupdate = getattr(context, 'cosupdate')
if not entry_attrs or cosupdate:
return
diff --git a/ipatests/test_xmlrpc/objectclasses.py b/ipatests/test_xmlrpc/objectclasses.py
index 363e1c7c35e95f4cbe421aaec06c522700019567..ff497c81edec7c6ba9825e5c65b6f179c97147d1 100644
--- a/ipatests/test_xmlrpc/objectclasses.py
+++ b/ipatests/test_xmlrpc/objectclasses.py
@@ -170,3 +170,9 @@
u'ipatokenradiusconfiguration',
u'top',
]
+
+pwpolicy = [
+u'krbpwdpolicy',
+u'nscontainer',
+u'top',
+]
diff --git a/ipatests/test_xmlrpc/test_pwpolicy_plugin.py b/ipatests/test_xmlrpc/test_pwpolicy_plugin.py
index 3b482ce2dd7413b9968ac6046295315110768d03..5a8ac103079ed70705fa0d5cbacfa82a298cbdc1 100644
--- a/ipatests/test_xmlrpc/test_pwpolicy_plugin.py
+++ b/ipatests/test_xmlrpc/test_pwpolicy_plugin.py
@@ -21,12 +21,14 @@
Test the `ipalib/plugins/pwpolicy.py` module.
-import sys
from nose.tools import assert_raises # pylint: disable=E0611
-from xmlrpc_test import XMLRPC_test, assert_attr_equal
from ipalib import api
from ipalib import errors
+from ipapython.dn import DN
+from ipatests.test_xmlrpc import objectclasses
+from ipatests.test_xmlrpc.xmlrpc_test import (XMLRPC_test, assert_attr_equal,
+ Declarative)
class test_pwpolicy(XMLRPC_test):
@@ -242,3 +244,69 @@ def test_e_pwpolicy_del(self):
# Remove the user we created
api.Command['user_del'](self.user)
+
+
+class test_pwpolicy_mod_cospriority(Declarative):
+Tests for cospriority modifications
+cleanup_commands = [
+('pwpolicy_del', [u'ipausers'], {}),
+]
+
+tests = [
+dict(
+desc='Create a password policy',
+command=('pwpolicy_add', [u'ipausers'], dict(
+krbmaxpwdlife=90,
+krbminpwdlife=1,
+krbpwdhistorylength=10,
+krbpwdmindiffchars=3,
+krbpwdminlength=8,
+cospriority=10,
+)),
+expected=dict(
+result=dict(
+cn=[u'ipausers'],
+cospriority=[u'10'],
+dn=DN('cn=ipausers', ('cn', api.env.realm),
+ 'cn=kerberos', api.env.basedn),
+krbmaxpwdlife=[u'90'],
+krbminpwdlife=[u'1'],
+krbpwdhistorylength=[u'10'],
+krbpwdmindiffchars=[u'3'],
+krbpwdminlength=[u'8'],
+objectclass=objectclasses.pwpolicy,
+),
+summary=None,
+value=u'ipausers',
+),
+),
+
+dict(
+# https://fedorahosted.org/freeipa/ticket/4309
+desc=Try no-op modification of password policy's cospriority,
+command=('pwpolicy_mod', [u'ipausers'], dict(
+cospriority=10,
+)),
+expected=errors.EmptyModlist(),
+),
+
+dict(
+desc=Modify the password policy's cospriority,
+command=('pwpolicy_mod', [u'ipausers'], dict(
+cospriority=20,
+)),
+expected=dict(
+result=dict(
+cn=[u'ipausers'],
+cospriority=[u'20'],
+krbmaxpwdlife=[u'90'],
+krbminpwdlife=[u'1'],
+krbpwdhistorylength=[u'10'],
+
Re: [Freeipa-devel] Supported Staged entries
On Tue, 2014-05-27 at 13:01 +0200, Martin Kosek wrote: On 05/27/2014 11:53 AM, Jan Cholasta wrote: On 27.5.2014 11:14, thierry bordaz wrote: Hello, Me again !!! Thanks to all your inputs, the discussion about User_life_cycle clarified a lot workflow/command verbs. Now I have a doubt about what would be an entry in staging (objectclass/attribute). Also I wonder if ipa CLI (ipa user-add --stage), would be the only support way to create stage entry. An active entry is looking like (with krb* attributes if the userpassword is defined): dn: uid=tb17,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com displayName: tb15 tb15 cn: tb15 tb15 objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson objectClass: inetuser objectClass: posixaccount objectClass: krbprincipalaux objectClass: krbticketpolicyaux objectClass: ipaobject objectClass: ipasshuser objectClass: ipaSshGroupOfPubKeys objectClass: mepOriginEntry loginShell: /bin/sh gecos: tb15 tb15 sn: tb15 homeDirectory: /home/tb17 uid: tb17 mail: t...@idm.lab.bos.redhat.com krbPrincipalName: t...@idm.lab.bos.redhat.com givenName: tb15 initials: tt ipaUniqueID: 3f1b5cce-e1b8-11e3-86fe-001a4a104ecd uidNumber: 64649 gidNumber: 64649 mepManagedEntry: cn=tb17,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat, dc=com memberOf: cn=ipausers,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc= com nsAccountLock: False A staged entry created by 'ipa user-add --stage' may look like the following. This kind of entry is easy to activate 'ipa user-unstage' dn: uid=tb20,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, dc=redhat,dc=com displayName: tb20 tb20 cn: tb20 tb20 objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson objectClass: inetuser objectClass: posixaccount objectClass: krbprincipalaux objectClass: krbticketpolicyaux objectClass: ipaobject objectClass: ipasshuser objectClass: ipaSshGroupOfPubKeys loginShell: /bin/sh uidNumber: -1 ipaUniqueID: autogenerate gidNumber: -1 gecos: tb20 tb20 sn: tb20 homeDirectory: /home/tb20 uid: tb20 mail: t...@idm.lab.bos.redhat.com krbPrincipalName: t...@idm.lab.bos.redhat.com givenName: tb20 initials: tt nsAccountLock: True Now are we going to support the following entries for 'ipa user-unstage' dn: cn=tb20,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, dc=redhat,dc=com objectClass: top objectClass: person sn: tb20 cn: tb20 nsAccountLock: True or dn: uid=tb20,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, dc=redhat,dc=com objectClass: top objectClass: person objectClass: posixAccount sn: tb20 cn: tb20 tb20 uid: tb20 uidNumber: -1 gidNumber: -1 homeDirectory: /home/tb20 nsAccountLock: True thanks thierry IIUC unstaging a user will do something like this: staged_user = ldap.get_entry(staged_dn, ['*']) api.Command.user_add(**staged_user) So IMO virtually any kind of entry should be supported in the staging tree. The workflow will be different from what Jan suggested, but yes, we should support wide range of entries. I suspect some provisioning systems may even write entries with different RDN - i.e. with CN for example. About the unstaging - we already spoke about it, we will need to consolidate current operations in user-add and user-mod in common functions that will be called by those commands and user-unstage command. I imagine user-unstage command would then do: 1) MODRDN from staged users to active users 2) Update user with the same default as user-add, if RDN is different than UID, it should be converted to UID I wonder how should be the step 2) authorized LDAP-wise. The easiest way to make it happen is to give the operator making unstage operator write permission/ACI to active users, but it may not be the ideal way - we would want to limit the write permission only to the actual unstage operation of the particular user... Simo, what is your take on
Re: [Freeipa-devel] Supported Staged entries
On 05/27/2014 02:16 PM, Simo Sorce wrote: On Tue, 2014-05-27 at 13:01 +0200, Martin Kosek wrote: On 05/27/2014 11:53 AM, Jan Cholasta wrote: On 27.5.2014 11:14, thierry bordaz wrote: Hello, Me again !!! Thanks to all your inputs, the discussion about User_life_cycle clarified a lot workflow/command verbs. Now I have a doubt about what would be an entry in staging (objectclass/attribute). Also I wonder if ipa CLI (ipa user-add --stage), would be the only support way to create stage entry. An active entry is looking like (with krb* attributes if the userpassword is defined): dn: uid=tb17,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com displayName: tb15 tb15 cn: tb15 tb15 objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson objectClass: inetuser objectClass: posixaccount objectClass: krbprincipalaux objectClass: krbticketpolicyaux objectClass: ipaobject objectClass: ipasshuser objectClass: ipaSshGroupOfPubKeys objectClass: mepOriginEntry loginShell: /bin/sh gecos: tb15 tb15 sn: tb15 homeDirectory: /home/tb17 uid: tb17 mail: t...@idm.lab.bos.redhat.com krbPrincipalName: t...@idm.lab.bos.redhat.com givenName: tb15 initials: tt ipaUniqueID: 3f1b5cce-e1b8-11e3-86fe-001a4a104ecd uidNumber: 64649 gidNumber: 64649 mepManagedEntry: cn=tb17,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat, dc=com memberOf: cn=ipausers,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc= com nsAccountLock: False A staged entry created by 'ipa user-add --stage' may look like the following. This kind of entry is easy to activate 'ipa user-unstage' dn: uid=tb20,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, dc=redhat,dc=com displayName: tb20 tb20 cn: tb20 tb20 objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson objectClass: inetuser objectClass: posixaccount objectClass: krbprincipalaux objectClass: krbticketpolicyaux objectClass: ipaobject objectClass: ipasshuser objectClass: ipaSshGroupOfPubKeys loginShell: /bin/sh uidNumber: -1 ipaUniqueID: autogenerate gidNumber: -1 gecos: tb20 tb20 sn: tb20 homeDirectory: /home/tb20 uid: tb20 mail: t...@idm.lab.bos.redhat.com krbPrincipalName: t...@idm.lab.bos.redhat.com givenName: tb20 initials: tt nsAccountLock: True Now are we going to support the following entries for 'ipa user-unstage' dn: cn=tb20,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, dc=redhat,dc=com objectClass: top objectClass: person sn: tb20 cn: tb20 nsAccountLock: True or dn: uid=tb20,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, dc=redhat,dc=com objectClass: top objectClass: person objectClass: posixAccount sn: tb20 cn: tb20 tb20 uid: tb20 uidNumber: -1 gidNumber: -1 homeDirectory: /home/tb20 nsAccountLock: True thanks thierry IIUC unstaging a user will do something like this: staged_user = ldap.get_entry(staged_dn, ['*']) api.Command.user_add(**staged_user) So IMO virtually any kind of entry should be supported in the staging tree. The workflow will be different from what Jan suggested, but yes, we should support wide range of entries. I suspect some provisioning systems may even write entries with different RDN - i.e. with CN for example. About the unstaging - we already spoke about it, we will need to consolidate current operations in user-add and user-mod in common functions that will be called by those commands and user-unstage command. I imagine user-unstage command would then do: 1) MODRDN from staged users to active users 2) Update user with the same default as user-add, if RDN is different than UID, it should be converted to UID I wonder how should be the step 2) authorized LDAP-wise. The easiest way to make it happen is to give the operator making unstage operator write permission/ACI to active users, but it may not be the ideal way - we would want to limit the write permission only to the actual unstage operation of the particular user... Simo, what is your take on this? My take is that users need to be created with uid=name as the RDN or the operation
Re: [Freeipa-devel] Supported Staged entries
On 05/27/2014 02:32 PM, Jan Cholasta wrote: On 27.5.2014 14:22, Simo Sorce wrote: On Tue, 2014-05-27 at 14:19 +0200, Martin Kosek wrote: On 05/27/2014 02:16 PM, Simo Sorce wrote: On Tue, 2014-05-27 at 13:01 +0200, Martin Kosek wrote: On 05/27/2014 11:53 AM, Jan Cholasta wrote: On 27.5.2014 11:14, thierry bordaz wrote: Hello, Me again !!! Thanks to all your inputs, the discussion about User_life_cycle clarified a lot workflow/command verbs. Now I have a doubt about what would be an entry in staging (objectclass/attribute). Also I wonder if ipa CLI (ipa user-add --stage), would be the only support way to create stage entry. An active entry is looking like (with krb* attributes if the userpassword is defined): dn: uid=tb17,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com displayName: tb15 tb15 cn: tb15 tb15 objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson objectClass: inetuser objectClass: posixaccount objectClass: krbprincipalaux objectClass: krbticketpolicyaux objectClass: ipaobject objectClass: ipasshuser objectClass: ipaSshGroupOfPubKeys objectClass: mepOriginEntry loginShell: /bin/sh gecos: tb15 tb15 sn: tb15 homeDirectory: /home/tb17 uid: tb17 mail: t...@idm.lab.bos.redhat.com krbPrincipalName: t...@idm.lab.bos.redhat.com givenName: tb15 initials: tt ipaUniqueID: 3f1b5cce-e1b8-11e3-86fe-001a4a104ecd uidNumber: 64649 gidNumber: 64649 mepManagedEntry: cn=tb17,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat, dc=com memberOf: cn=ipausers,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc= com nsAccountLock: False A staged entry created by 'ipa user-add --stage' may look like the following. This kind of entry is easy to activate 'ipa user-unstage' dn: uid=tb20,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, dc=redhat,dc=com displayName: tb20 tb20 cn: tb20 tb20 objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson objectClass: inetuser objectClass: posixaccount objectClass: krbprincipalaux objectClass: krbticketpolicyaux objectClass: ipaobject objectClass: ipasshuser objectClass: ipaSshGroupOfPubKeys loginShell: /bin/sh uidNumber: -1 ipaUniqueID: autogenerate gidNumber: -1 gecos: tb20 tb20 sn: tb20 homeDirectory: /home/tb20 uid: tb20 mail: t...@idm.lab.bos.redhat.com krbPrincipalName: t...@idm.lab.bos.redhat.com givenName: tb20 initials: tt nsAccountLock: True Now are we going to support the following entries for 'ipa user-unstage' dn: cn=tb20,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, dc=redhat,dc=com objectClass: top objectClass: person sn: tb20 cn: tb20 nsAccountLock: True or dn: uid=tb20,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, dc=redhat,dc=com objectClass: top objectClass: person objectClass: posixAccount sn: tb20 cn: tb20 tb20 uid: tb20 uidNumber: -1 gidNumber: -1 homeDirectory: /home/tb20 nsAccountLock: True thanks thierry IIUC unstaging a user will do something like this: staged_user = ldap.get_entry(staged_dn, ['*']) api.Command.user_add(**staged_user) So IMO virtually any kind of entry should be supported in the staging tree. The workflow will be different from what Jan suggested, but yes, we should support wide range of entries. I suspect some provisioning systems may even write entries with different RDN - i.e. with CN for example. About the unstaging - we already spoke about it, we will need to consolidate current operations in user-add and user-mod in common functions that will be called by those commands and user-unstage command. I imagine user-unstage command would then do: 1) MODRDN from staged users to active users 2) Update user with the same default as user-add, if RDN is different than UID, it should be converted to UID I wonder how should be the step 2) authorized LDAP-wise. The easiest way to make it happen is to give the operator making unstage operator write permission/ACI to active users, but it may not be the ideal way - we would want to limit the write permission only to the actual unstage operation of the particular user... Simo, what is your take on
Re: [Freeipa-devel] Supported Staged entries
On 05/27/2014 02:19 PM, Martin Kosek wrote: On 05/27/2014 02:16 PM, Simo Sorce wrote: On Tue, 2014-05-27 at 13:01 +0200, Martin Kosek wrote: On 05/27/2014 11:53 AM, Jan Cholasta wrote: On 27.5.2014 11:14, thierry bordaz wrote: Hello, Me again !!! Thanks to all your inputs, the discussion about User_life_cycle clarified a lot workflow/command verbs. Now I have a doubt about what would be an entry in staging (objectclass/attribute). Also I wonder if ipa CLI (ipa user-add --stage), would be the only support way to create stage entry. An active entry is looking like (with krb* attributes if the userpassword is defined): dn: uid=tb17,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com displayName: tb15 tb15 cn: tb15 tb15 objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson objectClass: inetuser objectClass: posixaccount objectClass: krbprincipalaux objectClass: krbticketpolicyaux objectClass: ipaobject objectClass: ipasshuser objectClass: ipaSshGroupOfPubKeys objectClass: mepOriginEntry loginShell: /bin/sh gecos: tb15 tb15 sn: tb15 homeDirectory: /home/tb17 uid: tb17 mail: t...@idm.lab.bos.redhat.com krbPrincipalName: t...@idm.lab.bos.redhat.com givenName: tb15 initials: tt ipaUniqueID: 3f1b5cce-e1b8-11e3-86fe-001a4a104ecd uidNumber: 64649 gidNumber: 64649 mepManagedEntry: cn=tb17,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat, dc=com memberOf: cn=ipausers,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc= com nsAccountLock: False A staged entry created by 'ipa user-add --stage' may look like the following. This kind of entry is easy to activate 'ipa user-unstage' dn: uid=tb20,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, dc=redhat,dc=com displayName: tb20 tb20 cn: tb20 tb20 objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson objectClass: inetuser objectClass: posixaccount objectClass: krbprincipalaux objectClass: krbticketpolicyaux objectClass: ipaobject objectClass: ipasshuser objectClass: ipaSshGroupOfPubKeys loginShell: /bin/sh uidNumber: -1 ipaUniqueID: autogenerate gidNumber: -1 gecos: tb20 tb20 sn: tb20 homeDirectory: /home/tb20 uid: tb20 mail: t...@idm.lab.bos.redhat.com krbPrincipalName: t...@idm.lab.bos.redhat.com givenName: tb20 initials: tt nsAccountLock: True Now are we going to support the following entries for 'ipa user-unstage' dn: cn=tb20,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, dc=redhat,dc=com objectClass: top objectClass: person sn: tb20 cn: tb20 nsAccountLock: True or dn: uid=tb20,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, dc=redhat,dc=com objectClass: top objectClass: person objectClass: posixAccount sn: tb20 cn: tb20 tb20 uid: tb20 uidNumber: -1 gidNumber: -1 homeDirectory: /home/tb20 nsAccountLock: True thanks thierry IIUC unstaging a user will do something like this: staged_user = ldap.get_entry(staged_dn, ['*']) api.Command.user_add(**staged_user) So IMO virtually any kind of entry should be supported in the staging tree. The workflow will be different from what Jan suggested, but yes, we should support wide range of entries. I suspect some provisioning systems may even write entries with different RDN - i.e. with CN for example. About the unstaging - we already spoke about it, we will need to consolidate current operations in user-add and user-mod in common functions that will be called by those commands and user-unstage command. I imagine user-unstage command would then do: 1) MODRDN from staged users to active users 2) Update user with the same default as user-add, if RDN is different than UID, it should be converted to UID I wonder how should be the step 2) authorized LDAP-wise. The easiest way to make it happen is to give the operator making unstage operator write permission/ACI to active users, but it may not be the ideal way - we would want to limit the write permission only to the actual unstage operation of the particular user... Simo, what is your take on this? My take is that users need to be created with uid=name as the RDN
Re: [Freeipa-devel] Supported Staged entries
On Tue, 2014-05-27 at 14:40 +0200, thierry bordaz wrote: On 05/27/2014 02:32 PM, Jan Cholasta wrote: On 27.5.2014 14:22, Simo Sorce wrote: On Tue, 2014-05-27 at 14:19 +0200, Martin Kosek wrote: On 05/27/2014 02:16 PM, Simo Sorce wrote: On Tue, 2014-05-27 at 13:01 +0200, Martin Kosek wrote: On 05/27/2014 11:53 AM, Jan Cholasta wrote: On 27.5.2014 11:14, thierry bordaz wrote: Hello, Me again !!! Thanks to all your inputs, the discussion about User_life_cycle clarified a lot workflow/command verbs. Now I have a doubt about what would be an entry in staging (objectclass/attribute). Also I wonder if ipa CLI (ipa user-add --stage), would be the only support way to create stage entry. An active entry is looking like (with krb* attributes if the userpassword is defined): dn: uid=tb17,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com displayName: tb15 tb15 cn: tb15 tb15 objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson objectClass: inetuser objectClass: posixaccount objectClass: krbprincipalaux objectClass: krbticketpolicyaux objectClass: ipaobject objectClass: ipasshuser objectClass: ipaSshGroupOfPubKeys objectClass: mepOriginEntry loginShell: /bin/sh gecos: tb15 tb15 sn: tb15 homeDirectory: /home/tb17 uid: tb17 mail: t...@idm.lab.bos.redhat.com krbPrincipalName: t...@idm.lab.bos.redhat.com givenName: tb15 initials: tt ipaUniqueID: 3f1b5cce-e1b8-11e3-86fe-001a4a104ecd uidNumber: 64649 gidNumber: 64649 mepManagedEntry: cn=tb17,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat, dc=com memberOf: cn=ipausers,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc= com nsAccountLock: False A staged entry created by 'ipa user-add --stage' may look like the following. This kind of entry is easy to activate 'ipa user-unstage' dn: uid=tb20,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, dc=redhat,dc=com displayName: tb20 tb20 cn: tb20 tb20 objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson objectClass: inetuser objectClass: posixaccount objectClass: krbprincipalaux objectClass: krbticketpolicyaux objectClass: ipaobject objectClass: ipasshuser objectClass: ipaSshGroupOfPubKeys loginShell: /bin/sh uidNumber: -1 ipaUniqueID: autogenerate gidNumber: -1 gecos: tb20 tb20 sn: tb20 homeDirectory: /home/tb20 uid: tb20 mail: t...@idm.lab.bos.redhat.com krbPrincipalName: t...@idm.lab.bos.redhat.com givenName: tb20 initials: tt nsAccountLock: True Now are we going to support the following entries for 'ipa user-unstage' dn: cn=tb20,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, dc=redhat,dc=com objectClass: top objectClass: person sn: tb20 cn: tb20 nsAccountLock: True or dn: uid=tb20,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, dc=redhat,dc=com objectClass: top objectClass: person objectClass: posixAccount sn: tb20 cn: tb20 tb20 uid: tb20 uidNumber: -1 gidNumber: -1 homeDirectory: /home/tb20 nsAccountLock: True thanks thierry IIUC unstaging a user will do something like this: staged_user = ldap.get_entry(staged_dn, ['*']) api.Command.user_add(**staged_user) So IMO virtually any kind of entry should be supported in the staging tree. The workflow will be different from what Jan suggested, but yes, we should support wide range of entries. I suspect some provisioning systems may even write entries with different RDN - i.e. with CN for example. About the unstaging - we already spoke about it, we will need to consolidate current operations in user-add and user-mod in common functions that will be called by those commands and user-unstage command. I imagine user-unstage command would then do: 1) MODRDN from staged users to active users 2) Update user with the same default as user-add, if RDN is different than UID, it should be converted to UID I wonder how should be the
Re: [Freeipa-devel] Supported Staged entries
On 05/27/2014 03:08 PM, Simo Sorce wrote: On Tue, 2014-05-27 at 14:40 +0200, thierry bordaz wrote: On 05/27/2014 02:32 PM, Jan Cholasta wrote: On 27.5.2014 14:22, Simo Sorce wrote: On Tue, 2014-05-27 at 14:19 +0200, Martin Kosek wrote: On 05/27/2014 02:16 PM, Simo Sorce wrote: On Tue, 2014-05-27 at 13:01 +0200, Martin Kosek wrote: On 05/27/2014 11:53 AM, Jan Cholasta wrote: On 27.5.2014 11:14, thierry bordaz wrote: Hello, Me again !!! Thanks to all your inputs, the discussion about User_life_cycle clarified a lot workflow/command verbs. Now I have a doubt about what would be an entry in staging (objectclass/attribute). Also I wonder if ipa CLI (ipa user-add --stage), would be the only support way to create stage entry. An active entry is looking like (with krb* attributes if the userpassword is defined): dn: uid=tb17,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com displayName: tb15 tb15 cn: tb15 tb15 objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson objectClass: inetuser objectClass: posixaccount objectClass: krbprincipalaux objectClass: krbticketpolicyaux objectClass: ipaobject objectClass: ipasshuser objectClass: ipaSshGroupOfPubKeys objectClass: mepOriginEntry loginShell: /bin/sh gecos: tb15 tb15 sn: tb15 homeDirectory: /home/tb17 uid: tb17 mail: t...@idm.lab.bos.redhat.com krbPrincipalName: t...@idm.lab.bos.redhat.com givenName: tb15 initials: tt ipaUniqueID: 3f1b5cce-e1b8-11e3-86fe-001a4a104ecd uidNumber: 64649 gidNumber: 64649 mepManagedEntry: cn=tb17,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat, dc=com memberOf: cn=ipausers,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc= com nsAccountLock: False A staged entry created by 'ipa user-add --stage' may look like the following. This kind of entry is easy to activate 'ipa user-unstage' dn: uid=tb20,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, dc=redhat,dc=com displayName: tb20 tb20 cn: tb20 tb20 objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson objectClass: inetuser objectClass: posixaccount objectClass: krbprincipalaux objectClass: krbticketpolicyaux objectClass: ipaobject objectClass: ipasshuser objectClass: ipaSshGroupOfPubKeys loginShell: /bin/sh uidNumber: -1 ipaUniqueID: autogenerate gidNumber: -1 gecos: tb20 tb20 sn: tb20 homeDirectory: /home/tb20 uid: tb20 mail: t...@idm.lab.bos.redhat.com krbPrincipalName: t...@idm.lab.bos.redhat.com givenName: tb20 initials: tt nsAccountLock: True Now are we going to support the following entries for 'ipa user-unstage' dn: cn=tb20,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, dc=redhat,dc=com objectClass: top objectClass: person sn: tb20 cn: tb20 nsAccountLock: True or dn: uid=tb20,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, dc=redhat,dc=com objectClass: top objectClass: person objectClass: posixAccount sn: tb20 cn: tb20 tb20 uid: tb20 uidNumber: -1 gidNumber: -1 homeDirectory: /home/tb20 nsAccountLock: True thanks thierry IIUC unstaging a user will do something like this: staged_user = ldap.get_entry(staged_dn, ['*']) api.Command.user_add(**staged_user) So IMO virtually any kind of entry should be supported in the staging tree. The workflow will be different from what Jan suggested, but yes, we should support wide range of entries. I suspect some provisioning systems may even write entries with different RDN - i.e. with CN for example. About the unstaging - we already spoke about it, we will need to consolidate current operations in user-add and user-mod in common functions that will be called by those commands and user-unstage command. I imagine user-unstage command would then do: 1) MODRDN from staged users to active users 2) Update user with the same default as user-add, if RDN is different than UID, it should be converted to UID I wonder how should be the step 2) authorized LDAP-wise. The easiest way to make it happen is to give the operator making unstage
Re: [Freeipa-devel] OTP Sync Client Design
On 26.5.2014 18:23, Nathaniel McCallum wrote: On Mon, 2014-05-26 at 09:56 +0200, Jan Cholasta wrote: On 23.5.2014 23:19, Nathaniel McCallum wrote: On Wed, 2014-05-14 at 14:08 -0400, Nathaniel McCallum wrote: Occasionally OTP tokens get out of sync with the server. When this happens, the user or an admin need to synchronize the token. To this end, we landed server-side synchronization support, which is a simple bind with a custom control. This all works with my sample test script. Client support is proving a bit more difficult. In the ideal world, the client would contact LDAP directly and perform the operation. This would make a man in the middle attack difficult and we can ensure encryption over the entire operation. However, browsers, without server-side assistance, cannot perform this operation from javascript. This means that, in this case, the first factor and two second factors must be transmitted to the FreeIPA server and then proxied to 389. Is this an acceptable compromise? This command also needs to be accessible *without* an existing user login since, if a user's token is out of sync, the user can't login. Is it possible to expose such an API? If so, how? Both ipa env and ipa ping seem to require kinit, so I don't see any obvious examples. Thanks everyone for your feedback. This particular feature is proving difficult to implement, even with our agreed upon design. To reiterate this design: there will be an HTTP method by which to synchronize tokens. There are two assumptions in the code which are making this difficult: 1. All cli commands are Command subclasses. 2. All Command subclasses create authenticated server methods. There are thus two ways to tackle this problem. First, I can create a standard POST method in rpcserver.py. This is not very modular. But the biggest problem is that there is no way to create the cli-side command to call it (assumption #1). Well, you could derive the command from ipalib.frontend.Local and manually call the POST method from it. This still creates a (NoOp) server-side RPC method, right? We can probably just accept this as a drawback for now and move on. After a future refactoring of rpcserver.py, we can move the manual POST method into this server-side RPC method. I agree, I think there's no harm in having a placeholder RPC method. -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Supported Staged entries
On 05/27/2014 03:10 PM, Simo Sorce wrote:
On Tue, 2014-05-27 at 14:59 +0200, thierry bordaz wrote:
Now if an entry was not created by FreeIPA CLI ('ipa user-add
--stage') it could be impossible to update/unstage the entry with
FreeIPA CLI .
For example with those two entries. 'ipa user-mod TestUser --stage' or
'ipa user-unstage TestUser' are unable to select the correct entry
Keep in mind that use case #1 for the staging are is non-freeipa
provisioning systems. So it is pretty much granted in the large majority
of cases entries will not be created by freeipa tools, which is why I
also do not want to move them, but only use them as templates for
actual user creation.
Simo.
Ok. Good to know, I was thinking 'non-freeipa' provisioning to be a
corner case and I was wrong it is the common case.
Now to make a user active, 'ipa user-unstage tuser' will be the unique way.
To be able to select the appropriate entry, I think we need to limit the
RDN attribute to 'uid'.
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Supported Staged entries
On 05/27/2014 03:08 PM, Simo Sorce wrote: On Tue, 2014-05-27 at 14:40 +0200, thierry bordaz wrote: On 05/27/2014 02:32 PM, Jan Cholasta wrote: On 27.5.2014 14:22, Simo Sorce wrote: On Tue, 2014-05-27 at 14:19 +0200, Martin Kosek wrote: On 05/27/2014 02:16 PM, Simo Sorce wrote: On Tue, 2014-05-27 at 13:01 +0200, Martin Kosek wrote: On 05/27/2014 11:53 AM, Jan Cholasta wrote: On 27.5.2014 11:14, thierry bordaz wrote: Hello, Me again !!! Thanks to all your inputs, the discussion about User_life_cycle clarified a lot workflow/command verbs. Now I have a doubt about what would be an entry in staging (objectclass/attribute). Also I wonder if ipa CLI (ipa user-add --stage), would be the only support way to create stage entry. An active entry is looking like (with krb* attributes if the userpassword is defined): dn: uid=tb17,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com displayName: tb15 tb15 cn: tb15 tb15 objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson objectClass: inetuser objectClass: posixaccount objectClass: krbprincipalaux objectClass: krbticketpolicyaux objectClass: ipaobject objectClass: ipasshuser objectClass: ipaSshGroupOfPubKeys objectClass: mepOriginEntry loginShell: /bin/sh gecos: tb15 tb15 sn: tb15 homeDirectory: /home/tb17 uid: tb17 mail: t...@idm.lab.bos.redhat.com krbPrincipalName: t...@idm.lab.bos.redhat.com givenName: tb15 initials: tt ipaUniqueID: 3f1b5cce-e1b8-11e3-86fe-001a4a104ecd uidNumber: 64649 gidNumber: 64649 mepManagedEntry: cn=tb17,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat, dc=com memberOf: cn=ipausers,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc= com nsAccountLock: False A staged entry created by 'ipa user-add --stage' may look like the following. This kind of entry is easy to activate 'ipa user-unstage' dn: uid=tb20,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, dc=redhat,dc=com displayName: tb20 tb20 cn: tb20 tb20 objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson objectClass: inetuser objectClass: posixaccount objectClass: krbprincipalaux objectClass: krbticketpolicyaux objectClass: ipaobject objectClass: ipasshuser objectClass: ipaSshGroupOfPubKeys loginShell: /bin/sh uidNumber: -1 ipaUniqueID: autogenerate gidNumber: -1 gecos: tb20 tb20 sn: tb20 homeDirectory: /home/tb20 uid: tb20 mail: t...@idm.lab.bos.redhat.com krbPrincipalName: t...@idm.lab.bos.redhat.com givenName: tb20 initials: tt nsAccountLock: True Now are we going to support the following entries for 'ipa user-unstage' dn: cn=tb20,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, dc=redhat,dc=com objectClass: top objectClass: person sn: tb20 cn: tb20 nsAccountLock: True or dn: uid=tb20,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, dc=redhat,dc=com objectClass: top objectClass: person objectClass: posixAccount sn: tb20 cn: tb20 tb20 uid: tb20 uidNumber: -1 gidNumber: -1 homeDirectory: /home/tb20 nsAccountLock: True thanks thierry IIUC unstaging a user will do something like this: staged_user = ldap.get_entry(staged_dn, ['*']) api.Command.user_add(**staged_user) So IMO virtually any kind of entry should be supported in the staging tree. The workflow will be different from what Jan suggested, but yes, we should support wide range of entries. I suspect some provisioning systems may even write entries with different RDN - i.e. with CN for example. About the unstaging - we already spoke about it, we will need to consolidate current operations in user-add and user-mod in common functions that will be called by those commands and user-unstage command. I imagine user-unstage command would then do: 1) MODRDN from staged users to active users 2) Update user with the same default as user-add, if RDN is different than UID, it should be converted to UID I wonder how should be the step 2) authorized LDAP-wise. The easiest way to make it happen is to give the operator making unstage operator write permission/ACI to active users,
Re: [Freeipa-devel] [PATCH 0257] Fix race condition during zone loading
On 27.5.2014 15:54, Petr Spacek wrote:
Fix race condition during zone loading.
DNS zone has to be added to DNS view before dns_zone_load() is called.
It is necessary to prevent dns_zone_load() from racing with dns_zone_setview().
This race condition sometimes prevents zone from being signed.
Now the unsigned zone is visible until signing process is complete. This
mimics BIND behavior for in-line signed zones.
https://fedorahosted.org/bind-dyndb-ldap/ticket/56
And here is the patch...
--
Petr^2 Spacek
From 9dd8cb898c674ad3cdd0bf5fe6c08770abc04176 Mon Sep 17 00:00:00 2001
From: Petr Spacek pspa...@redhat.com
Date: Tue, 27 May 2014 15:41:59 +0200
Subject: [PATCH] Fix race condition during zone loading.
DNS zone has to be added to DNS view before dns_zone_load() is called.
It is necessary to prevent dns_zone_load() from racing with dns_zone_setview().
This race condition sometimes prevents zone from being signed.
Now the unsigned zone is visible until signing process is complete. This
mimics BIND behavior for in-line signed zones.
https://fedorahosted.org/bind-dyndb-ldap/ticket/56
Signed-off-by: Petr Spacek pspa...@redhat.com
---
src/ldap_helper.c | 97 ++-
src/ldap_helper.h | 2 +-
2 files changed, 54 insertions(+), 45 deletions(-)
diff --git a/src/ldap_helper.c b/src/ldap_helper.c
index 3150b56f118b6270bb79a8bc2491c472b98477dc..d01d0de1654e9ebcd9bda7aaeb930a243e24bf3c 100644
--- a/src/ldap_helper.c
+++ b/src/ldap_helper.c
@@ -1100,65 +1100,74 @@ cleanup:
}
/**
+ * Add zone to view and call dns_zone_load().
+ */
+static isc_result_t ATTR_NONNULLS ATTR_CHECKRESULT
+activate_zone(isc_task_t *task, ldap_instance_t *inst, dns_name_t *name) {
+ isc_result_t result;
+ dns_zone_t *raw = NULL;
+ dns_zone_t *secure = NULL;
+ dns_zone_t *toview = NULL;
+ settings_set_t *zone_settings = NULL;
+
+ CHECK(zr_get_zone_ptr(inst-zone_register, name, raw, secure));
+
+ /* Load only secure zone if inline-signing is active.
+ * It will not work if raw zone is loaded explicitly
+ * - dns_zone_load() will fail magically. */
+ toview = (secure != NULL) ? secure : raw;
+
+ /*
+ * Zone has to be published *before* zone load
+ * otherwise it will race with zone-view != NULL check
+ * in zone_maintenance() in zone.c.
+ */
+ result = publish_zone(task, inst, toview);
+ if (result != ISC_R_SUCCESS) {
+ dns_zone_log(toview, ISC_LOG_ERROR,
+ cannot add zone to view: %s,
+ dns_result_totext(result));
+ goto cleanup;
+ }
+
+ CHECK(load_zone(toview));
+ if (secure != NULL) {
+ CHECK(zr_get_zone_settings(inst-zone_register, name,
+ zone_settings));
+ CHECK(zone_master_reconfigure_nsec3param(zone_settings,
+ secure));
+ }
+
+cleanup:
+ if (raw != NULL)
+ dns_zone_detach(raw);
+ if (secure != NULL)
+ dns_zone_detach(secure);
+ return result;
+}
+
+/**
* Add all zones in zone register to DNS view specified in inst-view
* and load zones.
*/
isc_result_t
activate_zones(isc_task_t *task, ldap_instance_t *inst) {
isc_result_t result;
- isc_boolean_t loaded;
rbt_iterator_t *iter = NULL;
- dns_zone_t *raw = NULL;
- dns_zone_t *secure = NULL;
- dns_zone_t *toview = NULL;
DECLARE_BUFFERED_NAME(name);
unsigned int published_cnt = 0;
unsigned int total_cnt = 0;
- settings_set_t *zone_settings = NULL;
INIT_BUFFERED_NAME(name);
- CHECK(zr_rbt_iter_init(inst-zone_register, iter, name));
- do {
+ for(result = zr_rbt_iter_init(inst-zone_register, iter, name);
+ result == ISC_R_SUCCESS;
+ dns_name_init(name, NULL), result = rbt_iter_next(iter, name)) {
++total_cnt;
- CHECK(zr_get_zone_ptr(inst-zone_register, name, raw, secure));
- /* Load only secure zone if inline-signing is active.
- * It will not work if raw zone is loaded explicitly. */
- toview = (secure != NULL) ? secure : raw;
- result = load_zone(toview);
- loaded = (result == ISC_R_SUCCESS);
- if (loaded == ISC_FALSE)
- dns_zone_log(raw, ISC_LOG_ERROR,
- unable to load zone: %s,
- dns_result_totext(result));
- else if (secure != NULL) {
- zone_settings = NULL;
- CHECK(zr_get_zone_settings(inst-zone_register,
- name, zone_settings));
- CHECK(zone_master_reconfigure_nsec3param(zone_settings,
- secure));
- }
-
- /*
- * Don't bother if load fails, server will return
- * SERVFAIL for queries beneath this zone. This is
- * admin's problem.
- */
- result = publish_zone(task, inst, toview);
- if (result != ISC_R_SUCCESS)
- dns_zone_log(toview, ISC_LOG_ERROR,
- cannot add zone to view: %s,
- dns_result_totext(result));
- else if (loaded == ISC_TRUE)
+ result = activate_zone(task, inst, name);
+ if (result == ISC_R_SUCCESS)
++published_cnt;
- dns_zone_detach(raw);
- if (secure != NULL)
- dns_zone_detach(secure);
+ };
- INIT_BUFFERED_NAME(name);
- CHECK(rbt_iter_next(iter, name));
- } while (result == ISC_R_SUCCESS);
-
-cleanup:
log_info(%u zones from LDAP instance '%s' loaded
[Freeipa-devel] [PATCH 0257] Fix race condition during zone loading
Hello, Fix race condition during zone loading. DNS zone has to be added to DNS view before dns_zone_load() is called. It is necessary to prevent dns_zone_load() from racing with dns_zone_setview(). This race condition sometimes prevents zone from being signed. Now the unsigned zone is visible until signing process is complete. This mimics BIND behavior for in-line signed zones. https://fedorahosted.org/bind-dyndb-ldap/ticket/56 -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFC] Migrating existing environments to Trust
On Tue, Apr 15, 2014 at 11:13:38AM +0200, Sumit Bose wrote: Hi, I have started to write a design page for 'Migrating existing environments to Trust' http://www.freeipa.org/page/V3/Migrating_existing_environments_to_Trust It shall cover https://fedorahosted.org/freeipa/ticket/3318 and https://fedorahosted.org/freeipa/ticket/3979 . while working on a new version of the page with more details on design and implementation I came across the following problem. On the IPA server there should be a way for SSSD to deliver unmodified data (no view applied) or views other than the one for the IPA server to processes which delivers user and group data to other clients. This are mainly the extdom and the compat plugin of dirsrv. The two currently use standard glibc calls like getpwnam_r() to get the needed data from SSSD. While they can read the view objects form the LDAP tree there is no way to read the original data for users from trusted domains because it is only in the cache of SSSD. I'm looking for a way to allow SSSD to deliver the data without changing the protocol used by the NSS responder. One way I can think of is to use a new socket like /var/lib/sss/pipes/nss_noview and create a small library for the extdom and compat plugin to use the new socket. With this the plugin have to apply the views on their own if needed. Another way would be a new command for the NSS responder with two arguments, the view name (or empty for unmodified data) and a blob which contains the data for the corresponding request like e.g. getpwnam_r() or getgrgid_r(). Here the plugins have to use some new calls but all view processing can happen in sssd and the plugins can deliver the data directly. A drawback in both cases is that the memcache cannot be used. If someone has suggestions for SSSD or other ways how to deliver user and group data to client with other views than the IPA server I'm all ears. bye, Sumit ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Should normal user see his krbt and password policies?
On 27.5.2014 14:28, Petr Vobornik wrote: Recent removal of global read-only ACI affects current self-service page. Now it displays error dialog with two errors: * None: password policy not found * an internal error has occurred They are results of: * pwpolicy-show --user=username * krbtpolicy-show username commands. The second one is an obvious bug: https://fedorahosted.org/freeipa/ticket/4354 The question is whether normal user should see this information or not. If yes, we should fix default permissions. If not, we should fix Web UI. A ticket for Web UI was created since the user can also browse other users. https://fedorahosted.org/freeipa/ticket/4355 Nevertheless, the original question still stands. -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] 0552-0554 Upgrading write permissions
On 05/26/2014 04:44 PM, Petr Viktorin wrote: On 05/22/2014 03:07 PM, Petr Viktorin wrote: Hello, Here I start upgrading the existing default permissions to the new Managed style. https://fedorahosted.org/freeipa/ticket/4346 The patches rely on my patch 0551 (https://fedorahosted.org/freeipa/ticket/4349) You may run into what seems to be a 389 bug. If you get a Midair Collision (NO_SUCH_ATTRIBUTE) error, restart the DS and try running ipa-ldap-updater again. I'm working with Ludwig on this one. The operation is now described at http://www.freeipa.org/page/V4/Managed_Read_permissions#Replacing_legacy_default_permissions If there user has modified an old default permission, a warning is logged the replacement permission is not added/updated. The user needs to evaluate the situation: either update the old permission to match the original default, or remove the old permission, and then run ipa-ldap-updater will create the new one. Is bailing out the right thing to do if the old entry was modified? Forcing user to remove old permission and create new one seems as a too much work to me. After the upgrade, we need to be sure that the managed permissions is there. What is the problem of having both 2 permissions in the DS? The old modified permission and the new system managed one? As we are dealing with allow permissions, having 2 of them should be harmless. It could be possible to parse the permission, figure out the changes the user made, and apply them to the new one, but that seems like too much guesswork to me. Maybe we could do the same we do with managed permissions upgrades? Only allow differences in the list of attributes? I am thinking that people could hotfix missing attributes at permissions themselves (like adding description to sudorule permission), this would lead to duplicate permissions later. What we could do when old ACI differs only in allowed attributes is to compare it to defaults and set whitelist and blacklist attributes of the new managed permission. Then we can safely delete the old ACI (with warning). If you think this is too much work, we can keep the old behavior and just add duplicate ACI. On the other hand, my approach has a downside as well: if the 'memberallowcmd' attribute was removed from 'Modify Sudo rule', there's now no way to upgrade while allowing access but keeping that attribute off-limits, short of writing deny a ACI by hand. How big a problem is this? It might be worth it to create a special tool that upgrades a single permission and allows setting the excluded/included attributes explicitly. This problem would be removed with my approach proposed above. There are some interesting scenarios to think about with respect to upgrades and user changes: * Upgrade to old version, e.g. - have IPA 3.2 master, IPA 3.2 replica - upgrade master to 4.0 (old permissions are updated) - then upgrade replica to 3.3 (old permissions are added again!) This is AFAIK not supported but it does happen. We can't change old IPA versions, so any upgrade to a pre-4.0 IPA will always add the old permissions, but with this patch, a subsequent upgrade to 4.0+, or running a 4.0+ ipa-ldap-update, will remove the old permissions again. Hm, I think this is the best option we have. We should warn about this behavior in our release notes though. Tied to that is another scenario: * Re-create permissions with old names - have IPA 4.0 master - Create a permission named 'Modify Sudo rule' - Upgrade to IPA 4.1 Here we need to make sure the new permission is *not* removed, because a new 'Modify Sudo rule' permission is no longer special in any way. To ensure this the updater only removes old-style permissions. Right, we can decide based on objectclasses - whether permissionsv2 OC is there or not. One thing that can happen when 4.0 masters are still mixed with 3.x is that an old permission named 'Modify Sudo rule' is added on the old server. Any update to 4.0+ will remove that. Old-style default permissions were sorta-kinda managed by IPA itself anyway, so users should expect this. We should still point it out in the docs though, since I expect some users to start messing with the permissions before upgrading all of the infrastructure to 4.0. +1, I would just point out that behavior in the release notes. The second patch upgrades sudorule permissions, this server as an example of how the will work. The third patch fixes https://fedorahosted.org/freeipa/ticket/4344 The user read permissions patches had a conflict with these; attaching rebased version. Now the actual review 552.2: worked fine for me. Some updates will probably be needed though, based on the discussion above. 553.2: 1) Why should we bother specifying ipapermdefaultattr for add ACIs? Looks like a noop to me, it was also never part of our add ACIs. I tried to strip that down to just description and I was still able to add a whole new SUDO
Re: [Freeipa-devel] Supported Staged entries
On Tue, 2014-05-27 at 15:21 +0200, Martin Kosek wrote: This topic was already discussed in the past, see following part of the design: http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Renaming_vs._Moving_Users_in_LDAP One of the biggest concern was that to allow operator unstage a user, he would need to have a delete ACI in staging container AND add ACI in the active users area - which would also allow him to create any user he wishes in the users area. This is the reason why we preferred to do and control it via MODRDN and the reason why Thierry implemented the new ACI for controlling MODRDN operation: https://fedorahosted.org/389/ticket/47553 I know that's why we did it, but I had a hard look since then, and I believe we cannot really use that method. The reason is simply that we do not control who adds the user object and our reason to do the staging is to make it simple for an external provisioning system to create a basic user entry the way it knows how to, with only the attributes the provisioning system cares about. But this means we have no guarantee of what objectclasses are available on the object, so we have no guarantees all the necessary structureal objectclasses have been added in the staging object. We have to recreate the user object in order to be able to add all the right structural objectclasses as those can only be added at object creation time in an LDAPv3 compliant LDAP server. Recreating the object will also allow you to deal with the other case you brought forward where the provisioning system used CN as the RDN, but we want uid. I understand it gives operators a higher privilege, but I think we'll have to think harder how to properly handle the issue. Perhaps the best way is to create a new proxy-API to promote users from a staging area. This service will have the privilege to create users using its own credentials instead of those of the operator. This can be done later, meanwhile we will have to accept operators need the privilege to create users. Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Supported Staged entries
On 05/27/2014 04:27 PM, Simo Sorce wrote: On Tue, 2014-05-27 at 15:21 +0200, Martin Kosek wrote: This topic was already discussed in the past, see following part of the design: http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Renaming_vs._Moving_Users_in_LDAP One of the biggest concern was that to allow operator unstage a user, he would need to have a delete ACI in staging container AND add ACI in the active users area - which would also allow him to create any user he wishes in the users area. This is the reason why we preferred to do and control it via MODRDN and the reason why Thierry implemented the new ACI for controlling MODRDN operation: https://fedorahosted.org/389/ticket/47553 I know that's why we did it, but I had a hard look since then, and I believe we cannot really use that method. The reason is simply that we do not control who adds the user object and our reason to do the staging is to make it simple for an external provisioning system to create a basic user entry the way it knows how to, with only the attributes the provisioning system cares about. But this means we have no guarantee of what objectclasses are available on the object, so we have no guarantees all the necessary structureal objectclasses have been added in the staging object. We have to recreate the user object in order to be able to add all the right structural objectclasses as those can only be added at object creation time in an LDAPv3 compliant LDAP server. Recreating the object will also allow you to deal with the other case you brought forward where the provisioning system used CN as the RDN, but we want uid. I understand it gives operators a higher privilege, but I think we'll have to think harder how to properly handle the issue. Perhaps the best way is to create a new proxy-API to promote users from a staging area. This service will have the privilege to create users using its own credentials instead of those of the operator. This can be done later, meanwhile we will have to accept operators need the privilege to create users. Simo. Ok, the point about structural objectclasses is a strong one. Thierry, you what to do - this should be noted in the design page... Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] 0540-0542 Add managed read permissions to user
On 05/26/2014 12:13 PM, Petr Viktorin wrote: [...] Thanks for the thorough review! Pushed to master: 63becae88c6c270b98f0432dc474b661b82f3119 Okay guys, we have another issue: user-add (and the migration plugin) needs access to cn=UPG Definition,cn=Definitions,cn=Managed Entries,cn=etc,... to check the originfilter for '(objectclass=disable)'. Do we want to give read access to all users, or just user admins? -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] 0540-0542 Add managed read permissions to user
On Tue, 27 May 2014, Petr Viktorin wrote: On 05/26/2014 12:13 PM, Petr Viktorin wrote: [...] Thanks for the thorough review! Pushed to master: 63becae88c6c270b98f0432dc474b661b82f3119 Okay guys, we have another issue: user-add (and the migration plugin) needs access to cn=UPG Definition,cn=Definitions,cn=Managed Entries,cn=etc,... to check the originfilter for '(objectclass=disable)'. Do we want to give read access to all users, or just user admins? I would say user admins. If something more substantial fails, we'll extend the access. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] 0540-0542 Add managed read permissions to user
On Tue, 2014-05-27 at 18:01 +0300, Alexander Bokovoy wrote: On Tue, 27 May 2014, Petr Viktorin wrote: On 05/26/2014 12:13 PM, Petr Viktorin wrote: [...] Thanks for the thorough review! Pushed to master: 63becae88c6c270b98f0432dc474b661b82f3119 Okay guys, we have another issue: user-add (and the migration plugin) needs access to cn=UPG Definition,cn=Definitions,cn=Managed Entries,cn=etc,... to check the originfilter for '(objectclass=disable)'. Do we want to give read access to all users, or just user admins? I would say user admins. If something more substantial fails, we'll extend the access. ACK ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Supported Staged entries
On 05/27/2014 04:35 PM, Martin Kosek wrote: On 05/27/2014 04:27 PM, Simo Sorce wrote: On Tue, 2014-05-27 at 15:21 +0200, Martin Kosek wrote: This topic was already discussed in the past, see following part of the design: http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Renaming_vs._Moving_Users_in_LDAP One of the biggest concern was that to allow operator unstage a user, he would need to have a delete ACI in staging container AND add ACI in the active users area - which would also allow him to create any user he wishes in the users area. This is the reason why we preferred to do and control it via MODRDN and the reason why Thierry implemented the new ACI for controlling MODRDN operation: https://fedorahosted.org/389/ticket/47553 I know that's why we did it, but I had a hard look since then, and I believe we cannot really use that method. The reason is simply that we do not control who adds the user object and our reason to do the staging is to make it simple for an external provisioning system to create a basic user entry the way it knows how to, with only the attributes the provisioning system cares about. But this means we have no guarantee of what objectclasses are available on the object, so we have no guarantees all the necessary structureal objectclasses have been added in the staging object. We have to recreate the user object in order to be able to add all the right structural objectclasses as those can only be added at object creation time in an LDAPv3 compliant LDAP server. Both approach looks possible: * adding required structural OC+AT in the existing entry * creating a new entry with all structural OC+AT and update the AT values with what exists in the stage entry but I think the second one would be simpler to implement. Here again uid uniqueness is a difficulty: if 'uid' exists in stage entry we need to delete the stage entry before adding the active one. There is a risk to loose the entry if the add fails. Also it is important to apply DEL/ADD on the same replica so that DEL csn ADD csn. Recreating the object will also allow you to deal with the other case you brought forward where the provisioning system used CN as the RDN, but we want uid. I am not sure: if some provisioning systems created the two entries # entry 1 dn: ou=TestUser,cn=staged users,cn=accounts,cn=provisioning,dc=example,dc=com objectClass: top objectClass: account uid: xxx ou: TestUser # entry 2 dn: uid=TestUser,cn=staged users,cn=accounts,cn=provisioning,dc=example,dc=com objectClass: top objectClass: posixAccount cn: TestUser uid: TestUser ipaUniqueID: autogenerate uidNumber: -1 gidNumber: -1 If we activate both entries. we will create a new entry with all the required objectclass but at the end we will need to pick up a 'uid' value. Entry 2 will keep its 'uid'. Entry 1 we have two solutions, 'xxx' but then it changes the RDN value or 'TestUser' (the former RDN value) that is in collision with entry 2. I think it would simplify the problem if we enforce that staged entries have 'uid' RDN. I understand it gives operators a higher privilege, but I think we'll have to think harder how to properly handle the issue. A possibility is to create a pre-active status, between 'stage' and 'active'. The 'stage' container contains raw provisioned entries. 'pre-active' a copy of the 'stage' entry with all the structural objectclasses. If 'pre-active' is out of the scope of uid uniqueness, we can add the 'pre-active' entry before removing the 'stage' entry (and rollback in case of failure). Then do a MODRDN (with appropriate aci) 'pre-active' - 'active'. Perhaps the best way is to create a new proxy-API to promote users from a staging area. This service will have the privilege to create users using its own credentials instead of those of the operator. This can be done later, meanwhile we will have to accept operators need the privilege to create users. Simo. Ok, the point about structural objectclasses is a strong one. Thierry, you what to do - this should be noted in the design page... Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Supported Staged entries
On Tue, 2014-05-27 at 17:55 +0200, thierry bordaz wrote: On 05/27/2014 04:35 PM, Martin Kosek wrote: On 05/27/2014 04:27 PM, Simo Sorce wrote: On Tue, 2014-05-27 at 15:21 +0200, Martin Kosek wrote: This topic was already discussed in the past, see following part of the design: http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Renaming_vs._Moving_Users_in_LDAP One of the biggest concern was that to allow operator unstage a user, he would need to have a delete ACI in staging container AND add ACI in the active users area - which would also allow him to create any user he wishes in the users area. This is the reason why we preferred to do and control it via MODRDN and the reason why Thierry implemented the new ACI for controlling MODRDN operation: https://fedorahosted.org/389/ticket/47553 I know that's why we did it, but I had a hard look since then, and I believe we cannot really use that method. The reason is simply that we do not control who adds the user object and our reason to do the staging is to make it simple for an external provisioning system to create a basic user entry the way it knows how to, with only the attributes the provisioning system cares about. But this means we have no guarantee of what objectclasses are available on the object, so we have no guarantees all the necessary structureal objectclasses have been added in the staging object. We have to recreate the user object in order to be able to add all the right structural objectclasses as those can only be added at object creation time in an LDAPv3 compliant LDAP server. Both approach looks possible: * adding required structural OC+AT in the existing entry * creating a new entry with all structural OC+AT and update the AT values with what exists in the stage entry but I think the second one would be simpler to implement. My assessment too. Here again uid uniqueness is a difficulty: if 'uid' exists in stage entry we need to delete the stage entry before adding the active one. There is a risk to loose the entry if the add fails. Also it is important to apply DEL/ADD on the same replica so that DEL csn ADD csn. I think the solution is to not have the uid uniqueness plugin look into the staging tree. I think it is fair to put the burden of not creatoing conflicting uids in the provisioning system the drives creating the staged entries. If a staged entry has a conflicting uid then at unstaging time we will throw an error and the admin will have to fix the staged entry (either remove it and ask the provisioning people to re-provision, or modifying it). Recreating the object will also allow you to deal with the other case you brought forward where the provisioning system used CN as the RDN, but we want uid. I am not sure: if some provisioning systems created the two entries # entry 1 dn: ou=TestUser,cn=staged users,cn=accounts,cn=provisioning,dc=example,dc=com objectClass: top objectClass: account uid: xxx ou: TestUser # entry 2 dn: uid=TestUser,cn=staged users,cn=accounts,cn=provisioning,dc=example,dc=com objectClass: top objectClass: posixAccount cn: TestUser uid: TestUser ipaUniqueID: autogenerate uidNumber: -1 gidNumber: -1 If we activate both entries. we will create a new entry with all the required objectclass but at the end we will need to pick up a 'uid' value. Entry 2 will keep its 'uid'. Entry 1 we have two solutions, 'xxx' but then it changes the RDN value or 'TestUser' (the former RDN value) that is in collision with entry 2. I think it would simplify the problem if we enforce that staged entries have 'uid' RDN. To be honest I do not see the problem. We just need to care about the 'uid' attribute in the staged entry, and pick that to generate the RDN of the user in the active tree. If there are conflicts the 'unstage' will fail cleanly, as the 'add' operation will just fail (due to non unique RDN) and the admin will have to take care of the situation. I understand it gives operators a higher privilege, but I think we'll have to think harder how to properly handle the issue. A possibility is to create a pre-active status, between 'stage' and 'active'. The 'stage' container contains raw provisioned entries. 'pre-active' a copy of the 'stage' entry with all the structural objectclasses. If 'pre-active' is out of the scope of uid uniqueness, we can add the 'pre-active' entry before removing the 'stage' entry (and rollback in case of failure). Then do a MODRDN (with appropriate aci) 'pre-active' - 'active'. Sounds like a lot of complexity for a problem we do not really have, all we need is to not enforce uniqueness in staging. Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Supported Staged entries
On 05/27/2014 06:06 PM, Simo Sorce wrote: On Tue, 2014-05-27 at 17:55 +0200, thierry bordaz wrote: On 05/27/2014 04:35 PM, Martin Kosek wrote: On 05/27/2014 04:27 PM, Simo Sorce wrote: On Tue, 2014-05-27 at 15:21 +0200, Martin Kosek wrote: This topic was already discussed in the past, see following part of the design: http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Renaming_vs._Moving_Users_in_LDAP One of the biggest concern was that to allow operator unstage a user, he would need to have a delete ACI in staging container AND add ACI in the active users area - which would also allow him to create any user he wishes in the users area. This is the reason why we preferred to do and control it via MODRDN and the reason why Thierry implemented the new ACI for controlling MODRDN operation: https://fedorahosted.org/389/ticket/47553 I know that's why we did it, but I had a hard look since then, and I believe we cannot really use that method. The reason is simply that we do not control who adds the user object and our reason to do the staging is to make it simple for an external provisioning system to create a basic user entry the way it knows how to, with only the attributes the provisioning system cares about. But this means we have no guarantee of what objectclasses are available on the object, so we have no guarantees all the necessary structureal objectclasses have been added in the staging object. We have to recreate the user object in order to be able to add all the right structural objectclasses as those can only be added at object creation time in an LDAPv3 compliant LDAP server. Both approach looks possible: * adding required structural OC+AT in the existing entry * creating a new entry with all structural OC+AT and update the AT values with what exists in the stage entry but I think the second one would be simpler to implement. My assessment too. Here again uid uniqueness is a difficulty: if 'uid' exists in stage entry we need to delete the stage entry before adding the active one. There is a risk to loose the entry if the add fails. Also it is important to apply DEL/ADD on the same replica so that DEL csn ADD csn. I think the solution is to not have the uid uniqueness plugin look into the staging tree. I think it is fair to put the burden of not creatoing conflicting uids in the provisioning system the drives creating the staged entries. If a staged entry has a conflicting uid then at unstaging time we will throw an error and the admin will have to fix the staged entry (either remove it and ask the provisioning people to re-provision, or modifying it). Ok great. Recreating the object will also allow you to deal with the other case you brought forward where the provisioning system used CN as the RDN, but we want uid. I am not sure: if some provisioning systems created the two entries # entry 1 dn: ou=TestUser,cn=staged users,cn=accounts,cn=provisioning,dc=example,dc=com objectClass: top objectClass: account uid: xxx ou: TestUser # entry 2 dn: uid=TestUser,cn=staged users,cn=accounts,cn=provisioning,dc=example,dc=com objectClass: top objectClass: posixAccount cn: TestUser uid: TestUser ipaUniqueID: autogenerate uidNumber: -1 gidNumber: -1 If we activate both entries. we will create a new entry with all the required objectclass but at the end we will need to pick up a 'uid' value. Entry 2 will keep its 'uid'. Entry 1 we have two solutions, 'xxx' but then it changes the RDN value or 'TestUser' (the former RDN value) that is in collision with entry 2. I think it would simplify the problem if we enforce that staged entries have 'uid' RDN. To be honest I do not see the problem. We just need to care about the 'uid' attribute in the staged entry, and pick that to generate the RDN of the user in the active tree. If there are conflicts the 'unstage' will fail cleanly, as the 'add' operation will just fail (due to non unique RDN) and the admin will have to take care of the situation. In that case the provisioning system created a staging entry ou=TestUser,$STAGING, it will get an active entry uid=xxx,$ACTIVE It could be an issue for the provisioning system to retrieve the entry it created. I understand it gives operators a higher privilege, but I think we'll have to think harder how to properly handle the issue. A possibility is to create a pre-active status, between 'stage' and 'active'. The 'stage' container contains raw provisioned entries. 'pre-active' a copy of the 'stage' entry with all the structural objectclasses. If 'pre-active' is out of the scope of uid uniqueness, we can add the 'pre-active' entry before removing the 'stage' entry (and rollback in case of failure). Then do a MODRDN (with appropriate aci) 'pre-active' - 'active'. Sounds like a lot of complexity for a problem we do not really have, all we need is to not enforce uniqueness in staging. This proposal was also to limit the operator privilege to do MODRDN from
Re: [Freeipa-devel] Supported Staged entries
On 05/27/2014 06:56 PM, Simo Sorce wrote: On Tue, 2014-05-27 at 18:39 +0200, thierry bordaz wrote: On 05/27/2014 06:06 PM, Simo Sorce wrote: We just need to care about the 'uid' attribute in the staged entry, and pick that to generate the RDN of the user in the active tree. If there are conflicts the 'unstage' will fail cleanly, as the 'add' operation will just fail (due to non unique RDN) and the admin will have to take care of the situation. In that case the provisioning system created a staging entry ou=TestUser,$STAGING, it will get an active entry uid=xxx,$ACTIVE It could be an issue for the provisioning system to retrieve the entry it created. Too bad for the provisioning system, we are not going to allow users to have a form that does not use uid in the RDN in IPA. Sounds like a lot of complexity for a problem we do not really have, all we need is to not enforce uniqueness in staging. This proposal was also to limit the operator privilege to do MODRDN from 'pre-active' to 'active', instead ADD on 'active'. It is not useful, the operator still needs to be able to create in pre-active ... so it can still create what it wants. yes that is correct. Does it address the security concern, if the operator that is allowed to add in 'staging'/'pre-active' is different from the one allowed to move the entry in 'active' ? Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Supported Staged entries
On Tue, 2014-05-27 at 19:59 +0200, thierry bordaz wrote: On 05/27/2014 06:56 PM, Simo Sorce wrote: On Tue, 2014-05-27 at 18:39 +0200, thierry bordaz wrote: On 05/27/2014 06:06 PM, Simo Sorce wrote: We just need to care about the 'uid' attribute in the staged entry, and pick that to generate the RDN of the user in the active tree. If there are conflicts the 'unstage' will fail cleanly, as the 'add' operation will just fail (due to non unique RDN) and the admin will have to take care of the situation. In that case the provisioning system created a staging entry ou=TestUser,$STAGING, it will get an active entry uid=xxx,$ACTIVE It could be an issue for the provisioning system to retrieve the entry it created. Too bad for the provisioning system, we are not going to allow users to have a form that does not use uid in the RDN in IPA. Sounds like a lot of complexity for a problem we do not really have, all we need is to not enforce uniqueness in staging. This proposal was also to limit the operator privilege to do MODRDN from 'pre-active' to 'active', instead ADD on 'active'. It is not useful, the operator still needs to be able to create in pre-active ... so it can still create what it wants. yes that is correct. Does it address the security concern, if the operator that is allowed to add in 'staging'/'pre-active' is different from the one allowed to move the entry in 'active' ? Well it really depends on 'who' the operator is. We would like to be able to allow a 'junior admin/helpdesk person' to just press a button to activate a user, but that shouldn't drive our design if it makes other things clumsy or suboptimal. The less privileged operator problem can always be solved by a middle-man script that has higher privileges. So we nee to give priority to getting the workflow right in terms of the way it works. I think re-creating the user object gives us better chances at handling the overall workflow and fixing up entries accordingly to the management framework view of what a user needs to look like, so in the end I prefer that route. Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Supported Staged entries
On Tue, 2014-05-27 at 21:14 +0300, Alexander Bokovoy wrote: On Tue, 27 May 2014, Simo Sorce wrote: On Tue, 2014-05-27 at 19:59 +0200, thierry bordaz wrote: On 05/27/2014 06:56 PM, Simo Sorce wrote: On Tue, 2014-05-27 at 18:39 +0200, thierry bordaz wrote: On 05/27/2014 06:06 PM, Simo Sorce wrote: We just need to care about the 'uid' attribute in the staged entry, and pick that to generate the RDN of the user in the active tree. If there are conflicts the 'unstage' will fail cleanly, as the 'add' operation will just fail (due to non unique RDN) and the admin will have to take care of the situation. In that case the provisioning system created a staging entry ou=TestUser,$STAGING, it will get an active entry uid=xxx,$ACTIVE It could be an issue for the provisioning system to retrieve the entry it created. Too bad for the provisioning system, we are not going to allow users to have a form that does not use uid in the RDN in IPA. Sounds like a lot of complexity for a problem we do not really have, all we need is to not enforce uniqueness in staging. This proposal was also to limit the operator privilege to do MODRDN from 'pre-active' to 'active', instead ADD on 'active'. It is not useful, the operator still needs to be able to create in pre-active ... so it can still create what it wants. yes that is correct. Does it address the security concern, if the operator that is allowed to add in 'staging'/'pre-active' is different from the one allowed to move the entry in 'active' ? Well it really depends on 'who' the operator is. We would like to be able to allow a 'junior admin/helpdesk person' to just press a button to activate a user, but that shouldn't drive our design if it makes other things clumsy or suboptimal. The less privileged operator problem can always be solved by a middle-man script that has higher privileges. So we nee to give priority to getting the workflow right in terms of the way it works. I think re-creating the user object gives us better chances at handling the overall workflow and fixing up entries accordingly to the management framework view of what a user needs to look like, so in the end I prefer that route. I agree. It also opens us a way to handle import of any foreign schema person if staged object uses extensibleObject object class where we are in control of what exactly will get into the actual tree. Right it allows us to do things like filter out objectclass or attributes the provisioning system adds but that the admin does not want in the final entry. This is not something we may want to build into the solution from day zero, but it gives us the option to build it more easily, as a framework filter on the 'unstage' operation. (We so need to be able to copy additional objectclasses and their attributes from day 0 though). Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Supported Staged entries
On Tue, 27 May 2014, Simo Sorce wrote: On Tue, 2014-05-27 at 19:59 +0200, thierry bordaz wrote: On 05/27/2014 06:56 PM, Simo Sorce wrote: On Tue, 2014-05-27 at 18:39 +0200, thierry bordaz wrote: On 05/27/2014 06:06 PM, Simo Sorce wrote: We just need to care about the 'uid' attribute in the staged entry, and pick that to generate the RDN of the user in the active tree. If there are conflicts the 'unstage' will fail cleanly, as the 'add' operation will just fail (due to non unique RDN) and the admin will have to take care of the situation. In that case the provisioning system created a staging entry ou=TestUser,$STAGING, it will get an active entry uid=xxx,$ACTIVE It could be an issue for the provisioning system to retrieve the entry it created. Too bad for the provisioning system, we are not going to allow users to have a form that does not use uid in the RDN in IPA. Sounds like a lot of complexity for a problem we do not really have, all we need is to not enforce uniqueness in staging. This proposal was also to limit the operator privilege to do MODRDN from 'pre-active' to 'active', instead ADD on 'active'. It is not useful, the operator still needs to be able to create in pre-active ... so it can still create what it wants. yes that is correct. Does it address the security concern, if the operator that is allowed to add in 'staging'/'pre-active' is different from the one allowed to move the entry in 'active' ? Well it really depends on 'who' the operator is. We would like to be able to allow a 'junior admin/helpdesk person' to just press a button to activate a user, but that shouldn't drive our design if it makes other things clumsy or suboptimal. The less privileged operator problem can always be solved by a middle-man script that has higher privileges. So we nee to give priority to getting the workflow right in terms of the way it works. I think re-creating the user object gives us better chances at handling the overall workflow and fixing up entries accordingly to the management framework view of what a user needs to look like, so in the end I prefer that route. I agree. It also opens us a way to handle import of any foreign schema person if staged object uses extensibleObject object class where we are in control of what exactly will get into the actual tree. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] faster ways to build/test dogtag?
On Tue, May 27, 2014 at 12:20:46PM +0200, Martin Kosek wrote: On 05/27/2014 09:00 AM, Fraser Tweedale wrote: Hi all, I've been working on a fix for a profile issue (https://fedorahosted.org/freeipa/ticket/2915). Unfortunately I find the scripts/compose_pki_core_packages - yum install - test cycle frustratingly slow on idm.lab.bos. Is there a quicker way to build and test the software - particularly as part of the larger IPA/certmonger/dogtag ecosystem? Cheers, Fraser I am not sure about dogtag - you would need to ask on pki-devel mailing list. As for FreeIPA - I use a home-grown synchronization script that puts modified python file in my local git directly into my test VM system so I do not need to compile and install FreeIPA rpms every time. Martin Alternatively, I've been building RPMs locally (you can use ramdisk for added speed bonus) and then rsync-ed them to the target VM. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFC] Migrating existing environments to Trust
On Tue, May 27, 2014 at 04:01:41PM +0200, Sumit Bose wrote: On Tue, Apr 15, 2014 at 11:13:38AM +0200, Sumit Bose wrote: Hi, I have started to write a design page for 'Migrating existing environments to Trust' http://www.freeipa.org/page/V3/Migrating_existing_environments_to_Trust It shall cover https://fedorahosted.org/freeipa/ticket/3318 and https://fedorahosted.org/freeipa/ticket/3979 . while working on a new version of the page with more details on design and implementation I came across the following problem. On the IPA server there should be a way for SSSD to deliver unmodified data (no view applied) or views other than the one for the IPA server to processes which delivers user and group data to other clients. This are mainly the extdom and the compat plugin of dirsrv. btw in the previous discussion, you proposed to get rid of the extdom plugin completely, is it still the plan? The two currently use standard glibc calls like getpwnam_r() to get the needed data from SSSD. While they can read the view objects form the LDAP tree there is no way to read the original data for users from trusted domains because it is only in the cache of SSSD. I'm looking for a way to allow SSSD to deliver the data without changing the protocol used by the NSS responder. One way I can think of is to use a new socket like /var/lib/sss/pipes/nss_noview and create a small library for the extdom and compat plugin to use the new socket. With this the plugin have to apply the views on their own if needed. Can we have a separate memory cache for the original view (or per-view) in this case used by this new small library? Since the memory cache has a fixed size and it would be used by a single process only, we wouldn't risk growing the memory consumption too much.. The NSS responder would have to be aware of multiple memory caches, which might be ugly, though.. Another way would be a new command for the NSS responder with two arguments, the view name (or empty for unmodified data) and a blob which contains the data for the corresponding request like e.g. getpwnam_r() or getgrgid_r(). Here the plugins have to use some new calls but all view processing can happen in sssd and the plugins can deliver the data directly. So there would be a special call in the nss client library (getpwnam_ipa()?) just for the server mode? Then I think the previous suggestion souds better to me, I think we should keep the current client library minimal and stable. A drawback in both cases is that the memcache cannot be used. If someone has suggestions for SSSD or other ways how to deliver user and group data to client with other views than the IPA server I'm all ears. bye, Sumit ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH 0054] Change OTPSyncRequest structure to use OctetString
This change has two motivations:
1. Clients don't have to parse the string.
2. Future token types may have new formats.
From 41d2ca7ddc827bbac1907a9d97502d1d9a4d0faa Mon Sep 17 00:00:00 2001
From: Nathaniel McCallum npmccal...@redhat.com
Date: Fri, 23 May 2014 13:01:59 -0400
Subject: [PATCH] Change OTPSyncRequest structure to use OctetString
This change has two motivations:
1. Clients don't have to parse the string.
2. Future token types may have new formats.
---
daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c | 4 +-
daemons/ipa-slapi-plugins/ipa-pwd-extop/syncreq.c | 37 ++-
daemons/ipa-slapi-plugins/ipa-pwd-extop/syncreq.h | 4 +-
daemons/ipa-slapi-plugins/libotp/libotp.c | 76 +++
daemons/ipa-slapi-plugins/libotp/libotp.h | 12 ++--
5 files changed, 78 insertions(+), 55 deletions(-)
diff --git a/daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c b/daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c
index 23c7cb18c9a1cb5256254f20080c5d9aaec25579..60ceaaa7ab0cd282efb45f1a89de9dbd240a452c 100644
--- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c
+++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c
@@ -1157,8 +1157,8 @@ static bool ipapwd_do_otp_auth(const char *dn, Slapi_Entry *bind_entry,
/* Loop through each token. */
for (int i = 0; tokens[i] !success; i++) {
/* Attempt authentication. */
-success = otptoken_validate_string(tokens[i], OTP_VALIDATE_STEPS,
- creds-bv_val, creds-bv_len, true);
+success = otptoken_validate_berval(tokens[i], OTP_VALIDATE_STEPS,
+ creds, true);
/* Truncate the password to remove the OTP code at the end. */
if (success) {
diff --git a/daemons/ipa-slapi-plugins/ipa-pwd-extop/syncreq.c b/daemons/ipa-slapi-plugins/ipa-pwd-extop/syncreq.c
index 27878776fd22a0b93dc00730316da98cddd89bf9..2bfcf10a271a497741f08bb519020cd159eb4aeb 100644
--- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/syncreq.c
+++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/syncreq.c
@@ -58,10 +58,11 @@ bool sync_request_handle(Slapi_ComponentId *plugin_id, Slapi_PBlock *pb,
{
struct otptoken **tokens = NULL;
LDAPControl **controls = NULL;
+struct berval *second = NULL;
+struct berval *first = NULL;
BerElement *ber = NULL;
char *token_dn = NULL;
-int second = 0;
-int first = 0;
+bool success;
if (slapi_pblock_get(pb, SLAPI_REQCONTROLS, controls) != 0)
return false;
@@ -79,32 +80,30 @@ bool sync_request_handle(Slapi_ComponentId *plugin_id, Slapi_PBlock *pb,
return false;
/* Decode the token codes. */
-if (ber_scanf(ber, {ii, first, second) == LBER_ERROR) {
+if (ber_scanf(ber, {OO, first, second) == LBER_ERROR) {
ber_free(ber, 1);
return false;
}
/* Decode the optional token DN. */
ber_scanf(ber, a, token_dn);
-if (ber_scanf(ber, }) == LBER_ERROR) {
-ber_free(ber, 1);
-return false;
+
+/* Process the synchronization. */
+success = false;
+if (ber_scanf(ber, }) != LBER_ERROR) {
+tokens = otptoken_find(plugin_id, user_dn, token_dn, true, NULL);
+if (tokens != NULL) {
+success = otptoken_sync_berval(tokens, OTP_SYNC_MAX_STEPS, first, second);
+otptoken_free_array(tokens);
+}
}
+
+ber_memfree(token_dn); token_dn = NULL;
+ber_bvfree(second);
+ber_bvfree(first);
ber_free(ber, 1);
-
-/* Find all the tokens. */
-tokens = otptoken_find(plugin_id, user_dn, token_dn, true, NULL);
-ber_memfree(token_dn);
-if (tokens == NULL)
+if (!success)
return false;
-
-/* Synchronize the token. */
-if (!otptoken_sync(tokens, OTP_SYNC_MAX_STEPS, first, second)) {
-otptoken_free_array(tokens);
-return false;
-}
-
-otptoken_free_array(tokens);
}
return true;
diff --git a/daemons/ipa-slapi-plugins/ipa-pwd-extop/syncreq.h b/daemons/ipa-slapi-plugins/ipa-pwd-extop/syncreq.h
index 049a621022af2c7d8f7b8b256ad499d49ba77e3e..34235901b7b2e49cc6e79423a92e0e4930c0b8cb 100644
--- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/syncreq.h
+++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/syncreq.h
@@ -48,8 +48,8 @@
* The ASN.1 encoding of the request structure:
*
* OTPSyncRequest ::= SEQUENCE {
- * firstCode INTEGER,
- * secondCode INTEGER,
+ * firstCode OCTET STRING,
+ * secondCode OCTET STRING,
* tokenDN OCTET STRING OPTIONAL
* }
*/
diff --git a/daemons/ipa-slapi-plugins/libotp/libotp.c b/daemons/ipa-slapi-plugins/libotp/libotp.c
index e6c8eaade32b4bbfe41fbd5983c1326aca16fc01..eeead43e35c9cbde473c54efcf6482d38e6329b3 100644
--- a/daemons/ipa-slapi-plugins/libotp/libotp.c
Re: [Freeipa-devel] [RFC] Migrating existing environments to Trust
On Tue, 2014-05-27 at 16:01 +0200, Sumit Bose wrote: On Tue, Apr 15, 2014 at 11:13:38AM +0200, Sumit Bose wrote: Hi, I have started to write a design page for 'Migrating existing environments to Trust' http://www.freeipa.org/page/V3/Migrating_existing_environments_to_Trust It shall cover https://fedorahosted.org/freeipa/ticket/3318 and https://fedorahosted.org/freeipa/ticket/3979 . while working on a new version of the page with more details on design and implementation I came across the following problem. On the IPA server there should be a way for SSSD to deliver unmodified data (no view applied) or views other than the one for the IPA server to processes which delivers user and group data to other clients. This are mainly the extdom and the compat plugin of dirsrv. The two currently use standard glibc calls like getpwnam_r() to get the needed data from SSSD. While they can read the view objects form the LDAP tree there is no way to read the original data for users from trusted domains because it is only in the cache of SSSD. I'm looking for a way to allow SSSD to deliver the data without changing the protocol used by the NSS responder. One way I can think of is to use a new socket like /var/lib/sss/pipes/nss_noview and create a small library for the extdom and compat plugin to use the new socket. With this the plugin have to apply the views on their own if needed. Another way would be a new command for the NSS responder with two arguments, the view name (or empty for unmodified data) and a blob which contains the data for the corresponding request like e.g. getpwnam_r() or getgrgid_r(). Here the plugins have to use some new calls but all view processing can happen in sssd and the plugins can deliver the data directly. A drawback in both cases is that the memcache cannot be used. If someone has suggestions for SSSD or other ways how to deliver user and group data to client with other views than the IPA server I'm all ears. Ok this one is hard to deal with in a way that will satisfy every possible user. I think what we need to aim is simplicity and predictability at the expense of flexibility. What I mean is that freeipa servers should be allowed to only stick to one view, the default view for external users. And then the extdom plugin will be allowed to overlay a different view for specific clients. But the default view is the baseline, no special behavior. If you need to 're'-override some attributes in specific views, so be it. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFC] Migrating existing environments to Trust
On Tue, 2014-05-27 at 20:57 +0200, Jakub Hrozek wrote: On Tue, May 27, 2014 at 04:01:41PM +0200, Sumit Bose wrote: On Tue, Apr 15, 2014 at 11:13:38AM +0200, Sumit Bose wrote: Hi, I have started to write a design page for 'Migrating existing environments to Trust' http://www.freeipa.org/page/V3/Migrating_existing_environments_to_Trust It shall cover https://fedorahosted.org/freeipa/ticket/3318 and https://fedorahosted.org/freeipa/ticket/3979 . while working on a new version of the page with more details on design and implementation I came across the following problem. On the IPA server there should be a way for SSSD to deliver unmodified data (no view applied) or views other than the one for the IPA server to processes which delivers user and group data to other clients. This are mainly the extdom and the compat plugin of dirsrv. btw in the previous discussion, you proposed to get rid of the extdom plugin completely, is it still the plan? Is this possible at all ? We'd break existing clients that rely on it. The two currently use standard glibc calls like getpwnam_r() to get the needed data from SSSD. While they can read the view objects form the LDAP tree there is no way to read the original data for users from trusted domains because it is only in the cache of SSSD. I'm looking for a way to allow SSSD to deliver the data without changing the protocol used by the NSS responder. One way I can think of is to use a new socket like /var/lib/sss/pipes/nss_noview and create a small library for the extdom and compat plugin to use the new socket. With this the plugin have to apply the views on their own if needed. Can we have a separate memory cache for the original view (or per-view) in this case used by this new small library? Since the memory cache has a fixed size and it would be used by a single process only, we wouldn't risk growing the memory consumption too much.. The NSS responder would have to be aware of multiple memory caches, which might be ugly, though.. no see my other reply, at most we can get a cache in extdom if we really care, but we shouldn't have special behavior in sssd for this feature. One server has one canonical view, and IPA server should be bound to the default view and not be able to be configured to use any other 'view'. In other words, 'views' are really only for ipa clients, not for the servers themselves. Another way would be a new command for the NSS responder with two arguments, the view name (or empty for unmodified data) and a blob which contains the data for the corresponding request like e.g. getpwnam_r() or getgrgid_r(). Here the plugins have to use some new calls but all view processing can happen in sssd and the plugins can deliver the data directly. So there would be a special call in the nss client library (getpwnam_ipa()?) just for the server mode? Then I think the previous suggestion souds better to me, I think we should keep the current client library minimal and stable. I am against it indeed. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
