[Date Prev][Date Next]
Re: Double referral not handled properly (ITS#3361)
>Full_Name: Ian Puleston
>Submission from: (NULL) (188.8.131.52)
>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
>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
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
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
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
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
Symas: Premier OpenSource Development and Support