Full_Name: Jeremiah Martell Version: 2.4.21 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.146.101.71) I have three windows active directory servers setup: childA.parent.example.com parent.example.com childB.parent.example.com I do a LDAP+GSSAPI bind to childA.parent.example.com. The bind succeeds. I do a search that returns referrals, (I know I need to be referred to parent, and then childB in order to find my result), and I have openldap follow referrals for me. My rebind proc is a function that only calls: ldap_sasl_interactive_bind_s( ld, NULL, NULL, NULL, NULL, LDAP_SASL_AUTOMATIC, sasl_driver, params ); where sasl_driver and params is the same parameters that I used for the initial bind call to childA. After the seach call, the debug looks like this: > ldap_chase_v3referrals, where ref[0] = parent.example.com > myGSSAPIrebindProc > ldap_sasl_interactive_bind_s < ldap_sasl_interactive_bind_s < myGSSAPIrebindProc < ldap_chase_v3referrals > ldap_chase_v3referrals, where ref[0] = childB.parent.example.com > myGSSAPIrebindProc > ldap_sasl_interactive_bind_s > ldap_chase_v3referrals, where ref[0] = childA.parent.example.com < ldap_chase_v3referrals > ldap_chase_v3referrals, where ref[0] = ForestDnsZones.parent.example.com > myGSSAPIrebindProc > ldap_sasl_interactive_bind_s ... HANG ON MUTEX I changed openldap to make all mutex's recursive, and this fixed my problem. I was then able to search, chase referrals, bind to referrals with ldap_sasl_interactive_bind_s, and eventually find my result. Thanks, - Jeremiah
inlovewithGod@gmail.com wrote: > Full_Name: Jeremiah Martell > Version: 2.4.21 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (192.146.101.71) > > > I have three windows active directory servers setup: > childA.parent.example.com > parent.example.com > childB.parent.example.com > > I do a LDAP+GSSAPI bind to childA.parent.example.com. > The bind succeeds. > > I do a search that returns referrals, (I know I need to be referred to > parent, and then childB in order to find my result), > and I have openldap follow referrals for me. > > My rebind proc is a function that only calls: > ldap_sasl_interactive_bind_s( ld, NULL, NULL, NULL, NULL, > LDAP_SASL_AUTOMATIC, sasl_driver, params ); > where sasl_driver and params is the same parameters that I used for > the initial bind call to childA. > > After the seach call, the debug looks like this: > >> ldap_chase_v3referrals, where ref[0] = parent.example.com > > myGSSAPIrebindProc > > ldap_sasl_interactive_bind_s > < ldap_sasl_interactive_bind_s > < myGSSAPIrebindProc > < ldap_chase_v3referrals > >> ldap_chase_v3referrals, where ref[0] = childB.parent.example.com > > myGSSAPIrebindProc > > ldap_sasl_interactive_bind_s > > ldap_chase_v3referrals, where ref[0] = childA.parent.example.com > < ldap_chase_v3referrals > > ldap_chase_v3referrals, where ref[0] = > ForestDnsZones.parent.example.com > > myGSSAPIrebindProc > > ldap_sasl_interactive_bind_s ... HANG ON MUTEX > > I changed openldap to make all mutex's recursive, and this fixed my problem. I > was then able to search, chase referrals, bind to referrals with > ldap_sasl_interactive_bind_s, and eventually find my result. Sounds like your servers are mis-configured, it is not legal to send a referral in response to a Bind request. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
On Apr 8, 2010, at 3:58 PM, hyc@symas.com wrote: > Sounds like your servers are mis-configured, it is not legal to send a > referral in response to a Bind request. I note that the technical specification doesn't actually preclude return of a referral in response to a Bind request. However, in practice, such return is quite problematic due to ambiguous semantics and security considerations. -- Kurt
Kurt@OpenLDAP.org wrote: > On Apr 8, 2010, at 3:58 PM, hyc@symas.com wrote: > >> Sounds like your servers are mis-configured, it is not legal to send a=20= > >> referral in response to a Bind request. > > I note that the technical specification doesn't actually preclude return = > of a referral in response to a Bind request. However, in practice, such = > return is quite problematic due to ambiguous semantics and security = > considerations. Right. I can't find the discussion we had about this back in 2004, but certainly we've already hashed this out in great detail before. The fact is that acting on a referral simply means performing a Bind against some other server. It does nothing for the authentication state of the session on the original server. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
On Apr 8, 2010, at 8:08 PM, Howard Chu wrote: > Kurt@OpenLDAP.org wrote: >> On Apr 8, 2010, at 3:58 PM, hyc@symas.com wrote: >> >>> Sounds like your servers are mis-configured, it is not legal to send a=20= >> >>> referral in response to a Bind request. >> >> I note that the technical specification doesn't actually preclude return = >> of a referral in response to a Bind request. However, in practice, such = >> return is quite problematic due to ambiguous semantics and security = >> considerations. > > Right. I can't find the discussion we had about this back in 2004, but certainly we've already hashed this out in great detail before. > > The fact is that acting on a referral simply means performing a Bind against some other server. > It does nothing for the authentication state of the session on the original server. Right, by returning a referral, regardless of how far the client got in authentication process (including completion of all challenges), the client is now anonymous at the original server. And there's a security concern, the referral information is not protected by the underlying authentication mechanism. It is actually quite possible that this be used by an attacker to cause the client to try authentication multiple times, possibly with chosen plaintext. I recommend that the library never chase bind referrals. (I tend to think of rebind as a misfeature. Robust clients really should be using the async API and carefully managing security contexts and chasing.) -- Kurt
changed notes changed state Open to Test moved from Incoming to Development
Kurt@OpenLDAP.org wrote: > On Apr 8, 2010, at 8:08 PM, Howard Chu wrote: > >> Kurt@OpenLDAP.org wrote: >>> On Apr 8, 2010, at 3:58 PM, hyc@symas.com wrote: >>> =20 >>>> Sounds like your servers are mis-configured, it is not legal to send = > a=3D20=3D >>> =20 >>>> referral in response to a Bind request. >>> =20 >>> I note that the technical specification doesn't actually preclude = > return =3D >>> of a referral in response to a Bind request. However, in practice, = > such =3D >>> return is quite problematic due to ambiguous semantics and security =3D= > >>> considerations. >> =20 >> Right. I can't find the discussion we had about this back in 2004, but = > certainly we've already hashed this out in great detail before. >> =20 >> The fact is that acting on a referral simply means performing a Bind = > against some other server. >> It does nothing for the authentication state of the session on the = > original server. > > Right, by returning a referral, regardless of how far the client got in = > authentication process (including completion of all challenges), the = > client is now anonymous at the original server. > > And there's a security concern, the referral information is not = > protected by the underlying authentication mechanism. It is actually = > quite possible that this be used by an attacker to cause the client to = > try authentication multiple times, possibly with chosen plaintext. > > I recommend that the library never chase bind referrals. Agreed. Patched in HEAD. > (I tend to = > think of rebind as a misfeature. Robust clients really should be using = > the async API and carefully managing security contexts and chasing.) -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
changed notes changed state Test to Release moved from Development to Software Bugs
changed notes changed state Release to Closed
do not automatically try to chase referrals returned by bind fixed in HEAD fixed in RE24