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.
Cheers L. ------ The most dangerous phrase in the language is, "We've always done it this way." - Grace Hopper On 15 July 2016 at 10:09, Lachlan Musicman <data...@gmail.com> wrote: > AH. I'm seeing a lot of this now. > > hbac_eval_user_element is returning the wrong number of groups. > > I just found another instance in my logs : > > (Fri Jul 15 08:39:04 2016) [sssd[be[unix.petermac.org.au]]] > [hbac_eval_user_element] (0x1000): [23] groups for [SimpsonLachlan] > > > IPA server > [root@vmpr-linuxidm ~]# id simpsonlach...@petermac.org.au | tr "," "\n" | > wc -l > 41 > > Host > [root@papr-res-galaxy ~]# id simpsonlach...@petermac.org.au | tr "," "\n" > |wc -l > 41 > > > L. > > ------ > The most dangerous phrase in the language is, "We've always done it this > way." > > - Grace Hopper > > On 15 July 2016 at 09:45, Lachlan Musicman <data...@gmail.com> wrote: > >> >> On 14 July 2016 at 17:44, Sumit Bose <sb...@redhat.com> wrote: >> >>> On Thu, Jul 14, 2016 at 11:47:41AM +1000, Lachlan Musicman wrote: >>> > Ok, I have some logs of sssd 1.13.0 not working. Same values as before: >>> > >>> > FreeIPA server: Centos 7, ipa 4.2, API_VERSION 2.156 >>> > >>> > Installed Packages >>> > Name : ipa-server >>> > Arch : x86_64 >>> > Version : 4.2.0 >>> > Release : 15.0.1.el7.centos.17 >>> > Size : 5.0 M >>> > Repo : installed >>> > >From repo : updates >>> > Summary : The IPA authentication server >>> > >>> > >>> > Successfully joined in one way trust to AD. >>> > >>> > Successfully have added hosts (Centos 7, sssd 1.13.0). >>> > >>> > >>> > [root@vmpr-linuxidm ~]# ipa hbacrule-find >>> > -------------------- >>> > 5 HBAC rules matched >>> > -------------------- >>> > >>> > Rule name: allow_all >>> > User category: all >>> > Host category: all >>> > Service category: all >>> > Description: Allow all users to access any host from any host >>> > Enabled: FALSE >>> > >>> > ... >>> > >>> > Rule name: ssh to galaxy >>> > Service category: all >>> > Description: Allows ssh to galaxy server >>> > Enabled: TRUE >>> > User Groups: ad_users >>> > Hosts: papr-res-galaxy.unix.petermac.org.au >>> > >>> > >>> > >>> > >>> > With allow_all HBAC rule enabled, can login every time with >>> > >>> > ssh user@ad_domain@unix_host >>> > >>> > If I implement a HBAC rule "ssh to galaxy" as per above, with: >>> > >>> > ad_users is a POSIX group with a GID. It has one member, the group >>> > >>> > ad_external an external group with a single, external, member >>> > >>> > pmc-res-ipaus...@petermac.org.au >>> > >>> > which is an AD group containing all the users that should have access >>> to >>> > the host. >>> > >>> > >>> > With allow_all disabled and "ssh to galaxy" enabled, some users can >>> login >>> > and some can't. There is no discernable pattern that might explain why >>> some >>> > are discriminated against. >>> > >>> > Here is the test from the server: >>> > >>> > [root@vmpr-linuxidm ~]# ipa hbactest --user= >>> sandsjor...@petermac.org.au >>> > --host=papr-res-galaxy.unix.petermac.org.au --service=sshd >>> > -------------------- >>> > Access granted: True >>> > -------------------- >>> > Matched rules: ssh to galaxy >>> > Not matched rules: Computing Cluster >>> > Not matched rules: FACS Computing >>> > >>> > I've installed ipa-admintools on the host in question and got the same >>> > result. >>> > >>> > To be on the safe side/tick all boxes, I have cleared the cache on the >>> host >>> > in question: >>> > >>> > systemctl stop sssd >>> > sss_cache -E >>> > systemctl start sssd >>> > >>> > and confirmed success with a status check. >>> > >>> > When the user tries to login, it fails. >>> > >>> > Log is here: >>> > >>> > http://dpaste.com/0VAFNPH >>> > >>> > >>> > The top is where the negotiating starts to the best of my knowledge. >>> > >>> > The attempts fails, with no information that is useful to me: >>> > >>> > 230 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]] >>> > [hbac_get_category] (0x0200): Category is set to 'all'. >>> > 231 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]] >>> > [hbac_thost_attrs_to_rule] (0x1000): Processing target hosts for rule >>> [ssh >>> > to galaxy] >>> > 232 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]] >>> > [hbac_shost_attrs_to_rule] (0x0400): Processing source hosts for rule >>> [ssh >>> > to galaxy] >>> > 233 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]] >>> > [hbac_eval_user_element] (0x1000): [3] groups for [ >>> > sandsjor...@petermac.org.au] >>> >>> According to the HBAC evaluation the user is a member of 3 groups. Is >>> this the expected number? >>> >>> Can you check if 'id sandsjor...@petermac.org.au' returns the expected >>> list of groups on the client and the IPA server? (The client does not >>> talk to AD directly only to the IPA server, so if something is already >>> missing on the server it cannot be seen on the client as well). >>> >>> >> No, this is incorrect. He belongs to 14 groups on both the FreeIPA server >> and the host in question. >> >> [root@vmpr-linuxidm ~]# id sandsjor...@petermac.org.au | tr "," "\n" | >> wc -l >> 14 >> >> [root@papr-res-galaxy ~]# id sandsjor...@petermac.org.au | tr "," "\n" | >> wc -l >> 14 >> >> >> >>> Can you send me the SSSD cache file from the client >>> /var/lib/sss/db/cache_unix.petermac.org.au.ldb after the login attempt? >>> Since it might contain password hashes you might want to remove >>> lines with 'cachedPassword' before >>> >>> >> >> Ok, off list. >> >> >> >>> bye, >>> Sumit >>> >>> >
-- 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