Mark O. Michael wrote:
> I'm about to start a pilot implementation, followed by
> enterprise-level deployment, of LDAP and CDS services, to support
> applications like employee locator, shared e-mail address book and DCE
> (plus DFS) services.
>
> I am curious about whether the following setup would yield the results
> I conjecture:
>
> - X.500 (either GDS [1988 X.500] or 1993 X.500) server at the logical
> and physical root of our enterprise namespace
>
> - DCE directory server(s) and tree(s) using the DCE GDA to
> interoperate with the GDS server
>
> - U-Mich or commercial LDAP server(s) capable of talking DAP/DSP to
> the X.500 root server
>
> - DCE directory servers and security registries populated with
> extended attributes of interest, such as campus/building/room,
> voice/fax phone number(s), public keys, etc.
>
> The conjecture:
>
> - I intend to find out whether an LDAP browser finds the DCE directory
> service data visible
>
> Anyone have any experience with this? If so, does it work? If not,
> how did you solve the functional requirement I wish to address with a
> minimum of redundantly stored data?
I think your functional requirements should be addressed by a scenario similar
to the following one:
- use a global name service for storing all data relevant for persons,
organizational units, ...
- use either X.500 or a single LDAP server for this - I'd recommend
a commercial X.500 server (there are several good vendors). For a list
see http://ds.internic.net/internet-drafts/draft-ietf-ids-x500-imps-02.txt
- If you have a lot of data you can distribute them to different servers. A
client talking to one server gets also information stored in other
servers - via referrals or chaining. Also shadowing concepts work for both
X.500 and single LDAP server.
- choose clients talking LDAP to the server; try to get clients also supporting
MAPI and OLE (for integration into MS Exchange, ...)
- for DCE:
- don't use CDS as a database for storing information not relevant for
DCE - store only DCE-RPC server binding information, ...
- if you have multiple cells and want to have intercell communication
choose hierarchical cells; if not possible choose DNS and/or X.500 names.
For both DNS and X.500 it's not very difficult to put the DCE information
of the cell (UUID's, binding information of CDS server, ...) into DNS
or X.500. The GDA is able to talk to both name services.
- to create your registry:
- Consider your X.500/LDAP server database as the master - all changes
(new employees, people having left the company, changed phone numbers,
public keys, ...) are done there first.
- write a tool which reads all persons needing a DCE account from
X.500/LDAP server and creates the appropriate principals/accounts
in the DCE registry (you have to have a concept how to map
X.500 names to principal names)
- this tool should run periodicly to keep the registry up to date
(i.e. if a public key (i.e. a X.509 certificate) is revoked (because
the smart card is lost) the dce_login should be revoked too)
Unfortunately this tool doesn't exist - as far as I know.
But I think it could be very useful - it would avoid the duplicated
efford of user/principal administration.
And - it shouldn't be very difficult to write such tool - either by using
the LDAP and DCE programming interfaces (preferred) or by using dcecp
and gdscp (for GDS in DCE 1.1).
In this scenario you don't need access via the LDAP programming interface
(or LDAP protocol) to CDS.
Hope this helps. Any comments on this scenario are appreciated.
Bye,
Jochen.
------------
Dr. Jochen Keutel currently at: Deutsche Telekom
duerr com-soft IZ Darmstadt
Senior Consultant
Phone: +49 6151 818 579
e-mail: keutel@u9ytb.iz-darmstadt.telekom.de
100.37805@germanynet.de
X.400 : /C=de/A=dbp/P=telekom400/O=dmst03/OU1=08/S=osys-02
WWW : http://www.geocities.com/WallStreet/3454