Re: [Freeipa-users] HBAC access denied, all AD groups not detected
On Wed, May 18, 2016 at 11:17:05PM +, Simpson Lachlan wrote: > > -Original Message- > > From: freeipa-users-boun...@redhat.com [mailto:freeipa-users- > > boun...@redhat.com] On Behalf Of Jakub Hrozek > > Sent: Wednesday, 18 May 2016 5:40 PM > > To: freeipa-users@redhat.com > > Subject: Re: [Freeipa-users] HBAC access denied, all AD groups not detected > > > > On Wed, May 18, 2016 at 08:35:14AM +1000, Lachlan Musicman wrote: > > > Hmmm, I also now see > > > > > > https://fedorahosted.org/sssd/ticket/2642 > > > and > > > https://bugzilla.redhat.com/show_bug.cgi?id=1217127 > > > > > > Versions being run: > > > > > > sssd-client-1.13.0-40.el7_2.4.x86_64 > > > sssd-ad-1.13.0-40.el7_2.4.x86_64 > > > sssd-proxy-1.13.0-40.el7_2.4.x86_64 > > > sssd-1.13.0-40.el7_2.4.x86_64 > > > sssd-common-1.13.0-40.el7_2.4.x86_64 > > > sssd-common-pac-1.13.0-40.el7_2.4.x86_64 > > > sssd-ipa-1.13.0-40.el7_2.4.x86_64 > > > sssd-ldap-1.13.0-40.el7_2.4.x86_64 > > > python-sssdconfig-1.13.0-40.el7_2.4.noarch > > > sssd-krb5-common-1.13.0-40.el7_2.4.x86_64 > > > sssd-krb5-1.13.0-40.el7_2.4.x86_64 > > > > > > ipa-server-trust-ad-4.2.0-15.0.1.el7.centos.6.1.x86_64 > > > > The reason I asked about the server versions is > > https://bugzilla.redhat.com/show_bug.cgi?id=1304333 > > > > I'm not too familiar with how the centos versioning works, can you check if > > that > > bug is mentioned in the rpm changelog? > > > "You are not authorized to access bug #1304333." :( > This email (including any attachments or links) may contain > confidential and/or legally privileged information and is > intended only to be read or used by the addressee. If you > are not the intended addressee, any use, distribution, > disclosure or copying of this email is strictly > prohibited. > Confidentiality and legal privilege attached to this email > (including any attachments) are not waived or lost by > reason of its mistaken delivery to you. > If you have received this email in error, please delete it > and notify us immediately by telephone or email. Peter > MacCallum Cancer Centre provides no guarantee that this > transmission is free of virus or that it has not been > intercepted or altered and will not be liable for any delay > in its receipt. Ah, sorry, there must have been some private customer information in the bugzilla. Here is the corresponding upstream ticket: https://fedorahosted.org/freeipa/ticket/5573 -- 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 access denied, all AD groups not detected
> -Original Message- > From: freeipa-users-boun...@redhat.com [mailto:freeipa-users- > boun...@redhat.com] On Behalf Of Jakub Hrozek > Sent: Wednesday, 18 May 2016 5:40 PM > To: freeipa-users@redhat.com > Subject: Re: [Freeipa-users] HBAC access denied, all AD groups not detected > > On Wed, May 18, 2016 at 08:35:14AM +1000, Lachlan Musicman wrote: > > Hmmm, I also now see > > > > https://fedorahosted.org/sssd/ticket/2642 > > and > > https://bugzilla.redhat.com/show_bug.cgi?id=1217127 > > > > Versions being run: > > > > sssd-client-1.13.0-40.el7_2.4.x86_64 > > sssd-ad-1.13.0-40.el7_2.4.x86_64 > > sssd-proxy-1.13.0-40.el7_2.4.x86_64 > > sssd-1.13.0-40.el7_2.4.x86_64 > > sssd-common-1.13.0-40.el7_2.4.x86_64 > > sssd-common-pac-1.13.0-40.el7_2.4.x86_64 > > sssd-ipa-1.13.0-40.el7_2.4.x86_64 > > sssd-ldap-1.13.0-40.el7_2.4.x86_64 > > python-sssdconfig-1.13.0-40.el7_2.4.noarch > > sssd-krb5-common-1.13.0-40.el7_2.4.x86_64 > > sssd-krb5-1.13.0-40.el7_2.4.x86_64 > > > > ipa-server-trust-ad-4.2.0-15.0.1.el7.centos.6.1.x86_64 > > The reason I asked about the server versions is > https://bugzilla.redhat.com/show_bug.cgi?id=1304333 > > I'm not too familiar with how the centos versioning works, can you check if > that > bug is mentioned in the rpm changelog? "You are not authorized to access bug #1304333." :( This email (including any attachments or links) may contain confidential and/or legally privileged information and is intended only to be read or used by the addressee. If you are not the intended addressee, any use, distribution, disclosure or copying of this email is strictly prohibited. Confidentiality and legal privilege attached to this email (including any attachments) are not waived or lost by reason of its mistaken delivery to you. If you have received this email in error, please delete it and notify us immediately by telephone or email. Peter MacCallum Cancer Centre provides no guarantee that this transmission is free of virus or that it has not been intercepted or altered and will not be liable for any delay in its receipt. -- 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 access denied, all AD groups not detected
On Wed, 18 May 2016, Jakub Hrozek wrote: On Wed, May 18, 2016 at 08:35:14AM +1000, Lachlan Musicman wrote: Hmmm, I also now see https://fedorahosted.org/sssd/ticket/2642 and https://bugzilla.redhat.com/show_bug.cgi?id=1217127 Versions being run: sssd-client-1.13.0-40.el7_2.4.x86_64 sssd-ad-1.13.0-40.el7_2.4.x86_64 sssd-proxy-1.13.0-40.el7_2.4.x86_64 sssd-1.13.0-40.el7_2.4.x86_64 sssd-common-1.13.0-40.el7_2.4.x86_64 sssd-common-pac-1.13.0-40.el7_2.4.x86_64 sssd-ipa-1.13.0-40.el7_2.4.x86_64 sssd-ldap-1.13.0-40.el7_2.4.x86_64 python-sssdconfig-1.13.0-40.el7_2.4.noarch sssd-krb5-common-1.13.0-40.el7_2.4.x86_64 sssd-krb5-1.13.0-40.el7_2.4.x86_64 ipa-server-trust-ad-4.2.0-15.0.1.el7.centos.6.1.x86_64 The reason I asked about the server versions is https://bugzilla.redhat.com/show_bug.cgi?id=1304333 I'm not too familiar with how the centos versioning works, can you check if that bug is mentioned in the rpm changelog? No, these packages are not at the level where all known membership bugs were fixed. RHEL 7.2 build should be ipa-4.2.0-15.el7_2.15. A corresponding CentOS build is already available in updates and it is ipa-4.2.0-15.el7.centos.15 -- / 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
Re: [Freeipa-users] HBAC access denied, all AD groups not detected
On Wed, May 18, 2016 at 08:35:14AM +1000, Lachlan Musicman wrote: > Hmmm, I also now see > > https://fedorahosted.org/sssd/ticket/2642 > and > https://bugzilla.redhat.com/show_bug.cgi?id=1217127 > > Versions being run: > > sssd-client-1.13.0-40.el7_2.4.x86_64 > sssd-ad-1.13.0-40.el7_2.4.x86_64 > sssd-proxy-1.13.0-40.el7_2.4.x86_64 > sssd-1.13.0-40.el7_2.4.x86_64 > sssd-common-1.13.0-40.el7_2.4.x86_64 > sssd-common-pac-1.13.0-40.el7_2.4.x86_64 > sssd-ipa-1.13.0-40.el7_2.4.x86_64 > sssd-ldap-1.13.0-40.el7_2.4.x86_64 > python-sssdconfig-1.13.0-40.el7_2.4.noarch > sssd-krb5-common-1.13.0-40.el7_2.4.x86_64 > sssd-krb5-1.13.0-40.el7_2.4.x86_64 > > ipa-server-trust-ad-4.2.0-15.0.1.el7.centos.6.1.x86_64 The reason I asked about the server versions is https://bugzilla.redhat.com/show_bug.cgi?id=1304333 I'm not too familiar with how the centos versioning works, can you check if that bug is mentioned in the rpm changelog? -- 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 access denied, all AD groups not detected
On Wed, May 18, 2016 at 09:46:49AM +1000, Lachlan Musicman wrote: > It's worth noting that, in difference to the bug report: > > 1. We aren't making changes to the overrides. The overrides exist, they > just aren't propagating evenly or consistently. > 2. We are seeing these errors in the various logs: > > > sssd_DOMAIN.log:(Wed May 18 09:00:01 2016) [sssd[be[DOMAIN]]] > [sysdb_delete_group] (0x0400): Error: 2 (No such file or directory) > sssd_DOMAIN.log:(Wed May 18 09:00:01 2016) [sssd[be[DOMAIN]]] > [sysdb_mod_group_member] (0x0400): Error: 2 (No such file or directory) > > > krb5_child.log:(Wed May 18 09:12:30 2016) [[sssd[krb5_child[8929 > [k5c_send_data] (0x0200): Received error code 0 > krb5_child.log:(Wed May 18 09:12:30 2016) [[sssd[krb5_child[8931 > [k5c_send_data] (0x0200): Received error code 1432158214 > > sssd_nss.log:Error: 3, 0, Account info lookup failed > sssd_nss.log:(Wed May 18 09:01:04 2016) [sssd[nss]] [sss_dp_get_reply] > (0x1000): Got reply from Data Provider - DP error code: 3 errno: 22 error > message: Account info lookup failed > sssd_nss.log:Error: 3, 22, Account info lookup failed > sssd_nss.log:(Wed May 18 09:01:04 2016) [sssd[nss]] [sss_dp_get_reply] > (0x1000): Got reply from Data Provider - DP error code: 3 errno: 0 error > message: Account info lookup failed You need to look into the failures in the domain log that happened in the same time as these. Some failures are recoverable, in some other cases we're just reporting failure even if we just didn't match any entry (yes, that a subtle bug we should fix). -- 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 access denied, all AD groups not detected
It's worth noting that, in difference to the bug report: 1. We aren't making changes to the overrides. The overrides exist, they just aren't propagating evenly or consistently. 2. We are seeing these errors in the various logs: sssd_DOMAIN.log:(Wed May 18 09:00:01 2016) [sssd[be[DOMAIN]]] [sysdb_delete_group] (0x0400): Error: 2 (No such file or directory) sssd_DOMAIN.log:(Wed May 18 09:00:01 2016) [sssd[be[DOMAIN]]] [sysdb_mod_group_member] (0x0400): Error: 2 (No such file or directory) krb5_child.log:(Wed May 18 09:12:30 2016) [[sssd[krb5_child[8929 [k5c_send_data] (0x0200): Received error code 0 krb5_child.log:(Wed May 18 09:12:30 2016) [[sssd[krb5_child[8931 [k5c_send_data] (0x0200): Received error code 1432158214 sssd_nss.log:Error: 3, 0, Account info lookup failed sssd_nss.log:(Wed May 18 09:01:04 2016) [sssd[nss]] [sss_dp_get_reply] (0x1000): Got reply from Data Provider - DP error code: 3 errno: 22 error message: Account info lookup failed sssd_nss.log:Error: 3, 22, Account info lookup failed sssd_nss.log:(Wed May 18 09:01:04 2016) [sssd[nss]] [sss_dp_get_reply] (0x1000): Got reply from Data Provider - DP error code: 3 errno: 0 error message: Account info lookup failed cheers L. -- The most dangerous phrase in the language is, "We've always done it this way." - Grace Hopper On 18 May 2016 at 08:35, Lachlan Musicman wrote: > Hmmm, I also now see > > https://fedorahosted.org/sssd/ticket/2642 > and > https://bugzilla.redhat.com/show_bug.cgi?id=1217127 > > Versions being run: > > sssd-client-1.13.0-40.el7_2.4.x86_64 > sssd-ad-1.13.0-40.el7_2.4.x86_64 > sssd-proxy-1.13.0-40.el7_2.4.x86_64 > sssd-1.13.0-40.el7_2.4.x86_64 > sssd-common-1.13.0-40.el7_2.4.x86_64 > sssd-common-pac-1.13.0-40.el7_2.4.x86_64 > sssd-ipa-1.13.0-40.el7_2.4.x86_64 > sssd-ldap-1.13.0-40.el7_2.4.x86_64 > python-sssdconfig-1.13.0-40.el7_2.4.noarch > sssd-krb5-common-1.13.0-40.el7_2.4.x86_64 > sssd-krb5-1.13.0-40.el7_2.4.x86_64 > > ipa-server-trust-ad-4.2.0-15.0.1.el7.centos.6.1.x86_64 > > > -- > The most dangerous phrase in the language is, "We've always done it this > way." > > - Grace Hopper > > On 17 May 2016 at 22:34, Jakub Hrozek wrote: > >> On Tue, May 17, 2016 at 03:08:37PM +1000, Lachlan Musicman wrote: >> > FWIW, >> > >> > We are seeing the issues that are described here: >> > >> > >> https://www.redhat.com/archives/freeipa-users/2015-December/msg00046.html >> > >> > I was about to write when I found this, it explains exactly what I am >> > seeing - right down to the "impossible to reproduce because it's so >> > (seemingly) random". >> > >> > >> > I am about to read up on the SSSD trouble shooting in order to up the >> logs >> > &etc, but here is some output I can share - note that this all happened >> in >> > ~5 minutes. As you can see, clearing the cache has various unpredictable >> > effects. Both users should return the same list of groups. This was >> > performed on a FreeIPA client. >> >> There were some bugs related to external groups, what server and client >> packages version are you running? >> >> -- >> 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 access denied, all AD groups not detected
Hmmm, I also now see https://fedorahosted.org/sssd/ticket/2642 and https://bugzilla.redhat.com/show_bug.cgi?id=1217127 Versions being run: sssd-client-1.13.0-40.el7_2.4.x86_64 sssd-ad-1.13.0-40.el7_2.4.x86_64 sssd-proxy-1.13.0-40.el7_2.4.x86_64 sssd-1.13.0-40.el7_2.4.x86_64 sssd-common-1.13.0-40.el7_2.4.x86_64 sssd-common-pac-1.13.0-40.el7_2.4.x86_64 sssd-ipa-1.13.0-40.el7_2.4.x86_64 sssd-ldap-1.13.0-40.el7_2.4.x86_64 python-sssdconfig-1.13.0-40.el7_2.4.noarch sssd-krb5-common-1.13.0-40.el7_2.4.x86_64 sssd-krb5-1.13.0-40.el7_2.4.x86_64 ipa-server-trust-ad-4.2.0-15.0.1.el7.centos.6.1.x86_64 -- The most dangerous phrase in the language is, "We've always done it this way." - Grace Hopper On 17 May 2016 at 22:34, Jakub Hrozek wrote: > On Tue, May 17, 2016 at 03:08:37PM +1000, Lachlan Musicman wrote: > > FWIW, > > > > We are seeing the issues that are described here: > > > > > https://www.redhat.com/archives/freeipa-users/2015-December/msg00046.html > > > > I was about to write when I found this, it explains exactly what I am > > seeing - right down to the "impossible to reproduce because it's so > > (seemingly) random". > > > > > > I am about to read up on the SSSD trouble shooting in order to up the > logs > > &etc, but here is some output I can share - note that this all happened > in > > ~5 minutes. As you can see, clearing the cache has various unpredictable > > effects. Both users should return the same list of groups. This was > > performed on a FreeIPA client. > > There were some bugs related to external groups, what server and client > packages version are you running? > > -- > 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 access denied, all AD groups not detected
On Tue, May 17, 2016 at 03:08:37PM +1000, Lachlan Musicman wrote: > FWIW, > > We are seeing the issues that are described here: > > https://www.redhat.com/archives/freeipa-users/2015-December/msg00046.html > > I was about to write when I found this, it explains exactly what I am > seeing - right down to the "impossible to reproduce because it's so > (seemingly) random". > > > I am about to read up on the SSSD trouble shooting in order to up the logs > &etc, but here is some output I can share - note that this all happened in > ~5 minutes. As you can see, clearing the cache has various unpredictable > effects. Both users should return the same list of groups. This was > performed on a FreeIPA client. There were some bugs related to external groups, what server and client packages version are you running? -- 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 access denied, all AD groups not detected
FWIW, We are seeing the issues that are described here: https://www.redhat.com/archives/freeipa-users/2015-December/msg00046.html I was about to write when I found this, it explains exactly what I am seeing - right down to the "impossible to reproduce because it's so (seemingly) random". I am about to read up on the SSSD trouble shooting in order to up the logs &etc, but here is some output I can share - note that this all happened in ~5 minutes. As you can see, clearing the cache has various unpredictable effects. Both users should return the same list of groups. This was performed on a FreeIPA client. [root@emts-facs ~]# id "ellul jason" | tr "," "\n" | grep 10 1750673801(external - exchange 2010 us...@petermac.org.au) 10004(bioinf-c...@unix.petermac.org.au) 10005(rcf-st...@unix.petermac.org.au) 10007(cluster-u...@unix.petermac.org.au) 10011(facs-comp...@unix.petermac.org.au) [root@emts-facs ~]# id "simpsonlachlan" | tr "," "\n" | grep 10 1750673801(external - exchange 2010 us...@petermac.org.au) [root@emts-facs ~]# id "ellul jason" | tr "," "\n" | grep 10 1750673801(external - exchange 2010 us...@petermac.org.au) 10007(cluster-u...@unix.petermac.org.au) [root@emts-facs ~]# systemctl stop sssd; sss_cache -E; systemctl start sssd [root@emts-facs ~]# id "simpsonlachlan" | tr "," "\n" | grep 10 1750673801(external - exchange 2010 us...@petermac.org.au) 10004(bioinf-c...@unix.petermac.org.au) 10005(rcf-st...@unix.petermac.org.au) 10007(cluster-u...@unix.petermac.org.au) 10011(facs-comp...@unix.petermac.org.au) [root@emts-facs ~]# id "ellul jason" | tr "," "\n" | grep 10 1750673801(external - exchange 2010 us...@petermac.org.au) 10011(facs-comp...@unix.petermac.org.au) 10004(bioinf-c...@unix.petermac.org.au) 10005(rcf-st...@unix.petermac.org.au) [root@emts-facs ~]# id "simpsonlachlan" | tr "," "\n" | grep 10 1750673801(external - exchange 2010 us...@petermac.org.au) 10004(bioinf-c...@unix.petermac.org.au) 10005(rcf-st...@unix.petermac.org.au) 10007(cluster-u...@unix.petermac.org.au) 10011(facs-comp...@unix.petermac.org.au) [root@emts-facs ~]# id "ellul jason" | tr "," "\n" | grep 10 1750673801(external - exchange 2010 us...@petermac.org.au) 10011(facs-comp...@unix.petermac.org.au) 10004(bioinf-c...@unix.petermac.org.au) 10005(rcf-st...@unix.petermac.org.au) [root@emts-facs ~]# systemctl stop sssd; sss_cache -E; systemctl start sssd [root@emts-facs ~]# id "ellul jason" | tr "," "\n" | grep 10 1750673801(external - exchange 2010 us...@petermac.org.au) 10011(facs-comp...@unix.petermac.org.au) 10004(bioinf-c...@unix.petermac.org.au) 10005(rcf-st...@unix.petermac.org.au) [root@emts-facs ~]# systemctl stop sssd [root@emts-facs ~]# rm -rf /var/lib/sss/db/* [root@emts-facs ~]# systemctl start sssd [root@emts-facs ~]# id "ellul jason" | tr "," "\n" | grep 10 1750673801(external - exchange 2010 us...@petermac.org.au) 10007(cluster-u...@unix.petermac.org.au) [root@emts-facs ~]# id "simpsonlachlan" | tr "," "\n" | grep 10 1750673801(external - exchange 2010 us...@petermac.org.au) 10007(cluster-u...@unix.petermac.org.au) [root@emts-facs ~]# systemctl stop sssd; sss_cache -E; systemctl start sssd [root@emts-facs ~]# id "ellul jason" | tr "," "\n" | grep 10 1750673801(external - exchange 2010 us...@petermac.org.au) [root@emts-facs ~]# id "simpsonlachlan" | tr "," "\n" | grep 10 1750673801(external - exchange 2010 us...@petermac.org.au) 10007(cluster-u...@unix.petermac.org.au) Cheers 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
Re: [Freeipa-users] HBAC access denied, all AD groups not detected
On Tue, Dec 08, 2015 at 04:10:42PM -0600, Sauls, Jeff wrote: > > Jakub Hrozek wrote: > > > > On Mon, Dec 07, 2015 at 02:04:26PM -0600, Sauls, Jeff wrote: > > > > Jakub Hrozek wrote: > > > > > > > > On Fri, Dec 04, 2015 at 02:03:04PM -0600, Sauls, Jeff wrote: > > > > > Hello, > > > > > > > > > > We are having a problem with HBAC that appears to be related to > > > > > group membership lookup. I am testing with a new install on RHEL > > > > > 7.2 with a cross-forest trust with AD. When an AD user attempts > > > > > to log into a client (RH 6.7 or 7.2) the "hbac_eval_user_element" > > > > > can report a different number of groups each time and never seems to > > contain the full list. > > > > > For the testing account, running the 'id' command returns 153 groups. > > > > > The ipa group "ad_admin" has setup to be able to log in anywhere, > > > > > everyone else is denied. With the default allow_all rule enabled, > > > > > everything works as expected. Any ideas on where I can look next? > > > > > > > > I assume the group membership is OK on the server, but not the > > > > client? Can you enable debugging and also include the full logs from > > > > the client after doing sss_cache -E on the client? > > > > > > I've done some more testing and installed a RHEL 6.6 client, the issue > > > doesn't > > occur there since it is not pulling in AD groups, it only shows the single > > POSIX > > group. The server is running 7.2 and I get the same issue logging into it. > > > > To make sure I understand -- the group you expect to be returned on the > > server > > is not either? So there is a consistent failure on the server as well? > > > > (It's important to see where the failure is, the server and the client use > > different methods to obtain the group memberships. The server talks > > directly to > > the AD, the clients talk to the server) > > > > > > > > This is the log section for a login that failed due to "Access denied > > > by HBAC rules" http://pastebin.com/paiBjG96 It shows it failing with 112 > > groups, but I've had it pass at 113 and fail on another user at 66. > > > > > > > > The server and client show the same symptoms. Ah, OK, then it sounds different from the other cases we've seen recently and we need to fix the server first, because the clients read data from the server. If you can catch the failure with logs that update the cache (so sss_cache -E was run before the id attempt), please go ahead and file a bug against sssd. It would also be nice to list what groups are not displayed but should be (or which work intermittently) and describe the hierarchy if possible, at least the part that includes the faulty groups, so we can set a similar environment locally. > If I clear the cache on both and log into each, the number of groups can > change between cache clearings. The only group used in the HBAC rule > "admin-access" is a POSIX group "ad_admins". Ad_admins contains an external > group with the AD user account in it. I can't consistently repeat it nor > find a pattern to the failure. > > After many cache clears and reboots testing with the server, I've managed to > get it into a failure state. After the reboot, I successfully logged in with > the AD account. It showed [113] groups in the log. I logged out and logged > back in with the same account a few minutes later and was denied by HABC > rules, the group count shows [71] for this session. Logging in 30 minutes > later still fails, but show [112] groups now. On the client system, I > cleared the cache and rebooted it, I'm able to log into it with the AD > account and it shows [72] groups in the log. > > -Jeff > > > -- > 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 access denied, all AD groups not detected
> Jakub Hrozek wrote: > > On Mon, Dec 07, 2015 at 02:04:26PM -0600, Sauls, Jeff wrote: > > > Jakub Hrozek wrote: > > > > > > On Fri, Dec 04, 2015 at 02:03:04PM -0600, Sauls, Jeff wrote: > > > > Hello, > > > > > > > > We are having a problem with HBAC that appears to be related to > > > > group membership lookup. I am testing with a new install on RHEL > > > > 7.2 with a cross-forest trust with AD. When an AD user attempts > > > > to log into a client (RH 6.7 or 7.2) the "hbac_eval_user_element" > > > > can report a different number of groups each time and never seems to > contain the full list. > > > > For the testing account, running the 'id' command returns 153 groups. > > > > The ipa group "ad_admin" has setup to be able to log in anywhere, > > > > everyone else is denied. With the default allow_all rule enabled, > > > > everything works as expected. Any ideas on where I can look next? > > > > > > I assume the group membership is OK on the server, but not the > > > client? Can you enable debugging and also include the full logs from > > > the client after doing sss_cache -E on the client? > > > > I've done some more testing and installed a RHEL 6.6 client, the issue > > doesn't > occur there since it is not pulling in AD groups, it only shows the single > POSIX > group. The server is running 7.2 and I get the same issue logging into it. > > To make sure I understand -- the group you expect to be returned on the server > is not either? So there is a consistent failure on the server as well? > > (It's important to see where the failure is, the server and the client use > different methods to obtain the group memberships. The server talks directly > to > the AD, the clients talk to the server) > > > > > This is the log section for a login that failed due to "Access denied > > by HBAC rules" http://pastebin.com/paiBjG96 It shows it failing with 112 > groups, but I've had it pass at 113 and fail on another user at 66. > > > > The server and client show the same symptoms. If I clear the cache on both and log into each, the number of groups can change between cache clearings. The only group used in the HBAC rule "admin-access" is a POSIX group "ad_admins". Ad_admins contains an external group with the AD user account in it. I can't consistently repeat it nor find a pattern to the failure. After many cache clears and reboots testing with the server, I've managed to get it into a failure state. After the reboot, I successfully logged in with the AD account. It showed [113] groups in the log. I logged out and logged back in with the same account a few minutes later and was denied by HABC rules, the group count shows [71] for this session. Logging in 30 minutes later still fails, but show [112] groups now. On the client system, I cleared the cache and rebooted it, I'm able to log into it with the AD account and it shows [72] groups in the log. -Jeff -- 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 access denied, all AD groups not detected
On Mon, Dec 07, 2015 at 02:04:26PM -0600, Sauls, Jeff wrote: > > Jakub Hrozek wrote: > > > > On Fri, Dec 04, 2015 at 02:03:04PM -0600, Sauls, Jeff wrote: > > > Hello, > > > > > > We are having a problem with HBAC that appears to be related to group > > > membership lookup. I am testing with a new install on RHEL 7.2 with a > > > cross-forest trust with AD. When an AD user attempts to log into a > > > client (RH 6.7 or 7.2) the "hbac_eval_user_element" can report a > > > different number of groups each time and never seems to contain the full > > > list. > > > For the testing account, running the 'id' command returns 153 groups. > > > The ipa group "ad_admin" has setup to be able to log in anywhere, > > > everyone else is denied. With the default allow_all rule enabled, > > > everything works as expected. Any ideas on where I can look next? > > > > I assume the group membership is OK on the server, but not the client? Can > > you > > enable debugging and also include the full logs from the client after doing > > sss_cache -E on the client? > > I've done some more testing and installed a RHEL 6.6 client, the issue > doesn't occur there since it is not pulling in AD groups, it only shows the > single POSIX group. The server is running 7.2 and I get the same issue > logging into it. To make sure I understand -- the group you expect to be returned on the server is not either? So there is a consistent failure on the server as well? (It's important to see where the failure is, the server and the client use different methods to obtain the group memberships. The server talks directly to the AD, the clients talk to the server) > > This is the log section for a login that failed due to "Access denied by HBAC > rules" http://pastebin.com/paiBjG96 > It shows it failing with 112 groups, but I've had it pass at 113 and fail on > another user at 66. > > > -- > 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 access denied, all AD groups not detected
> Jakub Hrozek wrote: > > On Fri, Dec 04, 2015 at 02:03:04PM -0600, Sauls, Jeff wrote: > > Hello, > > > > We are having a problem with HBAC that appears to be related to group > > membership lookup. I am testing with a new install on RHEL 7.2 with a > > cross-forest trust with AD. When an AD user attempts to log into a > > client (RH 6.7 or 7.2) the "hbac_eval_user_element" can report a > > different number of groups each time and never seems to contain the full > > list. > > For the testing account, running the 'id' command returns 153 groups. > > The ipa group "ad_admin" has setup to be able to log in anywhere, > > everyone else is denied. With the default allow_all rule enabled, > > everything works as expected. Any ideas on where I can look next? > > I assume the group membership is OK on the server, but not the client? Can you > enable debugging and also include the full logs from the client after doing > sss_cache -E on the client? I've done some more testing and installed a RHEL 6.6 client, the issue doesn't occur there since it is not pulling in AD groups, it only shows the single POSIX group. The server is running 7.2 and I get the same issue logging into it. This is the log section for a login that failed due to "Access denied by HBAC rules" http://pastebin.com/paiBjG96 It shows it failing with 112 groups, but I've had it pass at 113 and fail on another user at 66. -- 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 access denied, all AD groups not detected
On Fri, Dec 04, 2015 at 02:03:04PM -0600, Sauls, Jeff wrote: > Hello, > > We are having a problem with HBAC that appears to be related to group > membership lookup. I am testing with a new install on RHEL 7.2 with a > cross-forest trust with AD. When an AD user attempts to log into a client > (RH 6.7 or 7.2) the "hbac_eval_user_element" can report a different > number of groups each time and never seems to contain the full list. > For the testing account, running the 'id' command returns 153 groups. > The ipa group "ad_admin" has setup to be able to log in anywhere, everyone > else is denied. With the default allow_all rule enabled, everything works > as expected. Any ideas on where I can look next? I assume the group membership is OK on the server, but not the client? Can you enable debugging and also include the full logs from the client after doing sss_cache -E on the client? -- 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 access denied, all AD groups not detected
Hello, We are having a problem with HBAC that appears to be related to group membership lookup. I am testing with a new install on RHEL 7.2 with a cross-forest trust with AD. When an AD user attempts to log into a client (RH 6.7 or 7.2) the "hbac_eval_user_element" can report a different number of groups each time and never seems to contain the full list. For the testing account, running the 'id' command returns 153 groups. The ipa group "ad_admin" has setup to be able to log in anywhere, everyone else is denied. With the default allow_all rule enabled, everything works as expected. Any ideas on where I can look next? Example grep from the client domain log (account had no changes to group membership): (Fri Dec 4 00:46:35 2015) [sssd[be[ipa.domain.com]]] [hbac_eval_user_element] (0x1000): [113] groups for [testu...@ad.domain.com] (Fri Dec 4 00:47:31 2015) [sssd[be[ipa.domain.com]]] [hbac_eval_user_element] (0x1000): [112] groups for [testu...@ad.domain.com] (Fri Dec 4 01:00:20 2015) [sssd[be[ipa.domain.com]]] [hbac_eval_user_element] (0x1000): [72] groups for [testu...@ad.domain.com] (Fri Dec 4 01:10:24 2015) [sssd[be[ipa.domain.com]]] [hbac_eval_user_element] (0x1000): [72] groups for [testu...@ad.domain.com] (Fri Dec 4 01:14:20 2015) [sssd[be[ipa.domain.com]]] [hbac_eval_user_element] (0x1000): [72] groups for [testu...@ad.domain.com] (Fri Dec 4 01:24:21 2015) [sssd[be[ipa.domain.com]]] [hbac_eval_user_element] (0x1000): [72] groups for [testu...@ad.domain.com] (Fri Dec 4 14:27:57 2015) [sssd[be[ipa.domain.com]]] [hbac_eval_user_element] (0x1000): [73] groups for [testu...@ad.domain.com] Example of an HBAC rule passing: (Fri Dec 4 14:27:57 2015) [sssd[be[ipa.domain.com]]] [hbac_eval_user_element] (0x2000): Skipping non-group memberOf [CN=] ... repeated for however many groups happened to be examined (Fri Dec 4 14:27:57 2015) [sssd[be[ipa.domain.com]]] [hbac_eval_user_element] (0x1000): Added group [ad_admins] for user [testu...@ad.domain.com] (Fri Dec 4 14:27:57 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x2469f40 (Fri Dec 4 14:27:57 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x2460080 (Fri Dec 4 14:27:57 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Running timer event 0x2469f40 "ltdb_callback" (Fri Dec 4 14:27:57 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Destroying timer event 0x2460080 "ltdb_timeout" (Fri Dec 4 14:27:57 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Ending timer event 0x2469f40 "ltdb_callback" (Fri Dec 4 14:27:57 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x245aee0 (Fri Dec 4 14:27:57 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x2460080 (Fri Dec 4 14:27:57 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Running timer event 0x245aee0 "ltdb_callback" (Fri Dec 4 14:27:57 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Destroying timer event 0x2460080 "ltdb_timeout" (Fri Dec 4 14:27:57 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Ending timer event 0x245aee0 "ltdb_callback" (Fri Dec 4 14:27:57 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x2469f40 (Fri Dec 4 14:27:57 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x2460080 (Fri Dec 4 14:27:57 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Running timer event 0x2469f40 "ltdb_callback" (Fri Dec 4 14:27:57 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Destroying timer event 0x2460080 "ltdb_timeout" (Fri Dec 4 14:27:57 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Ending timer event 0x2469f40 "ltdb_callback" (Fri Dec 4 14:27:57 2015) [sssd[be[ipa.domain.com]]] [ipa_hbac_evaluate_rules] (0x0080): Access granted by HBAC rule [admin-access] Example of an HBAC rule failing: (Thu Dec 3 22:30:10 2015) [sssd[be[ipa.domain.com]]] [hbac_eval_user_element] (0x2000): Skipping non-group memberOf [CN=] ... repeated for however many groups happened to be examined (Thu Dec 3 22:30:10 2015) [sssd[be[ipa.domain.com]]] [hbac_eval_user_element] (0x2000): Skipping non-group memberOf [CN=] (Thu Dec 3 22:30:10 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x26f8d00 (Thu Dec 3 22:30:10 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x26e18d0 (Thu Dec 3 22:30:10 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Running timer event 0x26f8d00 "ltdb_callback" (Thu Dec 3 22:30:10 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Destroying timer event 0x26e18d0 "ltdb_timeout" (Thu Dec 3 22:30:10 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Ending timer event 0x26f8d00 "ltdb_callback" (Thu Dec 3 22:30:10 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x27e51f0 (Thu Dec 3 22:30:10 2015) [sssd[be[ipa.domain.com]]] [ldb
