I think the thing that frustrates the most is that id u...@domain.com is
returning correct data on both but they can't login....and I can't even
show that this is the case because now they can login. Difficult to
reproduce :/

------
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper

On 19 July 2016 at 11:13, Lachlan Musicman <data...@gmail.com> wrote:

> Ok, the bad news is that it didn't last. We are still having the same
> problem - HBAC is rejecting users because not all jobs are being discovered
> on the host.
>
> I turned the debug_level up to 10 as requested, but to be honest, it's
> impossible to find anything in the logs because it's so verbose - suddenly
> there are timer events everywhere. I'm going to turn it down to 7 again so
> I can actually parse it.
>
> Cheers
> L.
>
> ------
> The most dangerous phrase in the language is, "We've always done it this
> way."
>
> - Grace Hopper
>
> On 15 July 2016 at 17:56, Jakub Hrozek <jhro...@redhat.com> wrote:
>
>> On Fri, Jul 15, 2016 at 01:07:00PM +1000, Lachlan Musicman wrote:
>> > I've updated all the relevant hosts and the FreeIPA server to the COPR
>> sssd
>> > 1.14.0 release and the problem seems to have disappeared.
>>
>> Great, but please keep an eye on the machine, the 1.14 branch is still
>> kindof fresh and we did a lot of changes.
>>
>> About the HBAC issue, did you use the default_domain_suffix previously?
>>
>> --
>> Manage your subscription for the Freeipa-users mailing list:
>> https://www.redhat.com/mailman/listinfo/freeipa-users
>> Go to http://freeipa.org for more info on the project
>>
>
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Reply via email to