openldap-technical

openldap-technical@openldap.org

3 participants
9898 discussions

Re: unable to perform authenticated binds
by Tim Dunphy 05 Nov '10

05 Nov '10

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: [root@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. [root@ldap ldif]# ldapsearch -x -h ldap.acadaca.net -s base -b "cn=subschema" | grep sudoRole [root@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: [root@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: [root@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 text= 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]: 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]: daemon: activity on 1 descriptor 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_add Nov 5 15:00:33 ldap slapd[4429]: >>> dnPrettyNormal: <cn=defaults,ou=sudoers,ou=Services,dc=acadaca,dc=net> Nov 5 15:00:33 ldap slapd[4429]: <<< dnPrettyNormal: <cn=defaults,ou=sudoers,ou=Services,dc=acadaca,dc=net>, <cn=defaults,ou=sudoers,ou=services,dc=acadaca,dc=net> Nov 5 15:00:33 ldap slapd[4429]: do_add: dn (cn=defaults,ou=sudoers,ou=Services,dc=acadaca,dc=net) Nov 5 15:00:33 ldap slapd[4429]: conn=5 op=1 ADD dn="cn=defaults,ou=sudoers,ou=Services,dc=acadaca,dc=net" Nov 5 15:00:33 ldap slapd[4429]: send_ldap_result: conn=5 op=1 p=3 Nov 5 15:00:33 ldap slapd[4429]: send_ldap_result: err=21 matched="" text="objectClass: value #1 invalid per syntax" Nov 5 15:00:33 ldap slapd[4429]: send_ldap_response: msgid=2 tag=105 err=21 Nov 5 15:00:33 ldap slapd[4429]: conn=5 op=1 RESULT tag=105 err=21 text=objectClass: value #1 invalid per syntax 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]: 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]: daemon: activity on 1 descriptor 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]: ber_get_next on fd 12 failed errno=0 (Success) Nov 5 15:00:33 ldap slapd[4429]: connection_read(12): input error=-2 id=5, closing. Nov 5 15:00:33 ldap slapd[4429]: connection_closing: readying conn=5 sd=12 for close Nov 5 15:00:33 ldap slapd[4429]: connection_close: deferring conn=5 sd=-1 Nov 5 15:00:33 ldap slapd[4429]: do_unbind Nov 5 15:00:33 ldap slapd[4429]: conn=5 op=2 UNBIND Nov 5 15:00:33 ldap slapd[4429]: connection_resched: attempting closing conn=5 sd=12 Nov 5 15:00:33 ldap slapd[4429]: connection_close: conn=5 sd=-1 Nov 5 15:00:33 ldap slapd[4429]: daemon: removing 12 Nov 5 15:00:33 ldap slapd[4429]: conn=5 fd=12 closed 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]: 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 And as mentioned this exact schema configuration is working fine under OpenLDAP 2.4 under FreeBSD and behaving as you saw under OpenLDAP 2.3 CentOS 5.4 And everything looks correct to me. Any further ideas on why this isn't working? Thanks! On Thu, Nov 4, 2010 at 6:03 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Thursday, November 04, 2010 5:47 PM -0400 Tim Dunphy > <bluethundr(a)gmail.com> wrote: > >> however when I do a search for sudoRole it doesn't seem to show up >> >> [root@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 > -- Here's my RSA Public key: gpg --keyserver pgp.mit.edu --recv-keys 5A4873A9 Share and enjoy!!

2 1

Re: Issue with OpenLDAP shared libraries complie on AIX 6.1 using IBM xL Compiler
by Peter Lambrechtsen 05 Nov '10

05 Nov '10

On Wed, Nov 3, 2010 at 4:28 AM, Quanah Gibson-Mount <quanah(a)zimbra.com>wrote: > Examine config.log to see why it failed. > As per what I get in the config.log configure:8474: checking if cc_r -qlanglvl=extc89 static flag works configure:8502: result: yes configure:8570: checking for cc_r -qlanglvl=extc89 option to produce PIC configure:8774: result: configure:8841: checking if cc_r -qlanglvl=extc89 supports -c -o file.o configure:8862: cc_r -qlanglvl=extc89 -c -I/opt/openldap/include -I/opt/openldap/include -o out/conftest2.o conftest.c >&5 configure:8866: $? = 0 configure:8888: result: yes configure:8914: checking whether the cc_r -qlanglvl=extc89 linker (/usr/ccs/bin/ld) supports shared libraries configure:9790: result: no --- Any way to get a more verbose output from what it's trying to do?? configure:9861: checking dynamic linker characteristics configure:10415: result: no configure:10419: checking how to hardcode library paths into programs configure:10444: result: unsupported configure:10458: checking whether stripping libraries is possible configure:10479: result: no configure:10586: checking for shl_load configure:10642: cc_r -qlanglvl=extc89 -o conftest -I/opt/openldap/include -I/opt/openldap/include -L/opt/openldap/lib conftest.c >&5 ld: 0711-317 ERROR: Undefined symbol: .shl_load -- I think this is the prolbem, shl_load, looks like I may need another include or figure out why it's complaining. ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. configure:10648: $? = 8 configure: failed program was: | /* confdefs.h. */ | #define PACKAGE_NAME "" | #define PACKAGE_TARNAME "" | #define PACKAGE_VERSION "" | #define PACKAGE_STRING "" | #define PACKAGE_BUGREPORT "" | #define OPENLDAP_PACKAGE "OpenLDAP" | #define OPENLDAP_VERSION "2.4.23" | #define LDAP_VENDOR_VERSION 20423 | #define LDAP_VENDOR_VERSION_MAJOR 2 | #define LDAP_VENDOR_VERSION_MINOR 4 | #define LDAP_VENDOR_VERSION_PATCH 23 | #define HAVE_MKVERSION 1 | #define STDC_HEADERS 1 | #define HAVE_SYS_TYPES_H 1 | #define HAVE_SYS_STAT_H 1 | #define HAVE_STDLIB_H 1 | #define HAVE_STRING_H 1 | #define HAVE_MEMORY_H 1 | #define HAVE_STRINGS_H 1 | #define HAVE_INTTYPES_H 1 | #define HAVE_STDINT_H 1 | #define HAVE_UNISTD_H 1 | #define HAVE_DLFCN_H 1 | /* end confdefs.h. */ | /* Define shl_load to an innocuous variant, in case <limits.h> declares shl_load. | For example, HP-UX 11i <limits.h> declares gettimeofday. */ | #define shl_load innocuous_shl_load | | /* System header to define __stub macros and hopefully few prototypes, | which can conflict with char shl_load (); below. | Prefer <limits.h> to <assert.h> if __STDC__ is defined, since | <limits.h> exists even on freestanding compilers. */ | | #ifdef __STDC__ | # include <limits.h> | #else | # include <assert.h> | #endif | | #undef shl_load | | /* Override any GCC internal prototype to avoid an error. | Use char because int might match the return type of a GCC | builtin and then its argument prototype would still apply. */ | #ifdef __cplusplus | extern "C" | #endif | char shl_load (); | /* The GNU C library defines this for functions which it implements | to always fail with ENOSYS. Some functions are actually named | something starting with __ and the normal name is an alias. */ | #if defined __stub_shl_load || defined __stub___shl_load | choke me | #endif | | int | main () | { | return shl_load (); | ; | return 0; | } configure:10665: result: no configure:10670: checking for shl_load in -ldld configure:10705: cc_r -qlanglvl=extc89 -o conftest -I/opt/openldap/include -I/opt/openldap/include -L/opt/openldap/lib conftest.c -ldld >&5 ld: 0706-006 Cannot find or open library file: -l dld ld:open(): No such file or directory configure:10711: $? = 255 configure: failed program was: | /* confdefs.h. */ | #define PACKAGE_NAME "" | #define PACKAGE_TARNAME "" | #define PACKAGE_VERSION "" | #define PACKAGE_STRING "" | #define PACKAGE_BUGREPORT "" | #define OPENLDAP_PACKAGE "OpenLDAP" | #define OPENLDAP_VERSION "2.4.23" | #define LDAP_VENDOR_VERSION 20423 | #define LDAP_VENDOR_VERSION_MAJOR 2 | #define LDAP_VENDOR_VERSION_MINOR 4 | #define LDAP_VENDOR_VERSION_PATCH 23 | #define HAVE_MKVERSION 1 | #define STDC_HEADERS 1 | #define HAVE_SYS_TYPES_H 1 | #define HAVE_SYS_STAT_H 1 | #define HAVE_STDLIB_H 1 | #define HAVE_STRING_H 1 | #define HAVE_MEMORY_H 1 | #define HAVE_STRINGS_H 1 | #define HAVE_INTTYPES_H 1 | #define HAVE_STDINT_H 1 | #define HAVE_UNISTD_H 1 | #define HAVE_DLFCN_H 1 | /* end confdefs.h. */ | | /* Override any GCC internal prototype to avoid an error. | Use char because int might match the return type of a GCC | builtin and then its argument prototype would still apply. */ | #ifdef __cplusplus | extern "C" | #endif | char shl_load (); | int | main () | { | return shl_load (); | ; | return 0; | } configure:10729: result: no configure:10734: checking for dlopen configure:10790: cc_r -qlanglvl=extc89 -o conftest -I/opt/openldap/include -I/opt/openldap/include -L/opt/openldap/lib conftest.c >&5 configure:10796: $? = 0 configure:10813: result: yes configure:11046: checking whether a program can dlopen itself configure:11118: cc_r -qlanglvl=extc89 -o conftest -I/opt/openldap/include -I/opt/openldap/include -DHAVE_DLFCN_H -L/opt/openldap/lib conftest.c >&5 configure:11121: $? = 0 configure:11139: result: no configure:11260: checking if libtool supports shared libraries configure:11262: result: no configure:11265: checking whether to build shared libraries configure:11286: result: no configure:11289: checking whether to build static libraries configure:11293: result: yes Also found something similar for Samba: http://samba.2283325.n4.nabble.com/Failing-to-make-Samba-3-5-4-on-AIX-5-3-t… So going to do more digging, or suggestions are welcome ;)

3 4

loglevel question / problem
by Aaron Bennett 05 Nov '10

05 Nov '10

Hi, I have two reasonably identical Ubuntu Server 10.04 boxes running OpenLdap 2.4.21. ( I say reasonable identical because one is a master and the other pulls via syncrepl ). The master box is sending copious amount of query log info to syslog -- it looks like it's logging every search and connection. The other box looks like it's only logging syncrepl information to the debug facility. What I can't figure out is how this is happening. When I started, neither machine had olcLogLevel entries in cn=config.ldif ; I have since added olcLogLevel: none (no effect) and even olcLogLevel: 0 to the master, restarting slapd each time. I've verified that it's not getting any "-d" switch on startup, both by looking at the SLAPD_OPTIONS in /etc/default/slapd and with ps -ax (which shows /usr/sbin/slapd -h ldaps:/// ldap:/// ldapi:/// -g openldap -u openldap -F /etc/ldap/slapd.d). Here's sample syslog output from the master: Nov 5 07:48:06 nyx slapd[5100]: conn=1008 op=1357 SRCH attr=mailRoutingAddress Nov 5 07:48:06 nyx slapd[5100]: conn=1008 op=1357 SEARCH RESULT tag=101 err=0 nentries=0 text= Nov 5 07:48:06 nyx slapd[5100]: conn=1008 op=1358 SRCH base="dc=clarku,dc=edu" scope=2 deref=0 filter="(|(mail=@clarku.edu)(mailAlternateAddress=@clarku.edu))" Nov 5 07:48:06 nyx slapd[5100]: conn=1008 op=1358 SRCH attr=mailRoutingAddress Nov 5 07:48:06 nyx slapd[5100]: conn=1008 op=1358 SEARCH RESULT tag=101 err=0 nentries=1 text= Nov 5 07:48:06 nyx slapd[5100]: conn=1007 op=10647 SRCH base="dc=clarku,dc=edu" scope=2 deref=0 filter="(|(mail=clarku.edu)(mailAlternateAddress=clarku.edu))" And here's sample from the slave: Nov 5 07:54:21 erebus slapd[7913]: syncrepl_entry: rid=001 be_modify uid=dgoldman,ou=Users,dc=clarku,dc=edu (0) Nov 5 07:54:21 erebus slapd[7913]: slap_queue_csn: queing 0x7f730550e7e0 20101105115421.300608Z#000000#000#000000 Nov 5 07:54:21 erebus slapd[7913]: slap_graduate_commit_csn: removing 0x7f730407f560 20101105115421.300608Z#000000#000#000000 Nov 5 07:54:21 erebus slapd[7913]: do_syncrep2: rid=001 cookie=rid=001,csn=20101105115421.483388Z#000000#000#000000 Nov 5 07:54:21 erebus slapd[7913]: syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) Is there some other place that this information could be living? Thanks, Aaron Bennett Clark University ITS

1 0

openldap 2.4.2[13] socket close bug ?
by Arjan Filius 05 Nov '10

05 Nov '10

Hello openldap ml, while researching more or less regular xen/centos/openldap crash situation, i ran into a situation which i think is a (openldap) bug. Tested with self compiled/packed openldap 2.4.21 and 2.4.23 on centos 5.2 64 bits The most easy way to explain and test (for me) is: 1) Set threads to 2 in slapd.conf 2) Start a ldap search query which takes some time (say longer then a minute or so) ps: local or remote ldapsearch doesn't matter ps: i used ldapsearch and a "slowcat" to simulate 3) start a second ldap search querry as with 2) 4) Try to start a third ldapsearch query, which you may notice would connect (tcp backlog), but not yet handled by slapd. Normally when the first ldapsearch session would stop, the third session will be handled by slapd, which works just fine as expected, no need to test that now. >From now on you have some slightly different situations, which i will number 5a ....) 5a) while those first 2 sessions are still running, and session 3 is waiting, lets kill session 1 or 2, and here it happens: -slapd won't log the killed session, and the third session isn't going to handled. -The third session is going to be handled as soon as the second session finishes in a normal way. 5b) while those first 2 sessions are still running, and session 3 is waiting, kill all ldap search querries (press ^C within your ldapsearch for example) , and here it happens: -slapd won't log died sessions -new ldapsearch sessions are accepted by the backlog buffer, but are never going to be accepted by the slapd process. -when stopping slapd it complains about closing already died sessions/socket. So it looks like killed sessions, are not quite handled correctly within slapd, and i noticed as soon there is one session which finishes in a normal way, it will also clear and free the killed sessions. The other way arond, when killing all sessions, you've a denial of service, and no session will ever be cleared. Please confirm or deny, feedback welcome. Regards, -- Arjan Filius iafilius(a)xs4all.nl

1 1

Re: unable to perform authenticated binds
by Tim Dunphy 04 Nov '10

04 Nov '10

hi quannah, well from the includes in slapd.conf it certainly would appear to have been installed 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 however when I do a search for sudoRole it doesn't seem to show up [root@ldap openldap]# ldapsearch -b '' -s base '(objectclass=*)' sudoRole -x -W -D "cn=Manager,dc=acadaca,dc=net" Enter LDAP Password: # extended LDIF # # LDAPv3 # base <> with scope baseObject # filter: (objectclass=*) # requesting: sudoRole # # dn: # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 On Thu, Nov 4, 2010 at 5:41 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > Are you certain the schema for sudoRole has really been added? Have you > browsed the subschema entry while the server is running to verify it is > present? > > --Quanah > > --On Thursday, November 04, 2010 5:25 PM -0400 Tim Dunphy > <bluethundr(a)gmail.com> wrote: > >> My bad Quannah in sending to your direct email .. and my apologies >> >> >> Well it seems that I am running version 2.3 on the CentOS box and >> version 2.4 on the FreeBSD box.. >> >> >> Here's the class definition for sudoRole >> >> objectclass ( 1.3.6.1.4.1.15953.9.2.1 NAME 'sudoRole' SUP top STRUCTURAL >> DESC 'Sudoer Entries' >> MUST ( cn ) >> MAY ( sudoUser $ sudoHost $ sudoCommand $ sudoRunAs $ >> sudoRunAsUser $ sudoRunAsGroup $ sudoOption $ >> description ) >> ) >> >> >> could it be just that the older version is running under CentOS? any >> advice on how to get sudoRole working under openldap 2.3? > > Are you certain the schema for sudoRole has really been added? Have you > browsed the subschema entry while the server is running to verify it is > present? > > --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!!

2 1

Re: unable to perform authenticated binds
by Tim Dunphy 04 Nov '10

04 Nov '10

My bad Quannah in sending to your direct email .. and my apologies Well it seems that I am running version 2.3 on the CentOS box and version 2.4 on the FreeBSD box.. Here's the class definition for sudoRole objectclass ( 1.3.6.1.4.1.15953.9.2.1 NAME 'sudoRole' SUP top STRUCTURAL DESC 'Sudoer Entries' MUST ( cn ) MAY ( sudoUser $ sudoHost $ sudoCommand $ sudoRunAs $ sudoRunAsUser $ sudoRunAsGroup $ sudoOption $ description ) ) could it be just that the older version is running under CentOS? any advice on how to get sudoRole working under openldap 2.3? thanks On Thu, Nov 4, 2010 at 5:11 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Thursday, November 04, 2010 5:04 PM -0400 Tim Dunphy > <bluethundr(a)gmail.com> wrote: > >> hmm... so basically it's a syntax error in the LDIF? interesting.. >> that is the exact same entry I have under my working FreeBSD >> configuration... > > Keep your questions to the list please. My guess is that the FreeBSD > configuration is using an older version of OpenLDAP with schema checking > disabled? Since I don't know what the definition of that objectClass is, as > you haven't supplied it, I can't really say why that error is being > generated. > > --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!!

2 1

Re: unable to perform authenticated binds
by Quanah Gibson-Mount 04 Nov '10

04 Nov '10

--On Thursday, November 04, 2010 5:04 PM -0400 Tim Dunphy <bluethundr(a)gmail.com> wrote: > hmm... so basically it's a syntax error in the LDIF? interesting.. > that is the exact same entry I have under my working FreeBSD > configuration... Keep your questions to the list please. My guess is that the FreeBSD configuration is using an older version of OpenLDAP with schema checking disabled? Since I don't know what the definition of that objectClass is, as you haven't supplied it, I can't really say why that error is being generated. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: unable to perform authenticated binds
by Tim Dunphy 04 Nov '10

04 Nov '10

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 <quanah(a)zimbra.com> wrote: > --On Thursday, November 04, 2010 3:37 PM -0400 Tim Dunphy > <bluethundr(a)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 > -- Here's my RSA Public key: gpg --keyserver pgp.mit.edu --recv-keys 5A4873A9 Share and enjoy!!

2 1

Re: unable to perform authenticated binds
by Tim Dunphy 04 Nov '10

04 Nov '10

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 [root@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 <quanah(a)zimbra.com> wrote: > --On Tuesday, November 02, 2010 7:59 PM -0700 Chris Jacobs > <Chris.Jacobs(a)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!!

4 6

pwdChangedTime: and system timestamp
by Michael Starling 04 Nov '10

04 Nov '10

When looking at the value of pwdChangedTime on my openldap system everything seems to be correct except for the hours/minutes/seconds fields. If I have a value of pwdChangedTime: 20101104165037Z in LDAP The date command shows Thu Nov 4 13:04:30 EDT 2010 How are these the same or relatively close? -Mike

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical