On 03/24/2015 08:53 AM, Jan Cholasta wrote:
I have to say I am not very sure about this anymore. Although it would
be a great feature to have users' local time policies, it brings a lot
of traps on the way. The responsibility of keeping the LDAP database
consistent with reality is laid to a 3rd party application. If that
breaks or does not work well, this responsibility might be sometimes
transferred to admin. But if there's a lot of people traveling at a
time... I'm having mixed feelings about this.
Dne 24.3.2015 v 08:40 Martin Kosek napsal(a):
On 03/24/2015 08:20 AM, Jakub Hrozek wrote:
On Tue, Mar 24, 2015 at 08:07:53AM +0100, Martin Kosek wrote:
On 03/24/2015 07:16 AM, Jan Cholasta wrote:
Dne 23.3.2015 v 20:17 Standa Láznička napsal(a):
Given the above, HBAC rules could contain (time, anchor), where
Truth is, it was not really clear to me from the last week's
whose "Local Time" to use - do we use host's or do we use
would make sense to me to use the user's local time. But then you
need to really store at least the timezone information with each
is "UTC", "user local time" or "host local time".
object. And that information should probably change with user moving
between different timezones. That's quite a pickle I am in right
IMO whether to use user or host local time depends on organization
policy, hence my suggestion to support both.
I am bit confused, I would like to make sure we are on the same
regards to Local Time. When the Local Time rule is created, anchor
will be set
to "Local Time". Then SSSD would simply use host's local time, in
time zone the HBAC host is.
Yes, that was my understanding also.
So this is the default host enforcement. For the user, you want to
check authenticated user's entry, to see if there is a timezone
This would of course depend on the information being available. For
you would need to set it in ID Views or similar.
Yes, also in a previous e-mail, there was a suggestion to change
timezones by admin when the user changes timezones -- I didn't like
part, it seems really error prone and tedious. *If* there was this
choice, it should not be the default, rather the default should also be
host local time IMO.
I don't think you can expect host-local time to be good enough for
Host local time zone was the original case I expected. Enforcing
time zone is where this discussion started. Honze proposed making
option - leaving us to 3 different time modes:
* UTC - stored as (time + olson time zone), enforcement is clear
* Host Local Time - stored as (time + Host Local Time), enforcement by
* User Local Time - stored as (time + User Local Time), enforcement
So the rule may be:
* Employee Foo can access web service Bar only in his work hours
IMO, it is realistic for an administrator to set the time zone
setting in the
employee entry. Of course, it gets tricky when the user starts moving
It doesn't have to be the administrator, it can be automated by a 3rd
1. Employee schedules bussiness trip in time management system
2. Manager approves the bussiness trip in the time management system
3. The time management system takes care of changing the employee's
user object timezone when the bussiness trip starts and ends.
Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code