[Freeipa-users] IPA HBAC access using SSSD for user in trusted AD domain (RHEL 6.8)

[Sullivan, Daniel [AAA]]

Sumit,

Thank you for getting back to me  I really appreciate you taking the time to help me assess this problem (I am not authorized to view this bug).  In order to test I upgraded to ipa-server 4.2.0-15.el7_2.17 and flushed the cache on both the client and the server; the problem still presents itself. 

I’ve seen some threads around that seem related to what I am experiencing, i.e. 

https://www.redhat.com/archives/freeipa-users/2016-May/msg00354.html

https://www.redhat.com/archives/freeipa-users/2015-December/msg00046.html

Based on my reading I think that the version of the server I upgraded to would have fixed this problem, though (it did not).

Dan Sullivan

> On Jul 13, 2016, at 3:20 AM, Sumit Bose <sbose at redhat.com> wrote:
> 
> On Wed, Jul 13, 2016 at 08:37:44AM +0200, Jakub Hrozek wrote:
>> On Wed, Jul 13, 2016 at 09:10:07AM +0300, Alexander Bokovoy wrote:
>>> On Tue, 12 Jul 2016, Sullivan, Daniel [AAA] wrote:
>>>> Justin,
>>>> 
>>>> I really appreciate you taking the time to respond to me.  This problem
>>>> is driving me crazy and I will certainly take any help I can get. My
>>>> suspicion is that the external user group in the policy below was
>>>> causing the log entry you specified, removing it from the policy does
>>>> not remediate the problem, even after flushing the client cache.
>>>> 
>>>> The way I have this setup is as follows:
>>>> 
>>>> 1) I created a POSIX group in IPA named
>>>> 'cri-cri_server_administrators_ipa' and allowed IPA to assign the GID.
>>>> 2) I created an external group in IPA named
>>>> 'cri-cri_server_administrators_external’ and added the AD group in the
>>>> trusted domain as an external member to this group
>>>> (cri-cri_server_administrators at bsdad.uchicago.edu).
>>>> 3) I added the group cri-cri_server_administrators_external' as a
>>>> member of 'cri-cri_server_administrators_ipa’
>>>> 
>>>> The HBAC rule is configured as (removing the external group does not
>>>> seem to make a difference).
>>>> 
>>>> [root at cri-ksysipadcp2 a.cri.dsullivan]# ipa hbacrule-show 'cri-cri_server_administrators_allow_all'
>>>> Rule name: cri-cri_server_administrators_allow_all
>>>> Host category: all
>>>> Service category: all
>>>> Description: Allow anyone in cri-cri_server_administrators at bsdad.uchicago.edu<mailto:cri-cri_server_administrators at bsdad.uchicago.edu> to login to any machine
>>>> Enabled: TRUE
>>>> User Groups: cri-cri_server_administrators_external, cri-cri_server_administrators_ipa
>>>> [root at cri-ksysipadcp2 a.cri.dsullivan]#
>>>> 
>>>> For example, the problem still persists when the policy is configured in this manner:
>>>> 
>>>> [root at cri-ksysipadcp2 a.cri.dsullivan]# ipa hbacrule-show 'cri-cri_server_administrators_allow_all'
>>>> Rule name: cri-cri_server_administrators_allow_all
>>>> Host category: all
>>>> Service category: all
>>>> Description: Allow anyone in cri-cri_server_administrators at bsdad.uchicago.edu to login to any machine
>>>> Enabled: TRUE
>>>> User Groups: cri-cri_server_administrators_ipa
>>>> 
>>>> And my login validates against the host in question as follows:
>>>> 
>>>> As I said I have this working consistently (i.e. can flush the cash) on
>>>> another host with the same exact version of IPA and SSSD.  Here is a
>>>> validation of hbactest (works with either of the two policy
>>>> configurations above).
>>> I think you problems are related to this snippet of your domain log
>>> where SSSD on IPA client was unable to add membership of your user to
>>> any of these groups:
>>> 
> 
> ...
> 
>>> 
>>> as result, the user is viewed by SSSD on this IPA client as not
>>> belonging to the cri-cri_server_administrators at bsdad.uchicago.edu group
>>> and thus, HBAC rule validation on this client fails.
>> 
>> First, we have some debug messages in this part of sssd that can really
>> use some improvement. That is, some debug messages are expected to
>> report failures and we recover from them later.
>> 
>> But in general Alexander is right. Does 'id
>> a.cri.dsullivan at bsdad.uchicago.edu' report the user as a member of the
>> group that should be allowing access?
>> 
>> If not, I would suggest to run:
>>    1) sss_cache -E on both server and client (don't remove the cache,
>>    please)
>>    2) truncate the logs on server and client
>>    3) run id a.cri.dsullivan at bsdad.uchicago.edu on the client
>> then send us the logs from that single id run..
> 
> If some of the IPA group memberships are missing you might hit
> https://bugzilla.redhat.com/show_bug.cgi?id=1304333 which is not fixed
> in the IPA version you use (ipa-4.2.0-15.el7_2.6.1).
> 
> Mabye upgrading the server helps?
> 
> 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


********************************************************************************
This e-mail is intended only for the use of the individual or entity to which
it is addressed and may contain information that is privileged and confidential.
If the reader of this e-mail message is not the intended recipient, you are 
hereby notified that any dissemination, distribution or copying of this
communication is prohibited. If you have received this e-mail in error, please 
notify the sender and destroy all copies of the transmittal. 

Thank you
University of Chicago Medicine and Biological Sciences 
********************************************************************************