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]
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 <data...@gmail.com> 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 <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

Reply via email to