Re: [Freeipa-devel] [PATCHES 0200-0202] DNS fixes related to unsupported records
On 03/06/2015 01:30 PM, Petr Spacek wrote: On 4.3.2015 16:35, Martin Basti wrote: On 04/03/15 16:17, Martin Basti wrote: Ticket: https://fedorahosted.org/freeipa/ticket/4930 0200: 4.1, master Fixes traceback, which was raised if LDAP contained a record that was marked as unsupported. Now unsupported records are shown, if LDAP contains them. 0200: 4.1, master Records marked as unsupported will not show options for editing parts. 0202: only master Removes NSEC3PARAM record from record types. NSEC3PARAM can contain only zone, value is allowed only in idnszone objectclass, so do not confuse users. and patches attached :-) ACK. It works for me and can be pushed to branches 4.1 and master. Patches require a rebase. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0199] Remove unused disable-betxn.ldif file
On 03/09/2015 11:56 AM, David Kupka wrote: On 02/25/2015 02:45 PM, Martin Basti wrote: Hello, the file 'disable-betxn.ldif' is not used in code in IPA master branch. There is 10-enable-betxn.update which is used. If I'm right we can remove it. Patch attached. Please correct me if the file is needed. Martin^2 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel IIUC ipa stopped using this file in commit f1f1b4e7f2e9c1838ad7ec76002b78ca0c2a3c46 but it was not removed. Works for me, ACK. Pushed to master: a695f33989c3e6159a12c9341e42c042847cd57b -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [PATCHES 0015-0017] consolidation of various Kerberos auth methods in FreeIPA code
On 03/06/2015 01:05 PM, Martin Babinsky wrote:
This series of patches for the master/4.1 branch attempts to implement
some of the Rob's and Petr Vobornik's ideas which originated from a
discussion on this list regarding my original patch fixing
https://fedorahosted.org/freeipa/ticket/4808.
I suppose that these patches are just a first iteration, we may further
discuss if this is the right thing to do.
Below is a quote from the original discussion just to get the context:
The next iteration of patches is attached below. Thanks to jcholast and
pvoborni for the comments and insights.
--
Martin^3 Babinsky
From 97e4eed332391bab7a12dc593152e369f347fd3c Mon Sep 17 00:00:00 2001
From: Martin Babinsky mbabi...@redhat.com
Date: Mon, 9 Mar 2015 12:53:10 +0100
Subject: [PATCH 1/3] ipautil: new functions kinit_keytab and kinit_password
kinit_keytab replaces kinit_hostprincipal and performs Kerberos auth using
keytab file. Function is also able to repeat authentication multiple times
before giving up and raising StandardError.
kinit_password wraps kinit auth using password and also supports FAST
authentication using httpd armor ccache.
---
ipapython/ipautil.py | 60
1 file changed, 46 insertions(+), 14 deletions(-)
diff --git a/ipapython/ipautil.py b/ipapython/ipautil.py
index 4116d974e620341119b56fad3cff1bda48af3bab..4547165ccf24ff6edf5c65e756aa321aa34b9e61 100644
--- a/ipapython/ipautil.py
+++ b/ipapython/ipautil.py
@@ -1175,27 +1175,59 @@ def wait_for_open_socket(socket_name, timeout=0):
else:
raise e
-def kinit_hostprincipal(keytab, ccachedir, principal):
+
+def kinit_keytab(keytab, ccache_path, principal, attempts=1):
-Given a ccache directory and a principal kinit as that user.
+Given a ccache_path , keytab file and a principal kinit as that user.
+
+The optional parameter 'attempts' specifies how many times the credential
+initialization should be attempted before giving up and raising
+StandardError.
This blindly overwrites the current CCNAME so if you need to save
it do so before calling this function.
Thus far this is used to kinit as the local host.
-try:
-ccache_file = 'FILE:%s/ccache' % ccachedir
-krbcontext = krbV.default_context()
-ktab = krbV.Keytab(name=keytab, context=krbcontext)
-princ = krbV.Principal(name=principal, context=krbcontext)
-os.environ['KRB5CCNAME'] = ccache_file
-ccache = krbV.CCache(name=ccache_file, context=krbcontext, primary_principal=princ)
-ccache.init(princ)
-ccache.init_creds_keytab(keytab=ktab, principal=princ)
-return ccache_file
-except krbV.Krb5Error, e:
-raise StandardError('Error initializing principal %s in %s: %s' % (principal, keytab, str(e)))
+root_logger.debug(Initializing principal %s using keytab %s
+ % (principal, keytab))
+for attempt in xrange(attempts):
+try:
+krbcontext = krbV.default_context()
+ktab = krbV.Keytab(name=keytab, context=krbcontext)
+princ = krbV.Principal(name=principal, context=krbcontext)
+os.environ['KRB5CCNAME'] = ccache_path
+ccache = krbV.CCache(name=ccache_path, context=krbcontext,
+ primary_principal=princ)
+ccache.init(princ)
+ccache.init_creds_keytab(keytab=ktab, principal=princ)
+root_logger.debug(Attempt %d/%d: success
+ % (attempt + 1, attempts))
+return
+except krbV.Krb5Error, e:
+root_logger.debug(Attempt %d/%d: failed
+ % (attempt + 1, attempts))
+time.sleep(1)
+
+root_logger.debug(Maximum number of attempts (%d) reached
+ % attempts)
+raise StandardError(Error initializing principal %s: %s
+% (principal, str(e)))
+
+
+def kinit_password(principal, password, env={}, armor_ccache=):
+perform interactive kinit as principal using password. Additional
+enviroment variables can be specified using env. If using FAST for
+web-based authentication, use armor_ccache to specify http service ccache.
+
+root_logger.debug(Initializing principal %s using password % principal)
+args = [paths.KINIT, principal]
+if armor_ccache:
+root_logger.debug(Using armor ccache %s for FAST webauth
+ % armor_ccache)
+args.extend(['-T', armor_ccache])
+run(args, env=env, stdin=password)
+
def dn_attribute_property(private_name):
'''
--
2.1.0
From e438d8a0711b4271d24d7d24e98395503912a1c4 Mon Sep 17 00:00:00 2001
From: Martin Babinsky mbabi...@redhat.com
Date: Mon, 9 Mar 2015 12:53:57 +0100
Subject: [PATCH 2/3] ipa-client-install: try to get host TGT several times
before giving up
New option '--kinit-attempts' enables the host to
Re: [Freeipa-devel] Time-based account policies
On Mon, 2015-03-09 at 08:00 +0100, Stanislav Láznička wrote: Hi! My name is Stanislav Laznicka and I am a student at Brno University of Technology. As a part of my Master's thesis, I am supposed to design and implement time-based account policies extensions for FreeIPA and SSSD. While going through the code, I noticed time-based access control was implemented in the past, but it was pulled. I would very much be interested to know why that was and what were the problems with that implementation (so that I don't repeat those again). The solution to the time-based account policies as I see it can be divided into two possible directions - having the time of the policies stored as a UTC time (which is what both Active Directory and 389 Directory Server do), or it can be just a time record that would be compared to the local time of each client. Each of the approaches above has its pros and cons. Basically, local time approach is much more flexible when it comes to multiple time zones, however it does not allow the absolute control of access as the UTC time based approach would (or at least, it does not allow it without some further additions). I would therefore also be interested to hear from you about which of these approaches corresponds more to the common use-case of the FreeIPA system. I would be deeply worried about the unexpected security issues that could arise if local time was used by default. Nathaniel -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [PATCHES 306-316] Automated migration tool from Winsync
Hi, this couple of patches provides a initial implementation of the winsync migration tool: https://fedorahosted.org/freeipa/ticket/4524 Some parts could use some polishing, but this is a sound foundation. Tomas From 9d8f6f2aef6662fcf4cc706a18d7857c34187481 Mon Sep 17 00:00:00 2001 From: Tomas Babej tba...@redhat.com Date: Mon, 2 Mar 2015 16:30:56 +0100 Subject: [PATCH] winsync-migrate: Add initial plumbing --- install/tools/ipa-winsync-migrate | 23 ipaserver/winsync_migrate/__init__.py | 22 ipaserver/winsync_migrate/base.py | 67 +++ 3 files changed, 112 insertions(+) create mode 100755 install/tools/ipa-winsync-migrate create mode 100644 ipaserver/winsync_migrate/__init__.py create mode 100644 ipaserver/winsync_migrate/base.py diff --git a/install/tools/ipa-winsync-migrate b/install/tools/ipa-winsync-migrate new file mode 100755 index ..9eb9a03eb92396c855706e0f85850baece45b27e --- /dev/null +++ b/install/tools/ipa-winsync-migrate @@ -0,0 +1,23 @@ +#! /usr/bin/python2 -E +# Authors: Tomas Babej tba...@redhat.com +# +# Copyright (C) 2015 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/. +# + +from ipaserver.winsync_migrate.base import MigrateWinsync + +MigrateWinsync.run_cli() diff --git a/ipaserver/winsync_migrate/__init__.py b/ipaserver/winsync_migrate/__init__.py new file mode 100644 index ..e0da63db3a369adc4a34e8675471929b5839a812 --- /dev/null +++ b/ipaserver/winsync_migrate/__init__.py @@ -0,0 +1,22 @@ +# Authors: Tomas Babej tba...@redhat.com +# +# Copyright (C) 2015 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/. +# + + +Base subpackage for winsync-migrate related code. + diff --git a/ipaserver/winsync_migrate/base.py b/ipaserver/winsync_migrate/base.py new file mode 100644 index ..c21a861c2e49b4ab6d9783c117d1e4de126cb0b6 --- /dev/null +++ b/ipaserver/winsync_migrate/base.py @@ -0,0 +1,67 @@ +# Authors: Tomas Babej tba...@redhat.com +# +# Copyright (C) 2015 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/. +# + +import krbV +import sys + +from ipalib import api +from ipalib import errors +from ipapython import admintool +from ipapython.dn import DN +from ipapython.ipa_log_manager import log_mgr +from ipaserver.plugins.ldap2 import ldap2 + + +class MigrateWinsync(admintool.AdminTool): + +Tool to migrate winsync users. + + +command_name = 'ipa-migrate-winsync' +usage = ipa-migrate-winsync +description = ( +This tool creates user ID overrides for all the users +that were previously synced from AD domain using the +winsync replication agreement. It requires that trust +with the AD forest has already been established and +the users in question are resolvable using SSSD. +For more information, see `man ipa-migrate-winsync`. +) + +def run(self): +
[Freeipa-devel] [PATCH 0209] Fix logically dead code in ipap11helper module
Patch attached.
--
Martin Basti
From e7412b19bc1e6098181c71d18eba1cb261f3a128 Mon Sep 17 00:00:00 2001
From: Martin Basti mba...@redhat.com
Date: Mon, 9 Mar 2015 13:15:01 +0100
Subject: [PATCH] Fix dead code in ipap11helper module
https://fedorahosted.org/freeipa/ticket/4657
---
ipapython/ipap11helper/p11helper.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/ipapython/ipap11helper/p11helper.c b/ipapython/ipap11helper/p11helper.c
index eff49f5908412eb7b6e4c163710843e64e3bb69b..b05e17da24b94ea16f15f1663dc1dc4c1d683ea4 100644
--- a/ipapython/ipap11helper/p11helper.c
+++ b/ipapython/ipap11helper/p11helper.c
@@ -1320,7 +1320,7 @@ static PyObject *P11_Helper_import_RSA_public_key(P11_Helper *self,
GOTO_FAIL;
}
modulus_len = BN_bn2bin(rsa-n, (unsigned char *) modulus);
-if (modulus == NULL) {
+if (modulus_len == 0) {
PyErr_SetString(ipap11helperError,
import_RSA_public_key: BN_bn2bin modulus error);
GOTO_FAIL;
@@ -1332,7 +1332,7 @@ static PyObject *P11_Helper_import_RSA_public_key(P11_Helper *self,
GOTO_FAIL;
}
exponent_len = BN_bn2bin(rsa-e, (unsigned char *) exponent);
-if (exponent == NULL) {
+if (exponent_len == 0) {
PyErr_SetString(ipap11helperError,
import_RSA_public_key: BN_bn2bin exponent error);
GOTO_FAIL;
@@ -1531,11 +1531,7 @@ static PyObject *P11_Helper_export_wrapped_key(P11_Helper *self,
PyErr_NoMemory();
GOTO_FAIL;
}
-if (wrapped_key == NULL) {
-rv = CKR_HOST_MEMORY;
-if (!check_return_value(rv, key wrapping: buffer allocation))
-GOTO_FAIL;
-}
+
rv = self-p11-C_WrapKey(self-session, wrapping_mech,
object_wrapping_key, object_key, wrapped_key,
wrapped_key_len);
--
2.1.0
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCHES 134-136] extdom: handle ERANGE return code for getXXYYY_r()
On 03/06/2015 01:08 PM, Alexander Bokovoy wrote:
On Thu, 05 Mar 2015, Sumit Bose wrote:
On Thu, Mar 05, 2015 at 09:16:36AM +0100, Sumit Bose wrote:
On Wed, Mar 04, 2015 at 06:14:53PM +0100, Sumit Bose wrote:
On Wed, Mar 04, 2015 at 04:17:55PM +0200, Alexander Bokovoy wrote:
On Mon, 02 Mar 2015, Sumit Bose wrote:
diff --git
a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c
b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c
index
20fdd62b20f28f5384cf83b8be5819f721c6c3db..84aeb28066f25f05a89d0c2d42e8b060e2399501
100644
---
a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c
+++
b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c
@@ -49,6 +49,220 @@
#define MAX(a,b) (((a)(b))?(a):(b))
#define SSSD_DOMAIN_SEPARATOR '@'
+#define MAX_BUF (1024*1024*1024)
+
+
+
+static int get_buffer(size_t *_buf_len, char **_buf)
+{
+long pw_max;
+long gr_max;
+size_t buf_len;
+char *buf;
+
+pw_max = sysconf(_SC_GETPW_R_SIZE_MAX);
+gr_max = sysconf(_SC_GETGR_R_SIZE_MAX);
+
+if (pw_max == -1 gr_max == -1) {
+buf_len = 16384;
+} else {
+buf_len = MAX(pw_max, gr_max);
+}
Here you'd get buf_len equal to 1024 by default on Linux which
is too
low for our use case. I think it would be beneficial to add one
more
MAX(buf_len, 16384):
-if (pw_max == -1 gr_max == -1) {
-buf_len = 16384;
-} else {
-buf_len = MAX(pw_max, gr_max);
-}
+buf_len = MAX(16384, MAX(pw_max, gr_max));
with MAX(MAX(),..) you also get rid of if() statement as resulting
rvalue would be guaranteed to be positive.
done
The rest is going along the common lines but would it be better to
allocate memory once per LDAP client request rather than always
ask for
it per each NSS call? You can guarantee a sequential use of the
buffer
within the LDAP client request processing so there is no problem
with
locks but having this memory re-allocated on subsequent
getpwnam()/getpwuid()/... calls within the same request
processing seems
suboptimal to me.
ok, makes sense, I moved get_buffer() back to the callers.
New version attached.
Please ignore this patch, I will send a revised version soon.
Please find attached a revised version which properly reports missing
objects and out-of-memory cases and makes sure buf and buf_len are in
sync.
ACK to patches 0135 and 0136. This concludes the review, thanks!
Pushed to master: c15a407cbfaed163a933ab137eed16387efe25d2
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] UI plugins
Petr,
Using the information you provided I was able to get things working in a
general sense. I suspect the answer to my next question is going to be
use the source luke... which is cool but I was hoping documentation might
be available which describes adding sections to facets and controlling the
order of additional fields. I have added about a dozen and they don't sort
the way I'd like them to.
Thanks again for your help last week.
Corey
On Mar 6, 2015 7:26 AM, Corey Kovacs corey.kov...@gmail.com wrote:
Sounds great. Just wanted to know if I was going to be reinventing my own
wheel again.
Thanks again.
Corey
On Mar 6, 2015 6:58 AM, Petr Vobornik pvobo...@redhat.com wrote:
On 03/06/2015 02:31 PM, Corey Kovacs wrote:
I almost forgot to ask. Since you don't point it out, I am assuming
(yeah I
know) the plugin code methods have not changed from 3.3 to 4.1? That is
to
day I should be able to use the same techniques?
Same techniques should be applicable, there were no major improvements in
plugin support in 4.1. But Web UI doesn't have any stable API so little
things could be different.
Basically plugins interact with Web UI's core code which is not
perfect(easy to break things) but it's powerful and better than nothing.
Thanks again!
Corey
On Fri, Mar 6, 2015 at 3:51 AM, Petr Vobornik pvobo...@redhat.com
wrote:
On 03/06/2015 03:54 AM, Corey Kovacs wrote:
After reading the extending freeipa training document I was able
successfully add us to meet attributes and add/modify them using the
cli
which was pretty cool. Now that I got the cli out of the way I want to
add
the fields to the ui. Because of the similarities between what I want
to
do
and the example given in the docs I just followed along and changed
variables where it made sense to do so. I cannot however get the new
field
to show up. The Apache logs don't show any errors but they do show the
plugin being read as the page (user details) is loaded. After searching
around I found a document which attempts to explain the process but it
assumes some knowledge held by the reader which I don't possess.
It looks like I supposed to create some sort of index loader which
loads
all of the modules which are part of the plugin. I can't seem to find
any
good documents telling the whole process or least non that I can make
sense
of.
Plugin could be just one file, if the plugin name is myplugin it
has to
be:
/usr/share/ipa/ui/js/plugins/myplugin/myplugin.js
IPA Web UI uses AMD module format:
- https://dojotoolkit.org/documentation/tutorials/1.10/modules/
- http://requirejs.org/docs/whyamd.html#amd
I have some example plugins here:
- https://pvoborni.fedorapeople.org/plugins/
For your case I would look at:
- https://pvoborni.fedorapeople.org/plugins/employeenumber/
employeenumber.js
Web UI basics and introspection:
(this section is little redundant to your question, but it might help
others)
FreeIPA Web UI is semi declarative. That means that part of the pages
could be thrown away, modified or extended by plugins before the page is
constructed. To do that, one has to modify specification object of
particular module.
Here, I would assume that you don't have UI sources(before
minification),
so all introspection will be done in running web ui. Otherwise it's
easier
to inspect sources in install/ui/src/freeipa, i.e. checkout ipa-3-3
branch
from upstream git.
List of modules could be find(after authentication) in browse developer
tools console in object:
window.require.cache
or (depends on IPA version)
window.dojo.config.cache
One can then obtain the module by:
var user_module = require('freeipa/user')
specification object is usually in 'entity_spec' or '$enity_name_spec'
property.
user_module.entity_spec
UI is internally organized into entities. Entity corresponds to ipalib
object. Entity, e.g. user, usually have multiple pages called facets. To
get a list of facets:
user_module.entity_spec.facets
The one with fields has usually a name details. For users it's the
second facet:
var details_facet = user_module.entity_spec.facets[1]
IF i simplify it a bit, we can say that fields on a page are organized
in
sections:
details_facet.sections
Section has fields. A field usually represents an editable element on
page, e.g. a textbox with label, validators and other stuff.
Example of inspection:
https://pvoborni.fedorapeople.org/images/inspect_ui.png
Your goal is to pick a section, or create a new one an add a field
there.
To know what to define, just examine a definition of already existing
field
and just amend name, label, ...
It would help also to understand how to debug such a thing.
In browser developer tools. There is javascript console (use in the
text
above), javascript debugger, network tab for inspecting loaded files.
For developing RHEL 7 plugin, I would suggest you to install test
instance
Re: [Freeipa-devel] Time-based account policies
On Mon, 09 Mar 2015, Martin Kosek wrote:
On 03/09/2015 02:02 PM, Nathaniel McCallum wrote:
On Mon, 2015-03-09 at 08:00 +0100, Stanislav Láznička wrote:
Hi!
My name is Stanislav Laznicka and I am a student at Brno University
of Technology. As a part of my Master's thesis, I am supposed to
design and
implement time-based account policies extensions for FreeIPA and
SSSD.
While going through the code, I noticed time-based access control
was implemented in the past, but it was pulled. I would very much be
interested to know why that was and what were the problems with that
implementation (so that I don't repeat those again).
The solution to the time-based account policies as I see it can be
divided into two possible directions - having the time of the
policies stored as a UTC time (which is what both Active Directory
and 389 Directory Server do), or it can be just a time record that
would be compared to the local time of each client.
Each of the approaches above has its pros and cons. Basically, local
time approach is much more flexible when it comes to multiple time
zones, however it does not allow the absolute control of access as
the UTC time based approach would (or at least, it does not allow it
without
some further additions). I would therefore also be interested to
hear from you about which of these approaches corresponds more to
the common use-case of the FreeIPA system.
I would be deeply worried about the unexpected security issues that
could arise if local time was used by default.
Nathaniel
My comments for the options:
* Control in UTC time: easy to evaluate on client even when user (or anyone
else) misconfigured the time zone. However, implementation is more difficult:
- For rules like person X can interactively log in from 8:00 to 17:00, you
would need separate HBAC rule for each time zone as UTC range would differ
HBAC rules are applied on the client anyway so applying local time
correction is fine in both cases. The problem is then with HBAC rule
testing ('ipa hbactest') which runs on IPA master and would need to gain
ability to handle local time per client too. And this is not an easy
task.
- On the other hand, one can create simple rule person X can use company
resources from 8:00 EST to 17:00 EST, in whichever time zone they are located)
- FreeIPA would need some helper UI (or even zone indication stored with
host/hostgroup) that would help set up the access in local time and save in UTC
time
UI/CLI helpers are smaller issue if we can agree on the basic
functionality.
One of bigger issues we had was lack of versatile ical format parser to
handle calendar-like specification of events -- we need to allow
importing these ones instead of inventing our own.
Another issue is that often rule does depend on a details about specific
service -- it is common to have web services to use different timezone
than the rest of processes running on the server. You would get an HBAC
rule where something like apache service is defined but you'd need to
associate timezone with it and have this association to be specific to a
server or group of servers rather than just a service itself.
--
/ Alexander Bokovoy
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] UI plugins
On 03/09/2015 02:56 PM, Corey Kovacs wrote: Petr, Using the information you provided I was able to get things working in a general sense. I suspect the answer to my next question is going to be use the source luke... which is cool but I was hoping documentation might be available which describes adding sections to facets and controlling the order of additional fields. I have added about a dozen and they don't sort the way I'd like them to. Thanks again for your help last week. The order on the page matches the order in spec object. You can use standard Array.splice method[1] to put new field between two existing ones. [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/splice -- Petr Vobornik -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Time-based account policies
On 03/09/2015 02:02 PM, Nathaniel McCallum wrote: On Mon, 2015-03-09 at 08:00 +0100, Stanislav Láznička wrote: Hi! My name is Stanislav Laznicka and I am a student at Brno University of Technology. As a part of my Master's thesis, I am supposed to design and implement time-based account policies extensions for FreeIPA and SSSD. While going through the code, I noticed time-based access control was implemented in the past, but it was pulled. I would very much be interested to know why that was and what were the problems with that implementation (so that I don't repeat those again). The solution to the time-based account policies as I see it can be divided into two possible directions - having the time of the policies stored as a UTC time (which is what both Active Directory and 389 Directory Server do), or it can be just a time record that would be compared to the local time of each client. Each of the approaches above has its pros and cons. Basically, local time approach is much more flexible when it comes to multiple time zones, however it does not allow the absolute control of access as the UTC time based approach would (or at least, it does not allow it without some further additions). I would therefore also be interested to hear from you about which of these approaches corresponds more to the common use-case of the FreeIPA system. I would be deeply worried about the unexpected security issues that could arise if local time was used by default. Nathaniel My comments for the options: * Control in UTC time: easy to evaluate on client even when user (or anyone else) misconfigured the time zone. However, implementation is more difficult: - For rules like person X can interactively log in from 8:00 to 17:00, you would need separate HBAC rule for each time zone as UTC range would differ - On the other hand, one can create simple rule person X can use company resources from 8:00 EST to 17:00 EST, in whichever time zone they are located) - FreeIPA would need some helper UI (or even zone indication stored with host/hostgroup) that would help set up the access in local time and save in UTC time * Control in local time: difficult to evaluate, potential security issues as Nathaniel mentioned. Implementation and control would be easier though: - One could set up easy rule: person X can interactivelly log in from 8:00 to 17:00 - Easier UI as one would not need to mess with zones, we would assume time zone is set up correctly on each host. So far, it indeed looks like UTC is the way to go. Martin -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCHES 0200-0202] DNS fixes related to unsupported records
On 09/03/15 15:09, Tomas Babej wrote:
On 03/06/2015 01:30 PM, Petr Spacek wrote:
On 4.3.2015 16:35, Martin Basti wrote:
On 04/03/15 16:17, Martin Basti wrote:
Ticket: https://fedorahosted.org/freeipa/ticket/4930
0200: 4.1, master
Fixes traceback, which was raised if LDAP contained a record that
was marked
as unsupported.
Now unsupported records are shown, if LDAP contains them.
0200: 4.1, master
Records marked as unsupported will not show options for editing parts.
0202: only master
Removes NSEC3PARAM record from record types. NSEC3PARAM can contain
only
zone, value is allowed only in idnszone objectclass, so do not
confuse users.
and patches attached :-)
ACK. It works for me and can be pushed to branches 4.1 and master.
Patches require a rebase.
Rebased patch 202 for IPA 4-1 branch
--
Martin Basti
From 65dc9ff7302820e88021d8c4ab34ea7793665256 Mon Sep 17 00:00:00 2001
From: Martin Basti mba...@redhat.com
Date: Wed, 4 Mar 2015 15:13:48 +0100
Subject: [PATCH] DNS: remove NSEC3PARAM from records
NSEC3PARAM is configurable only from zone commands. This patch removes
this record type from DNS records.
Ticket: https://fedorahosted.org/freeipa/ticket/4930
---
API.txt | 12
VERSION | 4 ++--
ipalib/plugins/dns.py | 8 +---
3 files changed, 7 insertions(+), 17 deletions(-)
diff --git a/API.txt b/API.txt
index 10e204564e4e00617cf5e447b481592ed5f6d6d4..d987bc949948a280018f0f20d5af93838ecaeb20 100644
--- a/API.txt
+++ b/API.txt
@@ -805,7 +805,7 @@ output: Entry('result', type 'dict', Gettext('A dictionary representing an LDA
output: Output('summary', (type 'unicode', type 'NoneType'), None)
output: PrimaryKey('value', None, None)
command: dnsrecord_add
-args: 2,101,3
+args: 2,100,3
arg: DNSNameParam('dnszoneidnsname', cli_name='dnszone', multivalue=False, only_absolute=True, primary_key=True, query=True, required=True)
arg: DNSNameParam('idnsname', attribute=True, cli_name='name', multivalue=False, primary_key=True, required=True)
option: Str('a6_part_data', attribute=False, cli_name='a6_data', multivalue=False, option_group=u'A6 Record', required=False)
@@ -876,7 +876,6 @@ option: Str('naptr_part_replacement', attribute=False, cli_name='naptr_replaceme
option: Str('naptr_part_service', attribute=False, cli_name='naptr_service', multivalue=False, option_group=u'NAPTR Record', required=False)
option: NAPTRRecord('naptrrecord', attribute=True, cli_name='naptr_rec', csv=True, multivalue=True, option_group=u'NAPTR Record', required=False)
option: DNSNameParam('ns_part_hostname', attribute=False, cli_name='ns_hostname', multivalue=False, option_group=u'NS Record', required=False)
-option: NSEC3PARAMRecord('nsec3paramrecord', attribute=True, cli_name='nsec3param_rec', csv=True, multivalue=True, option_group=u'NSEC3PARAM Record', required=False)
option: NSEC3Record('nsec3record', attribute=True, cli_name='nsec3_rec', csv=True, multivalue=True, option_group=u'NSEC3 Record', required=False)
option: NSECRecord('nsecrecord', attribute=True, cli_name='nsec_rec', csv=True, multivalue=True, option_group=u'NSEC Record', required=False)
option: NSRecord('nsrecord', attribute=True, cli_name='ns_rec', csv=True, multivalue=True, option_group=u'NS Record', required=False)
@@ -913,7 +912,7 @@ output: Entry('result', type 'dict', Gettext('A dictionary representing an LDA
output: Output('summary', (type 'unicode', type 'NoneType'), None)
output: PrimaryKey('value', None, None)
command: dnsrecord_del
-args: 2,40,3
+args: 2,39,3
arg: DNSNameParam('dnszoneidnsname', cli_name='dnszone', multivalue=False, only_absolute=True, primary_key=True, query=True, required=True)
arg: DNSNameParam('idnsname', attribute=True, cli_name='name', multivalue=False, primary_key=True, query=True, required=True)
option: A6Record('a6record', attribute=True, autofill=False, cli_name='a6_rec', csv=True, multivalue=True, option_group=None, required=False)
@@ -938,7 +937,6 @@ option: KXRecord('kxrecord', attribute=True, autofill=False, cli_name='kx_rec',
option: LOCRecord('locrecord', attribute=True, autofill=False, cli_name='loc_rec', csv=True, multivalue=True, option_group=None, required=False)
option: MXRecord('mxrecord', attribute=True, autofill=False, cli_name='mx_rec', csv=True, multivalue=True, option_group=None, required=False)
option: NAPTRRecord('naptrrecord', attribute=True, autofill=False, cli_name='naptr_rec', csv=True, multivalue=True, option_group=None, required=False)
-option: NSEC3PARAMRecord('nsec3paramrecord', attribute=True, autofill=False, cli_name='nsec3param_rec', csv=True, multivalue=True, option_group=None, required=False)
option: NSEC3Record('nsec3record', attribute=True, autofill=False, cli_name='nsec3_rec', csv=True, multivalue=True, option_group=None, required=False)
option: NSECRecord('nsecrecord', attribute=True, autofill=False, cli_name='nsec_rec', csv=True, multivalue=True, option_group=None, required=False)
option:
Re: [Freeipa-devel] Time-based account policies
On Mon, 09 Mar 2015, Martin Kosek wrote: On 03/09/2015 03:58 PM, Alexander Bokovoy wrote: On Mon, 09 Mar 2015, Martin Kosek wrote: ... One of bigger issues we had was lack of versatile ical format parser to handle calendar-like specification of events -- we need to allow importing these ones instead of inventing our own. Good point. I wonder how rigorous we want to be. iCal is a pretty powerful calendaring format. If we want to implement full support for it, it would be lot of code both on server side for setting it and on client side for evaluating it (CCing Jakub for reference). AD itself has much simpler UI for setting the access time, a table like that: http://www.intelliadmin.com/images/Logon%20Hours%20Windows%20Active%20Directory.jpg IIRC, they only store the bits of can login/cannot login for the time slots. That's another alternative. Another issue is that often rule does depend on a details about specific service -- it is common to have web services to use different timezone than the rest of processes running on the server. You would get an HBAC rule where something like apache service is defined but you'd need to associate timezone with it and have this association to be specific to a server or group of servers rather than just a service itself. HBAC service is mostly only PAM service, not IPA service, so I do not think you can easily store this information. But we can certainly store time zone information in a host or a host group and let that help the hbactest-* or UI... I don't understand why are you involving IPA services here. HBAC rules are only about PAM services and PAM (HBAC) services are specific to hosts where they are in use. We aren't *that* contextual yet because we didn't need that in past but having a timezone info only per host is wrong precisely because every single process on the host can be run under different timezone as it is just a way of interpreting monotone time source data we get from kernel. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] UI plugins
Ahh of course that makes sense. I had made a separate plugin for each field. Thanks again On Mar 9, 2015 8:57 AM, Petr Vobornik pvobo...@redhat.com wrote: On 03/09/2015 02:56 PM, Corey Kovacs wrote: Petr, Using the information you provided I was able to get things working in a general sense. I suspect the answer to my next question is going to be use the source luke... which is cool but I was hoping documentation might be available which describes adding sections to facets and controlling the order of additional fields. I have added about a dozen and they don't sort the way I'd like them to. Thanks again for your help last week. The order on the page matches the order in spec object. You can use standard Array.splice method[1] to put new field between two existing ones. [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/ Reference/Global_Objects/Array/splice -- Petr Vobornik -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Time-based account policies
On 03/09/2015 03:58 PM, Alexander Bokovoy wrote: On Mon, 09 Mar 2015, Martin Kosek wrote: ... One of bigger issues we had was lack of versatile ical format parser to handle calendar-like specification of events -- we need to allow importing these ones instead of inventing our own. Good point. I wonder how rigorous we want to be. iCal is a pretty powerful calendaring format. If we want to implement full support for it, it would be lot of code both on server side for setting it and on client side for evaluating it (CCing Jakub for reference). AD itself has much simpler UI for setting the access time, a table like that: http://www.intelliadmin.com/images/Logon%20Hours%20Windows%20Active%20Directory.jpg IIRC, they only store the bits of can login/cannot login for the time slots. That's another alternative. Another issue is that often rule does depend on a details about specific service -- it is common to have web services to use different timezone than the rest of processes running on the server. You would get an HBAC rule where something like apache service is defined but you'd need to associate timezone with it and have this association to be specific to a server or group of servers rather than just a service itself. HBAC service is mostly only PAM service, not IPA service, so I do not think you can easily store this information. But we can certainly store time zone information in a host or a host group and let that help the hbactest-* or UI... -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Time-based account policies
On Mon, 09 Mar 2015, Jakub Hrozek wrote: On Mon, Mar 09, 2015 at 04:08:46PM +0100, Martin Kosek wrote: On 03/09/2015 03:58 PM, Alexander Bokovoy wrote: On Mon, 09 Mar 2015, Martin Kosek wrote: ... One of bigger issues we had was lack of versatile ical format parser to handle calendar-like specification of events -- we need to allow importing these ones instead of inventing our own. Good point. I wonder how rigorous we want to be. iCal is a pretty powerful calendaring format. If we want to implement full support for it, it would be lot of code both on server side for setting it and on client side for evaluating it (CCing Jakub for reference). AD itself has much simpler UI for setting the access time, a table like that: http://www.intelliadmin.com/images/Logon%20Hours%20Windows%20Active%20Directory.jpg IIRC, they only store the bits of can login/cannot login for the time slots. That's another alternative. I don't think that's what Alexander meant, I don't think the client library should come anywhere close to the iCal format. We might want to provide a script to convert an external format, but that's about it. I thought we could simply reuse parts of the previous grammar, maybe simplified. But I agree with Nathaniel (as I stated also in the private thread) that we should use UTC where possible. Yes and no. Let me go in details a bit. We need iCal support to allow importing events created by external tools. We don't need to use it as internal format. However, there are quite a lot of details that can be lost if only UTC would be in use for a date as you are ignoring a timezone information completely. Timezone information needs to be kept when importing and not always could be reliably represented in UTC so that conversion from one timezone to another could present quite a problem. See http://www.w3.org/TR/timezone/ for some of recommendations. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Time-based account policies
On Mon, 2015-03-09 at 16:17 -0400, John Dennis wrote: On 03/09/2015 03:45 PM, Simo Sorce wrote: We've been through this a few times already, it just doesn't work. At a minimum you need to be able to select between UTC and Local Time and it is a rathole down there (What time is it *here* may be a hard question to answer :-/) O.K. I'll bite, Converting from UTC to local using static UTC offsets is fraught with perils. But if you do the local conversion utilizing the tz (i.e. Olson) database why would be it hard to determine local time? In some cases it may be hard due to external reasons (think travelers and their devices). Another problem is to understand who's timezone to match and how do you know, if a user is connecting via the network and a local time rule is in place, whose local time should that be ? The user or the server's ? Simo. -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Time-based account policies
On Mon, 2015-03-09 at 20:55 +0200, Alexander Bokovoy wrote: On Mon, 09 Mar 2015, Nathaniel McCallum wrote: On Mon, 2015-03-09 at 20:22 +0200, Alexander Bokovoy wrote: On Mon, 09 Mar 2015, Jakub Hrozek wrote: On Mon, Mar 09, 2015 at 04:08:46PM +0100, Martin Kosek wrote: On 03/09/2015 03:58 PM, Alexander Bokovoy wrote: On Mon, 09 Mar 2015, Martin Kosek wrote: ... One of bigger issues we had was lack of versatile ical format parser to handle calendar-like specification of events -- we need to allow importing these ones instead of inventing our own. Good point. I wonder how rigorous we want to be. iCal is a pretty powerful calendaring format. If we want to implement full support for it, it would be lot of code both on server side for setting it and on client side for evaluating it (CCing Jakub for reference). AD itself has much simpler UI for setting the access time, a table like that: http://www.intelliadmin.com/images/Logon%20Hours%20Windows%20Active%20Directory.jpg IIRC, they only store the bits of can login/cannot login for the time slots. That's another alternative. I don't think that's what Alexander meant, I don't think the client library should come anywhere close to the iCal format. We might want to provide a script to convert an external format, but that's about it. I thought we could simply reuse parts of the previous grammar, maybe simplified. But I agree with Nathaniel (as I stated also in the private thread) that we should use UTC where possible. Yes and no. Let me go in details a bit. We need iCal support to allow importing events created by external tools. We don't need to use it as internal format. However, there are quite a lot of details that can be lost if only UTC would be in use for a date as you are ignoring a timezone information completely. Timezone information needs to be kept when importing and not always could be reliably represented in UTC so that conversion from one timezone to another could present quite a problem. See http://www.w3.org/TR/timezone/for some of recommendations. I'm fine with a plan like this. I just want the admin to opt-in to timezones. Localtime *by default* is fraught with pitfalls. If the admin needs local time policy, he should specify it exactly and should confirm the local time on affected systems. Yep. We need to make it easy -- probably by allowing to define timezones as part of host object (like Martin proposed) and overridden in HBAC service/service group. And all this have to be very visual in the UI. Another problem is how to deal with missing timezone information at the place where HBAC rule with time rules would need to be applied. We need to define the way we handle all these (unavailable, non-parsable and other kinds of errors) timezone info issues. I would rather punt, than do some crappy thing ala Windows. Local Only or UTC only is always wrong. For some tasks 'local' is the only thing that makes sense (your morning alarm clock), for other things 'UTC' is the only thing that make sense (coordinated changes across multiple distributed data centers). Implementing just one or the other is not useful. -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Time-based account policies
On Mon, 2015-03-09 at 18:13 +0100, Jakub Hrozek wrote: On Mon, Mar 09, 2015 at 04:08:46PM +0100, Martin Kosek wrote: On 03/09/2015 03:58 PM, Alexander Bokovoy wrote: On Mon, 09 Mar 2015, Martin Kosek wrote: ... One of bigger issues we had was lack of versatile ical format parser to handle calendar-like specification of events -- we need to allow importing these ones instead of inventing our own. Good point. I wonder how rigorous we want to be. iCal is a pretty powerful calendaring format. If we want to implement full support for it, it would be lot of code both on server side for setting it and on client side for evaluating it (CCing Jakub for reference). AD itself has much simpler UI for setting the access time, a table like that: http://www.intelliadmin.com/images/Logon%20Hours%20Windows%20Active%20Directory.jpg IIRC, they only store the bits of can login/cannot login for the time slots. That's another alternative. I don't think that's what Alexander meant, I don't think the client library should come anywhere close to the iCal format. We might want to provide a script to convert an external format, but that's about it. I thought we could simply reuse parts of the previous grammar, maybe simplified. But I agree with Nathaniel (as I stated also in the private thread) that we should use UTC where possible. Simplified == Kinda Broken. We've been through this a few times already, it just doesn't work. At a minimum you need to be able to select between UTC and Local Time and it is a rathole down there (What time is it *here* may be a hard question to answer :-/) Another issue is that often rule does depend on a details about specific service -- it is common to have web services to use different timezone than the rest of processes running on the server. You would get an HBAC rule where something like apache service is defined but you'd need to associate timezone with it and have this association to be specific to a server or group of servers rather than just a service itself. HBAC service is mostly only PAM service, not IPA service, so I do not think you can easily store this information. But we can certainly store time zone information in a host or a host group and let that help the hbactest-* or UI... -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Time-based account policies
On Mon, 2015-03-09 at 22:02 +0200, Alexander Bokovoy wrote: On Mon, 09 Mar 2015, Simo Sorce wrote: On Mon, 2015-03-09 at 20:55 +0200, Alexander Bokovoy wrote: On Mon, 09 Mar 2015, Nathaniel McCallum wrote: On Mon, 2015-03-09 at 20:22 +0200, Alexander Bokovoy wrote: On Mon, 09 Mar 2015, Jakub Hrozek wrote: On Mon, Mar 09, 2015 at 04:08:46PM +0100, Martin Kosek wrote: On 03/09/2015 03:58 PM, Alexander Bokovoy wrote: On Mon, 09 Mar 2015, Martin Kosek wrote: ... One of bigger issues we had was lack of versatile ical format parser to handle calendar-like specification of events -- we need to allow importing these ones instead of inventing our own. Good point. I wonder how rigorous we want to be. iCal is a pretty powerful calendaring format. If we want to implement full support for it, it would be lot of code both on server side for setting it and on client side for evaluating it (CCing Jakub for reference). AD itself has much simpler UI for setting the access time, a table like that: http://www.intelliadmin.com/images/Logon%20Hours%20Windows%20Active%20Directory.jpg IIRC, they only store the bits of can login/cannot login for the time slots. That's another alternative. I don't think that's what Alexander meant, I don't think the client library should come anywhere close to the iCal format. We might want to provide a script to convert an external format, but that's about it. I thought we could simply reuse parts of the previous grammar, maybe simplified. But I agree with Nathaniel (as I stated also in the private thread) that we should use UTC where possible. Yes and no. Let me go in details a bit. We need iCal support to allow importing events created by external tools. We don't need to use it as internal format. However, there are quite a lot of details that can be lost if only UTC would be in use for a date as you are ignoring a timezone information completely. Timezone information needs to be kept when importing and not always could be reliably represented in UTC so that conversion from one timezone to another could present quite a problem. See http://www.w3.org/TR/timezone/forsome of recommendations. I'm fine with a plan like this. I just want the admin to opt- in to timezones. Localtime *by default* is fraught with pitfalls. If the admin needs local time policy, he should specify it exactly and should confirm the local time on affected systems. Yep. We need to make it easy -- probably by allowing to define timezones as part of host object (like Martin proposed) and overridden in HBAC service/service group. And all this have to be very visual in the UI. Another problem is how to deal with missing timezone information at the place where HBAC rule with time rules would need to be applied. We need to define the way we handle all these (unavailable, non-parsable and other kinds of errors) timezone info issues. I would rather punt, than do some crappy thing ala Windows. +1 Local Only or UTC only is always wrong. +1. It was never my intent to imply this. :) For some tasks 'local' is the only thing that makes sense (your morning alarm clock), for other things 'UTC' is the only thing that make sense (coordinated changes across multiple distributed data centers). Implementing just one or the other is not useful. Correct. At this point I think we are more or less in agreement that we need to store time rules in UTC plus timezone correction information specific to the execution context (HBAC rule, host, etc). Handling 'UTC' rule is equivalent to selecting specific timezone (GMT+0, for example) so this is a case of more general (UTC time, timezone definiton) pairs. This timezone definition may have aliases forcing HBAC intepretation to use local machine defaults if needed but the general scheme stays the same. Agreed. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Time-based account policies
On 03/09/2015 03:45 PM, Simo Sorce wrote: We've been through this a few times already, it just doesn't work. At a minimum you need to be able to select between UTC and Local Time and it is a rathole down there (What time is it *here* may be a hard question to answer :-/) O.K. I'll bite, Converting from UTC to local using static UTC offsets is fraught with perils. But if you do the local conversion utilizing the tz (i.e. Olson) database why would be it hard to determine local time? -- John -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Time-based account policies
On Mon, 2015-03-09 at 20:22 +0200, Alexander Bokovoy wrote: On Mon, 09 Mar 2015, Jakub Hrozek wrote: On Mon, Mar 09, 2015 at 04:08:46PM +0100, Martin Kosek wrote: On 03/09/2015 03:58 PM, Alexander Bokovoy wrote: On Mon, 09 Mar 2015, Martin Kosek wrote: ... One of bigger issues we had was lack of versatile ical format parser to handle calendar-like specification of events -- we need to allow importing these ones instead of inventing our own. Good point. I wonder how rigorous we want to be. iCal is a pretty powerful calendaring format. If we want to implement full support for it, it would be lot of code both on server side for setting it and on client side for evaluating it (CCing Jakub for reference). AD itself has much simpler UI for setting the access time, a table like that: http://www.intelliadmin.com/images/Logon%20Hours%20Windows%20Active%20Directory.jpg IIRC, they only store the bits of can login/cannot login for the time slots. That's another alternative. I don't think that's what Alexander meant, I don't think the client library should come anywhere close to the iCal format. We might want to provide a script to convert an external format, but that's about it. I thought we could simply reuse parts of the previous grammar, maybe simplified. But I agree with Nathaniel (as I stated also in the private thread) that we should use UTC where possible. Yes and no. Let me go in details a bit. We need iCal support to allow importing events created by external tools. We don't need to use it as internal format. However, there are quite a lot of details that can be lost if only UTC would be in use for a date as you are ignoring a timezone information completely. Timezone information needs to be kept when importing and not always could be reliably represented in UTC so that conversion from one timezone to another could present quite a problem. See http://www.w3.org/TR/timezone/for some of recommendations. I'm fine with a plan like this. I just want the admin to opt-in to timezones. Localtime *by default* is fraught with pitfalls. If the admin needs local time policy, he should specify it exactly and should confirm the local time on affected systems. Nathaniel -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Time-based account policies
On Mon, 09 Mar 2015, Nathaniel McCallum wrote: On Mon, 2015-03-09 at 20:22 +0200, Alexander Bokovoy wrote: On Mon, 09 Mar 2015, Jakub Hrozek wrote: On Mon, Mar 09, 2015 at 04:08:46PM +0100, Martin Kosek wrote: On 03/09/2015 03:58 PM, Alexander Bokovoy wrote: On Mon, 09 Mar 2015, Martin Kosek wrote: ... One of bigger issues we had was lack of versatile ical format parser to handle calendar-like specification of events -- we need to allow importing these ones instead of inventing our own. Good point. I wonder how rigorous we want to be. iCal is a pretty powerful calendaring format. If we want to implement full support for it, it would be lot of code both on server side for setting it and on client side for evaluating it (CCing Jakub for reference). AD itself has much simpler UI for setting the access time, a table like that: http://www.intelliadmin.com/images/Logon%20Hours%20Windows%20Active%20Directory.jpg IIRC, they only store the bits of can login/cannot login for the time slots. That's another alternative. I don't think that's what Alexander meant, I don't think the client library should come anywhere close to the iCal format. We might want to provide a script to convert an external format, but that's about it. I thought we could simply reuse parts of the previous grammar, maybe simplified. But I agree with Nathaniel (as I stated also in the private thread) that we should use UTC where possible. Yes and no. Let me go in details a bit. We need iCal support to allow importing events created by external tools. We don't need to use it as internal format. However, there are quite a lot of details that can be lost if only UTC would be in use for a date as you are ignoring a timezone information completely. Timezone information needs to be kept when importing and not always could be reliably represented in UTC so that conversion from one timezone to another could present quite a problem. See http://www.w3.org/TR/timezone/for some of recommendations. I'm fine with a plan like this. I just want the admin to opt-in to timezones. Localtime *by default* is fraught with pitfalls. If the admin needs local time policy, he should specify it exactly and should confirm the local time on affected systems. Yep. We need to make it easy -- probably by allowing to define timezones as part of host object (like Martin proposed) and overridden in HBAC service/service group. And all this have to be very visual in the UI. Another problem is how to deal with missing timezone information at the place where HBAC rule with time rules would need to be applied. We need to define the way we handle all these (unavailable, non-parsable and other kinds of errors) timezone info issues. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Time-based account policies
On Mon, 09 Mar 2015, Simo Sorce wrote: On Mon, 2015-03-09 at 20:55 +0200, Alexander Bokovoy wrote: On Mon, 09 Mar 2015, Nathaniel McCallum wrote: On Mon, 2015-03-09 at 20:22 +0200, Alexander Bokovoy wrote: On Mon, 09 Mar 2015, Jakub Hrozek wrote: On Mon, Mar 09, 2015 at 04:08:46PM +0100, Martin Kosek wrote: On 03/09/2015 03:58 PM, Alexander Bokovoy wrote: On Mon, 09 Mar 2015, Martin Kosek wrote: ... One of bigger issues we had was lack of versatile ical format parser to handle calendar-like specification of events -- we need to allow importing these ones instead of inventing our own. Good point. I wonder how rigorous we want to be. iCal is a pretty powerful calendaring format. If we want to implement full support for it, it would be lot of code both on server side for setting it and on client side for evaluating it (CCing Jakub for reference). AD itself has much simpler UI for setting the access time, a table like that: http://www.intelliadmin.com/images/Logon%20Hours%20Windows%20Active%20Directory.jpg IIRC, they only store the bits of can login/cannot login for the time slots. That's another alternative. I don't think that's what Alexander meant, I don't think the client library should come anywhere close to the iCal format. We might want to provide a script to convert an external format, but that's about it. I thought we could simply reuse parts of the previous grammar, maybe simplified. But I agree with Nathaniel (as I stated also in the private thread) that we should use UTC where possible. Yes and no. Let me go in details a bit. We need iCal support to allow importing events created by external tools. We don't need to use it as internal format. However, there are quite a lot of details that can be lost if only UTC would be in use for a date as you are ignoring a timezone information completely. Timezone information needs to be kept when importing and not always could be reliably represented in UTC so that conversion from one timezone to another could present quite a problem. See http://www.w3.org/TR/timezone/for some of recommendations. I'm fine with a plan like this. I just want the admin to opt-in to timezones. Localtime *by default* is fraught with pitfalls. If the admin needs local time policy, he should specify it exactly and should confirm the local time on affected systems. Yep. We need to make it easy -- probably by allowing to define timezones as part of host object (like Martin proposed) and overridden in HBAC service/service group. And all this have to be very visual in the UI. Another problem is how to deal with missing timezone information at the place where HBAC rule with time rules would need to be applied. We need to define the way we handle all these (unavailable, non-parsable and other kinds of errors) timezone info issues. I would rather punt, than do some crappy thing ala Windows. Local Only or UTC only is always wrong. For some tasks 'local' is the only thing that makes sense (your morning alarm clock), for other things 'UTC' is the only thing that make sense (coordinated changes across multiple distributed data centers). Implementing just one or the other is not useful. Correct. At this point I think we are more or less in agreement that we need to store time rules in UTC plus timezone correction information specific to the execution context (HBAC rule, host, etc). Handling 'UTC' rule is equivalent to selecting specific timezone (GMT+0, for example) so this is a case of more general (UTC time, timezone definiton) pairs. This timezone definition may have aliases forcing HBAC intepretation to use local machine defaults if needed but the general scheme stays the same. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0199] Remove unused disable-betxn.ldif file
On 02/25/2015 02:45 PM, Martin Basti wrote: Hello, the file 'disable-betxn.ldif' is not used in code in IPA master branch. There is 10-enable-betxn.update which is used. If I'm right we can remove it. Patch attached. Please correct me if the file is needed. Martin^2 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel IIUC ipa stopped using this file in commit f1f1b4e7f2e9c1838ad7ec76002b78ca0c2a3c46 but it was not removed. Works for me, ACK. -- David Kupka -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] Time-based account policies
Hi! My name is Stanislav Laznicka and I am a student at Brno University of Technology. As a part of my Master's thesis, I am supposed to design and implement time-based account policies extensions for FreeIPA and SSSD. While going through the code, I noticed time-based access control was implemented in the past, but it was pulled. I would very much be interested to know why that was and what were the problems with that implementation (so that I don't repeat those again). The solution to the time-based account policies as I see it can be divided into two possible directions - having the time of the policies stored as a UTC time (which is what both Active Directory and 389 Directory Server do), or it can be just a time record that would be compared to the local time of each client. Each of the approaches above has its pros and cons. Basically, local time approach is much more flexible when it comes to multiple time zones, however it does not allow the absolute control of access as the UTC time based approach would (or at least, it does not allow it without some further additions). I would therefore also be interested to hear from you about which of these approaches corresponds more to the common use-case of the FreeIPA system. Cheers, Standa L. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
