[Freeipa-users] SSSD bug found? FreeIPA vs SSSD

[Lachlan Musicman]

I am still having problems with FreeIPA/HBAC, SSSD and logging into hosts.
Could this be the reason that SSSD isn't picking up the full list of groups
a user belongs to?

In particular, ipa hbac test says true. "id domain\\username" or "id
username at domain" returns the correct groups. But the
sssd_domain.com.log-<date> shows hbac_eval_user_element returning a list of
groups that doesn't include the IPA groups in the HBAC rule? (it does
return the AD group that is the external group that the IPA group would
register as being HBAC true, but not the matching IPA group)

cheers
L.


------
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper

On 9 March 2017 at 20:39, Jakub Hrozek <jhrozek at redhat.com> wrote:

> On Thu, Mar 09, 2017 at 11:32:35AM +0200, Alexander Bokovoy wrote:
> > On to, 09 maalis 2017, Jakub Hrozek wrote:
> > > On Thu, Mar 09, 2017 at 01:37:46PM +1100, Lachlan Musicman wrote:
> > > > Hola,
> > > >
> > > > On CentOS 7.3, using FreeIPA VERSION: 4.4.0, API_VERSION: 2.213 and
> sssd
> > > > (via COPR) 1.15.1, which has a one way trust to an AD domain.
> unix.name.org
> > > > -> name.org
> > > >
> > > > I've seen some interesting behaviour.
> > > >
> > > > Being part of a large organisation with a smaller nix environment
> and a
> > > > larger Windows environment we see all the best of odd AD management
> > > > behaviour (eg spaces in usernames...).
> > > >
> > > > Turns out some of the groups in AD have an @ symbol in them.
> > > >
> > > > The behavioural difference we see is: given userA in group "name @ of
> > > > group" that on the FreeIPA server:
> > > >
> > > > [root at vmpr-freeipa.unix.name.org ~]# id userA at name.org
> > > >
> > > > works as expected.
> > > >
> > > > But on a client
> > > >
> > > > [root at vmpr-linuxclient1.unix.name.org ~]# id userA at name.org
> > > >
> > > > returns nothing.
> > >
> > > Yes, it is a know issue:
> > >    https://pagure.io/SSSD/sssd/issue/3219
> > >
> > > There were some users who reported this works better with a modified
> > > re_expression:
> > >    re_expression = ((?P<name>.+)@(?P<domain>[^@]+$))
> > > but I agree we should fix this by default. However, the fix must be
> done
> > > at both the SSSD level and the IPA extdom plugin, which also searches
> > > for the @-sign in the user and group names.
> > Luckily, a change for extdom plugin seem to be straightforward -- search
> > for the *last* occurence of the domain separator, not the first one. We
> > had a similar issue with nfs idmapd code too.
>
> Yes, the most tricky part would be testing, to make sure the new regular
> expression doesn't break anything. I used the one I showed to unblock
> some RHEL customers that were complaining and were a bit stuck, but I
> didn't have enough time to run all our available tests with it, that's
> why we didn't switch by default..
>
> --
> 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/20170314/d7c2d62d/attachment.htm>