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

[Sullivan, Daniel [AAA]]

Lukas,

Thank you for your reply and inquiry.

First, to answer your question; yes, we have been using the default_domain_suffix for some time.  I am not sure what you mean by previously, but it is currently implemented and has been implemented prior to our 1.13 -> 1.14 upgrade.

And yes, I am assessing a possible software regression at the current moment. It might be related to the default_domain_suffix you are inquiring about.  Basically I am getting inconsistent results on invocation of the id command with specifying the username as ‘username’ or ‘username at fqdn’ on a client running 1.14 against a DC running 1.13 (i.e. no way to reliably invoke id against a trusted domain account).  Sometimes the command will return a result, and sometimes it will not.  Looking at nss debug logs it appears that a duplicate fqdn is being appended to the nss query as show here (as @bsdad.uchicago.edu at bsdad.uchicago.edu<mailto:bsdad.uchicago.edu at bsdad.uchicago.edu>).  This lookup fails.

(Fri Jul 15 06:53:07 2016) [sssd[nss]] [get_dp_name_and_id] (0x0400): Not a LOCAL view, continuing with provided values.
(Fri Jul 15 06:53:07 2016) [sssd[nss]] [sss_dp_issue_request] (0x0400): Issuing request for [0x41e750:1:mjarsulic at bsdad.uchicago.edu<mailto:mjarsulic at bsdad.uchicago.edu>@bsdad.uchicago.edu]
(Fri Jul 15 06:53:07 2016) [sssd[nss]] [sss_dp_get_account_msg] (0x0400): Creating request for [bsdad.uchicago.edu<http://bsdad.uchicago.edu>][0x1][BE_REQ_USER][1][name=mjarsulic at bsdad.uchicago.edu<mailto:name=mjarsulic at bsdad.uchicago.edu>:-]
(Fri Jul 15 06:53:07 2016) [sssd[nss]] [sbus_add_timeout] (0x2000): 0x7d0860
(Fri Jul 15 06:53:07 2016) [sssd[nss]] [sss_dp_internal_get_send] (0x0400): Entering request [0x41e750:1:mjarsulic at bsdad.uchicago.edu<mailto:mjarsulic at bsdad.uchicago.edu>@bsdad.uchicago.edu]
(Fri Jul 15 06:53:07 2016) [sssd[nss]] [sbus_remove_timeout] (0x2000): 0x7d0860
(Fri Jul 15 06:53:07 2016) [sssd[nss]] [sbus_dispatch] (0x4000): dbus conn: 0x7a1730
(Fri Jul 15 06:53:07 2016) [sssd[nss]] [sbus_dispatch] (0x4000): Dispatching.
(Fri Jul 15 06:53:07 2016) [sssd[nss]] [sss_dp_get_reply] (0x1000): Got reply from Data Provider - DP error code: 0 errno: 0 error message: Success
(Fri Jul 15 06:53:07 2016) [sssd[nss]] [sss_ncache_check_str] (0x2000): Checking negative cache for [NCE/USER/bsdad.uchicago.edu/mjarsulic at bsdad.uchicago.edu<mailto:NCE/USER/bsdad.uchicago.edu/mjarsulic at bsdad.uchicago.edu>]
(Fri Jul 15 06:53:07 2016) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [mjarsulic at bsdad.uchicago.edu<mailto:mjarsulic at bsdad.uchicago.edu>]
(Fri Jul 15 06:53:07 2016) [sssd[nss]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x7bb560

Right now I am considering snapshotting our DC, upgrading the sssd to 1.14 on it, flushing the cache on DC and client (both 1.14), and re-testing.

If you have any insight on resolving this issue I’d be interested in hearing your thoughts.

Best,

Dan

On Jul 15, 2016, at 6:13 AM, Lukas Slebodnik <lslebodn at redhat.com<mailto:lslebodn at redhat.com>> wrote:

On (14/07/16 21:23), Sullivan, Daniel [AAA] wrote:
Justin,

Thank you for taking the time to reply to me; I really appreciate your willingness to help.

Upgrading to sssd1.14 (from the copr repo) on the client seems to have fixed this problem across the board.  I don’t have a system that is currently broken to capture this data, but if it is important for you to have the log data to try and resolve this bug I could try to obtain it for you by purposely try to induce the issue by upgrading another system and hoping the bug presents itself, and then capture the data.  Please advise if you would like me to attempt this.

I was really frustrated by this bug and am happy that I can consider this issue resolved.  Please let me know if you would like me to try and capture the data as you described.

I am glad that 1.14 works for you :-)
But there might be other bugs. I know about few regressions.

BTW about the HBAC issue, did you use the default_domain_suffix previously?

LS


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