Learn more about these different git repos.
Other Git URLs
I'm trying to set up sssd for the first time (on Fedora 12). I noticed that queries aren't working correctly, so I ran "sshd -d 8" to get more debug information. In the output, I saw the error message: "Invalid DN syntax(34)". I'll paste the debug messages followed by the corresponding error messages from the openldap server. The remote LDAP server gave cryptic messages such as "slap_global_control: unrecognized control: 1.3.6.1.4.1.42.2.27.8.5.1" and even made a reference to "dc=example,dc=com" (which doesn't show up anywhere in sssd.conf). I have nss_ldap clients that are connecting to the same LDAP server without any problems. Is there any other information I could provide that would be helpful?
[sssd[be[LDAP]]] [be_get_account_info] (4): Got request for [4097][core][name=so meuser] [sssd[be[LDAP]]] [sdap_get_generic_send] (6): calling ldap_search_ext with [(&(u id=someuser)(objectclass=posixAccount))][ou=people,dc=aml,dc=cs,bc=byu,dc=edu]. [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [objectClass] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [uid] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [userPassword] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [uidNumber] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [gidNumber] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [gecos] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [homeDirectory] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [loginShell] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [krbPrincipalName] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [cn] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [modifyTimestamp] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [shadowLastChange] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [shadowMin] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [shadowMax] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [shadowWarning] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [shadowInactive] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [shadowExpire] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [shadowFlag] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [krbLastPwdChange] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [krbPasswordExpiration] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [pwdAttribute] [sssd[be[LDAP]]] [sdap_get_generic_send] (8): ldap_search_ext called, msgid = 5 [sssd[be[LDAP]]] [sdap_process_result] (8): Trace: sh[0x1d9b8c0], connected[1], ops[0x1da4b40], fde[0x1da5780], ldap[0x1d9c0d0] [sssd[be[LDAP]]] [sdap_get_generic_done] (6): Search result: Invalid DN syntax(34), invalid DN [sssd[be[LDAP]]] [sdap_get_users_process] (6): Search for users, returned 0 results. Mar 15 16:59:07 guru slapd[29729]: conn=34 fd=19 ACCEPT from IP=10.0.0.33:44903 (IP=0.0.0.0:389) Mar 15 16:59:07 guru slapd[29729]: conn=34 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" Mar 15 16:59:07 guru slapd[29729]: conn=34 op=0 SEARCH RESULT tag=101 err=0 nentries=1 text= Mar 15 16:59:07 guru slapd[29729]: conn=34 op=1 BIND dn="" method=128 Mar 15 16:59:07 guru slapd[29729]: slap_global_control: unrecognized control: 1.3.6.1.4.1.42.2.27.8.5.1 Mar 15 16:59:07 guru slapd[29729]: conn=34 op=1 RESULT tag=97 err=0 text= Mar 15 16:59:07 guru slapd[29729]: conn=34 op=2 do_search: invalid dn (ou=people,dc=aml,dc=cs,bc=byu,dc=edu) Mar 15 16:59:07 guru slapd[29729]: conn=34 op=2 SEARCH RESULT tag=101 err=34 nentries=0 text=invalid DN Mar 15 16:59:07 guru slapd[29729]: conn=34 op=3 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(&(cn=*)(objectClass=posixGroup))" Mar 15 16:59:07 guru slapd[29729]: conn=34 op=3 SRCH attr=objectClass cn userPassword gidNumber memberuid modifyTimestamp Mar 15 16:59:07 guru slapd[29729]: conn=34 op=3 SEARCH RESULT tag=101 err=32 nentries=0 text= Mar 15 16:59:07 guru slapd[29729]: conn=34 op=4 do_search: invalid dn (ou=people,dc=aml,dc=cs,bc=byu,dc=edu) Mar 15 16:59:07 guru slapd[29729]: conn=34 op=4 SEARCH RESULT tag=101 err=34 nentries=0 text=invalid DN Mar 15 16:59:11 guru slapd[29729]: conn=34 fd=19 closed (connection lost)
It looks like the bug system is broken. I'll try again and see if I can get that to be legible.
[sssd[be[LDAP]]] [be_get_account_info] (4): Got request for [4097][core][name=so meuser] [sssd[be[LDAP]]] [sdap_get_generic_send] (6): calling ldap_search_ext with [(&(u id=someuser)(objectclass=posixAccount))][ou=people,dc=aml,dc=cs,bc=byu,dc=edu]. [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [objectClass] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [uid] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [userPassword] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [uidNumber] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [gidNumber] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [gecos] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [homeDirectory] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [loginShell] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [krbPrincipalName] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [cn] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [modifyTimestamp] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [shadowLastChange] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [shadowMin] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [shadowMax] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [shadowWarning] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [shadowInactive] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [shadowExpire] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [shadowFlag] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [krbLastPwdChange] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [krbPasswordExpiration] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [pwdAttribute] [sssd[be[LDAP]]] [sdap_get_generic_send] (8): ldap_search_ext called, msgid = 5 [sssd[be[LDAP]]] [sdap_process_result] (8): Trace: sh[0x1d9b8c0], connected[1], ops[0x1da4b40], fde[0x1da5780], ldap[0x1d9c0d0] [sssd[be[LDAP]]] [sdap_get_generic_done] (6): Search result: Invalid DN syntax(34), invalid DN [sssd[be[LDAP]]] [sdap_get_users_process] (6): Search for users, returned 0 results. [sssd[be[LDAP]]] [sdap_process_result] (8): Trace: sh[0x1d9b8c0], connected[1], ops[(nil)], fde[0x1da5780], ldap[0x1d9c0d0] [sssd[be[LDAP]]] [sdap_process_result] (8): Trace: ldap_result found nothing! Mar 15 16:59:07 guru slapd[29729]: conn=34 fd=19 ACCEPT from IP=10.0.0.33:44903 (IP=0.0.0.0:389) Mar 15 16:59:07 guru slapd[29729]: conn=34 op=0 SRCH base="" scope=0 deref=0 fil ter="(objectClass=*)" Mar 15 16:59:07 guru slapd[29729]: conn=34 op=0 SEARCH RESULT tag=101 err=0 nent ries=1 text= Mar 15 16:59:07 guru slapd[29729]: conn=34 op=1 BIND dn="" method=128 Mar 15 16:59:07 guru slapd[29729]: slap_global_control: unrecognized control: 1. 3.6.1.4.1.42.2.27.8.5.1 Mar 15 16:59:07 guru slapd[29729]: conn=34 op=1 RESULT tag=97 err=0 text= Mar 15 16:59:07 guru slapd[29729]: conn=34 op=2 do_search: invalid dn (ou=people ,dc=aml,dc=cs,bc=byu,dc=edu) Mar 15 16:59:07 guru slapd[29729]: conn=34 op=2 SEARCH RESULT tag=101 err=34 nen tries=0 text=invalid DN Mar 15 16:59:07 guru slapd[29729]: conn=34 op=3 SRCH base="dc=example,dc=com" sc ope=2 deref=0 filter="(&(cn=*)(objectClass=posixGroup))" Mar 15 16:59:07 guru slapd[29729]: conn=34 op=3 SRCH attr=objectClass cn userPas sword gidNumber memberuid modifyTimestamp Mar 15 16:59:07 guru slapd[29729]: conn=34 op=3 SEARCH RESULT tag=101 err=32 nen tries=0 text= Mar 15 16:59:07 guru slapd[29729]: conn=34 op=4 do_search: invalid dn (ou=people ,dc=aml,dc=cs,bc=byu,dc=edu) Mar 15 16:59:07 guru slapd[29729]: conn=34 op=4 SEARCH RESULT tag=101 err=34 nen tries=0 text=invalid DN Mar 15 16:59:11 guru slapd[29729]: conn=34 fd=19 closed (connection lost)
Please include your [sanitized] sssd.conf, so we can tell if there's a misconfiguration.
description: I'm trying to set up sssd for the first time (on Fedora 12). I noticed that queries aren't working correctly, so I ran "sshd -d 8" to get more debug information. In the output, I saw the error message: "Invalid DN syntax(34)". I'll paste the debug messages followed by the corresponding error messages from the openldap server. The remote LDAP server gave cryptic messages such as "slap_global_control: unrecognized control: 1.3.6.1.4.1.42.2.27.8.5.1" and even made a reference to "dc=example,dc=com" (which doesn't show up anywhere in sssd.conf). I have nss_ldap clients that are connecting to the same LDAP server without any problems. Is there any other information I could provide that would be helpful?
[sssd[be[LDAP]]] [be_get_account_info] (4): Got request for [4097][core][name=so meuser] [sssd[be[LDAP]]] [sdap_get_generic_send] (6): calling ldap_search_ext with [(&(u id=someuser)(objectclass=posixAccount))][ou=people,dc=aml,dc=cs,bc=byu,dc=edu]. [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [objectClass] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [uid] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [userPassword] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [uidNumber] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [gidNumber] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [gecos] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [homeDirectory] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [loginShell] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [krbPrincipalName] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [cn] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [modifyTimestamp] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [shadowLastChange] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [shadowMin] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [shadowMax] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [shadowWarning] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [shadowInactive] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [shadowExpire] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [shadowFlag] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [krbLastPwdChange] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [krbPasswordExpiration] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [pwdAttribute] [sssd[be[LDAP]]] [sdap_get_generic_send] (8): ldap_search_ext called, msgid = 5 [sssd[be[LDAP]]] [sdap_process_result] (8): Trace: sh[0x1d9b8c0], connected[1], ops[0x1da4b40], fde[0x1da5780], ldap[0x1d9c0d0] [sssd[be[LDAP]]] [sdap_get_generic_done] (6): Search result: Invalid DN syntax(34), invalid DN [sssd[be[LDAP]]] [sdap_get_users_process] (6): Search for users, returned 0 results.
Mar 15 16:59:07 guru slapd[29729]: conn=34 fd=19 ACCEPT from IP=10.0.0.33:44903 (IP=0.0.0.0:389) Mar 15 16:59:07 guru slapd[29729]: conn=34 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=)" Mar 15 16:59:07 guru slapd[29729]: conn=34 op=0 SEARCH RESULT tag=101 err=0 nentries=1 text= Mar 15 16:59:07 guru slapd[29729]: conn=34 op=1 BIND dn="" method=128 Mar 15 16:59:07 guru slapd[29729]: slap_global_control: unrecognized control: 1.3.6.1.4.1.42.2.27.8.5.1 Mar 15 16:59:07 guru slapd[29729]: conn=34 op=1 RESULT tag=97 err=0 text= Mar 15 16:59:07 guru slapd[29729]: conn=34 op=2 do_search: invalid dn (ou=people,dc=aml,dc=cs,bc=byu,dc=edu) Mar 15 16:59:07 guru slapd[29729]: conn=34 op=2 SEARCH RESULT tag=101 err=34 nentries=0 text=invalid DN Mar 15 16:59:07 guru slapd[29729]: conn=34 op=3 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(&(cn=)(objectClass=posixGroup))" Mar 15 16:59:07 guru slapd[29729]: conn=34 op=3 SRCH attr=objectClass cn userPassword gidNumber memberuid modifyTimestamp Mar 15 16:59:07 guru slapd[29729]: conn=34 op=3 SEARCH RESULT tag=101 err=32 nentries=0 text= Mar 15 16:59:07 guru slapd[29729]: conn=34 op=4 do_search: invalid dn (ou=people,dc=aml,dc=cs,bc=byu,dc=edu) Mar 15 16:59:07 guru slapd[29729]: conn=34 op=4 SEARCH RESULT tag=101 err=34 nentries=0 text=invalid DN Mar 15 16:59:11 guru slapd[29729]: conn=34 fd=19 closed (connection lost) => I'm trying to set up sssd for the first time (on Fedora 12). I noticed that queries aren't working correctly, so I ran "sshd -d 8" to get more debug information. In the output, I saw the error message: "Invalid DN syntax(34)". I'll paste the debug messages followed by the corresponding error messages from the openldap server. The remote LDAP server gave cryptic messages such as "slap_global_control: unrecognized control: 1.3.6.1.4.1.42.2.27.8.5.1" and even made a reference to "dc=example,dc=com" (which doesn't show up anywhere in sssd.conf). I have nss_ldap clients that are connecting to the same LDAP server without any problems. Is there any other information I could provide that would be helpful?
{{{ [sssd[be[LDAP]]] [be_get_account_info] (4): Got request for [4097][core][name=so meuser] [sssd[be[LDAP]]] [sdap_get_generic_send] (6): calling ldap_search_ext with [(&(u id=someuser)(objectclass=posixAccount))][ou=people,dc=aml,dc=cs,bc=byu,dc=edu]. [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [objectClass] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [uid] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [userPassword] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [uidNumber] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [gidNumber] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [gecos] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [homeDirectory] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [loginShell] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [krbPrincipalName] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [cn] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [modifyTimestamp] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [shadowLastChange] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [shadowMin] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [shadowMax] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [shadowWarning] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [shadowInactive] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [shadowExpire] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [shadowFlag] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [krbLastPwdChange] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [krbPasswordExpiration] [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [pwdAttribute] [sssd[be[LDAP]]] [sdap_get_generic_send] (8): ldap_search_ext called, msgid = 5 [sssd[be[LDAP]]] [sdap_process_result] (8): Trace: sh[0x1d9b8c0], connected[1], ops[0x1da4b40], fde[0x1da5780], ldap[0x1d9c0d0] [sssd[be[LDAP]]] [sdap_get_generic_done] (6): Search result: Invalid DN syntax(34), invalid DN [sssd[be[LDAP]]] [sdap_get_users_process] (6): Search for users, returned 0 results. }}}
{{{ Mar 15 16:59:07 guru slapd[29729]: conn=34 fd=19 ACCEPT from IP=10.0.0.33:44903 (IP=0.0.0.0:389) Mar 15 16:59:07 guru slapd[29729]: conn=34 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=)" Mar 15 16:59:07 guru slapd[29729]: conn=34 op=0 SEARCH RESULT tag=101 err=0 nentries=1 text= Mar 15 16:59:07 guru slapd[29729]: conn=34 op=1 BIND dn="" method=128 Mar 15 16:59:07 guru slapd[29729]: slap_global_control: unrecognized control: 1.3.6.1.4.1.42.2.27.8.5.1 Mar 15 16:59:07 guru slapd[29729]: conn=34 op=1 RESULT tag=97 err=0 text= Mar 15 16:59:07 guru slapd[29729]: conn=34 op=2 do_search: invalid dn (ou=people,dc=aml,dc=cs,bc=byu,dc=edu) Mar 15 16:59:07 guru slapd[29729]: conn=34 op=2 SEARCH RESULT tag=101 err=34 nentries=0 text=invalid DN Mar 15 16:59:07 guru slapd[29729]: conn=34 op=3 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(&(cn=)(objectClass=posixGroup))" Mar 15 16:59:07 guru slapd[29729]: conn=34 op=3 SRCH attr=objectClass cn userPassword gidNumber memberuid modifyTimestamp Mar 15 16:59:07 guru slapd[29729]: conn=34 op=3 SEARCH RESULT tag=101 err=32 nentries=0 text= Mar 15 16:59:07 guru slapd[29729]: conn=34 op=4 do_search: invalid dn (ou=people,dc=aml,dc=cs,bc=byu,dc=edu) Mar 15 16:59:07 guru slapd[29729]: conn=34 op=4 SEARCH RESULT tag=101 err=34 nentries=0 text=invalid DN Mar 15 16:59:11 guru slapd[29729]: conn=34 fd=19 closed (connection lost) }}}
Fields changed
doc: 0 => 1 tests: 0 => 1
I wouldn't be shocked at all if it were misconfiguration. I'm attaching the sssd.conf. I don't think there's anything sensitive in it, so I'm posting it as-is. Note that I've tried a couple of variations for ldap_user_search_base, including "ou=people,dc=aml,dc=cs,bc=byu,dc=edu" and "dc=aml,dc=cs,bc=byu,dc=edu". Also, I disabled "auth_provider = ldap" and set "ldap_tls_reqcert = never" just to try to eliminate certain potential problems.
sssd configuration sssd.conf
Would it be helpful if I tried with 1.0.99? I'm excited to test out sssd, but I'm a little stuck. Is there any other information I could provide that would be helpful?
Just to get you up and running, try using
ldap_search_base = dc=aml,dc=cs,bc=byu,dc=edu
in place of {{{ldap_user_search_base}}} and {{{ldap_group_search_base}}}.
I think we may have a bug where those two bases are not overriding the search base the way that they should.
I tried removing the ldap_user_search_base and ldap_group_search_base and setting "ldap_search_base = dc=aml,dc=cs,bc=byu,dc=edu", but I'm still getting the same errors. It looks like debug level 6 is the best for seeing it:
[sssd[be[LDAP]]] [sdap_get_generic_send] (6): calling ldap_search_ext with [(&(uid=testuser)(objectclass=posixAccount))][dc=aml,dc=cs,bc=byu,dc=edu]. [sssd[be[LDAP]]] [sdap_get_generic_done] (6): Search result: Invalid DN syntax(34), invalid DN [sssd[be[LDAP]]] [sdap_get_users_process] (6): Search for users, returned 0 results.
In this case it's still giving the "Invalid DN syntax" error, and the LDAP server still gives the "slap_global_control: unrecognized control: 1.3 .6.1.4.1.42.2.27.8.5.1" error. I'm not sure if it's relevant, but the LDAP server is at the latest version (openldap-servers-2.4.19-3.fc12.x86_64).
I found mailing list thread about the "unrecognized control" error with this OID:
http://www.openldap.org/lists/openldap-software/200606/msg00021.html
Apparently this error means that sssd is using the Password Policy module, which isn't configured on my server. As a workaround, I'll try to figure out what the Password Policy module is (since I've never heard of it), and to try to enable it on the server. Here's a reference I found describing what Password Policy is:
http://tools.ietf.org/html/draft-behera-ldap-password-policy-00
Based on my initial reading, it seems surprising that sssd would use this at all when sssd.conf doesn't set "auth_provider = ldap".
That control is only used on bind and on password operations. And it is never set as critical, so it will just be ignored. In any case it can't cause a DN Syntax error on searches. Any chance you can raise your server log level to see exactly what it doesn't like ?
Wow. Apparently slapd can distinguish between "d" and "b" even though I can't. I guess I must be mildly dyslexic: "d" and "b" are mirror images. I guess you didn't notice it either. :) Anyway, there was definitely user error involved.
However, I don't think the issue has to be completely useless. Could I recommend having "Search result: Invalid DN syntax(34), invalid DN" be treated as a more serious error? Right now, this message is at log level 6, so it's really hard to see. In addition to being raised to one of the main log levels, it would also be helpful if the error printed out which DN it was searching on.
milestone: NEEDS_TRIAGE => SSSD 1.1 owner: somebody => sbose priority: major => critical
summary: Error: "Invalid DN syntax" => Print "Invalid DN syntax" at a lower log level
Fixed by b3f76cd
fixedin: => 1.1.0 resolution: => fixed status: new => closed
doc: 1 => 0
coverity: => patch: => 0 tests: 1 => 0 upgrade: => 0
rhbz: => 0
Metadata Update from @amcnabb: - Issue assigned to sbose - Issue set to the milestone: SSSD 1.1
SSSD is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in SSSD's github repository.
This issue has been cloned to Github and is available here: - https://github.com/SSSD/sssd/issues/1461
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Log in to comment on this ticket.