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