RE: [ldapext] LDAP ManageDSAIT Control Usage with JNDI

["Ramsay, Ron" <Ron.Ramsay@ca.com>]

I agree with you one hundred por cent!

-----Original Message-----
From: ldapext-bounces@ietf.org [mailto:ldapext-bounces@ietf.org]On
Behalf Of Andrew Sciberras
Sent: Tuesday, 28 September 2004 11:45
To: Ldapext
Subject: [ldapext] LDAP ManageDSAIT Control Usage with JNDI


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