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 [email protected] | tr "," "\n" | wc -l 41 Host [root@papr-res-galaxy ~]# id [email protected] | 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 <[email protected]> wrote: > > On 14 July 2016 at 17:44, Sumit Bose <[email protected]> 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 >> > >> > [email protected] >> > >> > 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 [email protected] >> > --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 [ >> > [email protected]] >> >> According to the HBAC evaluation the user is a member of 3 groups. Is >> this the expected number? >> >> Can you check if 'id [email protected]' 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 [email protected] | tr "," "\n" | wc > -l > 14 > > [root@papr-res-galaxy ~]# id [email protected] | 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
