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

Wed Jul 13 01:04:52 UTC 2016

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] <
dsullivan2 at 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_administrators at bsdad.uchicago.edu<mailto:
> cri-cri_server_administrators at 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 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<mailto:
> 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).
>
> [root at cri-ksysipadcp2 a.cri.dsullivan]# ipa hbactest
> User name: a.cri.dsullivan at bsdad.uchicago.edu<mailto:
> a.cri.dsullivan at bsdad.uchicago.edu>
> Target host: 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 at cri-ksysipadcp2 a.cri.dsullivan]#
>
> Thank you again for your response.
>
> Best,
>
> Dan
>
> On Jul 12, 2016, at 4:12 PM, Justin Stephenson <jstephen at redhat.com
> <mailto:jstephen at 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>]]] [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-users@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 for more info on the project
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20160713/009273d7/attachment.htm>