Hi, Lachlan,

Yes, I see that from here 
(https://www.redhat.com/archives/freeipa-users/2016-May/msg00322.html).  
Unfortunately clearing the cache and restarting SSSD is not proving to help us. 
 Iā€™d be interested to know any progress you make on this issue.

Thank you for responding to me.

Best,

Dan Sullivan


On Jul 12, 2016, at 8:04 PM, Lachlan Musicman 
<data...@gmail.com<mailto:data...@gmail.com>> wrote:

This is exactly the issue I'm seeing too, various differences, but the symptoms 
are the same.

Main diff would be that sometimes stopping sssd, clearing cache and restarting 
sssd works, but only if individual AD domain members are added to the external 
group - not AD domain groups.

Cheers
L.

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

- Grace Hopper

On 13 July 2016 at 08:07, Sullivan, Daniel [AAA] 
<dsulliv...@bsd.uchicago.edu<mailto:dsulliv...@bsd.uchicago.edu>> 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<https://cri-ksysipadcp2.cri.uchicago.edu/ipa/ui/#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<https://cri-ksysipadcp2.cri.uchicago.edu/ipa/ui/#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<mailto:cri-cri_server_administrat...@bsdad.uchicago.edu><mailto:cri-cri_server_administrat...@bsdad.uchicago.edu<mailto:cri-cri_server_administrat...@bsdad.uchicago.edu>>).
3) I added the group 
cri-cri_server_administrators_external<https://cri-ksysipadcp2.cri.uchicago.edu/ipa/ui/#cri-cri_server_administrators_external>
 as a member of 
'cri-cri_server_administrators_ipa<https://cri-ksysipadcp2.cri.uchicago.edu/ipa/ui/#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><mailto: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<mailto:cri-cri_server_administrat...@bsdad.uchicago.edu><mailto: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_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).

[root@cri-ksysipadcp2 a.cri.dsullivan]# ipa hbactest
User name: 
a.cri.dsulli...@bsdad.uchicago.edu<mailto:a.cri.dsulli...@bsdad.uchicago.edu><mailto:a.cri.dsulli...@bsdad.uchicago.edu<mailto:a.cri.dsulli...@bsdad.uchicago.edu>>
Target host: 
cri-kcriwebgdp1.cri.uchicago.edu<http://cri-kcriwebgdp1.cri.uchicago.edu/><http://cri-kcriwebgdp1.cri.uchicago.edu<http://cri-kcriwebgdp1.cri.uchicago.edu/>>
Service: sshd
--------------------
Access granted: True
--------------------
  Matched rules: cri-cri_server_administrators_allow_all
  Not matched rules: cri-hpc_server_administration
  Not matched rules: Gardner_cluster_login_no_ssh
  Not matched rules: s.cri.ipa-idprovisioner_domain_controllers
[root@cri-ksysipadcp2 a.cri.dsullivan]#

Thank you again for your response.

Best,

Dan

On Jul 12, 2016, at 4:12 PM, Justin Stephenson 
<jstep...@redhat.com<mailto:jstep...@redhat.com><mailto:jstep...@redhat.com<mailto:jstep...@redhat.com>>>
 wrote:


Hello,

I am assuming this is the AD trust user that is having the problem with HBAC, 
in my testing I was only allowed access when the HBAC rule is linked to the IDM 
POSIX AD trust group and not the external group used to retrieve AD trust 
users. I noticed the following in the logs which is why I mention this:

(Tue Jul 12 13:30:12 2016) 
[sssd[be[ipa.cri.uchicago.edu<http://ipa.cri.uchicago.edu/><http://ipa.cri.uchicago.edu<http://ipa.cri.uchicago.edu/>>]]]
 [hbac_user_attrs_to_rule] (0x2000): Added non-POSIX group 
[cri-cri_server_administrators_external] to rule 
[cri-cri_server_administrators_allow_all]

If this does not help, could you share with us more about the HBAC rule 
'cri-cri_server_administrators_allow_all' and how it is configured?

        # ipa hbacrule-show 'cri-cri_server_administrators_allow_all'

Kind regards,

Justin Stephenson

On 07/12/2016 04:11 PM, Sullivan, Daniel [AAA] wrote:

Hi,

I am experiencing an HBAC issue that is proving to be very difficult to 
diagnose.  It appears very closely related to the issue described in this 
thread 
(https://lists.fedorahosted.org/archives/list/sssd-us...@lists.fedorahosted.org/thread/DTX4LP5VI2AHANMT4QFXERCN7US2TCUB/),
 except that clearing the cache does not fix the problem.  I am further stumped 
by the fact that I have an additional machine that was deployed from an 
identical VMWare template image which IPA HBAC works correctly on.  From a 
client perspective I am working with a fully updated version of RHEL 6.8 with 
ipa-client 3.0.0-50.el6.1 and sssd 1.13.3-22.el6.  We have a domain with 2 IPA 
domain controllers (RHEL 7.2 and ipa-server 4.2.0-15.el7_2.6.1); I have since 
shut down one of the two domain controllers and cleared the cache 
(/var/lib/sssd/db/*) on both clients and restarted sssd (to isolate a potential 
replication problem between DCs); the HBAC rule validates correctly on the only 
remaining DC (basically an!
  any any rule). HBAC (the ability to login via sshd) continues to work on only 
one of the two clients.

>From what I can tell, both clients have the same version of all ipa-client and 
>sssd (and presumably related packages as both clients are fully updated). I 
>have compared their /etc/sshd/sshd_config, /etc/sssd/sssd.conf and all 
>configurations in /etc/pam.d and both systems appear consistent.

I feel that it is worthwhile to mention that I believe that one of the two 
machines in question (the one that is not working) was bound as a CentrifyDC 
client.  We are planning on replacing CentrifyDC with FreeIPA (for several 
reasons), so it is important that we are able to take an existing CentrifyDC 
client, unbind it, uninstall the CentrifyDC package(s), and install FreeIPA in 
its place.  Regardless of whether CentrifyDC was previously installed, I feel 
that my somewhat thorough examination of /etc/sshd/sshd_config and the contents 
of /etc/pam.d would negate any potential residual configuration from Centrify 
that would cause this sort of problem.  I have posted my domain log here: 
http://pastebin.com/41KeSnq4

It is also probably worthwhile to mention that I am authenticating as a user in 
a trusted domain, although I believe this should be apparent in the the 
pastebin.

I am hoping that a subject matter expert in IPA and or SSSD would be able to 
help me further diagnose the access denied by HBAC entry that is present in the 
pastebin specified above.  As I said, I have cleared /var/lib/sss/db/* and 
reinstalled IPA-client several times.  I have also rebooted the system 
completely.

Thank you for considering helping me; I appreciate your time and expertise.

Best,

Dan




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




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

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org<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


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

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

Reply via email to