[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: o and c or dc?
Hello i'm also developing a LDAP sys, and i'm using dc=org.country.XX.
I'm not breaking de domain component, is this completly incorrect?
I'm doing that way, because is more simple for normal user to understand
is login.
Exists same RFC that indicates the correct form to make a LDAP draw?
Thanks
Paulo Calçada
> On Mon, Jan 12, 2004 at 03:35:43PM -0400, Ace Suares wrote:
>
>> > The main difference is in how easy it would be for a user to find
>> your directory when they want it.
>>
>> Yes, if you are trying to implement something under ONE domain.
>
> Not at all - it is quite possible to have white-pages service across any
> number of domains. In the PARADISE X.500 network, we built user
> interfaces that would happily go and search for things like:
>
> smith, university, europe
>
> That would look for anyone called Smith (or Smithers or Smithson or...)
> in any organisation calling itself a university in any country that
> declared itself to be in Europe. In practice this is *not* a sensible
> search and you don't want people doing it as it soaks up resources at a
> frantic rate, but it *was* possible. If the development of LDAP is taken
> just a bit further and someone deploys a top-level server then it would
> be possible again.
>
>> What do you suggest if you implement something with many domains, like
>> a virtual domain hosting ISP ?
>
> It all depends on what sort of searches you want to support. I have
> built a mail system based around LDAP that does exactly what you
> describe, and I chose to place the 'customer domains' under an OU
> beneath my own organisation entry. In this case, the organisation entry
> was in dc= format, but it could equally well have been in o=, c= form.
> The critical consideration was that my mail admin tool needs complete
> authority over the subtree that it uses to define mail routing. White
> pages lookups are still possible but are very much a secondary
> requirement (if I were going to advertise a white-pages service I might
> well offer to alias each customer's data into the 'proper' place in the
> DIT)
>
> As a concrete example, suppose suares.nl wants to run a mail service for
> some well-known characters. It obviously has absolute rights to use
> dc=suares,dc=nl and anything underneath, so I would suggest
> starting with ou=mailsystem,dc=suares,dc=nl as the root of the system.
> Under that node, you could follow the Lachman-LASER scheme or you
> could define your own schema. I defined my own as I had some specific
> requirements that did not quite fit with Lachman-LASER. I chose to put
> my customer domains in a subtree called ou=domains,dc=..... and each
> domain has its own data under
> associatedDomain=<customer DNS name>,ou=domains,dc=....
> (This should make delegated management possible later if I need it,
> using ACLs). Each individual mail user gets an entry at the next level
> down, containing routing data, username, password (for IMAP) etc.
> Thus we would see:
>
> Main entry for the firytales.org customer:
> associatedDomain=fairytales.org,ou=mailsystem,dc=suares,dc=nl
>
> Some client mail-users:
> cn=Snow
> White,associatedDomain=fairytales.org,ou=mailsystem,dc=suares,dc=nl
> cn=Grumpy,associatedDomain=fairytales.org,ou=mailsystem,dc=suares,dc=nl
> cn=Snoozy,associatedDomain=fairytales.org,ou=mailsystem,dc=suares,dc=nl
>
> White pages lookups across the whole customer set are possible using a
> search base of ou=mailsystem,dc=suares,dc=nl but you may prefer to alias
> the entries into things like:
>
> cn=Grumpy,dc=fairytales,dc=org
>
> or
>
> cn=Grumpy,o=Seven Dwarves,c=Fairyland
>
> The problem then is that current user-interfaces would have trouble
> searching across all customers at once. This might well be considered an
> advantage :-)
>
> Andrew
> --
> -----------------------------------------------------------------------
> | From Andrew Findlay, Skills 1st Ltd |
> | Consultant in large-scale systems, networks, and directory services |
> | http://www.skills-1st.co.uk/ +44 1628 782565 |
> -----------------------------------------------------------------------