107 lines
6.6 KiB
HTML
107 lines
6.6 KiB
HTML
<?xml version="1.0" encoding="utf-8"?>
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
|
|
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
|
<html xmlns="http://www.w3.org/1999/xhtml" lang="en-US" xml:lang="en-us">
|
|
<head>
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
|
<meta name="dc.language" scheme="rfc1766" content="en-us" />
|
|
<!-- All rights reserved. Licensed Materials Property of IBM -->
|
|
<!-- US Government Users Restricted Rights -->
|
|
<!-- Use, duplication or disclosure restricted by -->
|
|
<!-- GSA ADP Schedule Contract with IBM Corp. -->
|
|
<meta name="dc.date" scheme="iso8601" content="2005-09-06" />
|
|
<meta name="copyright" content="(C) Copyright IBM Corporation 1998, 2006" />
|
|
<meta name="security" content="public" />
|
|
<meta name="Robots" content="index,follow"/>
|
|
<meta http-equiv="PICS-Label" content='(PICS-1.1 "http://www.icra.org/ratingsv02.html" l gen true r (cz 1 lz 1 nz 1 oz 1 vz 1) "http://www.rsac.org/ratingsv01.html" l gen true r (n 0 s 0 v 0 l 0) "http://www.classify.org/safesurf/" l gen true r (SS~~000 1))' />
|
|
<title>Directory Server (LDAP) - Recommended practices for directory structure</title>
|
|
<link rel="stylesheet" type="text/css" href="ibmidwb.css" />
|
|
<link rel="stylesheet" type="text/css" href="ic.css" />
|
|
</head>
|
|
<body>
|
|
<a id="Top_Of_Page" name="Top_Of_Page"></a><!-- Java sync-link -->
|
|
<script language = "Javascript" src = "../rzahg/synch.js" type="text/javascript"></script>
|
|
|
|
<img src="delta.gif" alt="Start of change" />
|
|
<a name="rzahyrecoprac"></a>
|
|
<h2 id="rzahyrecoprac">Recommended practices for directory structure</h2>
|
|
<p>The Directory Server is often used as a repository for users and groups.
|
|
This section describes some recommended practices for setting up a structure
|
|
that is optimized for managing users and groups. This structure and associated
|
|
security model can be extended to other uses of the directory.</p>
|
|
<p>Users are typically stored in a single, or few, locations. You might have
|
|
a single container, cn=users, that is the parent entry for all users, or separate
|
|
containers for distinct sets of users that are administered separately. For
|
|
example, employees, vendors, and self-registered Internet users might be located
|
|
under objects named cn=employees, cn=vendors, and cn=internet users, respectively.
|
|
One might be tempted to place people under the organizations they belong to;
|
|
however, this can create difficulties when they move to another organization
|
|
as the directory entry then also needs to be moved and groups or other data
|
|
sources (both internal and external to the directory) might have to be updated
|
|
to reflect the new DN. The relationship of users to the organizational structure
|
|
can be captured within the user entry using directory attributes such as "o"
|
|
(organization name), "ou" (organizational unit name), and departmentNumber
|
|
which are part of the standard schema for organizationalPerson and inetOrgPerson.</p>
|
|
<p>Similarly, groups are typically placed in a separate container, for example
|
|
a container named "cn=groups".</p>
|
|
<p>By organizing users and groups in this manner, there are only a few places
|
|
where access control lists (ACLs) need to be set.</p>
|
|
<p>Depending on how the directory server is used, and how users and groups
|
|
are managed, you might use one of the following access control patterns:</p>
|
|
<ul>
|
|
<li>If the directory is used for applications like an address book, you might
|
|
want to grant the special group cn=anybody read and search permissions for
|
|
"normal" attributes in the cn=users container and its parent objects.</li>
|
|
<li>Often, only the DNs used by specific applications and group administrators
|
|
need access to the cn=groups container. You might want to create a group holding
|
|
the DNs of group administrators and make that group the owner of cn=groups
|
|
and its subordinates. You might create another group holding the DNs used
|
|
by applications to read group information, and grant that group read and search
|
|
permissions to cn=groups.</li>
|
|
<li>If user objects are updated directly by users, you will want to grant
|
|
the special access-id cn=this appropriate read, write, and search permissions.</li>
|
|
<li>If users are updated through applications, often those applications run
|
|
under their own identity, and only those applications need authority to update
|
|
user objects. Once again, it is convenient to add these DNs to a group, for
|
|
example, cn=user administrators, and grant that group necessary permissions
|
|
to cn=users.</li></ul>
|
|
<p>Applying this type of structure and access control, your initial directory
|
|
might look like this:</p>
|
|
<p></p>
|
|
<a name="wq105"></a>
|
|
<div class="fignone" id="wq105"><span class="figcap">Figure 3. Example directory structure</span>
|
|
<div class="mmobj">
|
|
<img src="rzahy504.gif" alt="Example directory structure" /></div></div>
|
|
<ul>
|
|
<li>c=mycompany, dc=com is owned by the directory administrator, or another
|
|
user or group with authority to manage the top level of the directory. Additional
|
|
ACL entries grant read access to normal attributes for one of cn=anybody or
|
|
cn=authenticated, or possibly some other group if a more restrictive ACL is
|
|
needed.</li>
|
|
<li>cn=users has ACL entries beyond those described below to allow appropriate
|
|
access to users. ACLs might include:
|
|
<ul>
|
|
<li>read and search access to normal attributes for cn=anybody or cn=authenticated</li>
|
|
<li>read and search access to normal and sensitive attributes for managers</li>
|
|
<li>other ACL entries as desired, perhaps allowing write access for individuals
|
|
to their own entry.</li></ul></li></ul>
|
|
<a name="wq106"></a>
|
|
<div class="notetitle" id="wq106">Note:</div>
|
|
<div class="notebody">
|
|
<ul>
|
|
<li>To improve readability, RDNs of entries have been used rather than the
|
|
full DNs. For example, the "user admins" group would have the full DN uid=app,cn=users,dc=mycompany,dc=com
|
|
as a member rather than the shorter uid=app.</li>
|
|
<li>Some users and groups could be combined. For example, if the application
|
|
administrator was to have authority to manage users, the application could
|
|
run under the application administrator DN. However, that might restrict the
|
|
ability, for example, to change the application's administrator password without
|
|
also reconfiguring the new password in the application.</li>
|
|
<li>While the above represent best practices for directories used by only
|
|
one application, it might be more expedient to have all updates done authenticating
|
|
as the directory administrator. This practice is discouraged for reasons discussed
|
|
earlier.</li></ul></div><img src="deltaend.gif" alt="End of change" />
|
|
<a id="Bot_Of_Page" name="Bot_Of_Page"></a>
|
|
</body>
|
|
</html>
|