On Fri, Sep 23, 2016 at 06:52:17AM +0000, Ondrej Valousek wrote:
Here is the example (full log):
I think it's a bug..
(Thu Sep 22 13:35:41 2016) [sssd[be[default]]] [sdap_search_user_next_base] (0x0400):
Searching for users with base [DC=mydomain,DC=com]
(Thu Sep 22 13:35:41 2016) [sssd[be[default]]] [sdap_print_server] (0x2000): Searching
192.168.128.4
Can you check what is this server? Is it the server that handles
dc=mydomain,dc=com? (So, presumably, a DC in the
mydomain.com domain) or
a server from another domain?
In general when a user is requested from some domain (
mydomain.com), we
try to find a corresponding sdap_domain structure that contains the
search base of this domain (dc=mydomain,dc=com). I think in your case
this logic might have gone wrong.
> (Thu Sep 22 13:35:41 2016) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x0400):
calling ldap_search_ext with
[(&(uid=nigels)(objectclass=user)(uid=*)(&(uidNumber=*)(!(uidNumber=0))))][DC=mydomain,DC=com].
> (Thu Sep 22 13:35:41 2016) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000):
Requesting attrs: [objectClass]
> (Thu Sep 22 13:35:41 2016) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000):
Requesting attrs: [uid]
> (Thu Sep 22 13:35:41 2016) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000):
Requesting attrs: [unixUserPassword]
> (Thu Sep 22 13:35:41 2016) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000):
Requesting attrs: [uidNumber]
> (Thu Sep 22 13:35:41 2016) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000):
Requesting attrs: [gidNumber]
> (Thu Sep 22 13:35:41 2016) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000):
Requesting attrs: [gecos]
> (Thu Sep 22 13:35:41 2016) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000):
Requesting attrs: [unixHomeDirectory]
> (Thu Sep 22 13:35:41 2016) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000):
Requesting attrs: [loginShell]
> (Thu Sep 22 13:35:41 2016) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000):
Requesting attrs: [userPrincipalName]
> (Thu Sep 22 13:35:41 2016) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000):
Requesting attrs: [name]
> (Thu Sep 22 13:35:41 2016) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000):
Requesting attrs: [memberOf]
> (Thu Sep 22 13:35:41 2016) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000):
Requesting attrs: [objectGUID]
> (Thu Sep 22 13:35:41 2016) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000):
Requesting attrs: [objectSID]
> (Thu Sep 22 13:35:41 2016) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000):
Requesting attrs: [primaryGroupID]
> (Thu Sep 22 13:35:41 2016) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000):
Requesting attrs: [whenChanged]
> (Thu Sep 22 13:35:41 2016) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000):
Requesting attrs: [uSNChanged]
> (Thu Sep 22 13:35:41 2016) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000):
Requesting attrs: [accountExpires]
> (Thu Sep 22 13:35:41 2016) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000):
Requesting attrs: [userAccountControl]
> (Thu Sep 22 13:35:41 2016) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x2000):
ldap_search_ext called, msgid = 29
> (Thu Sep 22 13:35:41 2016) [sssd[be[default]]] [sdap_op_add] (0x2000): New operation
29 timeout 6
> (Thu Sep 22 13:35:41 2016) [sssd[be[default]]] [sdap_process_result] (0x2000): Trace:
sh[0x638ad80], connected[1], ops[0x638b640], ldap[0x6386ef0]
> (Thu Sep 22 13:35:41 2016) [sssd[be[default]]] [sdap_process_message] (0x4000):
Message type: [LDAP_RES_SEARCH_RESULT]
> (Thu Sep 22 13:35:41 2016) [sssd[be[default]]] [sdap_get_generic_op_finished]
(0x0400): Search result: Referral(10), 0000202B: RefErr: DSID-03100781, data 0, 1 access
points
> ref 1: 'mydomain.com'
>
> (Thu Sep 22 13:35:41 2016) [sssd[be[default]]] [sdap_get_generic_ext_add_references]
(0x1000): Additional References:
ldap://mydomain.com/DC=mydomain,DC=com
> (Thu Sep 22 13:35:41 2016) [sssd[be[default]]] [sdap_op_destructor] (0x2000):
Operation 29 finished
> (Thu Sep 22 13:35:41 2016) [sssd[be[default]]] [generic_ext_search_handler] (0x4000):
Request included referrals which were ignored.
> (Thu Sep 22 13:35:41 2016) [sssd[be[default]]] [generic_ext_search_handler] (0x4000):
Ref:
ldap://mydomain.com/DC=mydomain,DC=com
> (Thu Sep 22 13:35:41 2016) [sssd[be[default]]] [sdap_search_user_process] (0x0400):
Search for users, returned 0 results.
> (Thu Sep 22 13:35:41 2016) [sssd[be[default]]] [sdap_get_users_done] (0x0040): Failed
to retrieve users
> (Thu Sep 22 13:35:41 2016) [sssd[be[default]]] [sdap_id_op_done] (0x4000): releasing
operation connection
>
> -----Original Message-----
> From: Jakub Hrozek [mailto:jhrozek@redhat.com]
> Sent: Thursday, September 22, 2016 10:07 PM
> To: sssd-users(a)lists.fedorahosted.org
> Subject: [SSSD-users] Re: Ldap referrals
>
> On Thu, Sep 22, 2016 at 03:03:36PM +0000, Ondrej Valousek wrote:
> > Hi list,
> >
> > Is it safe to enable ldap referrals in sssd 13.3?
>
> nothing changed in libldap's referral support, so all the old problems still
apply..
>
> > I have them disabled (ldap_referrals=false) but it seems to me that it is
occasionally causing sssd to unable to find users in AD.
>
> Do you have an example? Normally SSSD shoudl contact the AD DC that 'knows'
the user already..
>
> > Thanks,
> >
> > Ondrej
> >
> > -----
> >
> > The information contained in this e-mail and in any attachments is confidential
and is designated solely for the attention of the intended recipient(s). If you are not an
intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or
any part thereof. If you have received this e-mail in error, please notify the sender by
return e-mail and delete all copies of this e-mail from your computer system(s). Please
direct any additional queries to: communications(a)s3group.com. Thank You. Silicon and
Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office:
South County Business Park, Leopardstown, Dublin 18.
>
> > _______________________________________________
> > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To
> > unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To unsubscribe send an
email to sssd-users-leave(a)lists.fedorahosted.org
>
> -----
>
> The information contained in this e-mail and in any attachments is confidential and
is designated solely for the attention of the intended recipient(s). If you are not an
intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or
any part thereof. If you have received this e-mail in error, please notify the sender by
return e-mail and delete all copies of this e-mail from your computer system(s). Please
direct any additional queries to: communications(a)s3group.com. Thank You. Silicon and
Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office:
South County Business Park, Leopardstown, Dublin 18.
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org