[Freeipa-users] HBAC and AD users

Lachlan Musicman datakid at gmail.com
Thu Jul 14 01:47:41 UTC 2016 

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 at 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 at 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-ipausers at 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 at vmpr-linuxidm ~]# ipa hbactest --user=sandsjordan at 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 [
SandsJordan at 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 <datakid at 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 <sbose at 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 <abokovoy at redhat.com>
>> wrote:
>> >
>> > > On Mon, 11 Jul 2016, Lachlan Musicman wrote:
>> > >
>> > >> Hola,
>> > >>
>> > >> Centos 7, up to date.
>> > >>
>> > >> [root at linuxidm ~]# ipa --version
>> > >> VERSION: 4.2.0, API_VERSION: 2.156
>> > >>
>> > >> One way trust is successfully established, can login with
>> > >>
>> > >> ssh username at 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 lachlan at domain1.com to the external members of
>> ad_external
>> > >> and that works, but adding the group server_admins at domain1.com (as
>> seen
>> > >> in
>> > >> `id lachlan at 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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20160714/bf9a6061/attachment.htm>

More information about the Freeipa-users mailing list