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]] 234 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]] [ipa_hbac_evaluate_rules] (0x0080): Access denied by HBAC rules 235 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 6, <NULL>) [Success (Permission denied)] 236 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]] [be_pam_handler_callback] (0x0100): Sending result [6][petermac.org.au] 237 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]] [be_pam_handler_callback] (0x0100): Sent result [6][petermac.org.au] Cheers L. ------ The most dangerous phrase in the language is, "We've always done it this way." - Grace Hopper On 12 July 2016 at 09:08, Lachlan Musicman <[email protected]> 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... > > 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
