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 <[email protected]> wrote: > > > On Mon, Jul 11, 2016 at 04:55:37PM +1000, Lachlan Musicman wrote: > > > On 11 July 2016 at 16:44, Alexander Bokovoy <[email protected]> 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 [email protected]@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 [email protected] to the external members of > > ad_external > > > >> and that works, but adding the group [email protected] (as > > seen > > > >> in > > > >> `id [email protected]`) 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
