Hi,
I have just tried to use a configuration I am currently using in Prague (small site, one AD DC) in Dublin as well (large site, many DCs). I am using DNS SRV lookups for everything (service auto discovery), but in Dublin it is failing for some reason, giving the error below:
(Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [fo_set_port_status] (0x0100): Marking port 389 of server 'dcduba.dublin.ad.s3group.com' as 'working' (Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [set_server_common_status] (0x0100): Marking server 'dcduba.dublin.ad.s3group.com' as 'working' (Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_id_op_connect_done] (0x2000): Old USN: 76274476, New USN: 31508106 (Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_id_op_connect_done] (0x4000): notify connected to op #1 (Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_users_next_base] (0x0400): Searching for users with base [dc=dublin,dc=ad,dc=s3group,dc=com] (Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(uid=ondrjev)(objectclass=user))][dc=dublin,dc=ad,dc=s3group,dc=com]. (Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] (Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uid] (Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userPassword] (Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uidNumber] (Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gidNumber] (Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gecos] (Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [unixHomeDirectory] (Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginShell] (Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [krbPrincipalName] (Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] (Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberOf] (Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [nsUniqueId] (Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [modifyTimestamp] (Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowLastChange] (Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowMin] (Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowMax] (Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowWarning] (Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowInactive] (Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowExpire] (Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [shadowFlag] (Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [krbLastPwdChange] (Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [krbPasswordExpiration] (Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [pwdAttribute] (Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [authorizedService] (Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [accountExpires] (Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userAccountControl] (Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [nsAccountLock] (Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [host] (Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginDisabled] (Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginExpirationTime] (Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [loginAllowedTimeMap] (Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 5 (Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_id_op_connect_done] (0x4000): caching successful connection after 1 notifies (Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_process_result] (0x2000): Trace: sh[0x1e9eca0], connected[1], ops[0x1ea0df0], ldap[0x1eadc50] (Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to [ldap://DomainDnsZones.dublin.ad.s3group.com/DC=DomainDnsZones,DC=dublin,DC=ad,DC=s3group,DC=com] with fd [35]. (Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_rebind_proc] (0x0020): ldap_sasl_interactive_bind_s failed (-2)[Local error] (Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_rebind_proc] (0x1000): Failed to bind to [ldap://DomainDnsZones.dublin.ad.s3group.com/DC=DomainDnsZones,DC=dublin,DC=ad,DC=s3group,DC=com]. (Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_ldap_connect_callback_del] (0x4000): Closing LDAP connection with fd [35]. (Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_REFERENCE] (Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_process_result] (0x2000): Trace: sh[0x1e9eca0], connected[1], ops[0x1ea0df0], ldap[0x1eadc50] (Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! (Thu Aug 2 14:19:42 2012) [sssd[be[default]]] [sdap_get_generic_done] (0x0100): sdap_get_generic_ext_recv failed [110]: Connection timed out (Thu Aug 2 14:19:42 2012) [sssd[be[default]]] [sdap_id_op_done] (0x0200): communication error on cached connection, moving to next server (Thu Aug 2 14:19:42 2012) [sssd[be[default]]] [sdap_id_op_done] (0x4000): too many communication failures, giving up... (Thu Aug 2 14:19:42 2012) [sssd[be[default]]] [sdap_id_op_done] (0x4000): releasing operation connection (Thu Aug 2 14:19:42 2012) [sssd[be[default]]] [sdap_id_release_conn_data] (0x4000): releasing unused connection (Thu Aug 2 14:19:42 2012) [sssd[be[default]]] [sdap_handle_release] (0x2000): Trace: sh[0x1e9eca0], connected[1], ops[(nil)], ldap[0x1eadc50], destructor_lock[0], release_memory[0] (Thu Aug 2 14:19:42 2012) [sssd[be[default]]] [remove_connection_callback] (0x4000): Successfully removed connection callback. (Thu Aug 2 14:19:42 2012) [sssd[be[default]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,110,User lookup failed
Does anyone know what could be wrong? I have a faint feeling Jakub managed to resolve this one it the past for me, but I can not find the mail, any longer. Note that DomainDnsZones.dublin.ad.s3group.com returns many servers, some of them might be no longer accessible, but there is certainly at least one of them which is working fine.
Many thanks. Ondrej
On Thu, 2012-08-02 at 15:43 +0200, Ondrej Valousek wrote:
(Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_ldap_connect_callback_del] (0x4000): Closing LDAP connection with fd [35]. (Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_REFERENCE]
I think you should turn off resolving referrals with AD for now.
Simo.
Yes, that was it, many thanks! BTW: Is this a flaw in sssd or is it a known problem?
Thanks. Ondrej
On 08/02/2012 04:01 PM, Simo Sorce wrote:
On Thu, 2012-08-02 at 15:43 +0200, Ondrej Valousek wrote:
(Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_ldap_connect_callback_del] (0x4000): Closing LDAP connection with fd [35]. (Thu Aug 2 14:19:35 2012) [sssd[be[default]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_REFERENCE]
I think you should turn off resolving referrals with AD for now.
Simo.
On Thu, 2012-08-02 at 16:06 +0200, Ondrej Valousek wrote:
Yes, that was it, many thanks! BTW: Is this a flaw in sssd or is it a known problem?
It is an issue between sssd and openldap libs we are planning to solve soon, but it is a complicated problem and the solution is not easy.
Simo.
On Thu, 2012-08-02 at 16:06 +0200, Ondrej Valousek wrote:
Yes, that was it, many thanks! BTW: Is this a flaw in sssd or is it a known problem?
It's partly a flaw in AD and partly a flaw in SSSD using OpenLDAP for referral chasing.
Active Directory does many completely-unnecessary referrals to the global catalog, and if the randomly-selected server for that referral isn't up, openldap's referral chasing breaks on it.
In many AD environments, referral chasing is unnecessary anyway, since most environments perform total replication. In environments with partial replication, it gets a little trickier.
Somewhere down the line, SSSD will reimplement referral-chasing on its own to be more reliable, but it's a sizeable effort (and one I've started and had to set aside twice already because of the effort involved).
Ok lads, many thanks for the explanation. Maybe it should be then switched off by default then? Or at least make it off in the new forthcoming AD configuration template? What do you think? Thanks,
Ondrej
On 08/02/2012 04:11 PM, Stephen Gallagher wrote:
On Thu, 2012-08-02 at 16:06 +0200, Ondrej Valousek wrote:
Yes, that was it, many thanks! BTW: Is this a flaw in sssd or is it a known problem?
It's partly a flaw in AD and partly a flaw in SSSD using OpenLDAP for referral chasing.
Active Directory does many completely-unnecessary referrals to the global catalog, and if the randomly-selected server for that referral isn't up, openldap's referral chasing breaks on it.
In many AD environments, referral chasing is unnecessary anyway, since most environments perform total replication. In environments with partial replication, it gets a little trickier.
Somewhere down the line, SSSD will reimplement referral-chasing on its own to be more reliable, but it's a sizeable effort (and one I've started and had to set aside twice already because of the effort involved).
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On Thu, Aug 02, 2012 at 04:23:03PM +0200, Ondrej Valousek wrote:
Ok lads, many thanks for the explanation. Maybe it should be then switched off by default then? Or at least make it off in the new forthcoming AD configuration template? What do you think? Thanks,
It is off by default in the AD provider.
sssd-users@lists.fedorahosted.org
-
Jakub Hrozek -
Ondrej Valousek -
Simo Sorce -
Stephen Gallagher