On Tue, Jul 12, 2016 at 09:08:01AM +1000, Lachlan Musicman wrote:
> Alex, Sumit,
> 
> Which log levels would you recommend for sssd to help debug this issue?
> 
> We've been using 7, but I just realised that it's not an increasing scale
> but bitmasked...

It is both 0-9 is increasing scale while values above 16 are treated as
bitmask. Please just use 9 to get all messages.

bye,
Sumit

> 
> cheers
> L.
> 
> ------
> The most dangerous phrase in the language is, "We've always done it this
> way."
> 
> - Grace Hopper
> 
> On 11 July 2016 at 17:15, Sumit Bose <sb...@redhat.com> wrote:
> 
> > On Mon, Jul 11, 2016 at 04:55:37PM +1000, Lachlan Musicman wrote:
> > > On 11 July 2016 at 16:44, Alexander Bokovoy <aboko...@redhat.com> wrote:
> > >
> > > > On Mon, 11 Jul 2016, Lachlan Musicman wrote:
> > > >
> > > >> Hola,
> > > >>
> > > >> Centos 7, up to date.
> > > >>
> > > >> [root@linuxidm ~]# ipa --version
> > > >> VERSION: 4.2.0, API_VERSION: 2.156
> > > >>
> > > >> One way trust is successfully established, can login with
> > > >>
> > > >> ssh usern...@domain1.com@server1.domain2.com
> > > >>
> > > >> Am testing to get HBAC to work.
> > > >>
> > > >> I've noticed that with the Allow All rule in effect, the following
> > set up
> > > >> is sufficient:
> > > >>
> > > >> add external group "ad_external"
> > > >> add internal group, "ad_internal", add ad_external as a group member
> > of
> > > >> ad_internal
> > > >>
> > > >> AD users can now successfully login to any server.
> > > >>
> > > >> When I tried to set up an HBAC, I couldn't get that set up to work, I
> > > >> needed to complete the extra step of adding AD users explicitly to the
> > > >> "external member" group of the external group.
> >
> > yes, this is expected you either have to add AD users or groups to the
> > external groups.
> >
> > > >>
> > > >> I also note that this seems to be explicitly user based, not group
> > based?
> > > >> IE, I can add lach...@domain1.com to the external members of
> > ad_external
> > > >> and that works, but adding the group server_adm...@domain1.com (as
> > seen
> > > >> in
> > > >> `id lach...@domain1.com`) doesn't allow all members access.
> >
> > Since it looks you are using FreeIPA 4.2 you might hit
> > https://fedorahosted.org/freeipa/ticket/5573 . But SSSD logs, especially
> > the part where the HBAC rules are evaluated would help to understand the
> > issue better.
> >
> > > >>
> > > >> Does that sound correct?
> > > >>
> > > > No, it does not.
> > > > HBAC evaluation and external group merging/resolution is done by SSSD.
> > > > Use https://fedorahosted.org/sssd/wiki/Troubleshooting to produce logs
> > > > that can help understanding what happens there.
> > > >
> > > > What SSSD version do you have on both IPA client and IPA server?
> > >
> > >
> > >
> > > 1.13.0 on both client and server.
> > >
> > > To be honest, we have ratcheted up the logs and it doesn't help that
> > much.
> > > We just got lots of "unsupported PAM command [249]"
> >
> > This is unrelated, I assume this happens when trying to store the hashed
> > password to the cache. This message is remove in newer releases.
> >
> > bye,
> > Sumit
> >
> > >
> > > Cheers
> > > L.
> >
> > > --
> > > 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

-- 
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