Re: unable to perform authenticated binds
Hey guys, And sorry to Quanah for the type-o. ;) At any rate thanks for the ldapsearch. It did return a ton of information on the attributes defined in my schema: [r...@ldap2 ~]# ldapsearch -x -h ldap.acadaca.net -s base -b cn=subschema + | more # extended LDIF # # LDAPv3 # base cn=subschema with scope baseObject # filter: (objectclass=*) # requesting: + # # Subschema dn: cn=Subschema structuralObjectClass: subentry createTimestamp: 20101105183240Z modifyTimestamp: 20101105183240Z ldapSyntaxes: ( 1.3.6.1.1.16.1 DESC 'UUID' ) ldapSyntaxes: ( 1.3.6.1.1.1.0.1 DESC 'RFC2307 Boot Parameter' ) ldapSyntaxes: ( 1.3.6.1.1.1.0.0 DESC 'RFC2307 NIS Netgroup Triple' ) ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.52 DESC 'Telex Number' ) ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number' ) ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.49 DESC 'Supported Algorithm' X-BIN ARY-TRANSFER-REQUIRED 'TRUE' X-NOT-HUMAN-READABLE 'TRUE' ) ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.45 DESC 'SubtreeSpecification' ) ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String' ) However, nothing shows up under the search regarding sudoRole. [r...@ldap ldif]# ldapsearch -x -h ldap.acadaca.net -s base -b cn=subschema | grep sudoRole [r...@ldap ldif]# This is curious to me as the sudoers.schema file (which has sudoRole defined) is most definitely entered correctly into my slapd.conf file. # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/misc.schema inlcude /etc/openldap/schema/sudoers.schema include /etc/openldap/schema/openldap.schema I checked the modes and permissions on sudoers.schema: [r...@ldap ~]# ls -l /etc/openldap/schema/sudoers.schema -r--r--r-- 1 ldap ldap 1655 Nov 4 18:38 /etc/openldap/schema/sudoers.schema But when I try to add this LDIF entry to my directory: # defaults, sudoers, Services, acadaca.net dn: cn=defaults,ou=sudoers,ou=Services,dc=acadaca,dc=net objectClass: top objectClass: sudoRole cn: defaults description: Default sudoOption's go here I am still getting this error: [r...@ldap ldif]# ldapadd -h ldap.acadaca.net -a -W -x -D cn=Manager,dc=acadaca,dc=net -f /home/tim/txt/ldif/acadaca2.ldif Enter LDAP Password: adding new entry cn=defaults,ou=sudoers,ou=Services,dc=acadaca,dc=net ldapadd: Invalid syntax (21) additional info: objectClass: value #1 invalid per syntax And these errors in the logs: Nov 5 15:00:33 ldap slapd[4429]: daemon: activity on 1 descriptor Nov 5 15:00:33 ldap slapd[4429]: daemon: activity on: Nov 5 15:00:33 ldap slapd[4429]: Nov 5 15:00:33 ldap slapd[4429]: slap_listener_activate(7): Nov 5 15:00:33 ldap slapd[4429]: daemon: epoll: listen=7 busy Nov 5 15:00:33 ldap slapd[4429]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Nov 5 15:00:33 ldap slapd[4429]: slap_listener(ldap:///) Nov 5 15:00:33 ldap slapd[4429]: daemon: listen=7, new connection on 12 Nov 5 15:00:33 ldap slapd[4429]: daemon: added 12r (active) listener=(nil) Nov 5 15:00:33 ldap slapd[4429]: conn=5 fd=12 ACCEPT from IP=75.101.129.124:55873 (IP=0.0.0.0:389) Nov 5 15:00:33 ldap slapd[4429]: daemon: activity on 2 descriptors Nov 5 15:00:33 ldap slapd[4429]: daemon: activity on: Nov 5 15:00:33 ldap slapd[4429]: 12r Nov 5 15:00:33 ldap slapd[4429]: Nov 5 15:00:33 ldap slapd[4429]: daemon: read active on 12 Nov 5 15:00:33 ldap slapd[4429]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Nov 5 15:00:33 ldap slapd[4429]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Nov 5 15:00:33 ldap slapd[4429]: connection_get(12) Nov 5 15:00:33 ldap slapd[4429]: connection_get(12): got connid=5 Nov 5 15:00:33 ldap slapd[4429]: connection_read(12): checking for input on id=5 Nov 5 15:00:33 ldap slapd[4429]: do_bind Nov 5 15:00:33 ldap slapd[4429]: dnPrettyNormal: cn=Manager,dc=acadaca,dc=net Nov 5 15:00:33 ldap slapd[4429]: dnPrettyNormal: cn=Manager,dc=acadaca,dc=net, cn=manager,dc=acadaca,dc=net Nov 5 15:00:33 ldap slapd[4429]: do_bind: version=3 dn=cn=Manager,dc=acadaca,dc=net method=128 Nov 5 15:00:33 ldap slapd[4429]: conn=5 op=0 BIND dn=cn=Manager,dc=acadaca,dc=net method=128 Nov 5 15:00:33 ldap slapd[4429]: == bdb_bind: dn: cn=Manager,dc=acadaca,dc=net Nov 5 15:00:33 ldap slapd[4429]: conn=5 op=0 BIND dn=cn=Manager,dc=acadaca,dc=net mech=SIMPLE ssf=0 Nov 5 15:00:33 ldap slapd[4429]: do_bind: v3 bind: cn=Manager,dc=acadaca,dc=net to cn=Manager,dc=acadaca,dc=net Nov 5 15:00:33 ldap slapd[4429]: send_ldap_result: conn=5 op=0 p=3 Nov 5 15:00:33 ldap slapd[4429]: send_ldap_result: err=0 matched= text= Nov 5 15:00:33 ldap slapd[4429]: send_ldap_response: msgid=1 tag=97 err=0 Nov 5 15:00:33 ldap slapd[4429]: conn=5 op=0 RESULT tag=97 err=0
Re: unable to perform authenticated binds
--On Thursday, November 04, 2010 3:37 PM -0400 Tim Dunphy bluethu...@gmail.com wrote: Thanks all.. I have read the man of ldif your advice has gotten me quite far both in my current implementation and in my overall understanding of LDAP which I am hoping grows with each passing day. In my attempt to build my current directory, I have taken a dump of my last successful implementation (which was created on FreeBSD 8.1) and substituted values for the dc=company and dc=com values with the correct ones for the current directory (attempting to implement under CentOS 5.4) and even tho the correct schemas are in place it is choking on this entry: # defaults, sudoers, Services, acadaca.com dn: cn=defaults,ou=sudoers,ou=Services,dc=acadaca,dc=net objectClass: top objectClass: sudoRole cn: defaults description: Default sudoOption's go here Since you fail to provide the error message you encountered, I see no way to help you. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc Zimbra :: the leader in open source messaging and collaboration
Re: unable to perform authenticated binds
sorry for the oversight Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on 1 descriptor Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on: Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=7 busy Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: listen=7, new connection on 12 Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: added 12r (active) listener=(nil) Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: conn=3 fd=12 ACCEPT from IP=10.203.49.140:51779 (IP=0.0.0.0:389) Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on 1 descriptor Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on: Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on 1 descriptor Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on: Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: 12r Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: read active on 12 Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: conn=3 op=0 BIND dn=cn=Manager,dc=acadaca,dc=net method=128 Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: conn=3 op=0 BIND dn=cn=Manager,dc=acadaca,dc=net mech=SIMPLE ssf=0 Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: conn=3 op=0 RESULT tag=97 err=0 text= Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on 1 descriptor Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on: Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on 1 descriptor Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on: Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: 12r Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: read active on 12 Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: conn=3 op=1 ADD dn=cn=defaults,ou=sudoers,ou=Services,dc=acadaca,dc=net Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: conn=3 op=1 RESULT tag=105 err=21 text=objectClass: value #1 invalid per syntax Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on 1 descriptor Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on: Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on 1 descriptor Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on: Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: 12r Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: read active on 12 Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: conn=3 op=2 UNBIND Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: removing 12 Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: conn=3 fd=12 closed Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on 1 descriptor Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on: Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Nov 4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=8 active_threads=0 tvp=NULL On Thu, Nov 4, 2010 at 3:49 PM, Quanah Gibson-Mount qua...@zimbra.com wrote: --On Thursday, November 04, 2010 3:37 PM -0400 Tim Dunphy bluethu...@gmail.com wrote: Thanks all.. I have read the man of ldif your advice has gotten me quite far both in my current implementation and in my overall understanding of LDAP which I am hoping grows with each passing day. In my attempt to build my current directory, I have taken a dump of my last successful
Re: unable to perform authenticated binds
--On Thursday, November 04, 2010 5:47 PM -0400 Tim Dunphy bluethu...@gmail.com wrote: however when I do a search for sudoRole it doesn't seem to show up [r...@ldap openldap]# ldapsearch -b '' -s base '(objectclass=*)' sudoRole -x -W -D cn=Manager,dc=acadaca,dc=net That is not a valid search of the cn=subschema entry. I would note you fail to offer a -h or -H option, so who knows what LDAP server it is talking to. ldapsearch -x -h zre-ldap001 -s base -b cn=subschema + for example, searches the subschema entry on my system. And my name has only one n in it. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc Zimbra :: the leader in open source messaging and collaboration
Re: unable to perform authenticated binds
sorry for the frustration all... removing the leading space in front of rootpw did the trick :) the directory is now populating, however I cannot understand why it is choking on this entry # pam_ldap, Services, acadaca.net dn: cn=pam_ldap,ou=Services,dc=acadaca,dc=net cn: pam_ldap objectClass: top objectClass: inetOrgPerson sn: PAM userPassword:: {SSHA}secret AFAIK I have ALL the scemas I need to import this entry yet ldapadd chokes [r...@ldap openldap]# ldapadd -h ldap -x -D cn=Manager,dc=acadaca,dc=net -w secret -f /home/tim/acadaca2.ldif ldapadd: invalid format (line 6) entry: cn=pam_ldap,ou=Services,dc=acadaca,dc=net include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/misc.schema inlcude /etc/openldap/schema/sudoers.schema I am sorry to ask for help again.. this sucks On Wed, Nov 3, 2010 at 12:20 PM, Quanah Gibson-Mount qua...@zimbra.com wrote: --On Tuesday, November 02, 2010 7:59 PM -0700 Chris Jacobs chris.jac...@apollogrp.edu wrote: If you're not calling me out via thanks so much for the exceedingly useful insight then feel free to skip the rest of this. I didn't think he was calling you out, myself. ;) Just noting that things are documented, and people who don't take the time to read the official project documentation (which happens a lot, unfortunately) don't deserve sympathy on it. We get a lot of people who spend their time reading documents from other sources such as Zytrax, which contain completely wrong information, and then come here to talk about how bad the documentation is. It gets frustrating. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc Zimbra :: the leader in open source messaging and collaboration -- Here's my RSA Public key: gpg --keyserver pgp.mit.edu --recv-keys 5A4873A9 Share and enjoy!!
Re: unable to perform authenticated binds
--On Wednesday, November 03, 2010 6:09 PM -0400 Tim Dunphy bluethu...@gmail.com wrote: holy crap!! it was the extra colon that killed it! found it, fixed it.. man oh man sorry for the intrusion! Yeah, :: on userPassword means it is base-64 encoded already, and clearly that bit of LDIF was not base-64 encoded. ;) --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc Zimbra :: the leader in open source messaging and collaboration
Re: unable to perform authenticated binds
Quanah Gibson-Mount wrote: --On Wednesday, November 03, 2010 6:09 PM -0400 Tim Dunphy bluethu...@gmail.com wrote: holy crap!! it was the extra colon that killed it! found it, fixed it.. man oh man sorry for the intrusion! Yeah, :: on userPassword means it is base-64 encoded already, and clearly that bit of LDIF was not base-64 encoded. ;) And again, stuff like this is clearly documented in the ldif(5) manpage... -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
unable to perform authenticated binds
I am attempting to setup an LDAP server under CentOS 5.4. However I am unable to search my ldap directory even tho I am supplying the proper credentials for the Manager account: [r...@ldap openldap]# ldapsearch -x -h ldap -D 'cn=Manager,dc=example,dc=net' -W -b 'dc=example,dc=net' Enter LDAP Password: ldap_bind: Invalid credentials (49) Anonymous searches do work however: ldapsearch -x -h ldap -b dc=example,dc=net -s sub objectclass=* [r...@ldap openldap]# ldapsearch -x -h ldap -b dc=example,dc=net -s sub objectclass=* # extended LDIF # # LDAPv3 # base dc=example,dc=net with scope subtree # filter: objectclass=* # requesting: ALL # # search result search: 2 result: 32 No such object I am currently attempting to use the actual word 'secret' to authenticate the Manager account: databasebdb suffix dc=example,dc=net rootdn cn=Manager,dc=example,dc=net # Cleartext passwords, especially for the rootdn, should # be avoided. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpwsecret # rootpw {CRYPT}secret And yet I am still getting error 49's in my openldap logs with loglevel set to 296 /var/log/openldap.log Nov 2 15:45:58 ldap slapd[3522]: slapd starting Nov 2 15:46:14 ldap slapd[3522]: conn=0 fd=11 ACCEPT from IP=127.0.0.1:44552 (IP=0.0.0.0:389) Nov 2 15:46:14 ldap slapd[3522]: conn=0 op=0 BIND dn=cn=Manager,dc=example,dc=net method=128 Nov 2 15:46:14 ldap slapd[3522]: conn=0 op=0 RESULT tag=97 err=49 text= Nov 2 15:46:14 ldap slapd[3522]: conn=0 fd=11 closed (connection lost) this is how I have configured my ldap.conf BASEdc=example,dc=net HOSTlocalhost URI ldap://ldap.example.net thanks in advance for your help -- Here's my RSA Public key: gpg --keyserver pgp.mit.edu --recv-keys 5A4873A9 Share and enjoy!!
Re: unable to perform authenticated binds
--On Tuesday, November 02, 2010 11:07 PM +0100 Benjamin Griese der.dar...@gmail.com wrote: Hello Tim, the password you supply won't work, as it is not encoded in base64. Try to generate a password hash + base64-enc with slappasswd and set this string as your password hash for rootpw. http://linux.die.net/man/8/slappasswd Benjamin, There is no requirement that the password value for the rootpw entry in slapd.conf be SSHA hashed or Base 64 encoded. I.e., rootpw secret is perfectly valid. Also, an LDIF file with userPassword: secret is also perfectly valid, as either slapadd or slapd (via ldapadd) will take care of encoding it to Base64. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc Zimbra :: the leader in open source messaging and collaboration
Re: unable to perform authenticated binds
thanks for the input guys.. I have to admit at this point, setting this up under FreeBSD was a breeze compared to what is going on now. I have made 3 attempts at this today.. twice on CentOS 5.4 and once on Ubuntu 10 Server. Given the differences in platform with identical outcomes I am thinking that it _has_ to be something with my slapd.conf file. I am still getting error 49s even if I use the actual word secret as the pass. Nov 2 19:02:00 ldap2 slapd[15768]: conn=0 fd=11 ACCEPT from IP=127.0.0.1:8 (IP=0.0.0.0:389) Nov 2 19:02:00 ldap2 slapd[15768]: conn=0 op=0 BIND dn=cn=Manager,dc=acadaca,dc=net method=128 Nov 2 19:02:00 ldap2 slapd[15768]: conn=0 op=0 RESULT tag=97 err=49 text= Nov 2 19:02:00 ldap2 slapd[15768]: conn=0 fd=11 closed (connection lost) And this is how my ldap.conf is setup BASEdc=acadaca,dc=net HOSTlocalhost I would appreciate it greatly if someone could please give it a look. Thank you On Tue, Nov 2, 2010 at 6:35 PM, Quanah Gibson-Mount qua...@zimbra.com wrote: --On Tuesday, November 02, 2010 11:07 PM +0100 Benjamin Griese der.dar...@gmail.com wrote: Hello Tim, the password you supply won't work, as it is not encoded in base64. Try to generate a password hash + base64-enc with slappasswd and set this string as your password hash for rootpw. http://linux.die.net/man/8/slappasswd Benjamin, There is no requirement that the password value for the rootpw entry in slapd.conf be SSHA hashed or Base 64 encoded. I.e., rootpw secret is perfectly valid. Also, an LDIF file with userPassword: secret is also perfectly valid, as either slapadd or slapd (via ldapadd) will take care of encoding it to Base64. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc Zimbra :: the leader in open source messaging and collaboration -- Here's my RSA Public key: gpg --keyserver pgp.mit.edu --recv-keys 5A4873A9 Share and enjoy!! slapd.conf Description: Binary data
Re: unable to perform authenticated binds
Ya know, that leading space thing confused the heck out of me when I started writing a slapf.conf from scratch. I'm guessing were ya'll to know at that start of spec'ing slapd.conf the methods that are now common to multi-line or 'containerize' options, something different, more readable, and less error (yes, user error) prone would have been selected. Really, white space shouldn't kill a config. Hindsight, eh? - chris Chris Jacobs, Systems Administrator Apollo Group | Apollo Marketing | Aptimus 2001 6th Ave Ste 3200 | Seattle, WA 98121 phone: 206.839-8245 | cell: 206.601.3256 | Fax: 208.441.9661 email: chris.jac...@apollogrp.edu - Original Message - From: openldap-technical-boun...@openldap.org openldap-technical-boun...@openldap.org To: Benjamin Griese der.dar...@gmail.com Cc: Tim Dunphy bluethu...@gmail.com; openldap-technical@openldap.org openldap-technical@openldap.org Sent: Tue Nov 02 17:30:29 2010 Subject: Re: unable to perform authenticated binds Benjamin Griese wrote: Hello Tim, the password you supply won't work, as it is not encoded in base64. Utter nonsense. You missed the more obvious problem. databasebdb suffix dc=example,dc=net rootdn cn=Manager,dc=example,dc=net # Cleartext passwords, especially for the rootdn, should # be avoided. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpwsecret # rootpw {CRYPT}secret The rootpw line has a leading space. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.
Re: unable to perform authenticated binds
Chris Jacobs wrote: Ya know, that leading space thing confused the heck out of me when I started writing a slapf.conf from scratch. I'm guessing were ya'll to know at that start of spec'ing slapd.conf the methods that are now common to multi-line or 'containerize' options, something different, more readable, and less error (yes, user error) prone would have been selected. Really, white space shouldn't kill a config. Hindsight, eh? Indeed, thanks so much for the exceedingly useful insight. The practice was established long before I joined the Project. Enough people whine about all the other insignificant, backward-compatible changes we make that changing this is obviously a non-starter. The use of whitespace is clearly described in the manpage and the Admin Guide. People who don't read the manpage deserve no sympathy. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: unable to perform authenticated binds
Howard Chu wrote: Chris Jacobs wrote: Ya know, that leading space thing confused the heck out of me when I started writing a slapf.conf from scratch. I'm guessing were ya'll to know at that start of spec'ing slapd.conf the methods that are now common to multi-line or 'containerize' options, something different, more readable, and less error (yes, user error) prone would have been selected. Really, white space shouldn't kill a config. Hindsight, eh? Indeed, thanks so much for the exceedingly useful insight. The practice was established long before I joined the Project. Since long before the Project existed, actually. Enough people whine about all the other insignificant, backward-compatible changes we make that changing this is obviously a non-starter. The use of whitespace is clearly described in the manpage and the Admin Guide. People who don't read the manpage deserve no sympathy. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: unable to perform authenticated binds
Well, I dunno, there's a /ton/ of material to cover for openldap newbies, and a simple config detail like this could be easily overlooked when figuring out how to do other things like multiple master scenarios/methods, syncing, bdb indexing for performance, the new (and exotic!) olc config, nss, pam, etc. Frankly, you're right though, they don't need sympathy. That's never helped a tech with a tech issue. If you're not calling me out via thanks so much for the exceedingly useful insight then feel free to skip the rest of this. If you were, why? I was being colloquial, friendly, and empathetic. We (well, maybe not you - I suspect you're very intelligent with a very high functioning memory/recall ability; no sarcasm!) will sometimes make silly mistakes or not understand something at first (or second!) pass. I'm not now, nor was I then, faulting anyone's past decisions or recent replies. - chris Chris Jacobs, Systems Administrator Apollo Group | Apollo Marketing | Aptimus 2001 6th Ave Ste 3200 | Seattle, WA 98121 phone: 206.839-8245 | cell: 206.601.3256 | Fax: 208.441.9661 email: chris.jac...@apollogrp.edu - Original Message - From: Howard Chu h...@symas.com To: Chris Jacobs Cc: 'der.dar...@gmail.com' der.dar...@gmail.com; 'bluethu...@gmail.com' bluethu...@gmail.com; 'openldap-technical@openldap.org' openldap-technical@openldap.org Sent: Tue Nov 02 19:23:27 2010 Subject: Re: unable to perform authenticated binds Chris Jacobs wrote: Ya know, that leading space thing confused the heck out of me when I started writing a slapf.conf from scratch. I'm guessing were ya'll to know at that start of spec'ing slapd.conf the methods that are now common to multi-line or 'containerize' options, something different, more readable, and less error (yes, user error) prone would have been selected. Really, white space shouldn't kill a config. Hindsight, eh? Indeed, thanks so much for the exceedingly useful insight. The practice was established long before I joined the Project. Enough people whine about all the other insignificant, backward-compatible changes we make that changing this is obviously a non-starter. The use of whitespace is clearly described in the manpage and the Admin Guide. People who don't read the manpage deserve no sympathy. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.