Re: [Freeipa-users] HBAC and AD users

2016-07-20 Thread Lachlan Musicman 
Sure - I've got tomorrow off, so it will be Friday morning.

cheers
L.

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

- Grace Hopper

On 20 July 2016 at 17:14, Jakub Hrozek  wrote:

> On Wed, Jul 20, 2016 at 09:28:06AM +1000, Lachlan Musicman wrote:
> > On 19 July 2016 at 16:40, Jakub Hrozek  wrote:
> >
> > > On Tue, Jul 19, 2016 at 11:26:02AM +1000, Lachlan Musicman wrote:
> > > > I think the thing that frustrates the most is that id
> u...@domain.com is
> > > > returning correct data on both but they can't loginand I can't
> even
> > > > show that this is the case because now they can login. Difficult to
> > > > reproduce :/
> > >
> > > Debugging from HBAC should at least tell you why the rules didn't
> > > match...
> > >
> >
> >
> > Sorry, I should have been clear - the issue is exactly the same. HBAC
> > rejected the user because they weren't in the correct groups, but sssd
> > hadn't got the correct number of groups from the AD server, and had
> missed
> > the group in question.
>
> Do you have the logs from the server and the client? If yes, feel free
> to send them in private mail if they are confidential, I'll try to
> find something in them.
>
> Specifying which groups are missing would help as well.
>
-- 
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

Re: [Freeipa-users] HBAC and AD users

2016-07-20 Thread Jakub Hrozek 
On Wed, Jul 20, 2016 at 09:28:06AM +1000, Lachlan Musicman wrote:
> On 19 July 2016 at 16:40, Jakub Hrozek  wrote:
> 
> > On Tue, Jul 19, 2016 at 11:26:02AM +1000, Lachlan Musicman wrote:
> > > I think the thing that frustrates the most is that id u...@domain.com is
> > > returning correct data on both but they can't loginand I can't even
> > > show that this is the case because now they can login. Difficult to
> > > reproduce :/
> >
> > Debugging from HBAC should at least tell you why the rules didn't
> > match...
> >
> 
> 
> Sorry, I should have been clear - the issue is exactly the same. HBAC
> rejected the user because they weren't in the correct groups, but sssd
> hadn't got the correct number of groups from the AD server, and had missed
> the group in question.

Do you have the logs from the server and the client? If yes, feel free
to send them in private mail if they are confidential, I'll try to
find something in them.

Specifying which groups are missing would help as well.

-- 
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

Re: [Freeipa-users] HBAC and AD users

2016-07-19 Thread Lachlan Musicman 
On 19 July 2016 at 16:40, Jakub Hrozek  wrote:

> On Tue, Jul 19, 2016 at 11:26:02AM +1000, Lachlan Musicman wrote:
> > I think the thing that frustrates the most is that id u...@domain.com is
> > returning correct data on both but they can't loginand I can't even
> > show that this is the case because now they can login. Difficult to
> > reproduce :/
>
> Debugging from HBAC should at least tell you why the rules didn't
> match...
>


Sorry, I should have been clear - the issue is exactly the same. HBAC
rejected the user because they weren't in the correct groups, but sssd
hadn't got the correct number of groups from the AD server, and had missed
the group in question.

This is the user that reported the issue yesterday morning:

[root@vmpr-linuxidm ~]# id "lupat richard"@petermac.org.au | tr "," "\n" |
wc -l
22

Here are the relevant lines from the log.

 (Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[hbac_attrs_to_rule] (0x1000): Processing rule [Computing Cluster]
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[hbac_user_attrs_to_rule] (0x1000): Processing users for rule [Computing
Cluster]
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[hbac_service_attrs_to_rule] (0x1000): Processing PAM services for rule
[Computing Cluster]
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[hbac_thost_attrs_to_rule] (0x1000): Processing target hosts for rule
[Computing Cluster]
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[hbac_shost_attrs_to_rule] (0x0400): Processing source hosts for rule
[Computing Cluster]
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[hbac_eval_user_element] (0x1000): [12] groups for [Lupat Richard]
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x1000): Parsing CN=.Research Bioinformatics Students
Reading Group,OU=Distribution Groups,OU=Research,OU=User Accounts,OU=User
Accounts,DC=petermac,DC=org,DC=au
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x0020): Expected cn in second component, got OU
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x1000): Parsing CN=.Research
Assistants,OU=Distribution Groups,OU=Research,OU=User Accounts,OU=User
Accounts,DC=petermac,DC=org,DC=au
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x0020): Expected cn in second component, got OU
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x1000): Parsing CN=Bioinf-Cluster,OU=Security
Groups,DC=petermac,DC=org,DC=au
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x0020): Expected cn in second component, got OU
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x1000): Parsing CN=External - Exchange 2010
Users,OU=SOE & IT,OU=Security Groups,DC=petermac,DC=org,DC=au
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x0020): Expected cn in second component, got OU
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x1000): Parsing CN=VPN Access - General,OU=Security
Groups,DC=petermac,DC=org,DC=au
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x0020): Expected cn in second component, got OU
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x1000): Parsing CN=.Mac Users,OU=!Exchange
Distribution Groups,OU=User Accounts,DC=petermac,DC=org,DC=au
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x0020): Expected cn in second component, got OU
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x1000): Parsing CN=Bioinf - Team,OU=!Security
Groups,OU=User Accounts,DC=petermac,DC=org,DC=au
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x0020): Expected cn in second component, got OU
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x1000): Parsing CN=.Research
Bioinformatics,OU=!Exchange Distribution Groups,OU=User
Accounts,DC=petermac,DC=org,DC=au
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x0020): Expected cn in second component, got OU
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x1000): Parsing
CN=DM_Outlook_Find,CN=Users,DC=petermac,DC=org,DC=au
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x0020): Expected groups second component, got Users
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x1000): Parsing CN=RES_BioInformatics,OU=Department
Groups,OU=Security Groups,DC=petermac,DC=org,DC=au
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x0020): Expected cn in second component, got OU
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname]

Re: [Freeipa-users] HBAC and AD users

2016-07-19 Thread Jakub Hrozek 
On Tue, Jul 19, 2016 at 11:26:02AM +1000, Lachlan Musicman wrote:
> I think the thing that frustrates the most is that id u...@domain.com is
> returning correct data on both but they can't loginand I can't even
> show that this is the case because now they can login. Difficult to
> reproduce :/

Debugging from HBAC should at least tell you why the rules didn't
match...

-- 
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

Re: [Freeipa-users] HBAC and AD users

2016-07-18 Thread Lachlan Musicman 
I think the thing that frustrates the most is that id u...@domain.com is
returning correct data on both but they can't loginand I can't even
show that this is the case because now they can login. Difficult to
reproduce :/

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

- Grace Hopper

On 19 July 2016 at 11:13, Lachlan Musicman  wrote:

> Ok, the bad news is that it didn't last. We are still having the same
> problem - HBAC is rejecting users because not all jobs are being discovered
> on the host.
>
> I turned the debug_level up to 10 as requested, but to be honest, it's
> impossible to find anything in the logs because it's so verbose - suddenly
> there are timer events everywhere. I'm going to turn it down to 7 again so
> I can actually parse it.
>
> Cheers
> L.
>
> --
> The most dangerous phrase in the language is, "We've always done it this
> way."
>
> - Grace Hopper
>
> On 15 July 2016 at 17:56, Jakub Hrozek  wrote:
>
>> On Fri, Jul 15, 2016 at 01:07:00PM +1000, Lachlan Musicman wrote:
>> > 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.
>>
>> Great, but please keep an eye on the machine, the 1.14 branch is still
>> kindof fresh and we did a lot of changes.
>>
>> About the HBAC issue, did you use the default_domain_suffix previously?
>>
>> --
>> 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

Re: [Freeipa-users] HBAC and AD users

2016-07-18 Thread Lachlan Musicman 
Ok, the bad news is that it didn't last. We are still having the same
problem - HBAC is rejecting users because not all jobs are being discovered
on the host.

I turned the debug_level up to 10 as requested, but to be honest, it's
impossible to find anything in the logs because it's so verbose - suddenly
there are timer events everywhere. I'm going to turn it down to 7 again so
I can actually parse it.

Cheers
L.

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

- Grace Hopper

On 15 July 2016 at 17:56, Jakub Hrozek  wrote:

> On Fri, Jul 15, 2016 at 01:07:00PM +1000, Lachlan Musicman wrote:
> > 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.
>
> Great, but please keep an eye on the machine, the 1.14 branch is still
> kindof fresh and we did a lot of changes.
>
> About the HBAC issue, did you use the default_domain_suffix previously?
>
> --
> 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

Re: [Freeipa-users] HBAC and AD users

2016-07-18 Thread Jakub Hrozek 
On Mon, Jul 18, 2016 at 09:17:06AM +1000, Lachlan Musicman wrote:
> Previously we did have the default_domain_suffix set, but we had to unset
> it. I can't remember why we had to - something to do with
> ownership/permissions and our filesystem (IBM v7000) not playing nice iirc.
> We really wanted to use the dds => the researchers are complaining of
> broken brains due to the new concept of "ssh us...@domain.com@ipa.domain.com".
> I will need to teach ssh config.

OK, in the versions before 1.14 it was quite hard (read: impossible) to
set short names for trusted users on the clients.

On the IDM servers, you should still use long names for output, because
that's what the IPA plugins expect, but on the clients, it should be
possible to set shortnames with the full_name_format.

-- 
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

Re: [Freeipa-users] HBAC and AD users

2016-07-17 Thread Lachlan Musicman 
Previously we did have the default_domain_suffix set, but we had to unset
it. I can't remember why we had to - something to do with
ownership/permissions and our filesystem (IBM v7000) not playing nice iirc.
We really wanted to use the dds => the researchers are complaining of
broken brains due to the new concept of "ssh us...@domain.com@ipa.domain.com".
I will need to teach ssh config.

Cheers
L.



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

- Grace Hopper

On 15 July 2016 at 17:56, Jakub Hrozek  wrote:

> On Fri, Jul 15, 2016 at 01:07:00PM +1000, Lachlan Musicman wrote:
> > 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.
>
> Great, but please keep an eye on the machine, the 1.14 branch is still
> kindof fresh and we did a lot of changes.
>
> About the HBAC issue, did you use the default_domain_suffix previously?
>
> --
> 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

Re: [Freeipa-users] HBAC and AD users

2016-07-15 Thread Jakub Hrozek 
On Fri, Jul 15, 2016 at 01:07:00PM +1000, Lachlan Musicman wrote:
> 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.

Great, but please keep an eye on the machine, the 1.14 branch is still
kindof fresh and we did a lot of changes.

About the HBAC issue, did you use the default_domain_suffix previously?

-- 
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

Re: [Freeipa-users] HBAC and AD users

2016-07-14 Thread 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  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@vmpr-linuxidm ~]# id simpsonlach...@petermac.org.au | tr "," "\n" |
> wc -l
> 41
>
> Host
> [root@papr-res-galaxy ~]# id simpsonlach...@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  wrote:
>
>>
>> On 14 July 2016 at 17:44, Sumit Bose  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@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]
>>>
>>> According to the HBAC evaluation the user is a member of 3 groups. Is
>>> this the expected number?
>>>
>>> Can you check if 'id sandsjor...@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

Re: [Freeipa-users] HBAC and AD users

2016-07-14 Thread Lachlan Musicman 
On 14 July 2016 at 17:44, Sumit Bose  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@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]
>
> According to the HBAC evaluation the user is a member of 3 groups. Is
> this the expected number?
>
> Can you check if 'id sandsjor...@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@vmpr-linuxidm ~]# id sandsjor...@petermac.org.au | tr "," "\n" | wc -l
14

[root@papr-res-galaxy ~]# id sandsjor...@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
>
>
-- 
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

Re: [Freeipa-users] HBAC and AD users

2016-07-14 Thread Sumit Bose 
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@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]

According to the HBAC evaluation the user is a member of 3 groups. Is
this the expected number?

Can you check if 'id sandsjor...@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).

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

bye,
Sumit


> 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, )
> [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  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  wrote:

Re: [Freeipa-users] HBAC and AD users

2016-07-13 Thread Lachlan Musicman 
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, )
[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  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  wrote:
>
>> On Mon, Jul 11, 2016 at 04:55:37PM +1000, Lachlan Musicman wrote:
>> > On 11 July 2016 at 16:44, Alexander Bokovoy 
>> 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
>> > >>

Re: [Freeipa-users] HBAC and AD users

2016-07-12 Thread Sumit Bose 
On Tue, Jul 12, 2016 at 09:08:01AM +1000, Lachlan Musicman 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...

It is both 0-9 is increasing scale while values above 16 are treated as
bitmask. Please just use 9 to get all messages.

bye,
Sumit

> 
> 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  wrote:
> 
> > On Mon, Jul 11, 2016 at 04:55:37PM +1000, Lachlan Musicman wrote:
> > > On 11 July 2016 at 16:44, Alexander Bokovoy  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

-- 
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

Re: [Freeipa-users] HBAC and AD users

2016-07-11 Thread Lachlan Musicman 
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  wrote:

> On Mon, Jul 11, 2016 at 04:55:37PM +1000, Lachlan Musicman wrote:
> > On 11 July 2016 at 16:44, Alexander Bokovoy  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

Re: [Freeipa-users] HBAC and AD users

2016-07-11 Thread Sumit Bose 
On Mon, Jul 11, 2016 at 04:55:37PM +1000, Lachlan Musicman wrote:
> On 11 July 2016 at 16:44, Alexander Bokovoy  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

Re: [Freeipa-users] HBAC and AD users

2016-07-11 Thread Lachlan Musicman 
On 11 July 2016 at 16:44, Alexander Bokovoy  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.
>>
>> 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.
>>
>> 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]"

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

Re: [Freeipa-users] HBAC and AD users

2016-07-11 Thread Alexander Bokovoy 

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.

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.

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?
--
/ Alexander Bokovoy

--
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

[Freeipa-users] HBAC and AD users

2016-07-11 Thread Lachlan Musicman 
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.

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.

Does that sound correct?

L.


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

- Grace Hopper
-- 
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