[Freeipa-users] HBAC and AD users

[Lachlan Musicman]

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 <datakid at 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 at vmpr-linuxidm ~]# id simpsonlachlan at petermac.org.au | tr "," "\n" |
> wc -l
> 41
>
> Host
> [root at papr-res-galaxy ~]# id simpsonlachlan at 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 <datakid at gmail.com> wrote:
>
>>
>> On 14 July 2016 at 17:44, Sumit Bose <sbose at 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 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]
>>>
>>> According to the HBAC evaluation the user is a member of 3 groups. Is
>>> this the expected number?
>>>
>>> Can you check if 'id SandsJordan at 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 at vmpr-linuxidm ~]# id sandsjordan at petermac.org.au | tr "," "\n" |
>> wc -l
>> 14
>>
>> [root at papr-res-galaxy ~]# id sandsjordan at 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
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20160715/87dc87c0/attachment.htm>