The question is not "can smart LDAP clients be developed with the current LDAP protocol and current LDAPv3 servers". The answer to that is most certainly yes. The question is "can today's popular LDAP clients handle a subtree of entries corresponding to a single user", and I think the answer is no. More below.
David Chadwick wrote:
> Most clients (mail clients, for example) do subtree searches. They areMost clients I've seen are built to expect many entries to be returned for a query such as the one above, but only one entry for each user in the directory.
> not smart about
> searching only for the person objectclass, for example, but just create a
> search filter that includes a number or OR'ed clauses such as
> "|(cn=*john*)(sn=*john*)(givenname=*john*)(mail=*john*))" if you type in
> "john". Depending on how you have distributed cn, sn, givenname, and mail
> attributes among the ancestor and the children, you may get one or many
> entries back, and the client will be confused.I dont understand why the client will be confused. If you do a full
subtree search of any LDAP server anywhere in the world today
and simply enter the keyword *john* you are bound to get back
hundreds of entries (unless you hit the admin limit of the server). SO
I dont see why you say a client will be confused, since they should
have already been built to cater for this.
Each entry is returned withThat is part of the problem, and of course it becomes even more confusing when some of the "John Smith"s are really one and the same while others correspond to different users.
its full distinguished name, remember, so it easy to differentiate
between them. I admit you may have a problem with clients that only
display the last RDN, but this is a bug with the client and it will also
be apparent today, for example if you have a John Smith in OU=1,
and a John Smith in OU=2, the client will not display the difference
to the user, they will look like the same entry containing different
attributes, and this will be confusing.
(In fact, there is a problem today with Netscape when you view
X.509 certificates, as it does not properly display the subject DN
field)
> That's probably true in many cases. However, some clients may assume thatWe don't need numSubordinates to determine if a node has children, since there is already hasSubordinates. And even if the latter didn't exist, a smart client could do a one level search and abandon the operation after receiving one result. So the problem is not that it is impossible to write a smart client. The problem is that some/most clients are not written to do this.
> entries with the objectclass of person are leaf entries.But this is a bug in the client, especially given the fact that each
entry should hold an operational attribute saying whether it is a leaf
or not (X.500 model) or the count of subordinates (Netscape
proposed model for LDAP as discussed in Oslo)
I agree however that clients are usually built with a particular DITI don't think I'm too far from the truth if I venture to guess that Messenger and Outlook Express are by far the most commonly used LDAP clients today, not web500.
structure in mind, and they dont work too well when they hit an
unusual (to them) structure. This is why many organisations
purchase clients specifically tailored to their DITs. In fact the best
client that I have used that can cater for any DIT structure is a
standard web browser e.g. Netscape, using HTTP to the web500
gateway product from University of Chemnitz. It is much more
flexible than the typical built in LDAP client.
Well, I'm not a client designer, but maybe you mean Netscape as a company.Several clients actually have quite a long way to go yet in producting
a good LDAP client that retrieves just the information you want it to.
(The sort of blunderbuss OR filter you described above is quite
appalling actually - it aims to maximise the number of hits to ensure
the entry you want is buried there somewhere in the hundreds
returned. Whereas what you should be trying to do is minimise the
number of hits and still ensure the entry you want is in this small
number.) You and other client designers would do well in reading
Paul Barker's PhD thesis on white pages searching, available from
> > c) A Compare operation is a bit like the base entry Search, and aRight. I was ambivalent about responding to your item c for that reason: whether or not current clients would behave well on a compare operation with a family of entries is hypothetical, since most current clients don't do compare anyway. But if they did, they would certainly have the same assumptions that they have for everything else they do - that each entry represents a single user ;-)
> > Compare on the ancestor may fail because the attributes are actually in
> > a child entry. Compares however, can be performed on each child entry
> > individually.
>
> That will not work well with most current clients, since they assume only
> entry with e.g. the common name "John Johnson" or the uid "johnj". The
> attribute being compared may live in another entry (within the family).
>Do most clients today support Compare? I am not aware that I can
perform this operation with MS or Netscape clients can I? RSVP
> >In a couple of the directory management applications from Netscape, and I believe in others I've seen as well, you can select whether to search for organizations, groups, or users. If you select to search for users (the application then adds objectclass=person to the search filter), you get a list of users and can then select one to delete. The list is flat; it shows no hieararchy. It would be impossible to tell from looking at the list if some of the entries were containers (and neither the applications nor the users running them would expect them to be containers). You could have those applications do a recursive delete, making all the entries appear to behave the same way, but that might be a little dangerous since the user can't see which other entries are children of the one she's deleting.
> > d) A Remove Entry on the ancestor would fail because it is not a leaf
> > entry. However, the client is able to delete the individual children one
> > by one. e) ModifyEntry and ModifyDN always operate on individual child
> > entries and since these are always visible to the client it is not a
> > problem.
>
> It is most definitely a problem. The way most clients work is to present
> a list of entriesI dont know who "most" refers to here? Do you mean MS and
Netscape? I have two clients on my PC that can modify entries
(neither MS or Netscape can that I am aware of) and both of these
allow me to browse the tree and pick the specific entry I want. I
suspect that Novell's client can do this as well. So I question your
assertion that most clients work the way you say.> matching a particular search _expression_.
This seems like a pretty dumb way to target an entry if you ask me.
If I type in Salford and it returns the org entry for University of
Salford would you expect me to be able to delete it? Obviously not. I
have to pick up leaf entries from browsing the tree. So not
identifying leafs in this sort of search seems to be an important
omission from those clients.
We have another directory management UI that contains a tree
view. It does allow recursive deletion. That is safer, because it is clear
from a glance what nodes are subordinate to what other ones.
>Then a user can select an entryIt will probably not be that difficult to write smart clients that can interpret families of entries (noticing the parent object class, etc) and they will benefit from their astuteness. I never questioned that. The issue here is the unmodified existing clients which will probably live on for a couple of years at least.
> in the list and request to delete it. The client gives no indication that
> an entry is a leaf node or not;poor client implementation if you ask me
>as a matter of fact it assumes that person
> entries are leaf entries and can be deleted. There will be no way (that I
> can think of) for most clients to allow the user to discover that a person
> entry has child entries which must be deleted first.Come on Rob. Didn't someone from your company give a
presentation in Oslo about an operational attribute you have defined
that counts the number of subordinates (including referral and glue
DSEs that dont have any entry information in them.) So counting the
number of children in a family wont be difficult will it. Furthermore
there is the parent object class defined in the ID that tells the client
that the entry is not a leaf, but part of a family and it has children.
Therefore there are at least 2 easy ways to determine if an entry is
a leaf or not.
>Most clients I amThat's probably where the disconnect comes from. The dumb (or half) clients dominate the world, not the smart (or full) ones. I'm not too worried about the smart ones.
> aware of do not have a list (one-level search or browse) function.This will definately pose a problem I agree. But then a car with an
engine but no gearbox will have difficulty in travelling fast on the flat
and going up steep hills as well. Half an LDAP client will have more
problems that a full client. Fortunately the client I use most and like
best has all the features.
The Search Root parameter is a configuration item for the entire directory. To use it the way you're suggesting, you would have to:>If
> there are ten members of a family of entries, and two of them match the
> search criteria in some way, then those two will show up as two
> independent entries in the list of search results, and the other eight
> will not show up at all. The user may be able to delete one of the entries
> if it happens to be a leaf node, but may not be able to delete the other
> one, and will have no idea why not.I agree with you that this is a problem for "half" an LDAP client i.e.
one that only supports half of LDAP. If you remember Roland's
presentation at the LSD2 BOF in Oslo, he said that the problem with
running a multi-organisational directory service today is not that the
LDAP protocol is short of features, but the fact that suppliers have
only implemented part of the protocol, and this is not yet sufficient
for a good service. (Apologies to Roland if I have misquoted him)However, even half an LDAP client should allow the user to enter
any distinguished name and perform a full subtree search on that,
should it not? Otherwise it is not even half a client. So, why cant I
put in the name (DN) of the person and do a full subtree search with
a simple * as the filter (i.e. return all entries). I can do this with
Netscape by setting the Search Root parameter.
- do a regular search
- locate an entry you suspect is the parent of a family of entries
(how?)
- somehow deduce what its DN is (I guess by taking the URL in the Location
box and URL-decoding it)
- select the directory node in the Directory list
- select Properties to configure it
- type in or paste in the DN of the parent entry (sans RDN) as Search
Root
- do a new search
- and be sure to restore the previous Search Root, or your address book
will be almost entirely worthless
> >I don't see how a base search could return multiple entries. Would any clients be able to handle that? I was assuming that a single entry would be returned with the union of attributes of the family members. The association information that was embodied in the structure of the family would be lost, but that's the best a clueless client can hope for. A less clueless client will use a control to indicate it can deal with a family of entries.
> > If we decide that the default action is that compound entries are
> > treated as a single entry then the following are the consequences. a)
> > Assuming the client thinks the compound entry is a single entry, a
> > Search on a base entry only (a read type operation) would always be more
> > likely to succeed because the attributes in all the children would be
> > merged before the filter was evaluated. The return of information poses
> > a problem. Either multiple single family entries would be returned
> > instead of the single ancestor that was expected (which might confuse or
> > break the client); or if the family-information derived attribute was
> > implemented, a complex formatted attribute would be returned.
> >
> > ***I need advice here from existing implementers as to whether or not
> > this would break existing LDAP client implementations or would be no
> > problem ***
> >Rob you made comments on lots of my message, but did not make a
comment on the bit that I specifically asked for comments on. Could
you comment on the above please. Ta
> In most cases, clients do not care which password was used toI think the way it is currently dealt with in systems where the passwords really are for distinct authentication services is to distinguish them by e.g. using different attribute names. But anyway, I'm not saying this is better than families of entries, I'm just saying this is how it is done today in the absence of families of entries, and this is what clients today expect.
> authenticate.They should! I dont believe you are correct here. If different
services have different passwords, and each service is in a child
entry, it would be a security flaw to allow the wrong password to gain
access to a service.
>The alternative: theI answered above about changing the Search Root for every search. But I don't see what it has to do with this? Netscape does a subtree search and will find the whole family regardless. Each entry will appear as a separate user on its own line, and there will be no way to tell which ones go together and which one is the parent (unless you somehow annotate the information into the attribute values).
> user may or may not be able to delete the entry/entries found and will not
> know how to go about deleting it/them.
>This is because the user has less than half a client that cannot
browse or do full searches from any DN. Even Netscape will allow
the user to add the DN of the ancestor into the Search Root
configuration parameter, and this should then return the whole
family, should it not? RSVP on this one.
Few clients are designed to allow specifying a DN, and the popular mail clients are among the ones that go to lengths to hide DNs. If only a list is displayed (as is the case with these clients), it will not be possible to determine which one to modify in general.> >
> > g) ModifyEntry always operates on single entries within a family. This
> > might mean that old clients would no longer be able to update compound
> > entries. (Otherwise there is a bit of a disconnect ? the compound entry
> > appears to be a single entry except when it is updated.) Is this a
> > problem or not. Comments please.
>
> Yes, this is a problem, for the same reason as the delete: how will the
> user know which of
> the entries to modify?By specifying the DN of course (or selecting the one after the
search has displayed the results, using your model).
Information will be lost if the whole family is treated as a single entry. That is inevitable. The information is actually lost already at the point where the client received the entry from the server. Maybe dumb clients should be prohibited from updating families of entries. But even semi-smart clients which send the control and explicitly request that the family be returned as a compound entry - should they be allowed to do updates? They've also lost information.It will be impossible to update a family as a single compound entry,
since the same attribute value might reside in two different children.
Then how do you specify which of the two values is to be updated if
you can only refer to the compound entry. Think about that one
please. If you have an answer to this, you can better convince me
that treating the family as one entry by default is feasible.
The user doesn't see hierarchy in the results list. The results are sorted by some attribute (such as cn, mail, etc) and associated entries may be scattered throughout the list. The user would have to somehow deduce which entry was the parent and then go through the steps described above...>And how will the user even be sure he/she has found
> all the entries associated with the family?
>By doing a full subtree search of the ancestor as explained above
> >Users currently have access to a lot of information that they find helpful through these "quarter clients" talking to directories such as WhoWhere or BigFoot, or to corporate phonebooks. It would be nice if the clients became smarter. It would not be nice if the servers restructured their DITs in such a way that the "quarter clients" were no longer able to return the information that the users had been able to access.
> > My conclusion to all of the above is that the existing default (treat
> > the compound entry as individual entries) causes less problems than
> > changing it to always assuming that the compound entry is a single
> > entry. We might decide to have a hybrid model i.e. that for Search, we
> > treat the compound entry as a single entry, but that for updates they
> > are treated as separate entries. Comments please.
>
> The more I think about it, the more I'm sure that treating the family
> members as individual
> entries (for any operation) will confuse existing clients and cause users
> of said clients to go ballistic.
>Well I would get pretty annoyed as well if I thought I had bought an
LDAP client, only to find it was quarter of a client that could not
support half of the LDAP protocol suite.
It will not be feasible to make the additional associative information embodied in families of entries available to those clients, but it may be possible to allow them to continue to receive the same information they have been receiving up to the point when the server restructures its DIT to support families of entries.> That said, I think there is value to families of entries; the trick is
> to make that value
> available to smart clients without breaking many of the existing clients.Agreed, this should be the aim. But by existing clients, you seem to
be referring to partially implemented LDAP clients, and I dont think
that it will be feasible to cater for these.
Rob
David
>
> Robl
>
>
>
>***************************************************
David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351 Fax +44 161 745 8169
Mobile +44 790 167 0359
*NEW* Email D.W.Chadwick@salford.ac.uk *NEW*
Home Page http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500 http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J***************************************************