Bug 1002338 - RHEL7 ipa trust getent lookups failing to see AD users
Summary: RHEL7 ipa trust getent lookups failing to see AD users
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: ipa
Version: 7.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Martin Kosek
QA Contact: Namita Soman
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-08-28 23:39 UTC by Scott Poore
Modified: 2013-09-04 17:54 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-08-29 14:41:09 UTC
Target Upstream Version:


Attachments (Terms of Use)
var log files (6.34 MB, application/x-tar)
2013-08-28 23:52 UTC, Scott Poore
no flags Details

Description Scott Poore 2013-08-28 23:39:49 UTC
Description of problem:

After setting up a trust, I'm unable to see users with getent.  wbinfo and kinit work.

[root@rhel7-1 sssd]# kinit aduser1.TEST
Password for aduser1.TEST: 

[root@rhel7-1 sssd]# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: aduser1.TEST

Valid starting       Expires              Service principal
08/28/2013 20:33:33  08/29/2013 06:33:33  krbtgt/AD1.EXAMPLE.TEST.TEST
	renew until 08/29/2013 20:33:30

[root@rhel7-1 sssd]# wbinfo -n 'AD1\aduser1'
S-1-5-21-1111600086-3918383388-1921175064-1109 SID_USER (1)

[root@rhel7-1 sssd]# getent passwd 'AD1\aduser1'
[root@rhel7-1 sssd]# getent passwd aduser1.test
[root@rhel7-1 sssd]# getent passwd aduser1.TEST
[root@rhel7-1 sssd]# 

Version-Release number of selected component (if applicable):
ipa-server-3.3.0-7.el7.x86_64
samba-4.1.0-0.5.rc2.el7.x86_64


How reproducible:
unknown but, seems like it's consistent in my local test env anyway.


Steps to Reproduce:
0.  Setup aduser1 user on AD server
1.  Install IPA Server
2.  yum -y install samba-client samba-winbind-clients \
                ipa-server-trust-ad samba-debuginfo
3.  ipa-adtrust-install --add-sids --netbios-name=$NBNAME -a $ADMINPW -U
4.  ipa dnszone-add $ADdomain --name-server=$ADhost. \
                --admin-email=\"hostmaster@$ADdomain\" --force \
                --forwarder=$ADip --forward-policy=only --ip-address=$ADip
5.  Setup Conditional Forwarder on AD server for IPA domain
6.  echo $ADMINPW | ipa trust-add $ADdomain --admin $ADadmin \
                --range-type=ipa-ad-trust --password
7.  Setup krb5.conf auth_to_local lines:
  auth_to_local = RULE:[1:$1@$0](^.*@AD1.EXAMPLE.TEST$)s/@AD1.EXAMPLE.TEST/@ad1.example.test/
  auth_to_local = DEFAULT
8.  getent passwd 'AD1\aduser1'

Actual results:
nothing returned.

Expected results:
passwd entry returned for aduser1.test 

Additional info:

Comment 2 Scott Poore 2013-08-28 23:52:41 UTC
Created attachment 791551 [details]
var log files

Comment 3 Scott Poore 2013-08-28 23:57:32 UTC
So it's a bit easier to see, here is some sssd_nss.log entries that I think are relevant here:

(Wed Aug 28 18:54:31 2013) [sssd[nss]] [nss_cmd_getbynam] (0x0400): Running command [17] with input [aduser1.test].
(Wed Aug 28 18:54:31 2013) [sssd[nss]] [sss_parse_name_for_domains] (0x0200): name 'aduser1.test' matched expression for domain 'ad1.example.test', user is aduser1
(Wed Aug 28 18:54:31 2013) [sssd[nss]] [nss_cmd_getbynam] (0x0100): Requesting info for [aduser1] from [ad1.example.test]
(Wed Aug 28 18:54:31 2013) [sssd[nss]] [sss_ncache_check_str] (0x2000): Checking negative cache for [NCE/USER/ad1.example.test/aduser1]
(Wed Aug 28 18:54:31 2013) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [aduser1.test]
(Wed Aug 28 18:54:31 2013) [sssd[nss]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x7fd2c128d2f0

(Wed Aug 28 18:54:31 2013) [sssd[nss]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x7fd2c128d420

(Wed Aug 28 18:54:31 2013) [sssd[nss]] [ldb] (0x4000): Running timer event 0x7fd2c128d2f0 "ltdb_callback"

(Wed Aug 28 18:54:31 2013) [sssd[nss]] [ldb] (0x4000): Destroying timer event 0x7fd2c128d420 "ltdb_timeout"

(Wed Aug 28 18:54:31 2013) [sssd[nss]] [ldb] (0x4000): Ending timer event 0x7fd2c128d2f0 "ltdb_callback"

(Wed Aug 28 18:54:31 2013) [sssd[nss]] [sss_dp_issue_request] (0x0400): Issuing request for [0x7fd2bf95ac90:1:aduser1.test]
(Wed Aug 28 18:54:31 2013) [sssd[nss]] [sss_dp_get_account_msg] (0x0400): Creating request for [ad1.example.test][4097][1][name=aduser1]
(Wed Aug 28 18:54:31 2013) [sssd[nss]] [sbus_add_timeout] (0x2000): 0x7fd2c128a750
(Wed Aug 28 18:54:31 2013) [sssd[nss]] [sss_dp_internal_get_send] (0x0400): Entering request [0x7fd2bf95ac90:1:aduser1.test]
(Wed Aug 28 18:54:31 2013) [sssd[nss]] [sbus_remove_timeout] (0x2000): 0x7fd2c128a750
(Wed Aug 28 18:54:31 2013) [sssd[nss]] [sbus_dispatch] (0x4000): dbus conn: 7FD2C1283AD0
(Wed Aug 28 18:54:31 2013) [sssd[nss]] [sbus_dispatch] (0x4000): Dispatching.
(Wed Aug 28 18:54:31 2013) [sssd[nss]] [sss_dp_get_reply] (0x1000): Got reply from Data Provider - DP error code: 3 errno: 11 error message: Account info lookup failed
(Wed Aug 28 18:54:31 2013) [sssd[nss]] [nss_cmd_getby_dp_callback] (0x0040): Unable to get information from Data Provider
Error: 3, 11, Account info lookup failed
Will try to return what we have in cache

Comment 4 Sumit Bose 2013-08-29 12:20:49 UTC
I can see 

[sasl_bind_send] (0x0080): Extended failure message: [SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (Clock skew too great)]

in the sssd logs. Please sync the times on all involved machines and try again.

Comment 5 Scott Poore 2013-08-29 14:23:44 UTC
Arg!   Sorry about that.  I just checked the time on the AD server and had assumed that the timezones matched.  They did not because I had reloaded my AD VM recently.  And, I've been having problems since.  The server apparently built in a different time zone.  This explains why.

So, I changed the timezone and made sure the times matched and everything is working again:

[root@rhel7-1 log]# getent passwd 'AD1\Administrator'
administrator.test:*:1956200500:1956200500:Administrator:/:

So, I think this can be closed as NOTABUG.

Comment 6 Scott Poore 2013-08-29 14:41:09 UTC
Ok, closing as NOTABUG becaues it is known that the time needs to be in sync between the IPA and AD servers/domains.


Note You need to log in before you can comment on or make changes to this bug.