Hi Folks,
I'm attempting to create a configuration whereby Active Directory is used via LDAP only to authenticate ONLY local users via a proxy id_provider using local files... this was the configuration that I was attempting:
[sssd] config_file_version = 2 domains = <domain> services = nss, pam
[nss]
[pam]
[domain/<domain>] debug_level = 9
id_provider = proxy auth_provider = ldap
proxy_lib_name = files
cache_credentials = true
ldap_uri = <list,of,domain,controllers>
ldap_id_use_start_tls = true ldap_tls_reqcert = allow
ldap_default_bind_dn = <bind account> ldap_default_authtok = <bind sekrit>
ldap_schema = ad ldap_search_base = <search base>
--
It seems to be finding my entry just fine in /etc/passwd... but, it seems to be unable to perform the LDAP search... as I get back these sanitized results... showing that it can't find my user object... for some reason...
(Thu Sep 22 16:12:39 2016) [sssd[be[<domain>]]] [sdap_search_user_next_base] (0x0400): Searching for users with base [<base>] (Thu Sep 22 16:12:39 2016) [sssd[be[<domain>]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(sAMAccountName=<myuser>)(objectclass=user))][<base>]. (Thu Sep 22 16:12:39 2016) [sssd[be[<domain>]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectclass] (Thu Sep 22 16:12:39 2016) [sssd[be[<domain>]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sAMAccountName] (Thu Sep 22 16:12:39 2016) [sssd[be[<domain>]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 2 (Thu Sep 22 16:12:39 2016) [sssd[be[<domain>]]] [sdap_process_result] (0x2000): Trace: sh[0xf49a70], connected[1], ops[0xf49400], ldap[0xf45cc0] (Thu Sep 22 16:12:39 2016) [sssd[be[<domain>]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! (Thu Sep 22 16:12:39 2016) [sssd[be[<domain>]]] [sdap_process_result] (0x2000): Trace: sh[0xf49a70], connected[1], ops[0xf49400], ldap[0xf45cc0] (Thu Sep 22 16:12:39 2016) [sssd[be[<domain>]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] (Thu Sep 22 16:12:39 2016) [sssd[be[<domain>]]] [sdap_get_generic_ext_done] (0x0400): Search result: Operations error(1), 000004DC: LdapErr: DSID-0C090752, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v2580 (Thu Sep 22 16:12:39 2016) [sssd[be[<domain>]]] [sdap_get_generic_ext_done] (0x0040): Unexpected result from ldap: Operations error(1), 000004DC: LdapErr: DSID-0C090752, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v2580 (Thu Sep 22 16:12:39 2016) [sssd[be[<domain>]]] [sdap_get_generic_done] (0x0100): sdap_get_generic_ext_recv failed [5]: Input/output error
--
If I perform a manual ldapsearch ... using the parameters indicated in the "ldap_search_ext" call ... it works just fine. I've checked in the logs and I see that it marks the connection to the domain controller as "working" ... so, I'm not sure why sssd complains that a successful bind must be completed... that seems to have happened already...
I'm running sssd version 1.11.7 ...
Any ideas, folks?
Thanks,
Andy Speagle
On Tue, Sep 27, 2016 at 07:35:38PM +0000, Speagle, Andy wrote:
Hi Folks,
I'm attempting to create a configuration whereby Active Directory is used via LDAP only to authenticate ONLY local users via a proxy id_provider using local files... this was the configuration that I was attempting:
[sssd] config_file_version = 2 domains = <domain> services = nss, pam
[nss]
[pam]
[domain/<domain>] debug_level = 9
id_provider = proxy auth_provider = ldap
proxy_lib_name = files
cache_credentials = true
ldap_uri = <list,of,domain,controllers>
ldap_id_use_start_tls = true ldap_tls_reqcert = allow
ldap_default_bind_dn = <bind account> ldap_default_authtok = <bind sekrit>
ldap_schema = ad ldap_search_base = <search base>
--
It seems to be finding my entry just fine in /etc/passwd... but, it seems to be unable to perform the LDAP search... as I get back these sanitized results... showing that it can't find my user object... for some reason...
(Thu Sep 22 16:12:39 2016) [sssd[be[<domain>]]] [sdap_search_user_next_base] (0x0400): Searching for users with base [<base>] (Thu Sep 22 16:12:39 2016) [sssd[be[<domain>]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(sAMAccountName=<myuser>)(objectclass=user))][<base>]. (Thu Sep 22 16:12:39 2016) [sssd[be[<domain>]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectclass] (Thu Sep 22 16:12:39 2016) [sssd[be[<domain>]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sAMAccountName] (Thu Sep 22 16:12:39 2016) [sssd[be[<domain>]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 2 (Thu Sep 22 16:12:39 2016) [sssd[be[<domain>]]] [sdap_process_result] (0x2000): Trace: sh[0xf49a70], connected[1], ops[0xf49400], ldap[0xf45cc0] (Thu Sep 22 16:12:39 2016) [sssd[be[<domain>]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! (Thu Sep 22 16:12:39 2016) [sssd[be[<domain>]]] [sdap_process_result] (0x2000): Trace: sh[0xf49a70], connected[1], ops[0xf49400], ldap[0xf45cc0] (Thu Sep 22 16:12:39 2016) [sssd[be[<domain>]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] (Thu Sep 22 16:12:39 2016) [sssd[be[<domain>]]] [sdap_get_generic_ext_done] (0x0400): Search result: Operations error(1), 000004DC: LdapErr: DSID-0C090752, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v2580 (Thu Sep 22 16:12:39 2016) [sssd[be[<domain>]]] [sdap_get_generic_ext_done] (0x0040): Unexpected result from ldap: Operations error(1), 000004DC: LdapErr: DSID-0C090752, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v2580 (Thu Sep 22 16:12:39 2016) [sssd[be[<domain>]]] [sdap_get_generic_done] (0x0100): sdap_get_generic_ext_recv failed [5]: Input/output error
--
If I perform a manual ldapsearch ... using the parameters indicated in the "ldap_search_ext" call ... it works just fine. I've checked in the logs and I see that it marks the connection to the domain controller as "working" ... so, I'm not sure why sssd complains that a successful bind must be completed... that seems to have happened already...
I'm running sssd version 1.11.7 ...
Any ideas, folks?
Interesting, it looks like the LDAP bind was not attempted at all. You're running a version that is not so new, does adding: ldap_default_authtok_type = password explicitly to sssd.conf work?
And a bit unrelated, but do you really need to use auth_provider=ldap? I would personally suggest to use auth_provider=krb5, like this:
auth_provider = krb5 krb5_server = kdc.example.com krb5_realm = EXAMPLE.COM
If I perform a manual ldapsearch ... using the parameters indicated in
the "ldap_search_ext" call ... it works just fine. I've checked in the logs and I see that it marks the connection to the domain controller as "working" ... so, I'm not sure why sssd complains that a successful bind must be completed... that seems to have happened already...
I'm running sssd version 1.11.7 ...
Any ideas, folks?
Interesting, it looks like the LDAP bind was not attempted at all. You're running a version that is not so new, does adding: ldap_default_authtok_type = password explicitly to sssd.conf work?
Sadly, adding that didn't help...
And a bit unrelated, but do you really need to use auth_provider=ldap? I would personally suggest to use auth_provider=krb5, like this:
auth_provider = krb5 krb5_server = kdc.example.com krb5_realm = EXAMPLE.COM
I can definitely make it work with kerberos... and have already proven that. The id source is AD ... and my Linux user base would like to try to avoid integration with AD as much as possible... so I was trying to find them a pure LDAP solution.
Actually... I lied about the version... I'm using 1.13.3 on CentOS 6.8 ... if that makes any difference.
Any thoughts?
On Wed, Sep 28, 2016 at 12:46:56PM +0000, Speagle, Andy wrote:
If I perform a manual ldapsearch ... using the parameters indicated in
the "ldap_search_ext" call ... it works just fine. I've checked in the logs and I see that it marks the connection to the domain controller as "working" ... so, I'm not sure why sssd complains that a successful bind must be completed... that seems to have happened already...
I'm running sssd version 1.11.7 ...
Any ideas, folks?
Interesting, it looks like the LDAP bind was not attempted at all. You're running a version that is not so new, does adding: ldap_default_authtok_type = password explicitly to sssd.conf work?
Sadly, adding that didn't help...
And a bit unrelated, but do you really need to use auth_provider=ldap? I would personally suggest to use auth_provider=krb5, like this:
auth_provider = krb5 krb5_server = kdc.example.com krb5_realm = EXAMPLE.COM
I can definitely make it work with kerberos... and have already proven that. The id source is AD ... and my Linux user base would like to try to avoid integration with AD as much as possible... so I was trying to find them a pure LDAP solution.
I think from user's point of view it doesn't matter since they would just type the same password and the protocol SSSD speaks towards the remote server is completely handled by SSSD..
Actually... I lied about the version... I'm using 1.13.3 on CentOS 6.8 ... if that makes any difference.
Any thoughts?
No, I'm sorry, this works for me. Do you see SSSD attempting StartTLS before the actual search?
On Wed, Sep 28, 2016 at 12:46:56PM +0000, Speagle, Andy wrote:
If I perform a manual ldapsearch ... using the parameters indicated in
the "ldap_search_ext" call ... it works just fine. I've checked in the logs and I see that it marks the connection to the domain controller as "working" ... so, I'm not sure why sssd complains that a successful bind must be completed... that seems to have happened
already...
I'm running sssd version 1.11.7 ...
Any ideas, folks?
Interesting, it looks like the LDAP bind was not attempted at all. You're running a version that is not so new, does adding: ldap_default_authtok_type = password explicitly to sssd.conf work?
Sadly, adding that didn't help...
And a bit unrelated, but do you really need to use auth_provider=ldap? I would personally suggest to use
auth_provider=krb5, like this:
auth_provider = krb5 krb5_server = kdc.example.com krb5_realm = EXAMPLE.COM
I can definitely make it work with kerberos... and have already proven that. The id source is AD ... and my Linux user base would like to try to avoid integration with AD as much as possible... so I was trying to find them a pure LDAP solution.
I think from user's point of view it doesn't matter since they would just type the same password and the protocol SSSD speaks towards the remote server is completely handled by SSSD..
Actually... I lied about the version... I'm using 1.13.3 on CentOS 6.8
... if that makes any difference.
Any thoughts?
No, I'm sorry, this works for me. Do you see SSSD attempting StartTLS before the actual search?
Yes... I do. Everything seems to work up to the point when it's supposed to perform the "ldap_search_ext" ... but, it doesn't. Very strange.
sssd-users@lists.fedorahosted.org
-
Jakub Hrozek -
Jakub Hrozek -
Speagle, Andy