re:Directroy Synchronization Two
Alan Wong <wong@vancouver.osiware.bc.ca> Fri, 28 July 1995 02:34 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22773; 27 Jul 95 22:34 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa22769; 27 Jul 95 22:34 EDT
Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa10169; 27 Jul 95 22:34 EDT
Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id <g.06321-0@haig.cs.ucl.ac.uk>; Fri, 28 Jul 1995 00:11:35 +0100
Received: from osison.osiware.bc.ca by bells.cs.ucl.ac.uk with Internet SMTP id <g.00402-0@bells.cs.ucl.ac.uk>; Fri, 28 Jul 1995 00:10:45 +0100
Received: by osison.osiware.bc.ca (4.1/SMI-4.1) id AA16822; Thu, 27 Jul 95 16:10:23 PDT
Date: Thu, 27 Jul 1995 15:47:00 -0700
X400-Trace: ca*infonet*iss; Arrival 27 Jul 95 15:47 PDT Action: Relayed
Priority: urgent
Ua-Content-Id: 950727732
P1-Message-Id: ca*infonet*iss;9507271547481659283
Original-Encoded-Information-Types: IA5-Text
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Alan Wong <wong@vancouver.osiware.bc.ca>
To: awon@vancouver.osiware.bc.ca
Cc: osi-ds@cs.ucl.ac.uk
Message-Id: <950727732*wong@vancouver.osiware.bc.ca>
Subject: re:Directroy Synchronization Two
Importance: High
>In message "Directroy Synchronization Two", >'jburgh@PrimeNet.com' writes: > 1. The OU Hierarchy Issue involves Organizational Department >(OR) leveling and X.400/X.500 Naming Convention Standard development. >This is a policy related problem. I've got to make sure that the OR's >System Administrators utilize appropriate standards when they develop >Distinguished Names (DN) for the users. As I synchronize the diverse >system directories, I'll probably have to "Re-Do" some of the DNs to >make sure that they comply with X.400/SMTP-based E-Mail address formats. I'm wary of the approach you seem to be suggesting: that an OR address be mapped directly to a DN, so that the resulting DN contains a large number of RDNs. This would result in a very deep and wide DIT, which would be difficult to maintain and difficult to browse. It is generally wiser to keep the DIT relatively flat. When selecting DIT levels to organize or manage user entries, choose those which change less frequently over time, i.e. if your employees change departments frequently but remain in the same metropolitan area, use location as a means of organizing entries. The point of this exercise is to build DNs which will change infrequently; this will be especially important if user DNs are to be incorporated into X.509 certificates, as a DN change requires that a new certificate be issued, with the resulting certificate management problems. Once you've chosen a structure for the tree, simply store the OR address and other email addressing information as attributes in the user's entry; your synchronizing DUAs can search for an entry using any mail address, i.e. search filter "OR address = /c=US/admd=ATT/prmd=ACME/s=smith/g=jones", and request the other email address attributes from each entry matching that filter. This is preferable to a programmatic mapping from OR address to DN, is more flexible, and, in the long term, will be more useful as your various email clients become X.500 clients. Note also that this approach does not require that querying DUAs have special knowledge, i.e. of the mapping from OR to DN: they simply ask for the email addresses of the entry which contains a particular OR address. As a final note, you will probably be required to use some sort of unique identifier to disambiguate DNs. While this may seem a less than satisfactory way of guaranteeting unique DNs, in practice it is the only workable approach. Other solutions involve sorting users by department, location, etc., and rely on these OU or L RDN components to provide uniqueness; there are three problems with this sort of approach: Resulting DITs are constructed arbitrarily and without regard for any structure which may be useful for the organization, or which may be useful to the organization's users (i.e. DIT structure reflects X.500's lack of solution to the problem of name uniqueness). This approach does not help you when two users in the same department have the same name; this happens frequently enough to cause problems. Some organizations solve this by adding arbitrary initials to the second user's name, which leads to two problems: if two long time employees with the same name move into the same department, which one gets the "Z.", and users generally find arbitrary bureaucratic changes to their names insulting. This approach does nothing to solve the problem of DN reuse: if Joe Smith leaves the company, and another Joe Smith is hired into the same department, how does the system differentiate between them. This is especially important if the DN is used in ACLs for various protected resources. (The X.500 unique identifier purports to solve this problem and does not; I won't get into the reasons, but it has to do with a) the unique identifier being optional, and b) there being no way to communicate it in the X.500 protocols, short of reading the user's entry.) That said, incorporate some sort of unique identifier into all DNs, one which will be unique to that person, i.e. will not be reused. At BNR, we use the HRR generated employee number, so that my DN is cn=Peter Whittaker + serialNumber=1660747, l=Ottawa, o=BNR, c=CA This may seem unattractive, but it is workable and problem free (bear in mind that DNs are to human consumable, not user friendly). > 2. The Identity Evolution Issue involves standardization of DN >X.400/SMTP-based E-Mail addresses throughout the ORs. This is a policy >related problem and it requires close coordination with the Human >Relation folks in my organizaiton. Employee turnover will require >"daily" attention. The System Administrators must keep up with the >personnel changes. Employees and Supervisors are involved in this >problem too. Can you provide more information on this issue? I do not understand it from the text above. >3. The User Multiple Identity Cross-Leveling Issue involves making sure >that "Dual Hat" employees, requiring different rights and privileges >based on their particular roles, get those rights and privileges >accordingly. This involves technical and policy related problems. The >System Administrators must make sure that the "Dual Hats" obtain >specific Login Scripts with "unique" characteristics for each role. I sense that this issue is being overcomplicated: a user presents their name (and possibly their cryptographic credentials) to a system, and the system grants them the permissions associated with their name/credentials. The Directory can be used as the storehouse of permissions, i.e. you can define attributes held in each user's entry which define what permissions that user has to a particular system. On the other hand, I may simply misunderstand the problem you are trying to solve. >I've got to make sure that the "Dual Hats" understand and follow >standard procedures, without abusing their access. The DUA might be >able to handle this problem for me. The problem with expecting users to understand issues and follow procedures as you describe above is twofold: some won't, either out of ignorance, pig-headedness, or forgetfulness, and some won't because they know they can compromise the system by ignoring the procedures (deliberate maliciousness). >4. The ADUA Utilization Procedures Issue involves standardizing DN >creation, modification and deletion procedures. This involves technical >and policy related problems too. Everyone must do everything right the >first time. The System Administrators must completely understand ADUA >functionality and employees must understand their E-Mail >responsibilities. I guess I'll be developing standard operating >procedures for "New" and "Terminated" employees. I'll probably make the >supervisors responsible for ensuring that their employees coordinate >with the System Administrators. Once you have decided on a tree structure and a name uniqueness provider, building a DN is relatively straightforward. The only questions that then arise are: where are the unique identifiers generated and stored? are terminated users left in the DIT and marked terminated (and possibly hidden from all but administrative users via careful application of access control information (ACI))? who has permissions to add, modify, and remove, particular attributes, i.e. OR addresses, etc. >5. The CRL/CKL Procedures Issues involves guaranteeing confidentiality >of "sensitive" information. Some of my Users deal with "proprietary" >information. We use asynchronous (public/private) key cryptography. >We're gonna incorporate X.509 Authentication Framework Certificates to >manage our Public Key Ring. The System Administrators must issue >CRL/CKLs whenever employees with access leave the organization or lose >control of their Private Key. Employees and Supervisors are also in >this loop and the distributed directory needs to be updated readily as >employee access changes. Sounds like you need an X.500 based certificate management system. I won't comment further as anything I say might be construed as an advertisement for Entrust :->. (Though you may want to send email to entrust.sales@entrust.com, or call +1 613 765 5607 for more information....) pww Peter Whittaker [~~~~~~~~~~~~~~~~~~~~~~~~~~] X.500 DS Specialist pww@entrust.com [ ] Nortel Secure Networks Ph: +1 613 765 2064 [ ] P.O. Box 3511, Station C FAX:+1 613 765 3520 [__________________________] Ottawa, Canada, K1Y 4H7
- re:Directroy Synchronization Two peter (p.w.) whittaker
- re:Directroy Synchronization Two peter (p.w.) whittaker
- re:Directroy Synchronization Two Alan Wong