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_administrat...@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@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_administrat...@bsdad.uchicago.edu<mailto:cri-cri_server_administrat...@bsdad.uchicago.edu> > > > to login to any machine > > > Enabled: TRUE > > > User Groups: cri-cri_server_administrators_external, > > > cri-cri_server_administrators_ipa > > > [root@cri-ksysipadcp2 a.cri.dsullivan]# > > > > > > For example, the problem still persists when the policy is configured in > > > this manner: > > > > > > [root@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_administrat...@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_administrat...@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.dsulli...@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.dsulli...@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