[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: [ldapext] LDAP ManageDSAIT Control Usage with JNDI



Hi

Thanks for all of the positive feedback (Vincent, Kurt, Ron, Jim).

Vincent, you state below that you will "cease using the ManageDsaIT control as a means to control when referrals are returned".
I don't think that your focus should be on controlling whether a referral is returned from the directory. Personally, I would focus on what you do with that referral once it is received.


Cheers,
Andrew Sciberras
eB2Bcom



Vincent Ryan wrote:

I agree that the behaviour of the JNDI/LDAP provider now needs to be modified.
We will update the provider to cease using the ManageDsaIT control as a means
to control when referrals are returned.

In the meantime, JNDI applications that wish to avoid sending the ManageDsaIT
control should set the java.naming.referral property to "follow".

In addition, applications that wish to avoid sending the ManageDsaIT control
but also wish to ignore (and not follow) referrals should set the property to
"throw" and then catch and ignore any ReferralException.


Jim Sermersheim wrote:

I completely agree with this Andrew. I suspect that the control was somewhat misunderstood back in the day (4 years prior to RFC 3296 I think) when the ldap service provider was written.  Also, I think most servers at that time only applied manageDsaIT to objects resembling the named subodinate references in that RFC.

Vincent,

Are you still over the LDAP service provider development? If so (as Andrew's message illustrates), it seems like some action should be taken in order to avoid confusion and problems * especially since ignore is the default.

Jiim



Andrew Sciberras <andrew.sciberras@eB2Bcom.com> 9/27/04 7:44:55 PM >>>

Hi

There is a good chance that this may have been discussed in the past, however I am currently seeing serious problems in which the manageDSAIT control (RFC3296) is being used. My concerns are discussed below and it would be greatly appreciated if I could get some feedback on whether others also share my views.

My concerns are with the way that JNDI handles naming referrals and resultantly their use of the manageDSAIT control within LDAP operations.

In the document titled "JNDI Implementor Guidelines for LDAP Service Providers - Draft 0.4.2" which can be found at the following location:

http://java.sun.com/j2se/1.4.2/docs/guide/jndi/jndi-ldap-gl.html#referral

a property called java.naming.referral is described.
This property identifies how referrals are to be handled. The default value of this property is 'ignore'.
The way in which the JNDI API will ignore a referral is by:
"sending a non-critical ManageDsaIT (RFC 3296) LDAP control with each LDAP request".


In my opinion this is a massive abuse and misuse of the control since the manageDSAIT control affects a lot more than the returning of referrals.

Looking at RFC3296, I see the following:
"A control, ManageDsaIT, is defined to allow manipulation of referral
   and other special objects as normal objects.  As the name of control
   implies, it is intended to be analogous to the ManageDsaIT service
   option described in X.511(97) [X.511]."

Being analogous to the ManageDsaIT service option described in X.511 causes me to have the following concerns:

· The purpose of the control is that it should only be used by administrative users to manage the DIT. This is significantly different to it being used as a mechanism to ignore referrals.

· All DSE's are treated as normal entries. This means that all of the below DSE's will be treated as an object entry (i.e DSE Type Entry):
o Root * Root DSE
o Glue- Represents Knowledge of a name only
o Cp * Context Prefix
o Alias * Alias Entry
o Subr * Subordinate Reference
o Nssr * Non-Specific Subordinate Reference
o Supr * Superior Reference
o Xr * Cross Reference
o AdmPoint * Administrative Point
o Subentry
o Shadow * Shadow Copy
o ImmSupr * Immediate Superior Reference
o Rhob * RHOB Information
o Sa * Subordinate Reference to alias entry
o DsSubentry * DSA Specific subentry
o FamilyMember * Family Member
The purpose here, as I see it, is purely to manage the data within these entries that would not normally be accessible through the protocol (DAP). The fact that you don't receive a referral is purely because you want to administer the data within these entries.



· An operation will never be chained. This is an obvious effect of treating all DSE's as object entries. If clients who want to ignore referrals continue to send the manageDSAIT control with every request, a request will never be chained. This will severely affect any LDAP Directory that also supports the X.500 distributed protocol (DSP), as well as any directory that implements Jim's distributed procedure draft.



· Schema Checking on entries.
The manageDSAIT control in X.500 somewhat allows the directory to perform operations that are not entirely consistent with the schema governing that entry. For example, it is explicitly stated in X.511 that an operation that carries the manageDSAIT control can result in the modification of attributes that are specified as 'no user modification'.



Based on the above information, it is my opinion that using the manageDSAIT control to prevent a directory from returning referrals is largely inappropriate and its future use should be largely discouraged.


Comments?

_________________________________________
Andrew Sciberras
eB2Bcom - View500 Software Engineer

Woodhouse Corporate Centre
Suite 3, 935 Station Street
Box Hill North, Victoria 3129, Australia

EMail: andrew.sciberras@eb2bcom.com Web http://www.eb2bcom.com



_______________________________________________
Ldapext mailing list
Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext




_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext