Re: openldap client GSSAPI authentication segfaults in fbgsd8-stable i386
On 18/02/2010 19:50, Dieter Kluenter wrote: George Mamalakismama...@eng.auth.gr writes: Dear all, I have submitted this email to freebsd-stable mailing list as well, but with no luck until now; so, I decided to share it with this list as well. The email is large, only because I have tested my setup in six different machines, and I explain my results for each one. The problem is more simple; my email subject explains it all. So, here is how it goes: [...] You didn't say anything about your kerberos setup. Did you create host principals and ldap service principals? Is the keytab readable by slapd user? -Dieter Dieter, in my ldap server: [r...@ldap /]# ls -lrta /etc/krb5.keytab -rw-r- 1 root ldap - 446 Sep 28 19:21 /etc/krb5.keytab but as I have already stated in my email, in one of my hosts ldapwhoami and ldapsearch work fine, either by kiniting or not. Once I kinit to user mamalos, three out of six clients work well (no segfaults or corrupted stacks). This implies that heimdal combined with slapd works fine. As far as host principals is concerned, fbsd8stable i386 on my laptop's virtual box does not have one, but it works ok once I kinit to my user. All tests have been performed as root, and when kiniting I use the mamalos user-principal. Thank you for your answer. mamalos -- George Mamalakis IT Officer Electrical and Computer Engineer (Aristotle Un. of Thessaloniki), MSc (Imperial College of London) Department of Electrical and Computer Engineering Faculty of Engineering Aristotle University of Thessaloniki phone number : +30 (2310) 994379
password change hangs: bug?
Hi, I'm running slapd 2.4.9 on Solaris10. I searched with no result: does anyone know if there is a bug on 2.4.9 regarding password changes? I'd like to know if newer releases have bug fixes specifically for this issue This is what happened to me. I have a client performing many password changes, which usually results in my logs like this: ... Feb 19 12:17:33 db1 slapd[49]: [ID 848112 local4.debug] conn=591 fd=22 ACCEPT from IP=192.168.2.253:49108 (IP=0.0.0.0:12312) Feb 19 12:17:33 db1 slapd[49]: [ID 215403 local4.debug] conn=591 op=0 BIND dn=uid=mario.ro...@unipd.it,ou=people,dc=unipd,dc=it method=128 Feb 19 12:17:33 db1 slapd[49]: [ID 600343 local4.debug] conn=591 op=0 BIND dn=uid=mario.ro...@unipd.it,ou=people,dc=unipd,dc=it mech=SIMPLE ssf=0 Feb 19 12:17:33 db1 slapd[49]: [ID 588225 local4.debug] conn=591 op=0 RESULT tag=97 err=0 text= Feb 19 12:17:33 db1 slapd[49]: [ID 270379 local4.debug] conn=591 op=1 EXT oid=1.3.6.1.4.1.4203.1.11.1 Feb 19 12:17:33 db1 slapd[49]: [ID 461300 local4.debug] conn=591 op=1 PASSMOD new Feb 19 12:17:33 db1 slapd[49]: [ID 875301 local4.debug] conn=591 op=1 RESULT oid= err=0 text= Feb 19 12:17:33 db1 slapd[49]: [ID 218904 local4.debug] conn=591 op=2 UNBIND Feb 19 12:17:33 db1 slapd[49]: [ID 952275 local4.debug] conn=591 fd=22 closed ... Always went fine, but yesterday this happened: ... Feb 18 22:45:41 db1 slapd[21872]: [ID 848112 local4.debug] conn=3186 fd=22 ACCEPT from IP=192.168.2.253:49820 (IP=0.0.0.0:12312) Feb 18 22:45:41 db1 slapd[21872]: [ID 215403 local4.debug] conn=3186 op=0 BIND dn=uid=maria.ve...@unipd.it,ou=people,dc=unipd,dc=it method=128 Feb 18 22:45:41 db1 slapd[21872]: [ID 600343 local4.debug] conn=3186 op=0 BIND dn=uid=maria.ve...@unipd.it,ou=people,dc=unipd,dc=it mech=SIMPLE ss f=0 Feb 18 22:45:41 db1 slapd[21872]: [ID 588225 local4.debug] conn=3186 op=0 RESULT tag=97 err=0 text= Feb 18 22:45:41 db1 slapd[21872]: [ID 270379 local4.debug] conn=3186 op=1 EXT oid=1.3.6.1.4.1.4203.1.11.1 Feb 18 22:45:41 db1 slapd[21872]: [ID 461300 local4.debug] conn=3186 op=1 PASSMOD new ... that is, no RESULT for PASSMD and the client performing the password change received no answer (hung), and this has caused us many problems. Could it possibly be an openldap bug? Thank you very much, Stefano
Re: Server-Side Sort Overlay ordering problems
Adam Tauno Williams wrote: On Thu, 2010-02-18 at 08:29 -0500, Adam Tauno Williams wrote: On Fri, 2010-01-15 at 11:27 -0200, Diego Lima wrote: I have enabled the server-side sorting overlay and I received the following error on a search: sssvlv: no ordering rule specified and no default ordering rule for attribute uid = get_ctrls: n=1 rc=18 err=serverSort control: No ordering rule send_ldap_result: conn=1000 op=7 p=3 send_ldap_response: msgid=8 tag=101 err=18 ber_flush2: 50 bytes to sd 13 Where should I specify the ordering rule for the uid attribute? The core schema? I believe I have this issue as well. Since upgrading to OL 2.4.20 our OpenFire XMPP server has been logging an unending stream of - 2010.02.15 11:02:26 [org.jivesoftware.openfire.ldap.LdapManager.retrieveList(LdapManager.java:1709)] javax.naming.directory.InvalidSearchFilterException: [LDAP: error code 18 - serverSort control: No ordering rule]; remaining name '' at com.sun.jndi.ldap.LdapCtx.mapErrorCode(Unknown Source) at com.sun.jndi.ldap.LdapCtx.processReturnCode(Unknown Source) at com.sun.jndi.ldap.LdapCtx.processReturnCode(Unknown Source) at com.sun.jndi.ldap.LdapCtx.searchAux(Unknown Source) at com.sun.jndi.ldap.LdapCtx.c_search(Unknown Source) at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(Unknown Source) No changes were made to the OpenFire configuration, so the issue must be do to a change in OL schema. Browsing our DSA's schema and cn and uid have no ordering rule. Setting the OpenFire server property ldap.clientSideSorting to true seems to have cleared up this issue. Without that property OpenFire was requesting the control 1.2.840.113556.1.4.473 on the uid attribute. Not sure what you're pointing out here. OpenLDAP doesn't advertise server-side sorting by default, you have to explicitly configure the overlay to get it. So there's no way that just upgrading to 2.4.20 would have suddenly caused this problem to start. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
