[Date Prev][Date Next] [Chronological] [Thread] [Top]
Re: Cannot find rootDN

To: "Tibbetts, Ric" <ric.tibbetts@ngc.com>
Subject: Re: Cannot find rootDN
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Date: Thu, 05 Feb 2004 10:37:59 -0800
Cc: openldap-software@OpenLDAP.org
In-reply-to: <40224A0C.1090301@ngc.com>
References: <4020074F.4010400@ngc.com> <5727135.1075814202@cadabra.stanford.edu> <4020F52D.9080504@ngc.com> <79306656.1075887784@cadabra.stanford.edu> <40213C95.10806@ngc.com> <6.0.1.1.0.20040204123909.046b8220@127.0.0.1> <40224A0C.1090301@ngc.com>
At 05:50 AM 2/5/2004, Tibbetts, Ric wrote:
>Thanks Kurt;
>1) However, the client was not previously hacked.
>2) The client (and all other Solaris clients) will authenticate just fine against the other LDAP server.

>      It is just this server specifically that I'm having this problem with.

Which implies that old server was hacked.  When I said
"OpenLDAP Software" before I wasn't referring to the Solaris
client.

Kurt


>-Ric
>
>
>
>Kurt D. Zeilenga wrote:
>
>>Seems to me that the client requested, without authenticating
>>first, the return of the root DSE.  It got what it asked for:
>>the root DSE.  However, I note that the client did not ask the
>>return of any operational attributes and, hence, none were provided.
>>However, if one look at your original post, the client was complaining
>>about not being able to locate any naming contexts (values of the
>>namingContext (operational) attribute in the root DSE).  The client
>>appears to be broken in that it expects the return of operational
>>attributes which it didn't ask to be returned.
>>
>>Since you said this occurred only after upgrading OpenLDAP Software,
>>i surmise that you were running a hacked version of OpenLDAP Software
>>previously to work around this client problem.  If you haven't
>>yet fixed (through the maintainer of this client) the problem, you
>>might try applying a similar hack to the later version of OpenLDAP
>>Software.
>>
>>Kurt
>>
>>At 10:40 AM 2/4/2004, Tibbetts, Ric wrote:
>>
>>
>> 
>>
>>>Quanah Gibson-Mount wrote:
>>>
>>>   
>>>
>>>>--On Wednesday, February 04, 2004 8:35 AM -0500 "Tibbetts, Ric" <ric.tibbetts@ngc.com> wrote:
>>>>
>>>>     
>>>>
>>>>>>What verion(s) did you upgrade from/to?
>>>>>>         
>>>>>
>>>>>(On the server)
>>>>From OpenLDAP 2.1.22
>>>>>
>>>>>To OpenLDAP 2.1.25 w/ Berkeley DB 4.2.52
>>>>>       
>>>>
>>>>I hope you got the patch for BDB 4.2.52
>>>>     
>>>I don't remember for sure. It was a couple of months ago.
>>>This is all on a development server, so there was no rush.
>>>Now I need to start building the production server, so it has become important.
>>>I'll be sure to add the patch to the full production version, once I get this one debugged.
>>>
>>>   
>>>
>>>>>It should have been a relatively routine upgrade.
>>>>>It's important to note that my AIX, and Linux clients are still able to
>>>>>authenticate without problem.
>>>>>It's only the Solaris clients that this affected.
>>>>>       
>>>>
>>>>Hm, that is odd.  Did you patch any of your solaris systems recently?
>>>>     
>>>I've done several things. But nothing that would effect this.
>>>And I've tried several systems.
>>>
>>>The primary system I'm using as a test client, was recently re-installed. It is still able to attach, and authenticate to the other LDAP server (we also have a Sun One Directory Server. There is no problem attaching to that.
>>>
>>>   
>>>
>>>>>When I did the upgrade, because I was changing the database, I exported
>>>>>the whole thing first with "slapcat". Then after installing the new s/w,
>>>>>I ran slapadd to put it all back.
>>>>>It seems to have dropped something.
>>>>>       
>>>>
>>>>I've never had slapadd "drop" anything... It just loads what is in the LDIF output.  Did you run slapadd with the '-c' option? If you did, and it had output, that would indicate you had errors in your LDIF as compared to your schema, which it would then skip past.
>>>>     
>>>I was being a bit tongue in cheek about that.
>>>I didn't run slapad with -c. If it had encountered errors, I would have prefered it stopped.
>>>It completed with no errors.
>>>
>>>   
>>>
>>>>     
>>>>
>>>>>The logs haven't been much help.
>>>>>Setting the loglevel to 128, shows the interaction with the ACLs, and I'm
>>>>>not seeing where anything is being denied.
>>>>>Below is an example run:
>>>>>       
>>>>
>>>>That log output isn't particularly useful.  If possible, I suggest having an isolated machine you can query with a Solaris system, and run slapd with the '-d -1' flag, and dump that output to a file as a connection is made. It will give you all relevant information.
>>>>     
>>>Okay, I did this, and got no rejects.
>>>So it is not rejecting the connection. It did come up with some errors about:
>>>
>>>ldap_read: want=8 error=Resource temporarily unavailable
>>>conn=0 op=1 UNBIND
>>>ber_get_next on fd 12 failed errno=11 (Resource temporarily unavailable)
>>>
>>>The complete file looks like:
>>>(Note: I trimmed off the top where slapd was starting, and dumping the schema parsing to the file.
>>>daemon: activity on 1 descriptors
>>>daemon: new connection on 12
>>>conn=0 fd=12 ACCEPT from IP=132.228.132.44:59223 (IP=0.0.0.0:389)
>>>daemon: added 12r
>>>daemon: activity on:
>>>daemon: select: listen=6 active_threads=0 tvp=NULL
>>>daemon: select: listen=7 active_threads=0 tvp=NULL
>>>daemon: select: listen=8 active_threads=0 tvp=NULL
>>>daemon: select: listen=9 active_threads=0 tvp=NULL
>>>daemon: activity on 1 descriptors
>>>daemon: activity on: 12r
>>>daemon: read activity on 12
>>>connection_get(12)
>>>connection_get(12): got connid=0
>>>connection_read(12): checking for input on id=0
>>>ber_get_next
>>>ldap_read: want=8, got=8
>>>0000:  30 25 02 01 01 63 20 04                            0%...c .
>>>ldap_read: want=31, got=31
>>>0000:  00 0a 01 00 0a 01 03 02  01 00 02 01 1e 01 01 00   ................
>>>0010:  87 0b 6f 62 6a 65 63 74  63 6c 61 73 73 30 00      ..objectclass0.
>>>ber_get_next: tag 0x30 len 37 contents:
>>>ber_dump: buf=0x002f92a8 ptr=0x002f92a8 end=0x002f92cd len=37
>>>0000:  02 01 01 63 20 04 00 0a  01 00 0a 01 03 02 01 00   ...c ...........
>>>0010:  02 01 1e 01 01 00 87 0b  6f 62 6a 65 63 74 63 6c   ........objectcl
>>>0020:  61 73 73 30 00                                     ass0.
>>>ber_get_next
>>>ldap_read: want=8 error=Resource temporarily unavailable
>>>ber_get_next on fd 12 failed errno=11 (Resource temporarily unavailable)
>>>do_search
>>>ber_scanf fmt ({miiiib) ber:
>>>daemon: select: listen=6 active_threads=1 tvp=NULL
>>>ber_dump: buf=0x002f92a8 ptr=0x002f92ab end=0x002f92cd len=34
>>>0000:  63 20 04 00 0a 01 00 0a  01 03 02 01 00 02 01 1e   c ..............
>>>0010:  01 01 00 87 0b 6f 62 6a  65 63 74 63 6c 61 73 73   .....objectclass
>>>0020:  30 00                                              0.
>>>daemon: select: listen=7 active_threads=1 tvp=NULL
>>>   
>>>
>>>>>>dnPrettyNormal: <>
>>>>>>         
>>><<< dnPrettyNormal: <>, <>
>>>SRCH "" 0 3    0 30 0
>>>begin get_filter
>>>PRESENT
>>>ber_scanf fmt (m) ber:
>>>ber_dump: buf=0x002f92a8 ptr=0x002f92be end=0x002f92cd len=15
>>>0000:  87 0b 6f 62 6a 65 63 74  63 6c 61 73 73 30 00      ..objectclass0.
>>>daemon: select: listen=8 active_threads=1 tvp=NULL
>>>end get_filter 0
>>>daemon: select: listen=9 active_threads=1 tvp=NULL
>>>filter: (objectClass=*)
>>>ber_scanf fmt ({M}}) ber:
>>>ber_dump: buf=0x002f92a8 ptr=0x002f92cb end=0x002f92cd len=2  0000:  00 00                                              ..
>>>attrs:
>>>conn=0 op=0 SRCH base="" scope=0 filter="(objectClass=*)"
>>>=> test_filter
>>>PRESENT
>>>=> access_allowed: search access to "" "objectClass" requested
>>>=> acl_get: [1] check attr objectClass
>>>=> dn: [2]
>>>=> acl_get: [2] matched
>>>=> acl_get: [2] check attr objectClass
>>><= acl_get: [2] acl  attr: objectClass
>>>=> acl_mask: access to entry "", attr "objectClass" requested
>>>=> acl_mask: to all values by "", (=n)
>>><= check a_peername_path: 127.0.0.1
>>>=> string_expand: pattern:  127.0.0.1
>>>=> string_expand: expanded: 127.0.0.1
>>>=> regex_matches: string:        IP=132.228.132.44:59223
>>>=> regex_matches: rc: 1 no matches
>>><= check a_peername_path: 132.228.*.*
>>>=> string_expand: pattern:  132.228.*.*
>>>=> string_expand: expanded: 132.228.*.*
>>>=> regex_matches: string:        IP=132.228.132.44:59223
>>>=> regex_matches: rc: 0 matches
>>><= acl_mask: [2] applying read(=rscx) (stop)
>>><= acl_mask: [2] mask: read(=rscx)
>>>=> access_allowed: search access granted by read(=rscx)
>>><= test_filter 6
>>>=> send_search_entry: dn=""
>>>=> access_allowed: read access to "" "entry" requested
>>>=> acl_get: [1] check attr entry
>>>=> dn: [2]
>>>=> acl_get: [2] matched
>>>=> acl_get: [2] check attr entry
>>><= acl_get: [2] acl  attr: entry
>>>=> acl_mask: access to entry "", attr "entry" requested
>>>=> acl_mask: to all values by "", (=n)
>>><= check a_peername_path: 127.0.0.1
>>>=> string_expand: pattern:  127.0.0.1
>>>=> string_expand: expanded: 127.0.0.1
>>>=> regex_matches: string:        IP=132.228.132.44:59223
>>>=> regex_matches: rc: 1 no matches
>>><= check a_peername_path: 132.228.*.*
>>>=> string_expand: pattern:  132.228.*.*
>>>=> string_expand: expanded: 132.228.*.*
>>>=> regex_matches: string:        IP=132.228.132.44:59223
>>>=> regex_matches: rc: 0 matches
>>><= acl_mask: [2] applying read(=rscx) (stop)
>>><= acl_mask: [2] mask: read(=rscx)
>>>=> access_allowed: read access granted by read(=rscx)
>>>=> access_allowed: read access to "" "objectClass" requested
>>>=> acl_get: [1] check attr objectClass
>>>=> dn: [2]
>>>=> acl_get: [2] matched
>>>=> acl_get: [2] check attr objectClass
>>><= acl_get: [2] acl  attr: objectClass
>>>access_allowed: no res from state (objectClass)
>>>=> acl_mask: access to entry "", attr "objectClass" requested
>>>=> acl_mask: to all values by "", (=n)
>>><= check a_peername_path: 127.0.0.1
>>>=> string_expand: pattern:  127.0.0.1
>>>=> string_expand: expanded: 127.0.0.1
>>>=> regex_matches: string:        IP=132.228.132.44:59223
>>>=> regex_matches: rc: 1 no matches
>>><= check a_peername_path: 132.228.*.*
>>>=> string_expand: pattern:  132.228.*.*
>>>=> string_expand: expanded: 132.228.*.*
>>>=> regex_matches: string:        IP=132.228.132.44:59223
>>>=> regex_matches: rc: 0 matches
>>><= acl_mask: [2] applying read(=rscx) (stop)
>>><= acl_mask: [2] mask: read(=rscx)
>>>=> access_allowed: read access granted by read(=rscx)
>>>ber_flush: 50 bytes to sd 12
>>>0000:  30 30 02 01 01 64 2b 04  00 30 27 30 25 04 0b 6f   00...d+..0'0%..o
>>>0010:  62 6a 65 63 74 43 6c 61  73 73 31 16 04 03 74 6f   bjectClass1...to
>>>0020:  70 04 0f 4f 70 65 6e 4c  44 41 50 72 6f 6f 74 44   p..OpenLDAProotD
>>>0030:  53 45                                              SE
>>>ldap_write: want=50, written=50
>>>0000:  30 30 02 01 01 64 2b 04  00 30 27 30 25 04 0b 6f   00...d+..0'0%..o
>>>0010:  62 6a 65 63 74 43 6c 61  73 73 31 16 04 03 74 6f   bjectClass1...to
>>>0020:  70 04 0f 4f 70 65 6e 4c  44 41 50 72 6f 6f 74 44   p..OpenLDAProotD
>>>0030:  53 45                                              SE
>>>conn=0 op=0 ENTRY dn=""
>>><= send_search_entry
>>>send_ldap_result: conn=0 op=0 p=3
>>>send_ldap_result: err=0 matched="" text=""
>>>send_ldap_response: msgid=1 tag=101 err=0
>>>ber_flush: 14 bytes to sd 12
>>>0000:  30 0c 02 01 01 65 07 0a  01 00 04 00 04 00         0....e........
>>>ldap_write: want=14, written=14
>>>0000:  30 0c 02 01 01 65 07 0a  01 00 04 00 04 00         0....e........
>>>conn=0 op=0 RESULT tag=101 err=0 text=
>>>daemon: activity on 1 descriptors
>>>daemon: activity on: 12r
>>>daemon: read activity on 12
>>>connection_get(12)
>>>connection_get(12): got connid=0
>>>connection_read(12): checking for input on id=0
>>>ber_get_next
>>>ldap_read: want=8, got=7
>>>0000:  30 05 02 01 02 42 00                               0....B.
>>>ber_get_next: tag 0x30 len 5 contents:
>>>ber_dump: buf=0x002fa7f8 ptr=0x002fa7f8 end=0x00ber_get_next
>>>do_unbind
>>>ldap_read: want=8 error=Resource temporarily unavailable
>>>conn=0 op=1 UNBIND
>>>ber_get_next on fd 12 failed errno=11 (Resource temporarily unavailable)
>>>daemon: select: listen=6 active_threads=1 tvp=NULL
>>>connection_closing: readying conn=0 sd=12 for close
>>>daemon: select: listen=7 active_threads=1 tvp=NULL
>>>daemon: select: listen=8 active_threads=1 tvp=NULL
>>>daemon: select: listen=9 active_threads=1 tvp=NULL
>>>daemon: activity on 2 descriptors
>>>connection_resched: attempting closing conn=0 sd=12
>>>daemon: select: listen=6 active_threads=1 tvp=NULL
>>>connection_close: conn=0 sd=12
>>>daemon: select: listen=7 active_threads=1 tvp=NULL
>>>daemon: removing 12
>>>daemon: select: listen=8 active_threads=1 tvp=NULL
>>>conn=0 fd=12 closed
>>>daemon: select: listen=9 active_threads=1 tvp=NULL
>>>daemon: shutdown requested and initiated.
>>>daemon: closing 6
>>>daemon: closing 7
>>>daemon: closing 8
>>>daemon: closing 9
>>>slapd shutdown: waiting for 0 threads to terminate
>>>slapd shutdown: initiated
>>>====> bdb_cache_release_all
>>>slapd shutdown: freeing system resources.
>>>====> bdb_cache_release_all
>>>slapd stopped.
>>>2fa7fd len=5
>>>0000:  02 01 02 42 00                                     ...B.
>>>
>>>Note: The bit at the end is where I shut it down folloing this test.
>>>For a while, I suspected myt ACLs, but there's no rejections through that section.
>>>
>>>Any thoughts?
>>>
>>>Thanks!!1
>>>
>>>-Ric
>>>   
>>
>>
Follow-Ups:
- Re: Cannot find rootDN
  - From: "Tibbetts, Ric" <ric.tibbetts@ngc.com>
References:
- Cannot find rootDN
  - From: "Tibbetts, Ric" <ric.tibbetts@ngc.com>
- Re: Cannot find rootDN
  - From: Quanah Gibson-Mount <quanah@stanford.edu>
- Re: Cannot find rootDN
  - From: "Tibbetts, Ric" <ric.tibbetts@ngc.com>
- Re: Cannot find rootDN
  - From: Quanah Gibson-Mount <quanah@stanford.edu>
- Re: Cannot find rootDN
  - From: "Tibbetts, Ric" <ric.tibbetts@ngc.com>
- Re: Cannot find rootDN
  - From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
- Re: Cannot find rootDN
  - From: "Tibbetts, Ric" <ric.tibbetts@ngc.com>
Prev by Date: Re: Did someone try Heimdal with openldap-2.2.x as backend ?
Next by Date: Disable NULL BASE queries
Index(es):
- Chronological
- Thread