Re: Double referral not handled properly (ITS#3361)

[hyc@symas.com]

ipuleston@sonicwall.com wrote:

>Full_Name: Ian Puleston
>Version: 2.2.17
>OS: vxWorks
>URL: ftp://ftp.openldap.org/incoming/
>Submission from: (NULL) (64.220.173.243)
>
>
>I have a vxWorks port of OpenLDAP 2.2.17 client connecting to 3 LDAP servers
>using referrals. The client talks directly to server A. Server A refers
>unmatched requests to server B, and server B refers unmatched requests to server
>C. If I initiate a search for objects located on server A or server B it works
>fine, however a search for objects located on server C (i.e. requiring two
>referrals) has problems. It actually completes successfully, but goes through
>additional unnecessary steps to do it. The sequence of events is:
>
>1. The client successfully binds to server A.
>2. The client sends the search request to server A. Server A returns a referral
>to server B.
>3. The client successfully binds to server B.
>4. The client sends the search request to server B. Server B returns a referral
>to server C.
>5. The client successfully binds to server C.
>6. The client then sends another bind to server C which is also successful.
>7. The client then unbinds from server C.
>8. The client then sends the search request to server B. Server B returns a
>referral to server C.
>9. The client successfully binds to server C.
>10. The client then sends the search request to server C. Server C returns the
>search results.
>11. The client then unbinds from server C.
>
>Steps 6 thru 9 are "surplus to requirements".
>
>
>The following is an Ethereal trace of the LDAP packets:
>
>Time      Source       Destination  Info
>0.028937  Client       Server_A     MsgId=1 Bind Request
>0.030059  Server_A     Client       MsgId=1 Bind Result
>0.141292  Client       Server_A     MsgId=2 Search Request, Base DN=dc=sub3,dc=
>...
>0.142351  Server_A     Client       MsgId=2 Search Result, Referral
>0.362101  Client       Server_B     MsgId=4 Bind Request
>0.364039  Server_B     Client       MsgId=4 Bind Result, Referral
>0.597262  Client       Server_C     MsgId=6 Bind Request
>0.658788  Server_C     Client       MsgId=6 Bind Result
>0.739044  Client       Server_C     MsgId=5 Bind Request
>0.802516  Server_C     Client       MsgId=5 Bind Result
>0.874740  Client       Server_C     MsgId=7 Unbind Request
>0.884954  Client       Server_B     MsgId=3 Search Request, Base DN=dc=sub3,dc=
>...
>0.886646  Server_B     Client       MsgId=3 Search Result, Referral
>1.112813  Client       Server_C     MsgId=9 Bind Request
>1.175319  Server_C     Client       MsgId=9 Bind Result
>1.250461  Client       Server_C     MsgId=8 Search Request, Base DN=dc=sub3,dc=
>...
>1.417046  Server_C     Client       MsgId=8 Search Entry
>1.435281  Server_C     Client       MsgId=8 Search Result
>1.549826  Client       Server_C     MsgId=10 Unbind Request
>
This trace shows that both the client library and server B are "being 
stupid."

In general, a server should not return a referral for a Bind request, 
because that does not in any way help accomplish the goal of such a 
request. (I.e., presumably you send a Bind request to a server to 
perform authentication *on that server*. Having it refer you to another 
server leaves you still unauthenticated on that original server.) I 
believe the current (2.2.17) slapd no longer returns referrals for Bind 
requests.

The client library always issues a Bind to the target server when 
chasing a referral. This happens before it looks at whatever request is 
being referred - which in this case is itself a Bind request. That's why 
you see two Bind requests in a row, followed by an Unbind - that is the 
client library processing the referral returned from the Bind request to 
server B.

Again, since it makes no sense to chase referrals for Bind requests, 
probably the client should ignore them. Failing that, it should be smart 
enough not to issue two redundant Binds in a row. But since this isn't 
causing a critical failure anywhere, I don't see changing this as a very 
high priority.

-- 
  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support