Novell EDIRECTORY 8.8 - ADMINISTRATION User Manual

Novell eDirectory 8.8 Administration Guide

Novell

novdocx (ENU) 01 February 2006

eDirectory

8.8

ADMINISTRATION GUIDE

February 3, 2006

TM

www.novell.com

Legal Notices

Novell, Inc. makes no representations or warranties with respect to the contents or use of this documentation, and
specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose.
Further, Novell, Inc. reserves the right to revise this publication and to make changes to its content, at any time,
without obligation to notify any person or entity of such revisions or changes.

Further, Novell, Inc. makes no representations or warranties with respect to any software, and specifically disclaims
any express or implied warranties of merchantability or fitness for any particular purpose. Further, Novell, Inc.
reserves the right to make changes to any and all parts of Novell software, at any time, without any obligation to
notify any person or entity of such changes.

Any products or technical information provided under this Agreement may be subject to U.S. export controls and the
trade laws of other countries. You agree to comply with all export control regulations and to obtain any required
licenses or classification to export, re-export, or import deliverables. You agree not to export or re-export to entities
on the current U.S. export exclusion lists or to any embargoed or terrorist countries as specified in the U.S. export
laws. You agree to not use deliverables for prohibited nuclear, missile, or chemical biological weaponry end uses.
Please refer to www.novell.com/info/exports/ for more information on exporting Novell software. Novell assumes no
responsibility for your failure to obtain any necessary export approvals.

Copyright © 2006 Novell, Inc. All rights reserved. No part of this publication may be reproduced, photocopied,
stored on a retrieval system, or transmitted without the express written consent of the publisher.

novdocx (ENU) 01 February 2006

Novell, Inc. has intellectual property rights relating to technology embodied in the product that is described in this
document. In particular, and without limitation, these intellectual property rights may include one or more of the U.S.
patents listed at http://www.novell.com/company/legal/patents/ and one or more additional patents or pending patent
applications in the U.S. and in other countries.

Novell, Inc.
404 Wyman Street, Suite 500
Waltham, MA 02451
U.S.A.
www.novell.com

Online Documentation: To access the online documentation for this and other Novell products, and to get

updates, see www.novell.com/documentation.

Novell Trademarks

Client32 is a trademark of Novell, Inc.

eDirectory is a trademark of Novell, Inc.

NetWare is a registered trademark of Novell, Inc., in the United States and other countries.

NetWare Core Protocol and NCP are trademarks of Novell, Inc.

NMAS is a trademark of Novell, Inc.

Novell is a registered trademark of Novell, Inc., in the United States and other countries.

Novell Client is a trademark of Novell, Inc.

Novell Directory Services and NDS are registered trademarks of Novell, Inc., in the United States and other

countries.

Ximiam is a registerd trademark of Novell, Inc., in the United States and other countries.

ZENworks is a registered trademark of Novell, Inc., in the United States and other countries.

Third-Party Materials

All third-party trademarks are the property of their respective owners.

This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit (http://

www.openssl.org).

novdocx (ENU) 01 February 2006

novdocx (ENU) 01 February 2006

Contents

About This Guide 17

1 Understanding Novell eDirectory 19

1.1 Ease of Management through Novell iManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

1.1.1 Powerful Tree Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

1.1.2 Web-Based Management Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

1.1.3 Single Login and Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

1.2 Object Classes and Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

1.2.1 List of Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

1.2.2 Container Object Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

1.2.3 Leaf Object Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

1.3 Context and Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

1.3.1 Distinguished Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

1.3.2 Typeful Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

1.3.3 Name Resolution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

1.3.4 Current Workstation Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

1.3.5 Leading Period . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

1.3.6 Relative Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

1.3.7 Trailing Periods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

1.3.8 Context and Naming on Linux and UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

1.4 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

1.4.1 Schema Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

1.4.2 Schema Classes, Attributes, and Syntaxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

1.4.3 Understanding Mandatory and Optional Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 46

1.4.4 Sample Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

1.4.5 Designing the Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

1.5 Partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

1.5.1 Partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

1.5.2 Distributing Replicas for Performance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

1.5.3 Partitions and WAN Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

1.6 Replicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

1.6.1 Replica Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

1.6.2 Filtered Replicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

1.7 NetWare Bindery Emulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

1.8 Server Synchronization in the Replica Ring. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

1.9 Access to Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

1.10 eDirectory Rights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

1.10.1 Trustee Assignments and Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

1.10.2 eDirectory Rights Concepts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

1.10.3 Default Rights for a New Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

1.10.4 Delegated Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

1.10.5 Administering Rights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

novdocx (ENU) 01 February 2006

5

2 Designing Your Novell eDirectory Network 69

2.1 eDirectory Design Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

2.1.1 Network Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

2.1.2 Organizational Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

2.1.3 Preparing for eDirectory Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

2.2 Designing the eDirectory Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

2.2.1 Creating a Naming Standards Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

2.2.2 Designing the Upper Layers of the Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

2.2.3 Designing the Lower Layers of the Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

2.3 Guidelines for Partitioning Your Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

2.3.1 Determining Partitions for the Upper Layers of the Tree . . . . . . . . . . . . . . . . . . . . . . 76

2.3.2 Determining Partitions for the Lower Layers of the Tree . . . . . . . . . . . . . . . . . . . . . . 77

2.3.3 Determining Partition Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

2.3.4 Considering Network Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

2.4 Guidelines for Replicating Your Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

2.4.1 Workgroup Needs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

2.4.2 Fault Tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

2.4.3 Determining the Number of Replicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

2.4.4 Replicating the Tree Partition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

2.4.5 Replicating for Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

2.4.6 Meeting Bindery Services Needs for NetWare. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

2.4.7 Managing WAN Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

2.5 Planning the User Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

2.5.1 Reviewing Users' Needs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

2.5.2 Creating Accessibility Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

2.6 Designing eDirectory for e-Business . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

2.7 Understanding the Novell Certificate Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

2.7.1 Rights Required to Perform Tasks on Novell Certificate Server . . . . . . . . . . . . . . . . 82

2.7.2 Ensuring Secure eDirectory Operations on Linux, Solaris, AIX, and HP-UX

Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

2.8 Synchronizing Network Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

2.8.1 Synchronizing Time on NetWare Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

2.8.2 Synchronizing Time on Windows Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

2.8.3 Synchronizing Time on Linux, Solaris, AIX, or HP-UX Systems . . . . . . . . . . . . . . . . 87

2.8.4 Verifying Time Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

2.9 Security Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

novdocx (ENU) 01 February 2006

3 Managing Objects 91

3.1 General Object Tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

3.1.1 Browsing the eDirectory Tree. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

3.1.2 Creating an Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

3.1.3 Modifying an Object's Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

3.1.4 Copying Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

3.1.5 Moving Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

3.1.6 Deleting Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

3.1.7 Renaming Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

3.2 Managing User Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

3.2.1 Creating and Modifying User Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

3.2.2 Setting Up Optional Account Features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

3.2.3 Setting Up Login Scripts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

3.2.4 Login Time Restrictions for Remote Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

3.2.5 Deleting User Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

3.3 Configuring Role-Based Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

3.3.1 Defining RBS Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

3.3.2 Defining Custom RBS Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

6 Novell eDirectory 8.8 Administration Guide

3.4 Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

3.4.1 Features of Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

3.4.2 Normal or Replica Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

3.4.3 Priority Sync . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

4 Managing the Schema 117

4.1 Extending the Schema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

4.1.1 Creating a Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

4.1.2 Deleting a Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

4.1.3 Creating an Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

4.1.4 Adding an Optional Attribute to a Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

4.1.5 Deleting an Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

4.1.6 Creating an Auxiliary Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

4.1.7 Extending an Object with the Properties of an Auxiliary Class . . . . . . . . . . . . . . . . 120

4.1.8 Modifying an Object's Auxiliary Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

4.1.9 Deleting Auxiliary Properties from an Object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

4.2 Viewing the Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

4.2.1 Viewing Class Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

4.2.2 Viewing Attribute Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

4.3 Manually Extending the Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

4.3.1 Extending the Schema on NetWare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

4.3.2 Extending the Schema on Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

4.3.3 Extending the Schema on Linux, Solaris, AIX, or HP-UX Systems. . . . . . . . . . . . . 123

4.4 Schema Flags Added in eDirectory 8.7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

4.5 Using the eMBox Client to Perform Schema Operations. . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

4.5.1 Using the DSSchema eMTool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

4.5.2 DSSchema eMTool Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

novdocx (ENU) 01 February 2006

5 Managing Partitions and Replicas 129

5.1 Creating a Partition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

5.2 Merging a Partition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

5.3 Moving Partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

5.4 Cancelling Create or Merge Partition Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

5.5 Administering Replicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

5.5.1 Adding a Replica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

5.5.2 Deleting a Replica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

5.5.3 Changing a Replica Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

5.6 Setting Up and Managing Filtered Replicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

5.6.1 Using the Filtered Replica Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

5.6.2 Defining a Partition Scope. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

5.6.3 Setting Up a Server Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

5.7 Viewing Partitions and Replicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

5.7.1 Viewing the Partitions on a Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

5.7.2 Viewing a Partition’s Replicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

5.7.3 Viewing Information about a Partition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

5.7.4 Viewing Partition Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

5.7.5 Viewing Information about a Replica. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

6 Novell eDirectory Management Utilities 141

6.1 Novell Import Conversion Export Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

6.1.1 Using the Novell iManager Import Convert Export Wizard . . . . . . . . . . . . . . . . . . . 142

6.1.2 Using the Command Line Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

6.1.3 Conversion Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

7

6.1.4 LDAP Bulk Update/Replication Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

6.1.5 Migrating the Schema between LDAP Directories . . . . . . . . . . . . . . . . . . . . . . . . . . 175

6.1.6 Improving the Speed of LDIF Imports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

6.2 Index Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

6.2.1 Creating an Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

6.2.2 Deleting an Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

6.2.3 Taking an Index Offline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

6.2.4 Managing Indexes on Other Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

6.2.5 Using the Novell Import Conversion Export Utility to Manage Indexes . . . . . . . . . . 179

6.3 Predicate Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

6.3.1 Managing Predicate Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

6.4 eDirectory Service Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182

6.4.1 Using the eMBox Client Service Manager eMTool . . . . . . . . . . . . . . . . . . . . . . . . . 182

6.4.2 Using the Service Manager Plug-In to Novell iManager . . . . . . . . . . . . . . . . . . . . . 183

7 Using Novell iMonitor 2.1 185

7.1 System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

7.1.1 Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

7.1.2 eDirectory Versions That Can Be Monitored . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

7.2 Accessing iMonitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

7.3 iMonitor Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

7.3.1 Anatomy of an iMonitor Page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

7.3.2 Modes of Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

7.3.3 iMonitor Features Available on Every Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

7.3.4 NetWare Remote Manager Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

7.3.5 Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

7.4 iMonitor Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

7.4.1 Viewing eDirectory Server Health . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194

7.4.2 Viewing Partition Synchronization Status. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194

7.4.3 Viewing Server Connection Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

7.4.4 Viewing Known Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

7.4.5 Viewing Replica Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196

7.4.6 Controlling and Configuring the DS Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196

7.4.7 Configuring Trace Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

7.4.8 Viewing Process Status Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198

7.4.9 Viewing Agent Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198

7.4.10 Viewing Traffic Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

7.4.11 Viewing Background Processes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

7.4.12 Viewing eDirectory Server Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

7.4.13 Viewing DSRepair Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

7.4.14 Viewing Agent Health Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200

7.4.15 Browsing Objects in Your Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200

7.4.16 Viewing Entries for Synchronization or Purging . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

7.4.17 Viewing Novell Nsure Identity Manager Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

7.4.18 Viewing the Synchronization Status of a Replica. . . . . . . . . . . . . . . . . . . . . . . . . . . 201

7.4.19 Configuring and Viewing Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

7.4.20 Viewing Schema, Class, and Attribute Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 203

7.4.21 Searching for Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203

7.4.22 Using the Stream Viewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204

7.4.23 Clone DIB Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204

7.5 Ensuring Secure iMonitor Operations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210

novdocx (ENU) 01 February 2006

8 Merging Novell eDirectory Trees 211

8.1 Merging eDirectory Trees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211

8.1.1 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212

8 Novell eDirectory 8.8 Administration Guide

8.1.2 Target Tree Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212

8.1.3 Schema Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212

8.1.4 Merging the Source into the Target Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213

8.1.5 Partition Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213

8.1.6 Preparing the Source and Target Trees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214

8.1.7 Synchronizing Time before the Merge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214

8.1.8 Merging Two Trees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215

8.1.9 Post-Merge Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216

8.2 Grafting a Single Server Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

8.2.1 Understanding Context Name Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219

8.2.2 Preparing the Source and Target Trees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220

8.2.3 Grafting the Source and Target Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222

8.3 Renaming a Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222

8.4 Using the eMBox Client to Merge Trees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223

8.4.1 Using the DSMerge eMTool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223

8.4.2 DSMerge eMTool Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224

9 Encrypting Data In eDirectory 227

9.1 Encrypted Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227

9.1.1 Using Encryption Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228

9.1.2 Managing Encrypted Attributes Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229

9.1.3 Accessing the Encrypted Attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232

9.1.4 Viewing the Encrypted Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233

9.1.5 Encrypting and Decrypting Backup Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234

9.1.6 Cloning the DIB Fileset Containing Encrypted Attributes . . . . . . . . . . . . . . . . . . . . 234

9.1.7 Adding eDirectory 8.8 Servers to Replica Rings . . . . . . . . . . . . . . . . . . . . . . . . . . . 234

9.1.8 Backward Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235

9.1.9 Migrating to Encrypted Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235

9.1.10 Replicating the Encrypted Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235

9.2 Encrypted Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235

9.2.1 Enabling Encrypted Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236

9.2.2 Adding a New Replica to a Replica Ring. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240

9.2.3 Synchronization and Encrypted Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245

9.2.4 Viewing the Encrypted Replication Status. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245

9.3 Achieving Complete Security While Encrypting Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246

9.3.1 Encrypting Data in an All New Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247

9.3.2 Encrypting Data in an Existing Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247

9.3.3 Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249

novdocx (ENU) 01 February 2006

10 Repairing the Novell eDirectory Database 251

10.1 Performing Basic Repair Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252

10.1.1 Performing an Unattended Full Repair . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252

10.1.2 Performing a Local Database Repair . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254

10.1.3 Checking External References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255

10.1.4 Repairing a Single Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255

10.1.5 Deleting Unknown Leaf Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256

10.2 Viewing and Configuring the Repair Log File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256

10.2.1 Opening the Log File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256

10.2.2 Setting Log File Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257

10.3 Performing a Repair in Novell iMonitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257

10.4 Repairing Replicas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257

10.4.1 Repairing All Replicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258

10.4.2 Repairing Selected Replicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258

10.4.3 Repairing Time Stamps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258

10.4.4 Designating This Server As the New Master Replica . . . . . . . . . . . . . . . . . . . . . . . 259

9

10.4.5 Destroying the Selected Replica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260

10.5 Repairing Replica Rings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260

10.5.1 Repairing All Replica Rings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260

10.5.2 Repairing the Selected Replica Ring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261

10.5.3 Sending All Objects to Every Server in the Ring . . . . . . . . . . . . . . . . . . . . . . . . . . . 261

10.5.4 Receiving All Objects from the Master to the Selected Replica . . . . . . . . . . . . . . . . 262

10.5.5 Removing This Server from the Replica Ring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262

10.6 Maintaining the Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262

10.6.1 Requesting Schema from the Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263

10.6.2 Resetting the Local Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263

10.6.3 Performing a Post-NetWare 5 Schema Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264

10.6.4 Performing Optional Schema Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264

10.6.5 Importing Remote Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264

10.6.6 Declaring a New Schema Epoch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265

10.7 Repairing Server Network Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265

10.7.1 Repairing All Network Addresses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266

10.7.2 Repairing a Server's Network Addresses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266

10.8 Performing Synchronization Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267

10.8.1 Synchronizing the Selected Replica on This Server . . . . . . . . . . . . . . . . . . . . . . . . 267

10.8.2 Reporting the Synchronization Status on This Server . . . . . . . . . . . . . . . . . . . . . . . 267

10.8.3 Reporting the Synchronization Status on All Servers . . . . . . . . . . . . . . . . . . . . . . . 268

10.8.4 Performing a Time Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268

10.8.5 Scheduling an Immediate Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269

10.9 Advanced DSRepair Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269

10.9.1 Running DSRepair on the eDirectory Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269

10.9.2 DSRepair Command Line Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271

10.9.3 Using Advanced DSRepair Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272

10.10 Using the eMBox Client to Repair a Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273

10.10.1 Using the DSRepair eMTool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273

10.10.2 DSRepair eMTool Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274

novdocx (ENU) 01 February 2006

11 WAN Traffic Manager 277

11.1 Understanding WAN Traffic Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277

11.1.1 LAN Area Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279

11.1.2 WAN Traffic Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280

11.1.3 Limiting WAN Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283

11.1.4 Assigning Cost Factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285

11.2 WAN Traffic Manager Policy Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286

11.2.1 1-3am.wmg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286

11.2.2 7am-6pm.wmg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286

11.2.3 Costlt20.wmg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286

11.2.4 Ipx.wmg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287

11.2.5 Ndsttyps.wmg. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287

11.2.6 Onospoof.wmg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298

11.2.7 Opnspoof.wmg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298

11.2.8 Samearea.wmg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299

11.2.9 Tcpip.wmg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299

11.2.10 Timecost.wmg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299

11.3 WAN Policy Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300

11.3.1 Declaration Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300

11.3.2 Selector Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302

11.3.3 Provider Section. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302

11.3.4 Construction Used within Policy Sections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303

10 Novell eDirectory 8.8 Administration Guide

12 Understanding LDAP Services for Novell eDirectory 309

12.1 Key Terms for LDAP Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310

12.1.1 Clients and Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310

12.1.2 Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310

12.1.3 Referrals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311

12.2 Understanding How LDAP Works with eDirectory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312

12.2.1 Connecting to eDirectory from LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313

12.2.2 Class and Attribute Mappings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316

12.2.3 Enabling Nonstandard Schema Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319

12.2.4 Syntax Differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319

12.2.5 Supported Novell LDAP Controls and Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 320

12.3 Using LDAP Tools on Linux, Solaris, AIX, or HP-UX. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321

12.3.1 LDAP Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322

12.4 Extensible Match Search Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331

13 Configuring LDAP Services for Novell eDirectory 335

13.1 Loading and Unloading LDAP Services for eDirectory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335

13.2 Verifying That the LDAP Server Is Loaded . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336

13.3 Verifying That the LDAP Server Is Running . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337

13.3.1 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337

13.3.2 Verifying That The LDAP Server Is Running . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338

13.3.3 Verifying That A Device Is Listening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339

13.4 Configuring LDAP Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340

13.4.1 Configuring LDAP Server and LDAP Group Objects on Linux, Solaris, AIX, or HP-UX

Systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341

13.5 Refreshing the LDAP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344

13.6 Authentication and Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345

13.6.1 Requiring TLS for Simple Binds with Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . 346

13.6.2 Starting and Stopping TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346

13.6.3 Configuring the Server for TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347

13.6.4 Configuring the Client for TLS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348

13.6.5 Exporting the Trusted Root . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349

13.6.6 Authenticating with a Client Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349

13.6.7 Using Certificate Authorities from Third-Party Providers . . . . . . . . . . . . . . . . . . . . . 349

13.6.8 Creating and Using LDAP Proxy Users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350

13.6.9 Using SASL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351

13.7 Using the LDAP Server to Search the Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353

13.7.1 Setting Search Limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353

13.7.2 Using Referrals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354

13.7.3 Searching Filtered Replicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359

13.8 Using LDAP Referral Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360

13.8.1 Need for LDAP Referral Filtering. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360

13.8.2 Using LDAP Referral Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360

13.8.3 Format for Specifying LDAP Referral Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361

13.8.4 Example Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362

13.8.5 Invalid Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363

13.8.6 Known Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363

13.9 Configuring for Superior Referrals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363

13.9.1 Scenario: Superior Referrals in a Federated Tree . . . . . . . . . . . . . . . . . . . . . . . . . 363

13.9.2 Creating a Nonauthoritative Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364

13.9.3 Specifying Reference Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365

13.9.4 Updating Reference Information through LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 366

13.9.5 Affected Operations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366

13.9.6 Discovering Support for Superior References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367

13.10 Persistent Search: Configuring for eDirectory Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367

novdocx (ENU) 01 February 2006

11

13.10.1 Managing Persistent Searches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368

13.10.2 Controlling Use of the Monitor Events Extended Operation. . . . . . . . . . . . . . . . . . . 369

13.11 Getting Information about the LDAP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370

14 Backing Up and Restoring Novell eDirectory 373

14.1 Checklist for Backing Up eDirectory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374

14.2 Understanding Backup and Restore Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376

14.2.1 About the eDirectory Backup eMTool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377

14.2.2 What's Different about Backup and Restore in eDirectory 8.7.3? . . . . . . . . . . . . . . 378

14.2.3 Overview of How the Backup eMTool Does a Restore . . . . . . . . . . . . . . . . . . . . . . 380

14.2.4 Format of the Backup File Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381

14.2.5 Format of the Backup Log File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385

14.2.6 Using DSMASTER Servers as Part of Disaster Recovery Planning . . . . . . . . . . . . 386

14.2.7 Transitive Vectors and the Restore Verification Process . . . . . . . . . . . . . . . . . . . . . 387

14.2.8 Restore Verification Is Backward Compatible Only with eDirectory 8.5 or Later . . . 388

14.2.9 Preserving Rights When Restoring File System Data on NetWare . . . . . . . . . . . . . 388

14.3 Using Roll-Forward Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389

14.3.1 Issues to Be Aware of When Turning On Roll-Forward Logging . . . . . . . . . . . . . . . 390

14.3.2 Location of the Roll-Forward Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391

14.3.3 Backing Up and Removing Roll-Forward Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392

14.3.4 Cautionary Note: Removing eDirectory Also Removes the Roll-Forward Logs . . . . 393

14.4 Preparing for a Restore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393

14.4.1 Prerequisites for Restoring. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394

14.4.2 Locating the Right Backup Files for a Restore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395

14.5 Using Novell iManager for Backup and Restore. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396

14.5.1 Backing Up Manually with iManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397

14.5.2 Configuring Roll-Forward Logs with iManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399

14.5.3 Restoring from Backup Files with iManager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401

14.6 Using the eMBox Client for Backup and Restore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404

14.6.1 Backing Up Manually with the eMBox Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404

14.6.2 Doing Unattended Backups, Using a Batch File with the eMBox Client . . . . . . . . . 407

14.6.3 Configuring Roll-Forward Logs with the eMBox Client. . . . . . . . . . . . . . . . . . . . . . . 410

14.6.4 Restoring from Backup Files with the eMBox Client . . . . . . . . . . . . . . . . . . . . . . . . 412

14.6.5 Backup and Restore Command Line Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415

14.7 Using DSBK.NLM on NetWare. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423

14.8 Changes to Server-Specific Information Backup (NetWare Only) . . . . . . . . . . . . . . . . . . . . . 423

14.9 Recovering the Database If Restore Verification Fails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425

14.9.1 Cleaning Up the Replica Ring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426

14.9.2 Repair the Failed Server and Readd Replicas to the Server . . . . . . . . . . . . . . . . . . 427

14.10 Scenarios for Backup and Restore. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429

14.10.1 Scenario: Losing a Hard Drive Containing eDirectory in a Single-Server NetWork . 429

14.10.2 Scenario: Losing a Hard Drive Containing eDirectory in a Multiserver Environment 430

14.10.3 Scenario: Losing an Entire Server in a Multiple-Server Environment . . . . . . . . . . . 432

14.10.4 Scenario: Losing Some Servers in a Multiple-Server Environment . . . . . . . . . . . . . 433

14.10.5 Scenario: Losing All Servers in a Multiple-Server Environment. . . . . . . . . . . . . . . . 433

14.11 Backing Up and Restoring NICI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435

14.11.1 UNIX. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436

14.11.2 NetWare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437

14.11.3 Windows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438

novdocx (ENU) 01 February 2006

15 SNMP Support for Novell eDirectory 441

15.1 Definitions and Terminology for SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441

15.2 Understanding SNMP Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442

15.3 eDirectory and SNMP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444

12 Novell eDirectory 8.8 Administration Guide

15.3.1 Benefits of SNMP Instrumentation on eDirectory . . . . . . . . . . . . . . . . . . . . . . . . . . 444

15.3.2 Understanding How SNMP Works with eDirectory . . . . . . . . . . . . . . . . . . . . . . . . . 444

15.4 Installing and Configuring SNMP Services for eDirectory . . . . . . . . . . . . . . . . . . . . . . . . . . . 447

15.4.1 Loading and Unloading the SNMP Server Module . . . . . . . . . . . . . . . . . . . . . . . . . 447

15.4.2 Subagent Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448

15.4.3 Setting Up SNMP Services for eDirectory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450

15.5 Monitoring eDirectory Using SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461

15.5.1 Traps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461

15.5.2 Configuring Traps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475

15.5.3 Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485

15.6 Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489

16 Maintaining Novell eDirectory 491

16.1 Improving eDirectory Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491

16.1.1 Distributing Memory between Entry and Block Caches. . . . . . . . . . . . . . . . . . . . . . 492

16.1.2 Using the Default Cache Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492

16.1.3 Tuning LDAP for eDirectory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496

16.2 Improving eDirectory Performance on Linux, Solaris, AIX, and HP-UX Systems . . . . . . . . . 498

16.2.1 Fine-Tuning the eDirectory Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498

16.2.2 Optimizing eDirectory Cache. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499

16.2.3 Tuning the Solaris OS for Novell eDirectory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502

16.3 Improving Bulkload Performance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504

16.3.1 eDirectory Cache Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504

16.3.2 LBURP Transaction Size Setting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504

16.3.3 Increasing the Number of Asynchronous Requests in ICE . . . . . . . . . . . . . . . . . . . 505

16.3.4 Increased Number of LDAP Writer Threads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506

16.3.5 Disabling Schema Validation in ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506

16.3.6 Disabling ACL Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506

16.3.7 Backlinker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508

16.3.8 Enabling/Disabling Inline Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508

16.3.9 Increasing the LBURP Time Out Period . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508

16.4 Keeping eDirectory Healthy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509

16.4.1 When to Perform Health Checks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509

16.4.2 Health Check Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509

16.4.3 Checking eDirectory Health Using iMonitor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 510

16.4.4 For More Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511

16.5 Resources for Monitoring. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511

16.6 Upgrading Hardware or Replacing a Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512

16.6.1 Planned Hardware or Storage Device Upgrade without Replacing the Server . . . . 512

16.6.2 Planned Replacement of a Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516

16.7 Restoring eDirectory after a Hardware Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519

novdocx (ENU) 01 February 2006

17 DHost iConsole Manager 521

17.1 What is DHost? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 522

17.2 Running DHost iConsole . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 522

17.2.1 Running DHost iConsole on NetWare. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523

17.2.2 Running DHost iConsole on Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523

17.2.3 Running DHost iConsole on Linux, Solaris, AIX, and HP-UX . . . . . . . . . . . . . . . . . 523

17.3 Managing eDirectory Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524

17.3.1 Loading or Unloading Modules on NetWare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524

17.3.2 Loading or Unloading Modules on Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525

17.3.3 Loading or Unloading Modules on Linux, Solaris, AIX, and HP-UX . . . . . . . . . . . . 525

17.4 Querying for DHost Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525

17.4.1 Viewing the Configuration Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525

13

17.4.2 Viewing Protocol Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526

17.4.3 Viewing Connection Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526

17.4.4 Viewing the Thread Pools Statistics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526

17.5 Process Stack. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527

17.6 Setting the SAdmin Password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527

17.6.1 Setting the SAdmin Password on NetWare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528

17.6.2 Setting the SAdmin Password on Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528

17.6.3 Setting the SAdmin Password on Linux, Solaris, AIX, and HP-UX . . . . . . . . . . . . . 529

18 The eDirectory Management Toolbox 531

18.1 Using the eMBox Command Line Client. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531

18.1.1 Displaying the Command Line Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532

18.1.2 Running the eMBox Command Line Client in Interactive Mode. . . . . . . . . . . . . . . . 532

18.1.3 Running the eMBox Command Line Client in Batch Mode . . . . . . . . . . . . . . . . . . . 536

18.1.4 eMBox Command Line Client Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 538

18.1.5 Establishing a Secure Connection with the eMBox Client . . . . . . . . . . . . . . . . . . . . 539

18.1.6 Finding Out eDirectory Port Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 539

18.2 Using the eMBox Logger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541

18.2.1 Using the eMBox Logger Command Line Client . . . . . . . . . . . . . . . . . . . . . . . . . . . 541

18.2.2 Using the eMBox Logger Feature in Novell iManager . . . . . . . . . . . . . . . . . . . . . . . 542

novdocx (ENU) 01 February 2006

A NMAS Considerations 543

A.1 Setting Up a Security Container As a Separate Partition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543

A.2 Merging Trees with Multiple Security Containers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543

A.2.1 Product-Specific Operations to Perform prior to Tree Merge. . . . . . . . . . . . . . . . . . 544

A.2.2 Performing the Tree Merge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547

A.2.3 Product-Specific Operations to Perform after the Tree Merge . . . . . . . . . . . . . . . . . 547

B Novell eDirectory Linux and UNIX Commands and Usage 549

B.1 General Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 549

B.2 LDAP-Specific Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554

C Configuring OpenSLP for eDirectory 557

C.1 Service Location Protocol. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 557

C.2 SLP Fundamentals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 557

C.2.1 Novell Service Location Providers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558

C.2.2 User Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558

C.2.3 Service Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 559

C.3 Configuration Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 559

D How Novell eDirectory Works with DNS 561

E Configuring GSSAPI with eDirectory 563

E.1 Prerequisites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563

E.1.1 Assumptions on Network Characteristics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564

E.1.2 Installing the Kerberos Plug-in for iManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564

E.1.3 Adding Kerberos LDAP Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565

E.1.4 Exporting the Trusted Root Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567

E.2 Configuring the SASL-GSSAPI Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567

E.2.1 Merging eDirectory Trees Configured with SASL-GSSAPI Method . . . . . . . . . . . . . 568

14 Novell eDirectory 8.8 Administration Guide

E.3 Managing the SASL-GSSAPI Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 568

E.3.1 Extending the Kerberos Schema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 568

E.3.2 Managing the Kerberos Realm Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 568

E.3.3 Managing a Service Principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 570

E.3.4 Editing Foreign Principals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574

E.4 Creating a Login Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574

E.5 How Does LDAP Use SASL-GSSAPI? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574

E.6 Error Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574

novdocx (ENU) 01 February 2006

15

novdocx (ENU) 01 February 2006

16 Novell eDirectory 8.8 Administration Guide

About This Guide

This guide describes how to manage and configure Novell® eDirectoryTM 8.8.

• Chapter 1, “Understanding Novell eDirectory,” on page 19

• Chapter 2, “Designing Your Novell eDirectory Network,” on page 69

• Chapter 3, “Managing Objects,” on page 91

• Chapter 4, “Managing the Schema,” on page 117

• Chapter 5, “Managing Partitions and Replicas,” on page 129

• Chapter 6, “Novell eDirectory Management Utilities,” on page 141

• Chapter 7, “Using Novell iMonitor 2.1,” on page 185

• Chapter 8, “Merging Novell eDirectory Trees,” on page 211

• Chapter 9, “Encrypting Data In eDirectory,” on page 227

• Chapter 10, “Repairing the Novell eDirectory Database,” on page 251

• Chapter 11, “WAN Traffic Manager,” on page 277

novdocx (ENU) 01 February 2006

• Chapter 12, “Understanding LDAP Services for Novell eDirectory,” on page 309

• Chapter 13, “Configuring LDAP Services for Novell eDirectory,” on page 335

• Chapter 14, “Backing Up and Restoring Novell eDirectory,” on page 373

• Chapter 15, “SNMP Support for Novell eDirectory,” on page 441

• Chapter 16, “Maintaining Novell eDirectory,” on page 491

• Chapter 17, “DHost iConsole Manager,” on page 521

• Chapter 18, “The eDirectory Management Toolbox,” on page 531

• Appendix A, “NMAS Considerations,” on page 543

• Appendix B, “Novell eDirectory Linux and UNIX Commands and Usage,” on page 549

• Appendix C, “Configuring OpenSLP for eDirectory,” on page 557

• Appendix D, “How Novell eDirectory Works with DNS,” on page 561

• Appendix E, “Configuring GSSAPI with eDirectory,” on page 563

Audience

The guide is intended for network administrators.

Feedback

We want to hear your comments and suggestions about this manual and the other documentation
included with this product. Please use the User Comments feature at the bottom of each page of the
online documentation, or go to www.novell.com/documentation/feedback.html and enter your
comments there.

17

Documentation Updates

For the most recent version of this guide, see Novell eDirectory 8.8 Administration Guide (http://

www.novell.com/documentation/edir88/index.html).

Additional Documentation

For eDirectory installation instructions, see the Novell eDirectory 8.8 Installation Guide (http://

www.novell.com/documentation/edir88/index.html).

For documentation on the eDirectory management utility, see the Novell iManager 2.5

Administration Guide (http://www.novell.com/documentation/imanager25/index.html).

Documentation Conventions

In this documentation, a greater-than symbol (>) is used to separate actions within a step and items
within a cross-reference path.

®

A trademark symbol (

, TM, etc.) denotes a Novell trademark. An asterisk (*) denotes a third-party

trademark.

novdocx (ENU) 01 February 2006

When a single pathname can be written with a backslash for some platforms or a forward slash for
other platforms, the pathname is presented with a backslash. Users of platforms that require a
forward slash, such as Linux and UNIX*, should use forward slashes as required by your software.

18 Novell eDirectory 8.8 Administration Guide

1

Understanding Novell eDirectory

In simplest terms, Novell® eDirectoryTM is a list of objects that represent network resources, such as
network users, servers, printers, print queues, and applications. Novell eDirectory is a highly
scalable, high-performing, secure directory service. It can store and manage millions of objects,
such as users, applications, network devices, and data. Novell eDirectory offers a secure identity
management solution that runs across multiple platforms, is internet-scalable, and extensible.

Novell eDirectory provides centralized identity management, infrastructure, Net-wide security, and
scalability to all types of applications running behind and beyond the firewall. Novell eDirectory
includes Web-based and wireless management capabilities, allowing you to access and manage the
directory and users, access rights, and network resources from a Web browser and a variety of
handheld devices.

Novell eDirectory natively supports the directory standard Lightweight Directory Access Protocol
(LDAP) 3 and provides support for TLS/SSL services based on the OpenSSL source code. For more
information on the eDirectory engine, see eDirectory Process Requests (http://developer.novell.com/

research/sections/netmanage/dirprimer/2002/august/p020801.htm).

novdocx (ENU) 01 February 2006

1

Figure 1-1 shows a few of the objects as viewed in the Novell iManager management utility.

Figure 1-1 eDirectory Objects in iManager

Some object classes might not be available, depending on the actual schema configured on the
eDirectory server and the operating system running eDirectory.

For more information on objects, see Section 1.2, “Object Classes and Properties,” on page 23.

If you have more than one eDirectory server on the network, the directory can be replicated on
multiple servers.

This chapter includes the following information:

• Section 1.1, “Ease of Management through Novell iManager,” on page 20

• Section 1.2, “Object Classes and Properties,” on page 23

• Section 1.3, “Context and Naming,” on page 38

• Section 1.4, “Schema,” on page 41

• Section 1.5, “Partitions,” on page 47

Understanding Novell eDirectory

19

• Section 1.6, “Replicas,” on page 50

• Section 1.7, “NetWare Bindery Emulation,” on page 55

• Section 1.8, “Server Synchronization in the Replica Ring,” on page 55

• Section 1.9, “Access to Resources,” on page 55

• Section 1.10, “eDirectory Rights,” on page 56

1.1 Ease of Management through Novell
iManager

Novell eDirectory allows for easy, powerful, and flexible management of network resources. It also
serves as a repository of user information for groupware and other applications. These applications
access your directory through the industry-standard Lightweight Directory Access Protocol
(LDAP).

eDirectory ease-of-management features include a powerful tree structure, an integrated
management utility, and single login and authentication.

Novell iManager lets you manage the directory and users, and access rights and network resources
within the directory, from a Web browser and a variety of handheld devices. The eDirectory plug-ins
to iManager give you access to basic directory management tasks, and to the eDirectory
management utilities you previously had to run on the eDirectory server, such as DSRepair,
DSMerge, and Backup and Restore.

novdocx (ENU) 01 February 2006

For more information, see the Novell iManager 2.5 Administration Guide (http://www.novell.com/

documentation/imanager25/index.html).

1.1.1 Powerful Tree Structure

Novell eDirectory organizes objects in a tree structure, beginning with the top Tree object, which
bears the tree's name.

®

Whether your eDirectory servers are running NetWare
resources can be kept in the same tree. You won’t need to access a specific server or domain to
create objects, grant rights, change passwords, or manage applications.

The hierarchical structure of the tree gives you great management flexibility and power. These
benefits primarily result from the following two features:

• “Container Objects” on page 20

• “Inheritance” on page 21

Container Objects

Container objects allow you to manage other objects in sets, rather than individually. There are three
common classes of container objects, as seen in Figure 1-2:

Figure 1-2 Common Classes of Container Objects

, Linux*, UNIX*, or Windows*, all

20 Novell eDirectory 8.8 Administration Guide

The Tree object is the top container object in the tree. It usually contains your company’s

Organization object.

Organization is normally the first container class under the Tree object. The Organization object
is typically named after your company. Small companies keep management simple by having all
other objects directly under the Organization object.

Organizational Unit objects can be created under the Organization to represent distinct
geographical regions, network campuses, or individual departments. You can also create
Organizational Units under other Organizational Units to further subdivide the tree.

Other classes of container objects are Country and Locality, which are typically used only in
multinational networks.

The Domain object can be created under the Tree object or under Organization, Organizational
Unit, Country, and Locality objects.

You can perform one task on the container object that applies to all objects within the container.
Suppose you want to give a user named Amy complete management control over all objects in the
Accounting container. (See Figure 1-3.)

novdocx (ENU) 01 February 2006

Figure 1-3 Container Object

To do this, right-click the Accounting object, select Trustees of This Object, then add Amy as a
trustee. Next, select the rights you want Amy to have, then click OK. Now Amy has rights to
manage the Database application, the Bookkeepers group, the LaserPrinter printer, and the users
Amy, Bill, and Bob.

Inheritance

Another powerful feature of eDirectory is rights inheritance. Inheritance means that rights flow
down to all containers in the tree. This allows you to grant rights with very few rights assignments.
For example, suppose you want to grant management rights to the objects shown in Figure 1-4 on

page 21.

Figure 1-4 Sample eDirectory Objects

Understanding Novell eDirectory 21

You could make any of the following assignments:

• If you grant a user rights to Allentown, the user can manage only objects in the Allentown
container.

• If you grant a user rights to East, the user can manage objects in the East, Allentown, and
Yorktown containers.

• If you grant a user rights to YourCo, the user can manage any objects in any of the containers
shown.

For more information on assigning rights, see Section 1.10, “eDirectory Rights,” on page 56.

1.1.2 Web-Based Management Utility

iManager is a browser-based tool used for administering, managing, and configuring eDirectory
objects. iManager gives you the ability to assign specific tasks or responsibilities to users and to
present the user with only the tools (with the accompanying rights) necessary to perform those sets
of tasks.

To run iManager, you will need a workstation with Microsoft* Internet Explorer 6.0 SP1 or later
(recommended), Mozilla* 1.7 or later, or Mozilla Firefox* 0.9.2.

novdocx (ENU) 01 February 2006

IMPORTANT: While you might be able to access iManager through a Web browser not listed, we
do not guarantee full functionality.

You can use iManager to perform the following supervisory tasks:

• Configure LDAP- and XML-based access to eDirectory

• Create objects representing network users, devices, and resources

• Define templates for creating new user accounts

• Find, modify, move, and delete network objects

• Define rights and roles to delegate administrative authority

• Extend the eDirectory schema to allow custom object types and properties

• Partition and replicate the eDirectory database across multiple servers

• Run eDirectory management utilities such as DSRepair, DSMerge, and Backup and Restore

You can use iManager to perform other management functions based on plug-ins that have been
loaded into iManager. The following eDirectory plug-ins are installed with iManager 2.5:

• eDirectory Backup and Restore

• eDirectory Log Files

• eDirectory Merge

• eDirectory Repair

• eDirectory Service Manager

• eGuide Content

• iManager Base Content

• Import Convert Export Wizard

• Index Management

22 Novell eDirectory 8.8 Administration Guide

•iPrint

• LDAP

• Universal Password Enforcement

• Priority Sync

• Encrypted Attributes

• Encrypted Replication

•NLS

•NMAS

• PKI/Certificate

• Filtered Replica Configuration Wizard

•SNMP

• WAN Traffic Manager

For more information on installing, configuring, and running iManager, see the Novell iManager 2.5

Administration Guide (http://www.novell.com/documentation/imanager25/index.html).

novdocx (ENU) 01 February 2006

1.1.3 Single Login and Authentication

With eDirectory, users log in to a global directory, so you don’t need to manage multiple server or
domain accounts for each user, and you don’t need to manage trust relationships or pass-through
authentication among domains.

A security feature of the directory is authentication of users. Before a user logs in, a User object
must be created in the directory. The User object has certain properties, such as a name and
password.

When the user logs in, eDirectory checks the password against the one stored in the directory for
that user and grants access if they match.

1.2 Object Classes and Properties

The definition of each type of eDirectory object is called an object class. For instance, User and
Organization are object classes. Each class of object has certain properties. A User object, for
example, has First Name, Last Name, and many other properties.

The schema defines the object classes and properties, along with the rules of containment (what
containers can contain which objects). eDirectory ships with a base schema that you, or the
applications you use, can extend. For more information about schemas, see Section 1.4, “Schema,”

on page 41.

Container objects contain other objects and are used to divide the tree into branches, while leaf
objects represent network resources.

1.2.1 List of Objects

The following tables list eDirectory object classes. Added services can create new object classes in
eDirectory that are not listed below.

Understanding Novell eDirectory 23

eDirectory Container Object Classes

novdocx (ENU) 01 February 2006

iManager Icon

Container Object
(Abbreviation)

Description

Tree Represents the beginning of your tree. For more

information, see “Tree” on page 25.

Country (C) Designates the countries where your network resides and

organizes other directory objects within the country. For
more information, see “Country” on page 28.

License Container (LC) Created automatically when you install a license certificate

or create a metering certificate using Novell Licensing
Services (NLS) technology. When an NLS-enabled
application is installed, it adds a License Container
container object to the tree and a License Certificate leaf
object to that container.

Organization (O) Helps you organize other objects in the directory. The

Organization object is a level below the Country object (if
you use the Country object). For more information, see

“Organization” on page 26.

Organizational Unit (OU) Helps you to further organize other objects in the directory.

The Organizational Unit object is a level below the
Organization object. For more information, see

“Organizational Unit” on page 27.

Domain (DC) Helps you to further organize other objects in the directory.

The Domain object can be created under the Tree object or
under Organization, Organizational Unit, Country, and
Locality objects. For more information, see “Domain” on

page 28.

eDirectory Leaf Object Classes

iManager Icon Leaf Object Description

AFP Server Represents an AppleTalk* Filing Protocol server that operates as a

node on your eDirectory network. It usually also acts as a NetWare
router to, and the AppleTalk server for, several Macintosh*
computers.

Alias Points to the actual location of an object in the directory. Any

directory object located in one place in the directory can also
appear to be in another place in the directory by using an Alias. For
more information, see “Alias” on page 36.

Application Represents a network application. Application objects simplify

administrative tasks such as assigning rights, customizing login
scripts, and launching applications.

Computer Represents a computer on the network.

Directory Map Refers to a directory in the file system. For more information, see

“Directory Map” on page 37.

24 Novell eDirectory 8.8 Administration Guide

iManager Icon Leaf Object Description

Group Assigns a name to a list of User objects in the directory. You can

assign rights to the group instead of to each user; then the rights
transfer to each user in the group. For more information, see

“Group” on page 32.

License Certificate Use with NLS technology to install product license certificates as

objects in the database. License Certificate objects are added to the
Licensed Product container when an NLS-aware application is
installed.

Organizational Role Defines a position or role within an organization.

Print Queue Represents a network print queue.

Print Server Represents a network print server.

Printer Represents a network printing device.

Profile Represents a login script used by a group of users who need to

share common login script commands. The users don’t need to be
in the same container. For more information, see “Profile” on

page 38.

novdocx (ENU) 01 February 2006

Server Represents a server running any operating system. For more

information, see “Server” on page 29.

Template Represents standard User object properties that can be applied to

new User objects.

Unknown Represents an object for which iManager has no custom icon.

User Represents the people who use your network. For more

information, see “User” on page 30.

Volume Represents a physical volume on the network. For more

information, see “Volume” on page 29.

1.2.2 Container Object Classes

• “Tree” on page 25

• “Organization” on page 26

• “Organizational Unit” on page 27

• “Country” on page 28

• “Domain” on page 28

Tree

The Tree container, formerly [Root], is created when you first install eDirectory on a server in
your network. As the top-most container, it usually holds Organization objects, Country objects, or
Alias objects.

What Tree Represents

Tree represents the top of your tree.

Understanding Novell eDirectory 25

Usage

Tree is used to make universal rights assignments. Because of inheritance, any rights assignments
you make to Tree as the target apply to all objects in the tree. See Section 1.10, “eDirectory Rights,”

on page 56. The [Public] trustee has the Browse right and Admin has the Supervisor right to Tree by

default.

Important Properties

The Tree object has a Name property, which is the tree name you supply when installing the first
server. The tree name is shown in the hierarchy of iManager.

Organization

An Organization container object is created when you first install eDirectory on a server in your
network. As the top-most container under Tree, it usually holds Organizational Unit objects and leaf
objects.

The User object named Admin is created by default in your first Organization container.

novdocx (ENU) 01 February 2006

What an Organization Object Represents

Normally the Organization object represents your company, although you can create additional
Organization objects under Tree. This is typically done for networks with distinct geographical
districts or for companies with separate eDirectory trees that have merged.

Usage

The way you use Organization objects in your tree depends on the size and structure of your
network. If the network is small, you should keep all leaf objects under one Organization object.

For larger networks, you can create Organizational Unit objects under the Organization to make
resources easier to locate and manage. For example, you can create Organizational Units for each
department or division in your company.

For networks with multiple sites, you should create an Organizational Unit for each site under the
Organization object. That way, if you have (or plan to have) enough servers to partition the
directory, you can do so logically along site boundaries.

For easy sharing of company-wide resources such as printers, volumes, or applications, create
corresponding Printer, Volume, or Application objects under the Organization.

Important Properties

The most useful properties for Organization are listed below. Only the Name property is required.
For a complete list of properties, select an Organization object in iManager. To display a description
for each page of properties, click Help.

•Name

Typically, the Name property is the same as your company’s name. Of course, you can shorten
it for simplicity. For instance, if the name of your company is Your Shoe Company, you might
use YourCo.

The Organization name becomes part of the context for all objects created under it.

26 Novell eDirectory 8.8 Administration Guide

•Login Script

The Login Script property contains commands that are executed by any User objects directly
under the Organization. These commands are run when a user logs in.

Organizational Unit

You can create Organizational Unit (OU) container objects to subdivide the tree. Organizational

Units are created with iManager under an Organization, Country, or another Organizational Unit.

Organizational Units can contain other Organizational Units and leaf objects such as User and
Application objects.

What an Organizational Unit Object Represents

Normally the Organizational Unit object represents a department, which holds a set of objects that
commonly need access to each other. A typical example is a set of Users, along with the Printers,
Volumes, and Applications that those Users need.

At the highest level of Organizational Unit objects, each Organizational Unit can represent each site
(separated by WAN links) in the network.

novdocx (ENU) 01 February 2006

Usage

The way you use Organizational Unit objects in your tree depends on the size and structure of your
network. If the network is small, you might not need any Organizational Units.

For larger networks, you can create Organizational Unit objects under the Organization to make
resources easier to locate and manage. For example, you can create Organizational Units for each
department or division in your company. Remember that administration is easiest when you keep
User objects together in the Organizational Unit with the resources they use most frequently.

For networks with multiple sites, you can create an Organizational Unit for each site under the
Organization object. That way, if you have (or plan to have) enough servers to partition the
directory, you can do so logically along site boundaries.

Important Properties

The most useful properties for the Organizational Unit are listed below. Only the Name property is
required. For a complete list of properties, select an Organizational Unit object in iManager. To
display a description for each page of properties, click Help.

•Name

Typically, the Name property is the same as the department name. Of course, you can shorten it
for simplicity. For instance, if the name of your department is Accounts Payable, you can
shorten it to AP.

The Organizational Unit name becomes part of the context for all objects created under it.

•Login Script

The Login Script property contains commands that are executed by any User objects directly
under the Organizational Unit. These commands are run when a user logs in.

Understanding Novell eDirectory 27

Country

You can create Country objects directly under the Tree object using iManager. Country objects

are optional and required only for connection to certain X.500 global directories.

What a Country Object Represents

The Country object represents the political identity of its branch of the tree.

Usage

Most administrators do not create a Country object, even if the network spans countries, since the
Country object only adds an unnecessary level to the tree. You can create one or many Country
objects under the Tree object, depending on the multinational nature of your network. Country
objects can contain only Organization objects.

If you do not create a Country object and find that you need one later, you can always modify the
tree to add one.

Important Properties

novdocx (ENU) 01 February 2006

The Country object has a two-letter Name property. Country objects are named with a standard two­letter code such as US, UK, or DE.

Domain

You can create Domain objects directly under the Tree object using iManager. You can also

create them under Organization, Organization Unit, Country, and Location objects.

What a Domain Object Represents

The Domain object represent DNS domain components. Domain objects let you use your Domain
Name System location of services resource records (DNS SRV) to locate services in your tree.

Using Domain objects, a tree could look something like this:

DS=Novell.DC=Provo.DC=USA

In this example, all subcontainers are domains. You can also use Domain objects in a mixed tree,
such as:

DC=Novell.O=Provo.C=USA

Or

OU=Novell.DC=Provo.C=USA

Usually, the topmost Domain is the overall Tree, with subdomains under Tree. For example,
machine1.novell.com could be represented by DC=machine1.DC=novell.DC=com in a tree
representation. Domains give you a more generic way to set up an eDirectory tree. If all containers
and subcontainers are DC objects, users do not need to remember C, O, or OUs when searching for
objects.

Usage

NetWare 4 and 5 trees cannot have Domain objects at the top of the tree. With NetWare 4 and 5, the
NCP Server object can be placed in an Organization, Country, Organizational Unit, or Locality

28 Novell eDirectory 8.8 Administration Guide

container, but not in a Domain container. With NetWare 6, however, you can place Domain objects
at the top of the tree, and you can place the NCP Server object in a Domain container.

For older installations of NetWare (such as NetWare 4), when you prepare the tree to install or
upgrade to NetWare 5 or later, the nds500.sch file will automatically run. After the first server is
installed into the tree, this file extends the schema to allow the Domain container to be created
anywhere and hold most directory objects.

1.2.3 Leaf Object Classes

• “Server” on page 29

• “Volume” on page 29

• “User” on page 30

• “Group” on page 32

• “Alias” on page 36

• “Directory Map” on page 37

• “Profile” on page 38

novdocx (ENU) 01 February 2006

Server

A Server object is automatically created in the tree whenever you install eDirectory on a server.

The object class can be any server running eDirectory.

You can also create a Server object to represent a NetWare 2 or NetWare 3 bindery server.

What a Server Object Represents

The Server object represents a server running eDirectory or a bindery-based (NetWare 2 or NetWare

3) server.

Usage

The Server object serves as a reference point for replication operations. A Server object that
represents a bindery-based server allows you to manage the server’s volumes with iManager.

Important Properties

The Server object has a Network Address property, among others. The Network Address property
displays the protocol and address number for the server. This is useful for troubleshooting at the
packet level

For a complete list of properties, select a Server object in iManager. To display a description for
each page of properties, click Help.

Volume

When you create a physical volume on a server, a Volume object is automatically created in the
tree. By default, the name of the Volume object is the server’s name with an underscore and the
physical volume’s name appended (for example, YOSERVER_SYS).

Volume objects are supported only on NetWare. Linux and UNIX file system partitions cannot be
managed using Volume objects.

Understanding Novell eDirectory 29

What a Volume Object Represents

A Volume object represents a physical volume on a server, whether it is a writable disk, a CD, or
other storage medium. The Volume object in eDirectory does not contain information about the files
and directories on that volume, although you can access that information through iManager. File and
directory information is retained in the file system itself.

Usage

In iManager, click the Vo lu m e icon to manage files and directories on that volume. iManager
provides information about the volume’s free disk space, directory entry space, and compression
statistics.

You can also create Volume objects in the tree for NetWare 2 and NetWare 3 volumes.

Important Properties

In addition to the required Name and Host Server properties, there are other important Volume
properties.

•Name

novdocx (ENU) 01 February 2006

This is the name of the Volume object in the tree. By default, this name is derived from the
name of the physical volume, though you can change the object name.

•Host Server

This is the server that the volume resides on.

•Version

This is the NetWare or eDirectory version of the server hosting the volume.

User

A User object is required for logging in. When you install the first server into a tree, a User

object named Admin is created. Log in as Admin the first time.

You can use the following methods to create or import User objects:

• iManager

For more information on iManager, see the Novell iManager 2.5 Administration Guide (http://

www.novell.com/documentation/imanager25/index.html).

• Batches from database files

For more information on using batch files, see Section 2.2, “Designing the eDirectory Tree,” on

page 70.

• NetWare upgrade utilities

For more information on upgrade utilities, including importing users from existing bindery
servers, see Section 2.2, “Designing the eDirectory Tree,” on page 70.

What a User Object Represents

A User object represents a person who uses the network.

30 Novell eDirectory 8.8 Administration Guide

Usage

You should create User objects for all users who need to use the network. Although you can manage
User objects individually, you can save time by

• Using Template objects to set default properties for most User objects. The Template applies
automatically to new Users you create (not to already existing ones).

• Creating Group objects to manage sets of Users.

• Assigning rights using the container objects as trustees when you want that assignment to apply
to all User objects in the container.

• Selecting multiple User objects by using Shift+click or Ctrl+click. When you do, you can
change property values for all selected User objects.

Important Properties

User objects have over 80 properties. For a complete list of properties, select a User object in
iManager. To display a description for each page of properties, click Help.

The Login Name and Last Name properties are required. These and some of the most useful
properties are listed below.

novdocx (ENU) 01 February 2006

• Account Expiration Date lets you limit the life of a user account. After the expiration date, the
account is locked so the user cannot log in.

• Account Disabled has a system-generated value that indicates a lock on the account so the user
cannot log in. The lock might occur if the account has expired or because the user has given too
many incorrect passwords in succession.

• Force Periodic Password Changes lets you enhance security by requiring the user to change
passwords after a specified interval.

• Group Memberships lists all the Group objects that include the User as a member.

• Home Directory refers to a NetWare volume and file system path for the user’s own files. Most
administrators like to create such a directory so that a user’s working files can be kept on the
network.

The directory referred to in this property can be automatically created when you create the User
object.

• Last Login is a system-generated property that lists the date and time that the user last logged
in.

• Last Name, although required, is not used directly by eDirectory. Applications that take
advantage of the eDirectory name base can use this property, along with other identification
properties such as Given Name, Title, Location, and Fax Number.

• Limit Concurrent Connections lets you set the maximum number of sessions a user can have on
the network at any given time.

• Login Name is the name shown in iManager by the User icon. It is also the name supplied by
the user when logging in.

eDirectory does not require that login names be unique throughout the network, only in each
container. However, you might want to keep login names unique across the company to
simplify administration.

Typically, login names are a combination of first and last names, such as STEVEJ or SJONES
for Steve Jones.

Understanding Novell eDirectory 31

• Login Script lets you create specific login commands for a User object. When a user logs in, the
container login script runs first. Then a profile login script runs if the User object has been
added to the membership list of a Profile object. Finally, the user login script runs (if one
exists).

You should put most of the login commands in container login scripts to save administrative
time. The user login script can be edited to manage unique exceptions to common needs.

• Login Time Restrictions lets you set times and days when the user can log in.

TM

• Network Addresses contains system-generated values that list all the IPX

and/or IP addresses
that the user is logged in from. These values are useful for troubleshooting network problems at
the packet level.

• Require a Password lets you control whether the user must use a password. Other related
properties let you set common password constraints such as password length.

• Rights to Files and Directories lists all rights assignments made for this user to the NetWare file
system. Using iManager, you can also check a user’s effective rights to files and directories,
which include those inherited from other objects.

Group

novdocx (ENU) 01 February 2006

You can create Group objects to help you manage sets of User objects.

What a Group Object Represents

A Group object represents a set of User objects.

Usage

Container objects let you manage all User objects in that container, and Group objects are for
subsets within a container or in multiple containers.

Group objects have two main purposes:

• They allow you to grant rights to a number of User objects at once.

• They allow you to specify login script commands using the IF MEMBER OF syntax.

Static Groups

Static groups identify the member objects explicitly. Each member is assigned to the group
explicitly.

These groups provide a static list of members, as well as referential integrity between the members
list of the group and the members of attributes on an object. Group membership is managed
explicitly through the member attribute.

Dynamic Groups

Dynamic groups use an LDAP URL to define a set of rules which, when matched by eDirectory
User objects, define the members of the group. Dynamic group members share a common set of
attributes as defined by the search filter specified in the URL. For more information on the LDAP
URL format, see RFC 2255 (http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2255.html).

Dynamic groups let you specify the criteria to be used for evaluating membership in a group. The
actual members of the group are dynamically evaluated by eDirectory, which lets you define the

32 Novell eDirectory 8.8 Administration Guide

group members in terms of a logical grouping and lets eDirectory automatically add and remove
group members. This solution is more scalable, reduces administrative costs, and can supplement
normal groups in LDAP to provide increased flexibility.

eDirectory lets you create a dynamic group when you want to automatically group users based on
any attribute, or when you want to apply ACLs to specific groups that contain matching DNs. For
example, you can create a group that automatically includes any DN that contains the attribute
Department=Marketing. If you apply a search filter for Department=Marketing, the search returns a
group including all DNs containing the attribute Department=Marketing. You can then define a
dynamic group from the search results based on this filter. Any User added to the directory who
matches the Department=Marketing criteria is automatically added to the group. Any User whose
Department is changed to another value (or who is removed from the directory) is automatically
removed from the group.

Dynamic groups are created in eDirectory by creating an object of type objectclass=dynamicGroup.
A static Group object can be converted into a dynamic group by associating an auxiliary class,
dynamicGroupAux, to the Group object. The dynamic group has the memberQueryURL attribute
associated with it.

A dgIdentity attribute can be set on the Dynamic Group object to the distinguished name of an entry,
whose credentials and rights should be used to expand the dynamic members of the group.

novdocx (ENU) 01 February 2006

The groups are managed using the memberQueryURL. A typical memberQueryURL has a base DN,
a scope, a filter, and an optional extension. The base DN specifies the search base. Scope specifies
the levels below the base to search, and filter is the search filter based on which entries are selected
from within the specified scope.

NOTE: To address exceptions to the listing created by the memberQueryURL, dynamic groups also
allow for explicit inclusion and exclusion of users.

Dynamic groups can be created and managed through Novell iManager. You can access the
Dynamic Group management tasks by clicking the Dynamic Groups role on the Roles and Tasks
page.

You can also use LDAP commands to manage such groups. The most useful properties associated
with dynamic groups are dgIdentity and memberQueryURL.

Important Properties

The most useful properties of the Group object are Members and Rights to Files and Directories. For
a complete list of properties, select a Group object in iManager. To display a description for each
page of properties, click Help.

• dgAllowDuplicates

Specifies whether or not duplicates are allowed while printing dynamic group members. The
default is TRUE.

• dgIdentity

This property holds the DN whose identity the dynamic group will use for authentication while
searching. The identity must be on the same partition as the dynamic group. The object
specified by dgldentity should have the necessary rights to do the search specified in the
memberQueryURL attribute.

For example, if memberQueryURL value is

Understanding Novell eDirectory 33

“ldap:///o=nov??sub?(title=*)”

then dgldentity should have read/compare rights on the attribute title below the container
o=nov.

•dgTimeout

This property specifies the maximum duration a server can take to read or compare a member
attribute before it times out. When the server exceeds this dgTimeout value, the -6016 error is
displayed.

• memberQueryURL

This property defines the set of rules that match with the attributes of the group members.

memberQueryURL is a multivalued attribute according to its schema definition. Although
memberQueryURL is multivalued, eDirectory 8.6.1 servers used only the first value of
memberQueryURL.

For example:

An administrator creates a dynamic group, which has two memberQueryURL values:

“ldap:///o=nov??sub?cn=*”

“ldap:///o=org??sub?cn=*”

eDirectory 8.6.x servers use “ldap:///o=nov??sub?cn=*” to compute the members of the group.
They accept more than one query, but only read the first query.

novdocx (ENU) 01 February 2006

This limitation was overcome in eDirectory 8.7.3. eDirectory 8.7.3 servers compute the
members based on all the memberQueryURL values, and the set of members is the union of the
members computed using each of the memberQueryURL values.

In the above example, resultant members of the dynamic group are all entries under o=org and
o=nov, which have cn values.

•member

This property lists all objects in the group. Rights assignments made to the Group object apply
to all members of that group. Adding values to the member property of a dynamic group will
add the static members to the dynamic group. This can be used for specific inclusion of
members.

• excludedMember

The property holds the DNs that are specifically excluded from the membership list of the
dynamic group. This can be used to construct exclusion lists for dynamic groups.

excludedMember is used to exclude DNs from being dynamic members of a dynamic group.

Thus, a DN is a dynamic member of a dynamic group only if it is selected by the member
criteria specified by memberQueryURL and is not listed in excludedMember or explicitly
added to uniqueMember or member.

• staticMember

This property reads the static members of a dynamic group and also determines whether a DN
is a static member of a dynamic group. staticMember can find the dynamic groups in which a
DN is a static member alone and can also find which groups have dynamic members and no
static members.

To add this property to the existing dynamic groups, extend the schema using dgstatic.sch.

34 Novell eDirectory 8.8 Administration Guide

Upgrading a Dynamic Groups on Pre-eDirectory 8.6.1 Databases

Dynamic groups functionality requires some internal values stored on the Dynamic Group objects,
which are created either when a dynamic group is locally created or received as a part of
synchronization.

Although older servers can hold dynamic groups, they are unable to generate these values, because
dynamic groups were introduced in eDirectory 8.6.1.

In eDirectory 8.6.2, automatic upgrade of the Dynamic Group objects in a pre-8.6.1 database to
match a eDirectory 8.6.1 database was implemented.

Support for Additional Syntaxes in memberQueryURL

The memberQueryURL attribute can hold a search filter that the eDirectory server uses to compute
the members of a dynamic group.

In eDirectory 8.6.1, the syntaxes of attributes used in the filter were restricted only to the following
basic string types:

• SYN_CE_STRING

• SYN_CI_STRING

• SYN_PR_STRING

novdocx (ENU) 01 February 2006

• SYN_NU_STRING

• SYN_CLASS_NAME

• SYN_TEL_NUMBER

• SYN_INTEGER

• SYN_COUNTER

•SYN_TIME

• SYN_INTERVAL

• SYN_BOOLEAN

• SYN_DIST_NAME

• SYN_PO_ADDRESS

•SYN_CI_LIST

• SYN_FAX_NUMBER

• SYN_EMAIL_ADDRESS

From eDirectory 8.7.3 onwards, the following additional attribute syntaxes are supported in a
memberQueryURL value:

•SYN_PATH

•SYN_TIMESTAMP

• SYN_TYPED_NAME

In both eDirectory 8.6.1 and eDirectory 8.7.x, binary syntaxes like SYN_OCTET_STRING and
SYN_NET_ADDRESS are not supported in the memberQueryURL search filters.

For more information, see How to Manage and Use Dynamic Groups in Novell eDirectory (http://

developer.novell.com/research/appnotes/2002/april/05/a020405.htm).

Understanding Novell eDirectory 35

Alias

You can create an Alias object that points to another object in the tree. An Alias object gives a

user a local name for an object that lies outside their container.

When you rename a container, you have the option of creating an Alias in the former container’s
place that points to the new name. Workstations and login script commands that reference objects in
the container can still access the objects without having the container name updated.

What an Alias Object Represents

An Alias object represents another object, which can be a container, User object, or any other object
in the tree. An Alias object does not carry trustee rights of its own. Any trustee authority you grant to
the Alias object applies to the object it represents. The Alias can be a target of a trustee assignment,
however.

Usage

Create an Alias object to make name resolution easier. Because object naming is simplest for objects
in the current context, you should create Alias objects there that point to any resources outside the
current context.

novdocx (ENU) 01 February 2006

For example, suppose users log in and establish a current context in the South container as shown in

Figure 1-5, but need access to the Print Queue object named ColorQ in the North container.

Figure 1-5 Sample Containers

You can create an Alias object in the South container, as shown in Figure 1-6.

Figure 1-6 Alias Object in eDirectory Container

The Alias object points to the original ColorQ object, so setting up printing for the users involves a
local object.

36 Novell eDirectory 8.8 Administration Guide

Important Properties

Alias objects have an Aliased Object property, which associates the Alias object with the original
object.

Directory Map

The Directory Map object is a pointer to a path in the server file system. It allows you to make

simpler references to directories.

If your network has no NetWare volumes, you cannot create Directory Map objects.

What a Directory Map Object Represents

A Directory Map object represents a directory on a NetWare volume. (An Alias object, on the other
hand, represents an object.)

Usage

Create a Directory Map object to make drive mapping simpler, particularly in login scripts. Using a
Directory Map object allows you to reduce complex file system paths to a single name.

novdocx (ENU) 01 February 2006

Also, when you change the location of a file, you don’t need to change login scripts and batch files
to reference the new location. You only need to edit the Directory Map object. For example, suppose
you were editing the login script for the container South, shown in Figure 1-7.

Figure 1-7 Sample eDirectory Container

A command mapping drives to the Shared directory on volume sys: would look like the following:

MAP N:=sys.North.:Shared

If you created the Shared Directory Map object, the map command would be much simpler:

MAP N:=Shared

Important Properties

The Directory Map object has the following properties:

•Name

Identifies the object in the directory (for example, Shared) and is used in MAP commands.

• Volume

Contains the name of the Volume object that the Directory Map object references, such as
Sys.North.YourCo.

•Path

Understanding Novell eDirectory 37

Specifies the directory as a path from the root of the volume, such as
public\winnt\nls\english.

Profile

Profile objects help you manage login scripts.

What a Profile Object Represents

A Profile object represents a login script that runs after the container login script and before the user
login script.

Usage

Create a Profile object if you want login script commands to run for only selected users. The User
objects can exist in the same container or be in different containers. After you have created the
Profile object, you add the commands to its Login Script property. Then make the User objects
trustees of the Profile object and add the Profile object to their Profile Membership property.

Important Properties

novdocx (ENU) 01 February 2006

The Profile object has two important properties:

•Login Script

Contains the commands you want to run for users of the Profile.

• Rights to Files and Directories

If you have INCLUDE statements in the login script, you need to give the Profile object rights
to the files included with the Rights to Files and Directories property.

1.3 Context and Naming

The context of an object is its position in the tree. It is nearly equivalent to a DNS domain.

You can see in the following figure that User Bob is in Organizational Unit Accounts, which is in
Organizational Unit Finance, which is in Organization YourCo.

Figure 1-8 Sample eDirectory Container

38 Novell eDirectory 8.8 Administration Guide

Sometimes, however, you need to express the context of an object in an eDirectory utility. For
example, you could be setting up Bob’s workstation and need to supply a name context, as shown in

Figure 1-9 on page 39.

Figure 1-9 Novell Client NDS Page

The context is specified as a list of containers separated by periods, between the object in question
and the top of the Tree. In the example above, User object Bob is in the container Accounts, which is
in the container Finance, which is in the container YourCo.

novdocx (ENU) 01 February 2006

1.3.1 Distinguished Name

The distinguished name of an object is its object name with the context appended. For example, the
complete name of User object Bob is Bob.Accounts.Finance.YourCo.

1.3.2 Typeful Name

Sometimes typeful names are displayed in eDirectory utilities. Typeful names include the object
type abbreviations listed in the following table:

Object Class Type Abbreviation

All leaf object classes Common Name CN

Organization Organization O

Organizational Unit Organizational Unit OU

Country Country C

Locality Locality or State/Province L or S

In creating a typeful name, eDirectory uses the type abbreviation, an equal sign, and the object’s
name. For instance, Bob’s partial typeful name is CN=Bob. Bob’s complete typeful name is
CN=Bob.OU=Accounts.OU=Finance.O=YourCo. You can use typeful names interchangeably with
typeless names in eDirectory utilities.

Understanding Novell eDirectory 39

1.3.3 Name Resolution

The process eDirectory uses to find an object’s location in the directory tree is called name
resolution. When you use object names in eDirectory utilities, eDirectory resolves the names

relative to either the current context or the top of the tree.

1.3.4 Current Workstation Context

Workstations have a context set when the networking software runs. This context relatively
identifies the location of the workstation in the network. For example, Bob’s workstation would be
set to the current context as follows:

Accounts.Finance.YourCo

Current context is a key to understanding the use of leading periods, relative naming, and trailing
periods, discussed in the following sections.

1.3.5 Leading Period

novdocx (ENU) 01 February 2006

Use a leading period to resolve the name from the top of the tree, no matter where the current
context is set. In the example below, the leading period tells the CX (Change Context) utility to
resolve the name relative to the top of the tree.

CX .Finance.YourCo

eDirectory interprets the command as “Change the context to the Finance container, which is in the
YourCo container, resolved from the top of the tree.”

1.3.6 Relative Naming

Relative naming means that names are resolved relative to the workstation’s current context, rather
than from the top of the tree. Relative naming never involves a leading period, since a leading period
indicates resolution from the top of the tree.

Suppose a workstation’s current context is set to Finance. (See Figure 1-10.)

Figure 1-10 Sample eDirectory Container

The relative object name of Bob is

Bob.Accounts

eDirectory interprets the name as “Bob, which is in Accounts, resolved from the current context,
which is Finance.”

40 Novell eDirectory 8.8 Administration Guide

1.3.7 Trailing Periods

Trailing periods can be used only in relative naming. Therefore, you can’t use both a leading period
and a trailing period. A trailing period changes the container that eDirectory resolves the name from.

Each trailing period changes the resolution point one container toward the top of the tree. For
example, suppose you want to change your workstation’s current context from Timmins to
Allentown in the example in Figure 1-11 on page 41.

Figure 1-11 Sample eDirectory Container

The proper CX command uses relative naming with trailing periods:

novdocx (ENU) 01 February 2006

CX Allentown.East..

eDirectory interprets the command as “Change the context to Allentown, which is in East, resolved
from two containers up the tree from the current context.”

Similarly, if Bob is in the Allentown container and your workstation’s current context is Timmins,
then Bob’s relative name would be

Bob.Allentown.East..

1.3.8 Context and Naming on Linux and UNIX

When Linux and UNIX user accounts are migrated to eDirectory, the eDirectory context is not used
to name users.

1.4 Schema

Schema defines the types of objects that can be created in your tree (such as Users, Printers, and
Groups) and what information is required or optional at the time the object is created. Every object
has a defined schema class for that type of object.

The schema that originally shipped with the product is called the base schema. After the base
schema has been modified in any way—such as adding a new class or a new attribute—then it is
considered the extended schema.

You aren't required to extend the schema, but you have the ability to do so. The Schema role in
iManager lets you extend the schema to meet organizational needs. For example, you might want to
extend your schema if your organization requires special footwear for employees and you need to
keep track of employee shoe sizes. You might want to create a new attribute called Shoe Size and
then add it to the User class.

For more information, see Chapter 4, “Managing the Schema,” on page 117.

Understanding Novell eDirectory 41

1.4.1 Schema Management

The Schema role in Novell iManager lets users who have the Supervisor rights to a tree customize
the schema of that tree. The Schema role, and its associated tasks, is available on the Roles and Task
page in iManager.

Use the Schema role to

• View a list of all classes and attributes in the schema.

• View information on an attribute such as its syntax and flags.

• Extend the schema by adding a class or an attribute to the existing schema.

• Create a class by naming it and specifying attributes, flags, containers that it can be added to,
and parent classes that it can inherit attributes from.

• Create an attribute by naming it and specifying its syntax and flags.

• Add an optional attribute to an existing class.

• Delete a class or attribute that is not used or that is obsolete.

novdocx (ENU) 01 February 2006

1.4.2 Schema Classes, Attributes, and Syntaxes

• “Classes” on page 42

• “Attributes” on page 43

• “Syntaxes” on page 43

Classes

A class is like a template for a directory object. A directory object is a class that has been filled in
with data. In other words:

CLASS + DATA = DIRECTORY OBJECT

Each class has a class name, an inheritance class (unless it is at the top of the class hierarchy), class
flags, and a group of attributes. Classes are named like directory objects (User, Printer, Queue,
Server, etc.), yet they are just structure, with no content.

An inheritance class is a class that is a starting point for defining other object classes. All of the
attributes of the inheritance class are inherited by the classes that come below it in the class
hierarchy.

A class hierarchy shows how a class is associated with its parent classes. This is a way of associating
similar classes and allowing attributes to be inherited. It also defines the types of containers the class
is valid in.

When creating a new class, you can use the class hierarchy and the additional attributes available to
customize each class. You can specify an inheritance class (which allows the new class to inherit all
of the attributes and flags of a class higher in the hierarchy) and then customize the new class by
selecting one or more attributes to add to those that were inherited. The additional attributes can be
selected as mandatory, naming, or optional attributes.

You can also modify existing classes by adding optional attributes.

42 Novell eDirectory 8.8 Administration Guide

Attributes

Attributes are the data fields in the eDirectory database. For example, if a class is like a form, then
an attribute is one field on the form. When an attribute is created, it is named (such as surname or
employee number) and given a syntax type (such as string or number). From then on, it is available
in the attribute lists in Schema Manager.

Syntaxes

There are several syntax options to choose from. These are used to specify the type of data entered
for each attribute. The syntax can be specified only when an attribute is created. You cannot modify
it later. Available syntaxes include the following:

• Backlink

Used to keep track of other servers referring to an object. It is used for internal eDirectory
management purposes.

• Boolean

Used by attributes whose values are True (represented as 1) or False (represented as 0). The
single-valued flag is set for this syntax type.

• Case Exact String

Used by attributes whose values are Unicode strings that are case sensitive in comparison
operations. Two Case Exact Strings match when they are of the same length and their
corresponding characters, including case, are identical.

•Case Ignore List

novdocx (ENU) 01 February 2006

Used by attributes whose values are ordered sequences of Unicode strings that are not case
sensitive in comparisons operations. Two Case Ignore Lists match if the number of strings in
each is the same and all corresponding strings match (that is, they are the same length and their
corresponding characters are identical).

• Case Ignore String

Used by attributes whose values are Unicode strings that are not case sensitive in comparison
operations. Two Case Ignore Strings match when they are of the same length and their
corresponding characters are identical in all respects except that of case.

• Class Name

Used by attributes whose values are object class names. Two Class Names match when they are
of the same length and their corresponding characters are identical in all respects except that of
case.

• Counter

Used by attributes whose values are incrementally modified numeric signed integers. Any
attribute defined using Counter is a single-valued attribute. This syntax differs from Integer in
that any value added to an attribute of this syntax is arithmetically added to the total, and any
value deleted is arithmetically subtracted from the total.

• Distinguished Name

Used by attributes whose values are the names of objects in the eDirectory tree. Distinguished
Names (DN) are not case sensitive, even if one of the naming attributes is case sensitive.

• E-mail Address

Understanding Novell eDirectory 43

Used by attributes whose values are strings of binary information. eDirectory makes no
assumption about the internal structure of the content of this syntax.

• Facsimile Telephone Number

Specifies a string that complies with the E.123 standard for storing international telephone
numbers and an optional bit string formatted according to recommendation T.20. Facsimile
Telephone Number values match when they are of the same length and their corresponding
characters are identical, except that all spaces and hyphen characters are ignored during
comparison.

• Hold

Used by attributes that are accounting quantities, whose values are signed integers. This syntax
is an accounting quantity (which is an amount tentatively held against a subject’s credit limit,
pending completion of a transaction). The hold amount is treated similarly to the Counter
syntax, with new values added to or subtracted from the base total. If the evaluated hold
amount goes to 0, the Hold record is deleted.

• Integer

Used by attributes represented as signed numeric values. Two Integer values match if they are
identical. The comparison for ordering uses signed integer rules.

• Interval

novdocx (ENU) 01 February 2006

Used by attributes whose values are signed numeric integers and represent intervals of time.
The Interval syntax uses the same representation as the Integer syntax. The Interval value is the
number of seconds in a time interval.

• Net Address

Represents a network layer address in the server environment. The address is in binary format.
For two values of Net Address to match, the type, length, and value of the address must match.

• Numeric String

Used by attributes whose values are numerical strings as defined in the CCITT X.208 definition
of Numeric String. For two Numeric Strings to match, the strings must be the same length and
their corresponding characters must be identical. Digits (0...9) and space characters are the only
valid characters in the numeric string character set.

• Object ACL

Used by attributes whose values represent Access Control List (ACL) entries. An Object ACL
value can protect either an object or an attribute.

•Octet List

Describes an ordered sequence of strings of binary information or Octet String. An Octet List
matches a stored list if it is a subset of the stored list. For two Octet Lists to match, they must be
the same length, and the corresponding bit sequence (octet) must be identical.

•Octet String

Used by attributes whose values are strings of binary information not interpreted by eDirectory.
These octet strings are non-Unicode strings. For two octet strings to match, they must be the
same length, and the corresponding bit sequence (octet) must be identical.

•Path

Attributes that represent a file system path contain all the information to locate a file on a
server. Two paths match when they are of the same length and their corresponding characters,
including case, are identical.

44 Novell eDirectory 8.8 Administration Guide

• Postal Address

Used by attributes whose values are Unicode strings of postal addresses. An attribute value for
Postal Address is typically composed of selected attributes from the MHS Unformatted Postal
O/R Address Specification version 1 according to recommendation F.401. The value is limited
to six lines of 30 characters each, including a postal country name. Two postal addresses match
if the number of strings in each is the same and all corresponding strings match (that is, they are
the same length and their corresponding characters are identical).

• Printable String

Used by attributes whose values are printable strings, as defined in CCITT X.208. The
printable character set consists of the following:

• Uppercase and lowercase alphabetic characters

• Digits (0...9)

• Space character

• Apostrophe (’)

• Left and right parentheses ( )

• Plus sign (+)

• Comma (,)

• Hyphen (-)

novdocx (ENU) 01 February 2006

• Period (.)

• Forward slash (/)

• Colon (:)

• Equals sign (=)

• Question mark (?)

Two printable strings are equal when they are the same length and their corresponding
characters are the same. Case is significant.

• Replica Pointer

Used by attributes whose values represent partition replicas. A partition of an eDirectory tree
can have replicas on different servers. The syntax has six components:

•Server Name

• Replica Type (master, secondary, read-only, subordinate reference)

• Replica Number

•Replica Root ID

• Number of Address

• Address Record

•Stream

Represents arbitrary binary information. The Stream syntax provides a way to make an
eDirectory attribute out of a file on a file server. Login scripts and other stream attributes use
this syntax. The data stored in a stream file has no syntax enforcement of any kind. It is
completely arbitrary data, defined by the application that created and uses it.

• Telephone Number

Understanding Novell eDirectory 45

Used by attributes whose values are telephone numbers. The length of telephone number
strings must be between 1 and 32 characters. Two telephone numbers match when they are of
the same length and their corresponding characters are identical, except that all spaces and
hyphen characters are ignored during comparison.

•Time

Used by attributes whose values are unsigned integers and represent time expressed in seconds.

•Timestamp

Used by attributes whose values mark the time when a particular event occurred. When a
significant event occurs, an eDirectory server mints a new Timestamp value and associates the
value with the event. Every Timestamp value is unique within an eDirectory partition. This
provides a total ordering of events occurring on all servers holding replicas of a partition.

• Typed Name

Used by attributes whose values represent a level and an interval associated with an object.
This syntax names an eDirectory object and attaches two numeric values to it:

• Level of the attribute indicative of its priority

• Interval representing the number of seconds between certain events or the frequency of the
reference

• Unknown

novdocx (ENU) 01 February 2006

Used by attributes whose attribute definition has been deleted from the schema. This syntax
represents strings of binary information.

1.4.3 Understanding Mandatory and Optional Attributes

Every object has a schema class that has been defined for that type of object, and a class is a group
of attributes organized in a meaningful way. Some of these attributes are mandatory and some are
optional.

Mandatory Attributes

A mandatory attribute is one that must be filled in when an object is being created. For example, if a
new user is being created using the User class, which has the employee number as a mandatory
attribute, then the new User object cannot be created without providing the employee number.

Optional Attributes

An optional attribute is one that can be filled in if desired but can be left without content. For
example, if a new User object is being created using the User class, which has Other Names as an
optional attribute, then the new User object can be created with or without data provided for that
attribute, depending on whether the new user is known by other names.

An exception to the rule is when an optional attribute is used for naming, the attribute then becomes
mandatory.

1.4.4 Sample Schema

Figure 1-12 on page 47 is a sample of part of a schema, which might be similar to your base schema.

This figure shows information on the Organization class. Most of the information displayed on this
screen was specified when the class was created. Some of the optional attributes were added later.

46 Novell eDirectory 8.8 Administration Guide

This icon is assigned to all classes and attributes that are extensions to the base schema.

Figure 1-12 Class Information Page in iManager

novdocx (ENU) 01 February 2006

1.4.5 Designing the Schema

Designing your schema initially can save you time and effort in the long run. You can view the base
schema and determine if it will meet your needs or if modifications are required. If changes are
needed, use Schema Manager to extend the schema. See Section 4.1, “Extending the Schema,” on

page 117 and Section 4.2, “Viewing the Schema,” on page 121 for more information.

1.5 Partitions

A partition is a logical division of the eDirectory database. A directory partition forms a distinct unit
of data in the tree that stores directory information.

Partitioning allows you to take part of the directory off one server and put it on another server.

If you have slow or unreliable WAN links or your directory has so many objects that the server is
overwhelmed and access is slow, you should consider partitioning the directory. For a complete
discussion of partitions, see Chapter 5, “Managing Partitions and Replicas,” on page 129.

Each directory partition consists of a set of container objects, all the objects contained in them, and
data about those objects. eDirectory partitions don’t include any information about the file system or
the directories and files contained there.

Understanding Novell eDirectory 47

Partitioning is done with Novell iManager. Partitions are identified in iManager by the following
partition icon ( ).

Figure 1-13 Replica View for a Server

In the above example, the partition icon is next to the Tree object. This means it is the top-most
container in the partition. No partitions are shown by any other containers, so this partition is the
only one.

novdocx (ENU) 01 February 2006

This is the default partitioning for eDirectory, keeping the entire directory together in one partition.

Notice in the example that the Replica View for Server1 is displayed. When you display the Replica
View for a server in iManager, any replicas held on that server are shown on the right. In this case,
Server1 holds a replica of the only partition. For more information, see Section 1.6, “Replicas,” on

page 50 and “Viewing Replicas on an eDirectory Server” on page 137.

1.5.1 Partitions

Partitions are named by their topmost container. In Figure 1-14 there are two partitions, named Tree
and Finance. Finance is called a child partition of Tree, because it was split off from Tree. Tree is
called the parent partition of Finance.

Figure 1-14 Replica View for a Partition

You might create such a partition because the directory has so many objects that the server is
overwhelmed and access to eDirectory is slow. Creating the new partition allows you to split the
database and pass the objects in that branch to a different server.

The example above shows the Replica View for the Finance partition.When you display the Replica
View for a partition in iManager, any servers holding a replica of that partition are shown on the
right. In this case, Server1 holds a Read-Write replica of the Finance partition. For more
information, see “Viewing a Partition’s Replicas” on page 139.

48 Novell eDirectory 8.8 Administration Guide

1.5.2 Distributing Replicas for Performance

In the preceding example, suppose that Server1 holds replicas of both the Tree partition and the
Finance partition. At this point, you haven’t gained any performance advantage from eDirectory
because Server1 still holds the entire directory (replicas of both partitions).

To gain the desired performance advantage, you need to move one of the replicas to a different
server. For instance, if you move the Tree partition to Server2, then Server2 holds all objects in the
Tree and YourCo containers. Server1 holds only objects in the Finance and Accounts containers.
The load on both Server1 and Server2 is less than it would be with no partitioning.

1.5.3 Partitions and WAN Links

Suppose your network spans two sites, a North site and a South Site, separated by a WAN link.
Three servers are at each site.

Figure 1-15 Sample eDirectory Containers

novdocx (ENU) 01 February 2006

eDirectory performs faster and more reliably in this scenario if the directory is divided in two
partitions.

With a single partition, the replicas are either kept at one site or distributed between the two sites.
This proves unwieldy for two reasons:

• If all replicas are kept on servers at the North site, for example, users at the South site encounter
delays when logging in or accessing resources. If the link goes down, users at the South site
can’t log in or access resources at all.

• If replicas are distributed between sites, users can access the directory locally. However, server­to-server synchronization of replicas happens over the WAN link, so there can be eDirectory
errors if the link is unreliable. Any changes to the directory are slow to propagate across the
WAN link.

Understanding Novell eDirectory 49

The two-partition solution shown in Figure 1-16 on page 50 solves performance and reliability
problems over the WAN link.

Figure 1-16 Sample Partitions

Replicas of the Tree partition are kept on servers at the North site. Replicas of the South partition are
kept on servers at the South site, as shown in Figure 1-17.

novdocx (ENU) 01 February 2006

Figure 1-17 Sample Partitions, Severs, and Replicas

For each site, the objects that represent local resources are kept locally. Synchronization traffic
among servers also happens locally over the LAN, rather than over the slow, unreliable WAN link.

eDirectory traffic is generated over the WAN link, however, when a user or administrator accesses
objects at a different site.

1.6 Replicas

A replica is a copy or an instance of a user-defined partition that is distributed to an eDirectory
server. If you have more than one eDirectory server on your network, you can keep multiple replicas

50 Novell eDirectory 8.8 Administration Guide

(copies) of the directory. That way, if one server or a network link to it fails, users can still log in and
use the remaining network resources (see Figure 1-18 on page 51).

Figure 1-18 eDirectory Replicas

Servers A and B

both hold replicas

of eDirectory.

When the link goes down,

users still have access to

Server A Server B

When the link is repaired, eDirectory

eDirectory on their

local servers.

automatically synchronizes

the two replicas.

User WorkstationsUser Workstations

novdocx (ENU) 01 February 2006

Each server can store more than 65,000 eDirectory replicas; however, only one replica of the same
user-defined partition can exist on the same server. For a complete discussion of replicas, see

Chapter 5, “Managing Partitions and Replicas,” on page 129.

We recommend that you keep three replicas for fault tolerance of eDirectory (assuming you have
three eDirectory servers to store them on). A single server can hold replicas of multiple partitions.

A replica server is a dedicated server that stores only eDirectory replicas. This type of server is
sometimes referred to as a DSMASTER server. This configuration is popular with some companies
that use many single-server remote offices. The replica server provides a place for you to store
additional replicas for the partition of a remote office location. (It can also be a part of your disaster
recovery planning, as described in “Using DSMASTER Servers as Part of Disaster Recovery

Planning” on page 386.)

eDirectory replication does not provide fault tolerance for the server file system. Only information
about eDirectory objects is replicated. You can get fault tolerance for file systems by using the

TM

Transaction Tracking System

(TTSTM), disk mirroring/duplexing, RAID, or Novell Replication

Services (NRS).

A master or read/write replica is required on NetWare servers that provide bindery services.

If users regularly access eDirectory information across a WAN link, you can decrease access time
and WAN traffic by placing a replica containing the needed information on a server that users can
access locally.

The same is true to a lesser extent on a LAN. Distributing replicas among servers on the network
means information is usually retrieved from the nearest available server.

Understanding Novell eDirectory 51

1.6.1 Replica Types

eDirectory supports the types of replicas shown in the following figure:

Figure 1-19 Replica Types

• “Master Replica” on page 52

• “Read/Write Replica” on page 53

• “Read-Only Replica” on page 53

• “Filtered Read/Write Replica” on page 53

• “Filtered Read-Only Replica” on page 53

• “Subordinate Reference Replica” on page 54

Master Replica

novdocx (ENU) 01 February 2006

The master replica is a writable replica type used to initiate changes to an object or partition.

The master replica manages the following types of eDirectory partition operations:

• Adding replicas to servers

• Removing replicas from servers

• Creating new partitions in the eDirectory tree

• Removing existing partitions from the eDirectory tree

• Relocating a partition in the eDirectory tree

The master replica is also used to perform the following types of eDirectory object operations:

• Adding new objects to the eDirectory tree

• Removing, renaming, or relocating existing objects in the eDirectory tree

• Authenticating objects to the eDirectory tree

• Adding new object attributes to the eDirectory tree

• Modifying or removing existing attributes

By default, the first eDirectory server on your network holds the master replica. There is only one
master replica for each partition at a time. If other replicas are created, they are read/write replicas
by default.

If you’re going to bring down the server holding a master replica for longer than a day or two, you
can make one of the read/write replicas the master. The original master replica automatically
becomes read/write.

A master replica must be available on the network for eDirectory to perform operations such as
creating a new replica or creating a new partition.

52 Novell eDirectory 8.8 Administration Guide

Read/Write Replica

eDirectory can access and change object information in a read/write replica as well as the

master replica. All changes are then automatically propagated to all replicas.

If eDirectory responds slowly to users because of delays in the network infrastructure (such as slow
WAN links or busy routers), you can create a read/write replica closer to the users who need it. You
can have as many read/write replicas as you have servers to hold them, although more replicas cause
more traffic to keep them synchronized.

Read-Only Replica

The read-only replica is a readable replica type used to read information about all objects in a

partition’s boundaries. Read-only replicas receive synchronization updates from master and read/
write replicas but don’t receive changes directly from clients.

This replica type is not able to provide bindery emulation, but it does provide eDirectory tree fault
tolerance. If the master replica and all read/write replicas are destroyed or damaged, the read-only
replica can be promoted to become the new master replica.

It also provides NDS Object Reads, Fault Tolerance (contains all objects within the Partition
boundaries), and NDS Directory Tree Connectivity (contains the Partition Root object).

novdocx (ENU) 01 February 2006

A read-only replica should never be used to establish a security policy within a tree to restrict the
modification of objects, because the client can always access a read/write replica and still make
modifications. There are other mechanisms that exist in the directory for this purpose, such as using
an Inherited Rights Filter. For more information, see “Inherited Rights Filter (IRF)” on page 61.

Filtered Read/Write Replica

Filtered read/write replicas contain a filtered set of objects or object classes along with a

filtered set of attributes and values for those objects. The contents are limited to the types of
eDirectory objects and properties specific in the host server's replication filter. Users can read and
modify the contents of the replica, and eDirectory can access and change selected object
information. The selected changes are then automatically propagated to all replicas.

With filtered replicas, you can have only one filter per server. This means that any filter defined for
a server applies to all filtered replicas on that server. You can, however, have as many filtered
replicas as you have servers to hold them, although more replicas cause more traffic to keep them
synchronized.

For more information, see “Filtered Replicas” on page 54.

Filtered Read-Only Replica

Filtered read-only replicas contain a filtered set of objects or object classes along with a

filtered set of attributes and values for those objects. They receive synchronization updates from
master and read/write replicas but don’t receive changes directly from clients. Users can read but not
modify the contents of the replica. The contents are limited to the types of eDirectory objects and
properties specific in the host server's replication filter.

For more information, see “Filtered Replicas” on page 54.

Understanding Novell eDirectory 53

Subordinate Reference Replica

Subordinate reference replicas are system-generated replicas that don’t contain all the object data of
a master or a read/write replica. Subordinate reference replicas, therefore, don’t provide fault
tolerance. They are internal pointers that are generated to contain enough information for eDirectory
to resolve object names across partition boundaries.

You can’t delete a subordinate reference replica; eDirectory deletes it automatically when it is not
needed. Subordinate reference replicas are created only on servers that hold a replica of a parent
partition but no replicas of its child partitions.

If a replica of the child partition is copied to a server holding the replica of the parent, the
subordinate reference replica is automatically deleted.

1.6.2 Filtered Replicas

Filtered replicas contain a filtered set of objects or object classes along with a filtered set of
attributes and values for those objects. For example, you might want to create a set of filtered
replicas on a single server that contains only User objects from various partitions in the eDirectory
tree. In addition to this, you can choose to include only a subset of the User objects’ data (for
example, Given Name, Surname, and Telephone Number).

novdocx (ENU) 01 February 2006

A filtered replica can construct a view of eDirectory data onto a single server. To do this, filtered
replicas let you create a scope and a filter. This results in an eDirectory server that can house a well­defined data set from many partitions in the tree.

The descriptions of the server’s scope and data filters are stored in eDirectory and can be managed
through the Server object in iManager.

A server hosting one of more filtered replicas has only a single replication filter. Therefore, all
filtered replicas on the server contain the same subset of information from their respective partitions.
The master partition replica of a filtered replica must be hosted on an eDirectory server running
eDirectory 8.5 or later.

Filtered replicas can

• Reduce synchronization traffic to the server by reducing the amount of data that must be
replicated from other servers.

• Reduce the number of events that must be filtered by Novell Nsure Identity Manager.

For more information on Novell Nsure Identity Manager, see the Novell Nsure Identity

Manager Administration Guide (http://www.novell.com/documentation/dirxml20/index.html).

• Reduce the size of the directory database.

Each replica adds to the size of the database. By creating a filtered replica that contains only
specific classes (instead of creating a full replica), you can reduce the size of your local
database.

For example, if your tree contains 10,000 objects but only a small percentage of those objects
are Users, you could create a filtered replica containing only the User objects instead of a full
replica containing all 10,000 objects.

Other than the ability to filter data stored in a local database, the filtered replica is like a normal
eDirectory replica and it can be changed back to a full replica at any time.

54 Novell eDirectory 8.8 Administration Guide

NOTE: Filtered replicas by default will have the Organization and the Organizational Unit as
mandatory filters.

For more information on setting up and managing filtered replicas, see Section 5.6, “Setting Up and

Managing Filtered Replicas,” on page 136.

1.7 NetWare Bindery Emulation

Many applications, such as print servers and backup software, were written for NetWare versions
earlier than NetWare 4. These applications used the NetWare bindery instead of eDirectory for
network access and object manipulation.

The bindery is a flat database of objects such as Users, Groups, and Volumes known to a given
server. The bindery is server specific and server centric.

Older NetWare client software (such as the NETX bindery shell) used a bindery login procedure in
which a user logged in to a specific server only. Access to multiple servers required multiple logins
using multiple user accounts.

novdocx (ENU) 01 February 2006

eDirectory allows applications written for a bindery to function using bindery services. Bindery
services allows you to set an eDirectory context or a number of contexts (up to 12) as an eDirectory
server’s virtual bindery. The context you set is called the server’s bindery context.

Following are some important facts about bindery services:

• To use bindery services, you must set a bindery context for the eDirectory server.

• Not all objects map to bindery objects. Many objects, such as Alias objects, do not have a
bindery equivalent.

• Most bindery applications have been upgraded to work with eDirectory. Check with your
application vendor to get the newest version.

• Each eDirectory server with a bindery context must hold a master or read/write replica of the
partition that includes the bindery context.

1.8 Server Synchronization in the Replica Ring

When multiple servers hold replicas of the same partition, those servers are considered a replica
ring. Synchronization is the propagation of directory information from one replica to another, so the
information in each partition is consistent with the other. eDirectory automatically keeps those
servers synchronized. For more information, refer Section 3.4, “Synchronization,” on page 105

The following are the types of eDirectory synchronization:

• Normal Synchronization or Replica Synchronization

• Priority Sync

1.9 Access to Resources

eDirectory provides a basic level of network access security through default rights. You can provide
additional access control by completing the tasks outlined below.

• Assigning rights

Understanding Novell eDirectory 55

Each time a user attempts to access a network resource, the system calculates the user’s
effective rights to that resource. To ensure that users have the appropriate effective rights to
resources, you can make explicit trustee assignments, grant security equivalences, and filter
inherited rights.

To simplify the assignment of rights, you can create Group and Organizational Role objects,
then assign users to the groups and roles.

• Adding login security

Login security is not provided by default. You can set up several optional login security
measures, including login passwords, login location and time restrictions, limits on concurrent
login sessions, intruder detection, and login disabling.

• Setting up role-based administration

You can set up administrators for specific object properties and grant them rights to only those
properties. This allows you to create administrators with specific responsibilities that can be
inheritable to subordinates of any given container object. A role-based administrator can have
responsibilities over any specific properties, such as those that relate to employee information
or passwords.

See Installing RBS (http://www.novell.com/documentation/imanager25/imanager_admin_25/

data/am757mw.html#bu1rlq9) in the Novell iManager 2.5 Administration Guide for instruction

on setting up Role-Based Services.

novdocx (ENU) 01 February 2006

You can also define roles in terms of the specific tasks that administrators can perform in role­based administration applications. See Section 3.3, “Configuring Role-Based Services,” on

page 101 for more information.

1.10 eDirectory Rights

When you create a tree, the default rights assignments give your network generalized access and
security. Some of the default assignments are as follows:

• User Admin has the Supervisor right to the top of the tree, giving Admin complete control over
the entire directory. Admin also has the Supervisor right to the NetWare Server object, giving
complete control over any volumes on that server.

• [Public] has the Browse right to the top of the tree, giving all users the right to view any objects
in the tree.

• Objects created through an upgrade process such as a NetWare migration, printing upgrade, or
Windows user migration receive trustee assignments appropriate for most situations.

1.10.1 Trustee Assignments and Targets

The assignment of rights involves a trustee and a target object. The trustee represents the user or set
of users that are receiving the authority. The target represents those network resources the users have
authority over.

• If you make an Alias a trustee, the rights apply only to the object the alias represents. The Alias
object can be an explicit target, however.

• A file or directory in the NetWare file system can also be a target, although file system rights
are stored in the file system itself, not in eDirectory.

56 Novell eDirectory 8.8 Administration Guide

NOTE: The [Public] trustee is not an object. It is a specialized trustee that represents any network
user, logged in or not, for rights assignment purposes.

1.10.2 eDirectory Rights Concepts

The following concepts can help you better understand eDirectory rights.

• “Object (Entry) Rights” on page 57

• “Property Rights” on page 57

• “Effective Rights” on page 58

• “How Effective Rights Are Calculated” on page 58

• “Security Equivalence” on page 60

• “Access Control List (ACL)” on page 61

• “Inherited Rights Filter (IRF)” on page 61

Object (Entry) Rights

novdocx (ENU) 01 February 2006

When you make a trustee assignment, you can grant object rights and property rights. Object rights
apply to manipulation of the entire object, while property rights apply only to certain object
properties. An object right is described as an entry right because it provides an entry into the
eDirectory database.

A description of each object right follows:

• Supervisor includes all rights to the object and all of its properties.

•Browse lets the trustee see the object in the tree. It does not include the right to see an object’s

properties.

•Create applies only when the target object is a container. It allows the trustee to create new
objects below the container and also includes the Browse right.

• Delete lets the trustee delete the target from the directory.

• Rename lets the trustee change the name of the target.

Property Rights

When you make a trustee assignment, you can grant object rights and property rights. Object rights
apply to manipulation of the entire object, while property rights apply only to certain object
properties.

iManager gives you two options for managing property rights:

• You can manage all properties at once when the [All Attributes Rights] item is selected.

• You can manage one or more individual properties when the specific property is selected.

A description of each property right follows:

• Supervisor gives the trustee complete power over the property.

•Compare lets the trustee compare the value of a property to a given value. This right allows

searching and returns only a true or false result. It does not allow the trustee to actually see the
value of the property.

Understanding Novell eDirectory 57

•Read lets the trustee see the values of a property. It includes the Compare right.

•Write lets the trustee create, change, and delete the values of a property.

•Add Self lets the trustee add or remove itself as a property value. It only applies to properties

with object names as values, such as membership lists or Access Control Lists (ACLs).

Effective Rights

Users can receive rights in a number of ways, such as explicit trustee assignments, inheritance, and
security equivalence. Rights can also be limited by Inherited Rights Filters and changed or revoked
by lower trustee assignments. The net result of all these actions—the rights a user can employ—are
called effective rights.

A user’s effective rights to an object are calculated each time the user attempts an action.

How Effective Rights Are Calculated

Each time a user attempts to access a network resource, eDirectory calculates the user’s effective
rights to the target resource using the following process:

novdocx (ENU) 01 February 2006

1. eDirectory lists the trustees whose rights are to be considered in the calculation. These include

• The user who is attempting to access the target resource.

• The objects that the user is security equivalent to.

2. For each trustee in the list, eDirectory determines its effective rights as follows:

a. eDirectory starts with the inheritable rights that the trustee has at the top of the tree.

eDirectory checks the Object Trustees (ACL) property of the Tree object for entries that
list the trustee. If any are found and they are inheritable, eDirectory uses the rights
specified in those entries as the initial set of effective rights for the trustee.

b. eDirectory moves down a level in the branch of the tree that contains the target resource.

c. eDirectory removes any rights that are filtered at this level.

eDirectory checks the ACL at this level for Inherited Rights Filters (IRFs) that match with
the right types (object, all properties, or a specific property) of the trustee’s effective
rights. If any are found, eDirectory removes from the trustee’s effective rights any rights
that are blocked by those IRFs.

For example, if the trustee’s effective rights so far include an assignment of Write All
Properties, but an IRF at this level blocks Write All Properties, the system removes Write
All Properties from the trustee’s effective rights.

d. eDirectory adds any inheritable rights that are assigned at this level, overriding as needed.

eDirectory checks the ACL at this level for entries that list the trustee. If any are found,
and they are inheritable, eDirectory copies the rights from those entries to the trustee’s
effective rights, overriding as needed.

For example, if the trustee’s effective rights so far include the Create and Delete object
rights but no property rights, and if the ACL at this level contains both an assignment of
zero object rights and an assignment of Write all properties for this trustee, then the
system replaces the trustee’s existing object rights (Create and Delete) with zero rights and
adds the new all property rights.

e. eDirectory repeats the filtering and adding steps (c and d above) at each level of the tree,

including at the target resource.

58 Novell eDirectory 8.8 Administration Guide

f. eDirectory adds any noninheritable rights assigned at the target resource, overriding as

needed.

eDirectory uses the same process as in Step 2d above. The resulting set of rights
constitutes the effective rights for this trustee.

3. eDirectory combines the effective rights of all the trustees in the list as follows:

a. eDirectory includes every right held by any trustee in the list and excludes only those

rights that are missing from every trustee in the list. eDirectory does not mix right types.
For example, it does not add rights for a specific property to rights for all properties or
vice versa.

b. eDirectory adds rights that are implied by any of the current effective rights.

The resulting set of rights constitutes the user’s effective rights to the target resource.

Example

User DJones is attempting to access volume Acctg_Vol. (See Figure 1-20.)

Figure 1-20 Sample Trustee Rights

novdocx (ENU) 01 February 2006

[Public] Browse object
(inheritable) [Public] Read
all prop (inheritable)

IRF Write all prop (n/a)
DJones Write all prop

DJones zero object
(inheritable) DJones zero

ACL

ACL

ACL

The following process shows how eDirectory calculates DJones’ effective rights to Acctg_Vol:

1. The trustees whose rights are to be considered in the calculation are DJones, Marketing, Tree,
and [Public].

This assumes that DJones doesn’t belong to any groups or roles and has not been explicitly
assigned any security equivalences.

2. The effective rights for each trustee are as follows:

• DJones: Zero object, zero all properties

The assignment of zero all property rights at Acctg_Vol overrides the assignment of Write
all properties at Accounting.

• Marketing: Zero all properties

The assignment of Write all properties at the top of the tree is filtered out by the IRF at
Accounting.

• Tree: No rights

No rights are assigned for Tree anywhere in the pertinent branch of the tree.

• [Public]: Browse object, Read all properties

Understanding Novell eDirectory 59

These rights are assigned at the root and aren’t filtered or overridden anywhere in the
pertinent branch of the tree.

3. Combining the rights from all these trustees results in the following:

DJones: Browse object, Read all properties

4. Adding the Compare all properties right that is implied by the Read all properties right, DJones
has the following final effective rights to Acctg_Vol:

DJones: Browse object, Read and Compare all properties

Blocking Effective Rights

Because of the way that effective rights are calculated, it is not always obvious how to block
particular rights from being effective for specific users without resorting to an IRF (an IRF blocks
rights for all users).

To block particular rights from being effective for a user without using an IRF, do either of the
following:

• Ensure that neither the user nor any of the objects that the user is security equivalent to ever
gets assigned those rights, either at the target resource or at any level above the target resource
in the tree.

novdocx (ENU) 01 February 2006

• If the user or any object that the user is security equivalent to does get assigned those rights,
ensure that that object also has an assignment lower in the tree that omits those rights. Do this
for every trustee (associated with the user) that has the unwanted rights.

Security Equivalence

Security equivalence means having the same rights as another object. When you make one object
security equivalent to another object, the rights of the second object are added to the rights of the
first object when the system calculates the first object's effective rights.

For example, suppose you make User object Joe security equivalent to the Admin object. After you
create the security equivalence, Joe has the same rights to the tree and file system as Admin.

There are three types of security equivalence:

• Explicit: By assignment

• Automatic: By membership in a group or role

• Implied: Equivalent to all parent containers and the [Public] trustee

Security equivalence is effective only for one step. For example, if you make a third user security
equivalent to Joe in the example above, that user does not receive Admin rights.

Security equivalence is recorded in eDirectory as values in the User object’s Security Equal To
property.

When you add a User object as an occupant to an Organizational Role object, that User
automatically becomes security equivalent to the Organizational Role object. The same is true when
a User becomes a member of a Group role object.

60 Novell eDirectory 8.8 Administration Guide

Access Control List (ACL)

The Access Control List (ACL) is also called the Object Trustees property. Whenever you make a
trustee assignment, the trustee is added as a value to the Object Trustees (ACL) property of the
target.

This property has strong implications for network security for the following reasons:

• Anyone who has the Supervisor or Write right to the Object Trustees (ACL) property of an
object can determine who is a trustee of that object.

• Any users with the Add Self right to the Object Trustees (ACL) property of an object can
change their own rights to that object. For example, they can grant themselves the Supervisor
right.

For these reasons, be careful giving Add Self rights to all properties of a container object. That
assignment makes it possible for the trustee to become Supervisor of that container, all objects in it,
and all objects in containers beneath it.

Inherited Rights Filter (IRF)

novdocx (ENU) 01 February 2006

The Inherited Rights Filter allows you to block rights from flowing down the eDirectory Tree. For
more information on configuring this filter, see “Blocking Inherited Rights to an eDirectory Object

or Property” on page 65.

1.10.3 Default Rights for a New Server

When you install a new Server object into a tree, the following trustee assignments are made:

Default Trustees Default Rights

Admin (first eDirectory server in the tree) Supervisor object right to the Tree object.

Admin has the Supervisor object right to the NetWare
Server object, which means that Admin also has the
Supervisor right to the root directory of the file system
of any volumes on the server.

[Public] (first eDirectory server in the tree) Browse object right to the Tree object.

Tree The Tree Read property right to the Host Server Name

and Host Resource properties on all Volume objects.

This gives all objects access to the physical volume
name and physical server name.

Container objects Read and File Scan rights to sys: \public. This allows

User objects under the container to access NetWare
utilities in \public.

User objects If home directories are automatically created for users,

the users have the Supervisor right to those directories.

Understanding Novell eDirectory 61

1.10.4 Delegated Administration

eDirectory lets you delegate administration of a branch of the tree, revoking your own management
rights to that branch. One reason for this approach is that special security requirements require a
different administrator with complete control over that branch.

To delegate administration:

1 Grant the Supervisor object right to a container.

1a In Novell iManager, click the Roles and Tasks button .

1b Click Rights > Modify Trustees.

1c Enter the name and context of the container object that you want to control access to, then

click OK.

1d Click Assigned Rights.

1e Click the Supervisor checkbox for the properties you want.

1f Click Done, then click OK.

2 Create an IRF on the container that filters the Supervisor and any other rights you want

blocked.

novdocx (ENU) 01 February 2006

2a In Novell iManager, click the Roles and Tasks button

2b Click Rights > Modify Inherited Rights Filter.

2c Specify the name and context of the object whose inherited rights filter you want to

modify, then click OK.

2d Edit the list of inherited rights filters as needed.

To edit the list of filters, you must have the Supervisor or Access Control right to the ACL
property of the object. You can set filters that block inherited rights to the object as a
whole, to all the properties of the object, and to individual properties.

NOTE: These filters won't block rights that are explicitly granted a trustee on this object,
since such rights aren't inherited.

2e Click OK.

IMPORTANT: If you delegate administration to a User object and that object is subsequently
deleted, there are no objects with rights to manage that branch.

To delegate administration of specific eDirectory properties, such as Password Management, see

“Granting Equivalence” on page 64.

To delegate the use of specific functions in role-based administration applications, see Section 3.3,

“Configuring Role-Based Services,” on page 101.

1.10.5 Administering Rights

• “Assigning Rights Explicitly” on page 63

• “Granting Equivalence” on page 64

• “Blocking Inherited Rights to an eDirectory Object or Property” on page 65

• “Viewing Effective Rights to an eDirectory Object or Property” on page 66

62 Novell eDirectory 8.8 Administration Guide

Assigning Rights Explicitly

When the default rights assignments in your eDirectory tree provide users with either too much or
not enough access to resources, you can create or modify explicit rights assignments. When you
create or modify a rights assignment, you start by selecting either the resource that you are
controlling access to or the trustee (the eDirectory object that possesses, or will possess, the rights).

TIP: To manage users' rights collectively rather than individually, make a group, role, or container
object the trustee. To restrict access to a resource globally (for all users), see “Blocking Inherited

Rights to an eDirectory Object or Property” on page 65.

• “Controlling Access to Novell eDirectory by Resource” on page 63

• “Controlling Access to Novell eDirectory by Trustee” on page 63

Controlling Access to Novell eDirectory by Resource

1 In Novell iManager, click the Roles and Tasks button .

2 Click Rights > Modify Trustees.

3 Specify the name and context of the eDirectory resource (object) that you want to control

access to, then click OK.

Choose a container if you want to control access to all the objects below it.

4 Edit the list of trustees and their rights assignments as needed.

novdocx (ENU) 01 February 2006

4a To modify a trustee's rights assignment, select the trustee, click Assigned Rights, modify

the rights assignment as needed, then click Done.

4b To add an object as a trustee, click Add Trustee, select the object, click OK, click Assigned

Rights to assign the trustee's rights, then click Done.

When creating or modifying a rights assignment, you can grant or deny access to the
object as a whole, to all the properties of the object, and to individual properties.

4c To remove an object as a trustee, select the trustee, then click Delete Trustee.

The deleted trustee no longer has explicit rights to the object or its properties but might
still have effective rights through inheritance or security equivalence.

5 Click OK.

Controlling Access to Novell eDirectory by Trustee

1 In Novell iManager, click the Roles and Tasks button .

2 Click Rights > Rights to Other Objects.

3 Enter the name and context of the trustee (the object that possesses, or will possess, the rights)

whose rights you want to modify.

4 In the Context to Search From field, specify the part of the eDirectory tree to be searched for

eDirectory objects that the trustee currently has rights assignments to.

5 Click OK.

A screen appears showing the progress of the search. When the search is done, the Rights to
Other Objects page appears with the results of the search filled in.

6 Edit the trustee's eDirectory rights assignments as needed.

Understanding Novell eDirectory 63

6a To add a rights assignment, click Add Object, select the object to control access to, click

OK, click Assigned Rights, assign the trustee's rights, then click Done.

6b To modify a rights assignment, select the object you want to control access to, click

Assigned Rights, modify the trustee's rights assignment as needed, then click Done.

When creating or modifying a rights assignment, you can grant or deny access to the
object as a whole, to all the properties of the object, and to individual properties.

6c To remove a rights assignment, select the object you want to control access to, then click

Delete Object.

The trustee no longer has explicit rights to the object or its properties but might still have
effective rights through inheritance or security equivalence.

7 Click OK.

Granting Equivalence

A user who is security equivalent to another eDirectory object effectively has all the rights of that
object. A user is automatically security equivalent to the groups and roles that they belong to. All
users are implicitly security equivalent to the [Public] trustee and to each container above their User
objects in the eDirectory tree, including the Tree object. You can also explicitly grant a user security
equivalence to any eDirectory object.

novdocx (ENU) 01 February 2006

NOTE: The tasks in this section allow you to delegate administrative authority through eDirectory
rights. If you have administration applications that use Role-Based Services (RBS) roles, you can
also delegate administrative authority by assigning users membership in those roles.

• “Granting Security Equivalence by Membership” on page 64

• “Granting Security Equivalence Explicitly” on page 65

• “Setting Up an Administrator For an Object's Specific eDirectory Properties” on page 65

Granting Security Equivalence by Membership

1 If you haven't already done so, create the group or role object that you want the users to be

security equivalent to.

See “Creating an Object” on page 94 for details.

2 Grant the group or role the eDirectory rights that you want the users to have.

See “Assigning Rights Explicitly” on page 63 for details.

3 Edit the membership of the group or role to include those users who need the rights of the

group or role.

• For a Group object, use the Members property page.

In Novell iManager, click eDirectory Administration > Modify Object, specify the name
and context of a Group object, click OK, then click the Members tab.

• For an Organizational Role object, use the Role Occupant field on the Role Occupant
property page.

In Novell iManager, click eDirectory Administration > Modify Object, specify the name
and context of an rbsRole object, click OK, then click Role Occupant on the General tab.

• For an rbsRole object, use the Modify iManager Members page.

64 Novell eDirectory 8.8 Administration Guide

In Novell iManager, click the Configure button , click Role Configuration > Modify
iManager Roles, click the Modify Members button to the left of the role you want to

modify, then use the options on the Modify iManager Members page to add or remove
members from a role.

4 Click OK.

Granting Security Equivalence Explicitly

1 In Novell iManager, click the Roles and Tasks button .

2 Click eDirectory Administration > Modify Object.

3 Enter the name and context of the user or object that you want the user to be security equivalent

to, then click OK.

4 Click the Security tab, then grant the security equivalence as follows:

• If you chose a user, click Security Equal To > enter the name and context of the object that
you want the user to be security equivalent to, press Enter, then click OK.

• If you chose an object that you want the user to be security equivalent to, click Security
Equal to Me, enter the name and context of the user that you want the object to be security
equivalent to, press Enter, then click OK.

The contents of these two property pages are synchronized by the system.

novdocx (ENU) 01 February 2006

5 Click OK.

Setting Up an Administrator For an Object's Specific eDirectory Properties

1 If you haven’t already done so, create the User, Group, Role, or Container object that you want

to make a trustee of the object's specific properties.

If you create a container as a trustee, all objects inside and below the container will have the
rights you grant. You must make the property inheritable or the container and its members will
not have rights below its level.

See “Creating an Object” on page 94 for information.

2 In Novell iManager, click the Roles and Tasks button .

3 Click Rights > Modify Trustees.

4 Specify the name and context of the highest-level container that you want the administrator to

manage, then click OK.

5 On the Modify Trustees page, click Add Trustee, select the object that represents the

administrator, then click OK.

6 Click Assigned Rights for the trustee you just added, then click Add Property.

7 Select the properties you want to add to the property list, then click

OK.

8 For each property that the administrator will manage, assign the needed rights.

Be sure to select the Inheritable check box on each rights assignment.

9 Click Done, then click OK.

Blocking Inherited Rights to an eDirectory Object or Property

In eDirectory, rights assignments on containers can be inheritable or non-inheritable. In the NetWare
file system, all rights assignments on folders are inheritable. In both eDirectory and NetWare, you

Understanding Novell eDirectory 65

can block such inheritance on individual subordinate items so that the rights aren’t effective on those
items, no matter who the trustee is. One exception is that the Supervisor right can’t be blocked in the
NetWare file system.

1 In Novell iManager, click the Roles and Tasks button

2 Click Rights > Modify Inherited Rights Filter.

3 Specify the name and context of the object whose inherited rights filter you want to modify,

then click OK.

This displays a list of the inherited rights filters that have already been set on the object.

4 On the property page, edit the list of inherited rights filters as needed.

To edit the list of filters, you must have the Supervisor or Access Control right to the ACL
property of the object. You can set filters that block inherited rights to the object as a whole, to
all the properties of the object, and to individual properties.

NOTE: These filters won't block rights that are explicitly granted a trustee on this object,
because such rights aren't inherited.

5 Click OK.

novdocx (ENU) 01 February 2006

Viewing Effective Rights to an eDirectory Object or Property

Effective rights are the actual rights users can exercise on specific network resources. They are
calculated by eDirectory based on explicit rights assignments, inheritance, and security equivalence.
You can query the system to determine a user’s effective rights to any resource.

1 In Novell iManager, click the Roles and Tasks button

2 Click Rights > View Effective Rights.

3 Enter the name and context of the trustee whose effective rights you want to view, then click

OK.

4 Choose from the following options:

Option Description

Property Name Lists the properties that the trustee has effective rights to. The

properties are read from eDirectory and so are always shown in
English. Each item in the list is one of the following types:

[All Attributes Rights]-Represents all the properties of the object.

[Entry Rights]-Represents the object as a whole. Rights to this
item don’t imply any property rights, except in the case of
Supervisor.

Specific properties-These are specific properties that the trustee
has rights to individually. By default, only properties of this object
class are listed (see below).

Effective Rights Shows the trustee’s effective rights to the selected property, as

66 Novell eDirectory 8.8 Administration Guide

calculated by eDirectory.

Option Description

Show All Properties in Schema Leave this check box deselected to show only the properties of

this object class.

To show the properties of all classes defined in the eDirectory
schema, select this check box. The additional properties are
pertinent only if this object is a container, or if it has been
extended to include the properties of an auxiliary class. The
additional properties are shown without a bullet next to them.

5 Click Done.

novdocx (ENU) 01 February 2006

Understanding Novell eDirectory 67

novdocx (ENU) 01 February 2006

68 Novell eDirectory 8.8 Administration Guide

2

Designing Your Novell eDirectory

novdocx (ENU) 01 February 2006

Network

The design of Novell® eDirectoryTM impacts virtually every network user and resource. A good
eDirectory design can enhance the performance and value of the entire network by making the
network more efficient, fault tolerant, secure, and scalable, and operable. This chapter provides
suggestions for designing your eDirectory network.

• Section 2.1, “eDirectory Design Basics,” on page 69

• Section 2.2, “Designing the eDirectory Tree,” on page 70

• Section 2.3, “Guidelines for Partitioning Your Tree,” on page 76

• Section 2.4, “Guidelines for Replicating Your Tree,” on page 78

• Section 2.5, “Planning the User Environment,” on page 80

• Section 2.6, “Designing eDirectory for e-Business,” on page 81

• Section 2.7, “Understanding the Novell Certificate Server,” on page 82

• Section 2.8, “Synchronizing Network Time,” on page 86

•

2.1 eDirectory Design Basics

2

An efficient eDirectory design is based on the network layout, organizational structure of the
company, and proper preparation.

If you are designing eDirectory for e-business, refer to Section 2.6, “Designing eDirectory for e-

Business,” on page 81.

2.1.1 Network Layout

The network layout is the physical setup of your network. To develop an efficient eDirectory design,
you need to be aware of the following:

• WAN links

• Users that need remote access

• Network resources (such as number of servers)

• Network conditions (such as frequent power outages)

• Anticipated changes to the network layout

2.1.2 Organizational Structure

The organizational structure of the company will influence the eDirectory design. To develop an
efficient eDirectory design you need

• The organizational chart and an understanding of how the company operates.

Designing Your Novell eDirectory Network

69

• Personnel who have the skills needed to complete the design and implementation of your
eDirectory tree.

You will need to identify personnel who can do the following:

• Maintain the focus and schedule of the eDirectory design

• Understand eDirectory design, design standards, and security

• Understand and maintain the physical network structure

• Manage the internetwork backbone, telecommunications, WAN design, and router
placement

2.1.3 Preparing for eDirectory Design

Before you actually create the eDirectory design, you should

• Set realistic expectations concerning scope and schedule.

• Notify all users who will be affected by the design of your implementation of eDirectory.

• Review the information in “Network Layout” on page 69 and “Organizational Structure” on

page 69.

novdocx (ENU) 01 February 2006

2.2 Designing the eDirectory Tree

Designing the eDirectory tree is the most important procedure in the design and implementation of a
network. The design consists of the following tasks:

• “Creating a Naming Standards Document” on page 70

• “Designing the Upper Layers of the Tree” on page 73

• “Designing the Lower Layers of the Tree” on page 75

2.2.1 Creating a Naming Standards Document

Using standard names such as object names makes your network more intuitive to both users and
administrators. Written standards can also specify how administrators set other property values, such
as telephone numbers and addresses.

Searching and browsing the directory rely greatly on the consistency of naming or property values.

The use of standard names also makes it easier for Novell Nsure Identity Manager to move data
between eDirectory and other applications. For more information on Novell Nsure Identity
Manager, see the Novell Nsure Identity Manager Administration Guide (http://www.novell.com/

documentation/dirxml20/index.html).

Naming Conventions

• “Objects” on page 71

• “Server Objects” on page 71

• “Country Objects” on page 71

• “Bindery Objects” on page 71

70 Novell eDirectory 8.8 Administration Guide

Objects

• The name must be unique in the container. For example, Debra Jones and Daniel Jones cannot
both be named DJONES if they are in the same container.

• Special characters are allowed. However, plus signs (+), equals signs (=), and periods (.) must
be preceded by a backslash (\) if used. Additional naming conventions apply to Server and
Country objects, as well as to bindery services and multilingual environments.

• Uppercase and lowercase letters, as well as underscores and spaces, are displayed as you first
entered them, but they aren’t distinguished. For example, Manager_Profile and MANAGER
PROFILE are considered identical.

• If you use spaces, you must enclose the name in quotes when entering it on the command line
or in login scripts.

Server Objects

• Server objects are automatically created when you install new servers.

• You can create additional Server objects for existing NetWare

®

and Windows servers and for

eDirectory servers in other trees, but they are all treated as bindery objects.

novdocx (ENU) 01 February 2006

• When creating a Server object, the name must match the physical server name, which

• Is unique in the entire network.

• Is from 2 to 47 characters long.

• Contains only letters A-Z, numbers 0-9, hyphens (-), periods (.), and underscores (_).

• Does not use a period as the first character.

• Once named, the Server object cannot be renamed in Novell iManager. If you rename it at the
server, the new name automatically appears in iManager.

Country Objects

Country objects should follow the standard two-letter ISO country code.

For more information, see the ISO 3166 Code Lists (http://www.iso.ch/iso/en/prods-services/

iso3166ma/02iso-3166-code-lists/list-en1.html).

Bindery Objects

If the object is accessed from NetWare 2 or NetWare 3 through bindery services, the following
restrictions apply:

• Spaces in the name are replaced with underscores

• Names are truncated to 47 characters

• The following characters are not allowed: slash (/), backslash (\), colon (:), comma (,), asterisk
(*), and question mark (?)

IMPORTANT: Bindery emulation is not supported on Linux, Solaris, AIX, or HP-UX platforms.

Designing Your Novell eDirectory Network 71

Multilingual Considerations

If you have workstations running in different languages, you might want to limit object names to
characters that are viewable on all the workstations. For example, a name entered in Japanese cannot
contain characters that aren’t viewable in Western languages.

HP-UX supports only the English language.

IMPORTANT: The Tree name should always be specified in English.

Sample Standards Document

The following is a sample document containing standards for some of the most frequently used
properties. You need to have standards only for those properties you use. Distribute the standards
document to all administrators responsible for creating or modifying objects.

Object Class | Property Standard Examples Rationale

novdocx (ENU) 01 February 2006

User | Login name First initial, middle initial (if

applicable), and last name
(all lowercase). Eight
characters maximum. All
common names are unique
in the company.

User | Last name Last name (normal

capitalization).

Telephone and fax
numbers

Multiple classes |
Location

Organization | Name The name of your company

Organizational Unit |
Name (based on
location)

Organizational Unit |
Name (based on
department)

Numbers separated by
hyphens.

Two-letter location code
(uppercase), hyphen, mail
stop.

for all trees.

Two- or three-letter location
code, all uppercase.

Department name or
abbreviation.

msmith, bjohnson Using unique names

company-wide is not
required by eDirectory but
helps avoid conflicts within
the same context (or
bindery context).

Smith Used for generating

mailing labels.

US: 123-456-7890
Other: 44-344­123456

BA-C23 Used by interoffice mail

YourCo If you have separate trees,

ATL, CHI, CUP, LA,
BAT, BOS, DAL

Sales, Eng Short, standard names

Used by autodialing
software.

carriers.

a standard Organization
name allows for future
merging of trees.

Short, standard names are
used for efficient
searching.

make it easy to identify
which department the
container is servicing.

Group | Name Descriptive name. Project Managers Avoid extremely long

Directory Map | Name Contents of the directory

72 Novell eDirectory 8.8 Administration Guide

indicated by the Directory
Map.

names; some utilities will
not display them.

DOSAPPS Short, standard names

make it easy to identify
which department the
container is servicing.

Object Class | Property Standard Examples Rationale

Profile | Name Purpose of the profile. MobileUser Short, standard names

make it easy to identify
which department the
container is servicing.

novdocx (ENU) 01 February 2006

Server | Name SERV, hyphen, department,

hyphen, unique number.

SERV-Eng-1 eDirectory requires server

names to be unique in the
tree.

2.2.2 Designing the Upper Layers of the Tree

You should carefully design the upper layers of the tree because changes to the upper layers affect
the rest of the tree, especially if your organization has WAN links. You want to design the top of the
tree so that few changes will be necessary.

Use the following eDirectory design rules to create your eDirectory tree:

• Use a pyramid design.

• Use one eDirectory tree with a unique name.

• Create a single Organization object.

• Create first-level Organizational Units that represent the physical network infrastructure.

Figure 2-1 depicts the eDirectory design rules.

Figure 2-1 eDirectory Design Rules

O=ACME

Geographic

(Regional)

Geographic

(Location)

Operational

Project/Department

OU=AMERC

OU=CHI

OU=PRV

OU=HR

OU=RECR

OU=PACRIM

OU=TKYO

OU=SALES

OU=PAY

OU=HKNG

OU=EUROPE

OU=LON

OU=PAR

To create the upper layers of the tree, see “Creating an Object” on page 94 and “Modifying an

Object's Properties” on page 94.

Using a Pyramid Design

With a pyramid-designed eDirectory, managing, initiating changes to large groups, and creating
logical partitions are easier.

Designing Your Novell eDirectory Network 73

The alternative to the pyramid design is a flat tree that places all objects in the top layers of the tree.
eDirectory can support a flat tree design; however, a flat tree design can be more difficult to manage
and partition.

Using One eDirectory Tree with a Unique Name

A single tree works best for most organizations. By default, one tree is created. With one tree you
have single-user identity on the network, simpler administration of security, and single point of
management.

This recommendation for a single tree for business use does not preclude additional trees for testing
and development.

Some organizations, however, might need multiple trees because of legal, political, or corporate
issues. For example, an organization consisting of several autonomous organizations might need to
create several trees. If your organization needs multiple trees, consider using Novell Nsure Identity
Manager to simplify management. For more information on Novell Nsure Identity Manager, see the

Novell Nsure Identity Manager Administration Guide (http://www.novell.com/documentation/
dirxml20/index.html).

novdocx (ENU) 01 February 2006

NOTE: HP-UX does not support Novell Nsure Identity Manager.

When you name the tree, use a unique name that will not conflict with other tree names. Use a name
that is short and descriptive, such as EDL-TREE.

If two trees have the same name and are located on the same network, you might encounter the
following problems:

• Updates going to the wrong tree

• Resources disappearing

• Rights disappearing

•Corruption

You can change the tree name using the DSMERGE utility, but do so with caution. A tree name
change impacts the network because you need to reconfigure the clients to use the new tree name.

Creating a Single Organization Object

Generally, an eDirectory tree should have one Organization object. By default, a single Organization
object is created and named after your company. This allows you to configure changes that apply to
the whole company from a single location in the tree.

®

For example, you can use ZENworks

to create a Workstation Import Policy object in the
Organization object. In this policy, which affects the whole organization, you define how
Workstation objects are named when created in eDirectory.

In the Organization container, the following objects are created:

•Admin

•Server

• Volume

74 Novell eDirectory 8.8 Administration Guide

Networks with only a Windows, Linux, Solaris, AIX, or HP-UX server running eDirectory
have no Volume objects.

You might want to create multiple Organization objects if your company has the following needs:

• It comprises multiple companies that do not share the same network.

• It needs to represent separate business units or organizations.

• It has a policy or other internal guidelines that dictate that organizations remain separate.

Creating Organizational Units That Represent the Physical Network

First-level Organizational Unit design is important because it affects the partitioning and efficiency
of eDirectory.

For networks that span more than one building or location using either a LAN or a WAN, the first­level Organizational Unit object design should be based on location. This allows you to partition
eDirectory in a way that keeps all objects in a partition at one location. It also provides a natural
place to make security and administrator assignments for each location.

novdocx (ENU) 01 February 2006

2.2.3 Designing the Lower Layers of the Tree

You should design the lower layers of the tree based on the organization of network resources. You
have more freedom in designing the lower layers of an eDirectory tree than the upper layers because
lower-layer design affects only objects at the same location.

To create the lower layers of the tree, see “Creating an Object” on page 94 and “Modifying an

Object's Properties” on page 94.

Determining Container, Tree, and Database Size

The number of lower-level container objects you create depends on the total number of objects in
your tree and your disk space and disk I/O speed limitations. eDirectory has been tested with over 1
billion objects in a single eDirectory tree, so the only real limitations are disk space, disk I/O speed,
and RAM to maintain performance. Keep in mind that the impact of replication on a large tree is
significant.

A typical object in eDirectory is 3 to 5 KB in size. Using this object size, you can quickly calculate
disk space requirements for the number of objects you have or need. Keep in mind that the object
size will grow depending upon how many attributes are completed with data and what the data is. If
objects will hold binary large object (BLOB) data such as pictures, sounds, or biometrics, the object
size will subsequently grow.

The larger the partitions, the slower the replication cycles. If you are using products that require the
use of eDirectory, such as ZENworks and DNS/DHCP services, the eDirectory objects created by
these products will affect the size of the containers they are located in. You might consider placing
objects that are for administration purposes only, such as DNS/DHCP, in their own partition so user
access is not affected with slower replication. Also, managing partitions and replicas will be easier.

If you are interested, you can easily determine the size of your eDirectory database or the Directory
Information Base (DIB) Set.

• For NetWare, download toolbox.nlm from the Novell Support Web site (http://

support.novell.com) to see the sys:_netware directory on your server.

Designing Your Novell eDirectory Network 75

• For Windows, look at the DIB Set at \novell\nds\dibfiles.

• For Linux, Solaris, AIX, or HP-UX, look at the DIB Set in the directory you specified during
installation.

Deciding Which Containers to Create

In general, create containers for objects that have access needs in common with other eDirectory
objects. This lets you service many users with one trustee assignment or login script. You can create
containers specifically to make container login scripts more effective, or you can place two
departments in one container to make login script maintenance more feasible.

Keep users close to the resources they need to limit traffic over the network. For example, people
who work in the same department generally work near each other. They usually need access to the
same file system and they print to the same printers.

Exceptions to general workgroup boundaries are not hard to manage. If two workgroups use a
common printer, for instance, you can create an Alias object to the printer in one of the workgroups.
You can create Group objects to manage some User objects within a workgroup or User objects
across multiple workgroups. You can create Profile objects for subsets of users with unique login
script requirements.

novdocx (ENU) 01 February 2006

2.3 Guidelines for Partitioning Your Tree

When you partition eDirectory, you allow parts of the database to exist on several servers. With this
capability, you can optimize network use by distributing the eDirectory data processing and storage
load over multiple servers on the network. By default, a single partition is created. For more
information on partitions, refer to Section 1.5, “Partitions,” on page 47. For information on creating
partitions, refer to Chapter 5, “Managing Partitions and Replicas,” on page 129.

The following are guidelines for most networks. However, depending on the specific configuration,
hardware, and traffic throughput of the network, you might need to adjust some guidelines to fit
your needs.

2.3.1 Determining Partitions for the Upper Layers of the Tree

Just as you design your tree with a pyramid design, you will also partition with a pyramid design.
Your partition structure will have few partitions at the top of the tree and more partitions as you
move toward the bottom. Such a design creates fewer subordinate references than an eDirectory tree
structure that has more partitions at the top than at the bottom.

This pyramid design can be achieved if you always create the partitions relatively close to the leaf
objects, particularly the users. (An exception is the partition created at the root of the tree during
installation.)

When designing the partitions for the upper layers, keep the following in mind:

• Partition the top of the tree based on the WAN infrastructure. Place fewer partitions at the top
of the tree with more at the bottom.

You can create containers for each site separated by WAN links (placing each Server object in
its local container), then create a partition for each site.

• In a network with WAN links, partitions should not span multiple locations.

76 Novell eDirectory 8.8 Administration Guide

This design ensures that replication traffic between different sites is not unnecessarily
consuming WAN bandwidth.

• Partition locally around the servers. Keep physically distant servers in separate partitions.

For more information on managing your WAN traffic, see Chapter 11, “WAN Traffic Manager,” on

page 277.

2.3.2 Determining Partitions for the Lower Layers of the Tree

When designing the partitions for the lower layers of the eDirectory tree, keep the following in
mind:

• Define lower-layer partitions by organizational divisions, departments, and workgroups, and
their associated resources.

• Partition so that all objects in each partition are at a single location. This ensures that updates to
eDirectory can occur on a local server.

2.3.3 Determining Partition Size

novdocx (ENU) 01 February 2006

With eDirectory, we recommend the following design limits for partition sizes:

Element Limit

Partition Size Unlimited Objects

Replica Directory Information Base (DIB) limited
to ITB

Total number of partitions in tree Unlimited

Number of child partitions per parent 150

Number of replicas per partition 50

Limited by replica DIB

Number of replicas per replica server 250

This change in design guidelines from NDS

®

6 and 7 is due to architectural changes in NDS 8.
These recommendations apply to distributed environments such as corporate enterprises. These
recommendations might not subsequently apply to e-business or applications.

Although typical e-business users require that all the data be stored on a single server, eDirectory
provides filtered replicas that can contain a subset of objects and attributes from different areas of
the tree. This allows for the same e-business needs without storing all the data on the server. For
more information, see “Filtered Replicas” on page 54.

2.3.4 Considering Network Variables

Consider the following network variables and their limitations when planning your partitions:

• The number and speed of servers

• The speed of network infrastructure (such as network adapters, hubs, and routers)

Designing Your Novell eDirectory Network 77

• The amount of network traffic

2.4 Guidelines for Replicating Your Tree

Creating multiple eDirectory partitions does not, by itself, increase fault tolerance or improve
performance of the directory; however, strategically using multiple replicas does. The placement of
replicas is extremely important for accessibility and fault tolerance. eDirectory data needs to be
available as quickly as possible and needs to be copied in several places to ensure fault tolerance.
For information on creating replicas, refer to Chapter 5, “Managing Partitions and Replicas,” on

page 129.

The following guidelines will help determine your replica placement strategy.

• “Workgroup Needs” on page 78

• “Fault Tolerance” on page 78

• “Determining the Number of Replicas” on page 79

• “Replicating the Tree Partition” on page 79

• “Replicating for Administration” on page 79

• “Meeting Bindery Services Needs for NetWare” on page 80

• “Managing WAN Traffic” on page 80

novdocx (ENU) 01 February 2006

2.4.1 Workgroup Needs

Place replicas of each partition on servers that are physically close to the workgroup that uses the
information in that partition. If users on one side of a WAN link often access a replica stored on a
server on the other side, place a replica on servers on both sides of the WAN link.

Place replicas in the location of highest access by users, groups, and services. If groups of users in
two separate containers need access to the same object within another partition boundary, place the
replica on a server that exists in the container one level above the two containers holding the group.

2.4.2 Fault Tolerance

If a disk crashes or a server goes down, replicas on servers in other locations can still authenticate
users to the network and provide information on objects in partitions stored on the disabled server.

With the same information distributed on several servers, you are not dependent on any single server
to authenticate you to the network or to provide services (such as login).

To create fault tolerance, plan for three replicas for each partition if the directory tree has enough
servers to support that number. There should be at least two local replicas of the local partition.
There is no need to have more than three replicas unless you need to provide for accessibility of the
data at other locations, or you participate in e-business or other applications that need to have
multiple instances of the data for load balancing and fault tolerance.

You can have only one master replica. Additional replicas must be read/write, read-only, or filtered.
Most replicas should be read/write. They can handle object viewing, object management, and user
login, just as the master replica can. They send out information for synchronization when a change is
made.

78 Novell eDirectory 8.8 Administration Guide

Read-only replicas cannot be written to. They allow object searching and viewing, and they are
updated when the replicas of the partition synchronize.

Do not depend on a subordinate reference or filtered replicas for fault tolerance. A subordinate
reference is a pointer and does not contain objects other than the partition root object. Filtered
replicas do not contain all objects within the partition.

eDirectory allows for an unlimited number of replicas per partition, but the amount of network
traffic increases as the number of replicas increase. Balance fault tolerance needs with network
performance needs.

You can store only one replica per partition on a server. A single server can store replicas of multiple
partitions.

Depending on your organization's disaster recovery plan, the major work of rebuilding the network
after a loss of a server or location can be done using partition replicas. If the location has only one
server, back up eDirectory regularly. (Some backup software does not back up eDirectory.) Consider
purchasing another server for fault tolerance replication.

2.4.3 Determining the Number of Replicas

novdocx (ENU) 01 February 2006

The limiting factor in creating multiple replicas is the amount of processing time and traffic required
to synchronize them. When a change is made to an object, that change is communicated to all
replicas in the replica ring. The more replicas in a replica ring, the more communication is required
to synchronize changes. If replicas must synchronize across a WAN link, the time cost of
synchronization is greater.

If you plan partitions for many geographical sites, some servers will receive numerous subordinate
reference replicas. eDirectory can distribute these subordinate references among more servers if you
create regional partitions.

2.4.4 Replicating the Tree Partition

The Tree partition is the most important partition of the eDirectory tree. If the only replica of this
partition becomes corrupted, users will experience impaired functionality on the network until the
partition is repaired or the eDirectory tree is completely rebuilt. You will also not be able to make
any design changes involving the Tree.

When creating replicas of the Tree partition, balance the cost of synchronizing subordinate
references with the number of replicas of the Tree partition.

2.4.5 Replicating for Administration

Because partition changes originate only at the master replica, place master replicas on servers near
the network administrator in a central location. It might seem logical to keep masters at remote sites;
however, master replicas should be where the partition operations will occur.

We recommend that major eDirectory operations, such as partitioning, be handled by one person or
group in a central location. This methodology limits errors that could have adverse effects to
eDirectory operations and provides for a central backup of the master replicas.

The network administrator should perform high-cost activities, such as creating a replica, at times
when network traffic is low.

Designing Your Novell eDirectory Network 79

2.4.6 Meeting Bindery Services Needs for NetWare

If you are using eDirectory on NetWare and your users require access to a server through bindery
services, that server must contain a master or read/write replica that contains the bindery context.
The bindery context is set by the SET BINDERY CONTEXT statement in autoexec.ncf.

Users can access objects providing bindery services only if real objects exist on that server. Adding
a replica of a partition to the server adds real objects to the server and lets users with User objects in
that partition log in to the server with a bindery connection.

For more information on bindery services, refer to Section 1.7, “NetWare Bindery Emulation,” on

page 55.

2.4.7 Managing WAN Traffic

If users currently use a WAN link to access particular directory information, you can decrease access
time and WAN traffic by placing a replica containing the needed information on a server that users
can access locally.

If you are replicating the master replicas to a remote site or are forced to place replicas over the
WAN for accessibility or fault tolerance, keep in mind the bandwidth that will be used for
replication.

novdocx (ENU) 01 February 2006

Replicas should only be placed in nonlocal sites to ensure fault tolerance if you are not able to get
the recommended three replicas, increase accessibility, and provide centralized management and
storage of master replicas.

To control the replication of eDirectory traffic over WAN links, use WAN Manager. For more
information, see Chapter 11, “WAN Traffic Manager,” on page 277.

2.5 Planning the User Environment

After you have designed the basic structure of the eDirectory tree and have set up partitioning and
replication, you should plan the user environment to simplify management and increase access to
network resources. To create a user environment plan, review the users' needs and create
accessibility guidelines for each area.

2.5.1 Reviewing Users' Needs

When you review users' needs, consider the following:

• Physical network needs, such as printers or file storage space

Evaluate if resources are shared by groups of users within a tree or shared by groups of users
from multiple containers. Also consider the physical resource needs of remote users.

• Bindery services needs for NetWare users

Consider which applications are bindery-based and who uses them.

• Application needs

Consider which applications and data files are needed by users, what operating systems exist,
and which groups or users need access to applications. Consider if the shared applications
should be manually or automatically launched by applications such as ZENworks.

80 Novell eDirectory 8.8 Administration Guide

2.5.2 Creating Accessibility Guidelines

After you have gathered information about user needs, you should determine the eDirectory objects
that you will use to create the users' environments. For example, if you create policy packages or
Application objects, you should determine how many you will create and where you will allow them
to be placed in the tree.

You should also determine how you will implement security to restrict user access. You should
identify any security precautions related to specific security practices. For example, you could warn
network administrators to avoid granting the eDirectory Supervisor right to Server objects because
this right is inherited by the file system.

2.6 Designing eDirectory for e-Business

If you use eDirectory for e-Business, whether you are providing a portal for services or sharing data
with another business, the recommendations already mentioned in this chapter might not apply to
you.

You might want to follow these suggested eDirectory e-business design guidelines instead:

novdocx (ENU) 01 February 2006

• Create a tree with a limited number of containers.

This guideline depends on the applications you use and your implementation of eDirectory. For
example, a global deployment of a messaging server might require the more traditional
eDirectory design guidelines discussed earlier in this chapter. Or, if you are going to distribute
administration of users, you might create a separate Organizational Unit (OU) for each area of
administrative responsibility.

• Maintain at least two partitions.

Maintain the default partition at the Tree level, and create a partition for the rest of the tree. If
you have created separate OUs for administrative purposes, create partitions for each of the
OUs.

If you are splitting the load over multiple servers, consider limiting the number of partitions,
but still maintain at least two for backup or disaster recovery.

• Create at least three replicas of your tree for fault tolerance and load balancing.

Keep in mind that LDAP does not load balance itself. To balance the load on LDAP, consider
using Layer 4 switches.

• Create a separate tree for e-Business. Limit the network resources, such as servers and printers,
included in the tree. Consider creating a tree that contains only User objects.

You can use Novell Nsure Identity Manager to link this user tree to your other trees that contain
network information. For more information, see the Novell Nsure Identity Manager

Administration Guide (http://www.novell.com/documentation/dirxml20/index.html).

• Use auxiliary classes to customize your schema.

If a customer or application requires a User object that is different from the standard
inetOrgPerson, use auxiliary classes to customize your schema. Using auxiliary classes allows
application designers to change the attributes used in the class without needing to re-create the
tree.

• Increase LDIF-import performance.

Designing Your Novell eDirectory Network 81

When the Novell Import Conversion Export utility is used, eDirectory indexes each object
during the process. This can slow down the LDIF-import process. To increase the LDIF-import
performance, suspend all indexes from the attributes of the objects you are creating, use the
Novell Import Conversion Export utility, then resume indexing the attributes.

• Implement globally unique common names (CN).

eDirectory allows the same CN in different containers. However, if you use globally unique
CNs, you can perform searches on CN without implementing logic for dealing with multiple
replies.

2.7 Understanding the Novell Certificate Server

Novell Certificate ServerTM allows you to mint, issue, and manage digital certificates by creating a
Security container object and an Organizational Certificate Authority (CA) object. The
Organizational CA object enables secure data transmissions and is required for Web-related
products such as NetWare Web Manager and NetWare Enterprise Web Server. The first eDirectory
server will automatically create and physically store the Security container object and
Organizational CA object for the entire eDirectory tree. Both objects are created and must remain at
the top of the eDirectory tree.

novdocx (ENU) 01 February 2006

Only one Organizational CA object can exist in an eDirectory tree. After the Organizational CA
object is created on a server, it cannot be moved to another server. Deleting and re-creating an
Organizational CA object invalidates any certificates associated with the Organizational CA.

IMPORTANT: Make sure that the first eDirectory server is the server that you intend to
permanently host the Organizational CA object and that the server will be a reliable, accessible, and
continuing part of your network.

If this is not the first eDirectory server on the network, the installation program finds and references
the eDirectory server that holds the Organizational CA object. The installation program accesses the
Security container and creates a Server Certificate object.

If an Organizational CA object is not available on the network, Web-related products will not
function.

2.7.1 Rights Required to Perform Tasks on Novell Certificate
Server

To complete the tasks associated with setting up Novell Certificate Server, the administrator needs to
have rights as described in the following table.

Novell Certificate Server Task Rights Required

Base security setup for installing the first server into
a new tree or upgrading the first server in a tree
where there is no base security previously installed

Base security setup for installing subsequent servers Supervisor right on the server’s container

Creating the Organizational CA Supervisor right on the Security container

82 Novell eDirectory 8.8 Administration Guide

Supervisor right at the root of the tree

Supervisor right on the Security container

Supervisor right on the W0 object (located
inside the Security container)

Novell Certificate Server Task Rights Required

Creating Server Certificate objects Supervisor right on the server’s container

Read right to the NDSPKI:Private Key attribute
on the Organizational CA’s object

The root administrator can also delegate the authority to use the Organizational CA by assigning the
following rights to subcontainer administrators. Subcontainer administrators require the following
rights to install Novell eDirectory with SSL security:

• Read right to the NDSPKI:Private Key attribute on the Organizational CA’s object, located in
the Security container.

• Supervisor right to the W0 object located in the Security container, inside the KAP object.

These rights are assigned to a group or a role, where all the administrative users are defined. For a
complete list of required rights to perform specific tasks associated with Novell Certificate Server,
refer to the Novell Certificate Server (http://www.novell.com/documentation/beta/crt30/index.html)
online documentation.

novdocx (ENU) 01 February 2006

2.7.2 Ensuring Secure eDirectory Operations on Linux, Solaris,
AIX, and HP-UX Systems

eDirectory includes Public Key Cryptography Services (PKCS), which contains the Novell
Certificate Server that provides Public Key Infrastructure (PKI) services, Novell International
Cryptographic Infrastructure (NICI), and SAS*-SSL server.

The following sections provide information about performing secure eDirectory operations:

• “Verifying Whether NICI Is Installed and Initialized on the Server” on page 83

• “Initializing the NICI Module on the Server” on page 84

• “Starting the Certificate Server (PKI Services)” on page 85

• “Stopping the Certificate Server (PKI Services)” on page 85

• “Creating an Organizational Certificate Authority Object” on page 85

• “Creating a Server Certificate Object” on page 85

• “Exporting an Organizational CA's Self-Signed Certificate” on page 85

For information about using external certificate authority, refer to the Novell Certificate Server

Administration Guide (http://www.novell.com/documentation/beta/crt30/index.html).

Verifying Whether NICI Is Installed and Initialized on the Server

Verify the following conditions, which indicate that the NICI module has been properly installed and
initialized:

•The file /etc/nici.cfg exists

• The directory /var/novell/nici exists

•The file /var/novell/nici/primenici exists

Designing Your Novell eDirectory Network 83

If these conditions are not met, follow the procedure in the next section, “Initializing the NICI

Module on the Server” on page 84.

Initializing the NICI Module on the Server

1 Stop the eDirectory server.

• On Linux systems, enter

/etc/init.d/ndsd stop

• On Solaris systems, enter

/etc/init.d/ndsd stop

• On AIX systems, enter

/etc/ndsd stop

• On HP-UX systems, enter

/sbin/init.d/ndsd stop

IMPORTANT: We recommend you to use ndsmanage to start and stop ndsd.

novdocx (ENU) 01 February 2006

2 Verify whether the NICI package is installed.

• On Linux systems, enter

rpm -qa | grep nici

• On Solaris systems, enter

pkginfo | grep NOVLniu0

• On AIX systems, enter

lslpp -l | grep NOVLniu0

• On HP-UX systems, enter

swlist | grep NOVLniu0

3 (Conditional) If the NICI package is not installed, install it now.

You will not be able to proceed if the NICI package is not installed.

4 Copy the .nfk file provided with the package to the /var/novell/nici directory.

Execute the /var/novell/nici/primenici program.

5 Start the eDirectory server.

• On Linux systems, enter

/etc/init.d/ndsd start

• On Solaris systems, enter

/etc/init.d/ndsd start

• On AIX systems, enter

/etc/ndsd start

• On HP-UX systems, enter

/sbin/init.d/ndsd start

IMPORTANT: We recommend you to use ndsmanage to start and stop ndsd.

84 Novell eDirectory 8.8 Administration Guide

Starting the Certificate Server (PKI Services)

To start PKI services, enter

npki -1.

Stopping the Certificate Server (PKI Services)

To stop PKI services, enter

npki -u.

Creating an Organizational Certificate Authority Object

1 Launch Novell iManager.

2 Log in to the eDirectory tree as an administrator with the appropriate rights.

To view the appropriate rights for this task, see Creating an Organizational CA (http://

www.novell.com/documentation/beta/crt30/crtadmin/data/fbgccghh.html) in the Novell

Certificate Server Administration Guide.

3 Click the Roles and Tasks button , click PKI Certificate Management, then click Create

Certificate Authority.

This opens the Create Organizational Certificate Authority Object Wizard. Follow the prompts
to create the object. For specific information on any of the wizard pages, click Help.

novdocx (ENU) 01 February 2006

NOTE: You can have only one Organizational CA for your eDirectory tree.

Creating a Server Certificate Object

Server Certificate objects are created in the container that holds the eDirectory Server object.
Depending on your needs, you might create a separate Server Certificate object for each
cryptography-enabled application on the server. Or you might create one Server Certificate object
for all applications used on that server.

NOTE: The terms Server Certificate Object and Key Material Object (KMO) are synonymous. The
schema name of the eDirectory object is NDSPKI:Key Material.

1 Launch Novell iManager.

2 Log in to the eDirectory tree as an administrator with the appropriate rights.

To view the appropriate rights for this task, see Creating Server Certificate Objects (http://

www.novell.com/documentation/beta/crt30/crtadmin/data/fbgcdhec.html) in the Novell

Certificate Server Administration Guide.

3 Click the Roles and Tasks button , click PKI Certificate Management, then click Create

Server Certificate.

This opens the Create Server Certificate Wizard. Follow the prompts to create the object. For
specific information on any of the wizard pages, click Help.

Exporting an Organizational CA's Self-Signed Certificate

A self-signed certificate can be used for verifying the identity of the Organizational CA and the
validity of a certificate signed by the Organizational CA.

Designing Your Novell eDirectory Network 85

From the Organizational CA’s property page, you can view the certificates and properties associated
with this object. From the Self-Signed Certificate property page, you can export the self-signed
certificate to a file for use in cryptography-enabled applications.

The self-signed certificate that resides in the Organizational CA is the same as the Trusted Root
certificate in a Server Certificate object that has a certificate signed by the Organizational CA. Any
service that recognizes the Organizational CA’s self-signed certificate as a trusted root will accept a
valid user or server certificate signed by the Organizational CA.

1 In Novell iManager, click the Roles and Tasks button .

2 Click eDirectory Administration > Modify Object.

3 Specify the name and context of an Organizational Certificate Authority object, then click OK.

Organizational Certificate Authority objects are located in Security container.

4 Click the Certificates tab, then click Self-Signed Certificate.

5 Click Export.

This opens the Export Certificate Wizard. Follow the prompts to export the certificate. For
specific information on any of the wizard pages, click Help.

6 On the Export Certificate Summary page, click Save the Exported Certificate to a File.

The certificate is saved to a file and is available to be imported into a cryptography-enabled
application as the trusted root.

7 Click Close.

novdocx (ENU) 01 February 2006

Include this file in all command line operations that establish secure connections to eDirectory

2.8 Synchronizing Network Time

Time synchronization is a service that maintains consistent server time across the network. Time
synchronization is provided by the server operating system, not by eDirectory. eDirectory maintains
its own internal time to ensure the proper order of eDirectory packets, but it gets its time from the
server operating system.

This section focuses on integrating NetWare time synchronization with that of Windows, Linux,
Solaris, AIX, and HP-UX.

2.8.1 Synchronizing Time on NetWare Servers

In IP networks and mixed protocol networks, NetWare 5 servers communicate time with other
servers using IP. NetWare 5 servers use timesync.nlm and Network Time Protocol (NTP) to
accomplish this.

Time synchronization in NetWare 5 and 6 always uses timesync.nlm, whether servers are using IP
only, IPX
configured through timesync.nlm.

If your network also uses Windows, Linux, Solaris, AIX, or HP-UX, you should use NTP to
synchronize the servers because it is a standard to provide time synchronization.

TM

only, or both protocols. Timesync.nlm loads when a server is installed. NTP can be

For NetWare 3 and NetWare 4, third-party NTP time services are available.

86 Novell eDirectory 8.8 Administration Guide

For more information on time synchronization software, see The Network Time Protocol (http://

www.ntp.org) Web s ite.

NTP

NTP functions as part of the UDP protocol suite, which is part of the TCP/IP protocol suite.
Therefore, a computer using NTP must have the TCP/IP protocol suite loaded. Any computers on
your network with Internet access can get time from NTP servers on the Internet.

NTP synchronizes clocks to the Universal Time Coordinated (UTC) standard, which is the
international time standard.

NTP introduces the concept of a stratum. A stratum-1 server has an attached accurate time piece
such as a radio clock or an atomic clock. A stratum-2 server gets time from a stratum-1 server, and
so on.

For NetWare 5 and 6 servers, you can load ntp.nlm to implement NTP time synchronization through
timesync.nlm. When NTP is configured with the timesync.nlm on an IP server, NTP becomes the
time source for both IP and IPX servers. In this case, IPX servers must be set to secondary servers.

For more information on time synchronization, see the Network Time Management Administration

Guide (http://www.novell.com/documentation/lg/nw65/time_enu/data/hl5k6r0y.html) and the
Network Time Protocol Administration Guide (http://www.novell.com/documentation/lg/nw65/ntp/

data/aizwub2.html).

novdocx (ENU) 01 February 2006

TIMESYNC.NLM

Timesync.nlm synchronizes time among NetWare servers. You can use timesync.nlm with an
external time source like an Internet NTP server. You can also configure Novell Client
workstations to update their clocks to servers running the timesync.nlm.

For more information on time synchronization, refer to the Network Time Management

Administration Guide (http://www.novell.com/documentation/lg/nw65/time_enu/data/
hl5k6r0y.html).

TM

2.8.2 Synchronizing Time on Windows Servers

For information on time synchronization for Windows 2000 servers, refer to the operating system
documentation.

2.8.3 Synchronizing Time on Linux, Solaris, AIX, or HP-UX
Systems

You can use the xntpd Network Time Protocol (NTP) daemon to synchronize time on Linux, Solaris,
AIX, and HP-UX servers. xntpd is an operating system daemon that sets and maintains the system
time-of-day in synchronism with Internet standard time servers.

For more information on running xntpd on AIX systems, see xntpd Daemon (http://

publibn.boulder.ibm.com/doc_link/en_US/a_doc_lib/cmds/aixcmds6/xntpd.htm) in the AIX

Commands Reference, Volume 6.

Designing Your Novell eDirectory Network 87

For more information on running xntpd on Solaris system, see http://docs.sun.com/?p=/doc/806-

0625/6j9vfim2v&a=view#xntpd-1m-indx-2 (http://docs.sun.com/?p=/doc/806-0625/
6j9vfim2v&a=view#xntpd-1m-indx-2).

For more information on running xntpd on HP-UX system, see Configuring NTP (http://

docs.hp.com/cgi-bin/fsearch/framedisplay?top=/hpux/onlinedocs/B2355-90147/B2355­90147_top.html&con=/hpux/onlinedocs/B2355-90147/00/00/58-con.html&toc=/hpux/onlinedocs/
B2355-90147/00/00/58-toc.html&searchterms=ntp%7cconfiguring&queryid=20030922-153023).

For information on running ntpd on Linux systems, see ntpd - Network Time Protocol (NTP)

Daemon (http://www.eecis.udel.edu/~mills/ntp/html/ntpd.html).

2.8.4 Verifying Time Synchronization

To verify that time is synchronized in the tree, run DSRepair from a server in the Tree that has at
least Read/Write rights to the Tree object.

NetWare

1 At the server console, load dsrepair.nlm.

2 Select Time Synchronization.

novdocx (ENU) 01 February 2006

For help interpreting the log, click F1.

NOTE: The following command will help troubleshoot time synchronization issues:

set timesync debug=7

Windows

1 Click Start > Settings > Control Panel > Novell eDirectory Services.

2 Click dsrepair.dlm > Start.

3 Click Repair > Time Synchronization.

Linux, Solaris, AIX, and HP-UX

1 Run the following command:

ndsrepair -T

2.9 Security Considerations

The LDAP binds should take place over a secure connection. We recommend that you always use a
SSL/TLS connection; else:

• The key transmitted over the wire can be sniffed out. So you need to physically secure the
corporate network against eaves-dropping or “packet sniffing”.

• You need to keep the servers in a physically secure location with access by authorized
personnel only.

• When the product is used by users outside of the corporate firewall, a VPN should be
employed.

88 Novell eDirectory 8.8 Administration Guide

• If a server is accessible from outside the corporate network, a firewall should be employed to
prevent direct access by a would-be intruder.

• Audit logs should be checked periodically.

• Different administrative duties should be given to separate people.

• We recommend that you identify a particular LDAP server as the right server for Kerberos
management. You can specify the server name in iManager.

IMPORTANT: The user needs to access the LDAP server using the DNS name instead of the IP
address of the server. This is because the conversion of the IP address to the DNS name is not
secure.

novdocx (ENU) 01 February 2006

Designing Your Novell eDirectory Network 89

novdocx (ENU) 01 February 2006

90 Novell eDirectory 8.8 Administration Guide

3

Managing Objects

Novell® eDirectoryTM 8.8 includes Novell iManager 2.5, a Web-based network management
application that lets you manage the objects in your eDirectory tree. To understand the features and
benefits of Novell iManager, see the Novell iManager 2.5 Administration Guide (http://

www.novell.com/documentation/imanager25/index.html).

Managing eDirectory objects involves creating, modifying, and manipulating objects. For example,
you might need to create user accounts and administer user rights. Use Novell iManager to:

• Perform administration basics, such as browsing, creating, editing, and organizing objects.

• Create user accounts, including specifying a user's login name and supplying other information
used by eDirectory

• Administer rights (assign rights, grant equivalence, block inheritance, and view effective
rights). See “Administering Rights” on page 62 for more information.

• Configure role-based administration (define administrator roles for specific administrative
applications through the role-based services object).

novdocx (ENU) 01 February 2006

3

This chapter contains information on the following topics:

• Section 3.1, “General Object Tasks,” on page 91

• Section 3.2, “Managing User Accounts,” on page 95

• Section 3.3, “Configuring Role-Based Services,” on page 101

3.1 General Object Tasks

This section contains steps for basic tasks you will use when managing your eDirectory tree:

• “Browsing the eDirectory Tree” on page 91

• “Creating an Object” on page 94

• “Modifying an Object's Properties” on page 94

• “Copying Objects” on page 94

• “Moving Objects” on page 94

• “Deleting Objects” on page 95

• “Renaming Objects” on page 95

3.1.1 Browsing the eDirectory Tree

The View Obj ects button ( ) in Novell iManager lets you search or browse for objects in your
eDirectory tree. You can view the structure of your tree and right-click objects to perform tasks. The
tasks available depend on the type of object you select.

The eDirectory Object Selector page in Novell iManager also lets you search or browse for objects.
In most entry fields in Novell iManager, you can specify an object name and context, or you can
click the Object Selector button to search or browse for the object you want. Selecting an object
in the eDirectory Object Selector page inserts the object and the object's context into the entry field.

Managing Objects

91

This section contains the following information:

• “Using the View Object Button” on page 92

• “Using the Object Selector Button” on page 93

Using the View Object Button

Use the techniques described below to locate the specific objects you want to manage.

• “Using Browse” on page 92

• “Using Search” on page 92

Using Browse

1 In Novell iManager, click the View Obj ects button .

2 Click Browse.

3 Use the following options to browse for an object:

Option Description

novdocx (ENU) 01 February 2006

Lets you move down one level in the tree.

Lets you move up one level in the tree.

Context Lets you specify the name of the container whose contents you want to

view.

To use this option, specify the name of the container you want, then click
Apply.

Name Lets you specify the name of an object.

You can use an asterisk (*) as a wildcard character in this field. For
example, g* finds all objects starting with g, such as Germany or Greg,
and *te finds all entries ending in te, such as Kate or Corporate.

To use this option, type the name you want, then click Apply.

Type Lets you specify the type of object you want to search for. The default is

All Available Types.

To use this option, select an object type from the drop-down list, then
click Apply.

4 When you find the object you are looking for, right-click the object, then choose from the list of

available tasks to perform.

Using Search

1 In Novell iManager, click the View Obj ects button .

2 Click Search.

3 In the Context field, specify the name of the container you want to search in.

Click Search Sub-containers to include all subcontainers located within the current container in
the search.

4 In the Name field, specify the name of the object you want to search for.

92 Novell eDirectory 8.8 Administration Guide

You can use an asterisk (*) as a wildcard character in this field. For example, g* finds all
objects starting with g, such as Germany or Greg, and *te finds all entries ending in te, such as
Kate or Corporate.

5 Select the type of object you want to search for from the Ty pe drop-down list.

6 Click Search.

7 When you find the object you are looking for, right-click the object, then choose from the list of

available tasks to perform.

Using the Object Selector Button

Use the techniques described below to locate the specific objects you want to manage.

• “Using Browse” on page 93

• “Using Search” on page 93

Using Browse

1 Click the Object Selector button on an iManager property page.

2 Click Browse.

novdocx (ENU) 01 February 2006

3 Use the following options to browse for an object:

Option Description

Lets you move down one level in the tree.

Lets you move up one level in the tree.

Look In Specify the name of the container whose contents you want to

view, then click Apply.

Look for Objects Named Lets you specify the name of an object.

You can use an asterisk (*) as a wildcard character in this field.
For example, g* finds all objects starting with g, such as Germany
or Greg, and *te finds all entries ending in te, such as Kate or
Corporate.

To use this option, type the name you want, then click Apply.

Using Search

1 Click the Object Selector button on an iManager property page.

2 Click Search.

3 In the Start Search In field, specify the name of the container you want to search in.

Click Search Sub-containers to include all subcontainers located within the current container in
the search.

4 In the Search For Objects Named field, specify the name of the object you want to search for.

You can use an asterisk (*) as a wildcard character in this field. For example, g* finds all
objects starting with g, such as Germany or Greg, and *te finds all entries ending in te, such as
Kate or Corporate.

5 Click Search.

Managing Objects 93

3.1.2 Creating an Object

1 In Novell iManager, click the Roles and Tasks button .

2 Click eDirectory Administration > Create Object.

3 Select an object from the list of available object classes, then click OK.

4 Specify the information requested, then click OK.

The information requested depends on the type of object you are creating. Click for more
information.

5 Click OK.

3.1.3 Modifying an Object's Properties

1 In Novell iManager, click the Roles and Tasks button .

2 Click eDirectory Administration > Modify Object.

3 Specify the name and context of the object or objects you want to modify, then click OK.

4 Edit the property pages you want.

Click for more information on specific property pages.

5 Click OK.

novdocx (ENU) 01 February 2006

3.1.4 Copying Objects

This option lets you create a new object with the same attribute values as an existing object, or copy
attribute values from one object to another.

1 In Novell iManager, click the Roles and Tasks button .

2 Click eDirectory Administration > Copy Object.

3 In the Object to Copy From field, specify the name and context of the object you want to copy.

4 Select one of the following options:

• Create New Object and Copy Attribute Values

• Copy Attribute Values to an Existing Object

5 If you want to copy access control list (ACL) rights to the object you are creating/modifying,

select Copy ACL Rights.

Copying ACL rights can take additional processing time depending upon your system and
networking environment.

6 Click OK.

3.1.5 Moving Objects

1 In Novell iManager, click the Roles and Tasks button .

2 Click eDirectory Administration > Move Object.

3 In the Object Name field, specify the name and context of the object or objects you want to

move.

4 In the Move To field, specify the container you want to move the object or objects to.

94 Novell eDirectory 8.8 Administration Guide

5 If you want to create an Alias in the old location for each object being moved, select Create an

Alias in Place of Moved Object.

This allows any operations that are dependent on the old location to continue uninterrupted
until you can update those operations to reflect the new location.

6 Click OK.

3.1.6 Deleting Objects

1 In Novell iManager, click the Roles and Tasks button .

2 Click eDirectory Administration > Delete Object.

3 Specify the name and context of the object or objects you want to delete.

4 Click OK.

3.1.7 Renaming Objects

1 In Novell iManager, click the Roles and Tasks button .

2 Click eDirectory Administration > Rename Object.

novdocx (ENU) 01 February 2006

3 In the Object Name field, specify the name and context of the object you want to rename.

4 In the New Object Name field, specify the new name for the object.

Do not include the object's context in the New Object Name field.

5 If you want to create an Alias for the object being renamed, select Create an Alias in Place of

Renamed Object.

This allows any operations that are dependent on the old object name to continue uninterrupted
until you can update those operations to reflect the new name.

6 If you want to save the old object name, select Save Old Name.

This saves the old name as an additional (unofficial) value of the Name property. Saving the old
name lets users search for the object based on that name. After renaming the object, you can
view the old name in the Other Name field on the General Identification tab for that object.

7 Click OK.

3.2 Managing User Accounts

Setting up an eDirectory user account involves creating a User object and setting properties to
control login and the user’s network computing environment. You can use a template object to
facilitate these tasks.

You can create login scripts to cause users to be connected automatically to the files, printers, and
other network resources they need when they log in. If several users use the same resources, you can
put the login script commands in container and profile login scripts.

This section contains the following information:

• “Creating and Modifying User Accounts” on page 96

• “Setting Up Optional Account Features” on page 97

• “Setting Up Login Scripts” on page 98

Managing Objects 95

• “Login Time Restrictions for Remote Users” on page 99

• “Deleting User Accounts” on page 100

3.2.1 Creating and Modifying User Accounts

A user account is a User object in the eDirectory tree. A User object specifies a user’s login name
and supplies other information used by eDirectory to control the user's access to network resources.

This section contains the following information:

• “Creating a User Object” on page 96

• “Modifying a User Account” on page 96

• “Enabling a User Account” on page 96

• “Disabling a User Account” on page 96

Creating a User Object

1 In Novell iManager, click the Roles and Tasks button .

novdocx (ENU) 01 February 2006

2 Click Users > Create User.

3 Specify a user name and a last name for the user.

4 Specify a container to create the user in.

5 Specify any additional (optional) information you want, then click OK.

Click for more information on the available options.

6 Click OK.

Modifying a User Account

1 In Novell iManager, click the Roles and Tasks button .

2 Click Users > Modify User.

3 Specify the name and context of the User or Users you want to modify, then click OK.

4 Edit the property pages you want.

Click for more information on specific properties.

5 Click OK.

Enabling a User Account

1 In Novell iManager, click the Roles and Tasks button .

2 Click Users > Enable Account.

3 Specify the name and context of the User, then click OK.

Disabling a User Account

1 In Novell iManager, click the Roles and Tasks button .

2 Click Users > Disable Account.

3 Specify the name and context of the User, then click OK.

96 Novell eDirectory 8.8 Administration Guide

3.2.2 Setting Up Optional Account Features

After creating a User object, you can set up the user’s network computing environment and
implement extra login security features.

Setting Up a User's Network Computing Environment

1 In Novell iManager, click the Roles and Tasks button .

2 Click Users > Modify User.

3 Specify the name and context of the User or Users you want to modify, then click OK.

4 On the General tab, select the Environment page.

5 Fill in the property page.

Click for more information on specific properties.

6 Click OK.

Setting Up Extra Login Security for a User

novdocx (ENU) 01 February 2006

1 In Novell iManager, click the Roles and Tasks button .

2 Click Users > Modify User.

3 Specify the name and context of the User or Users you want to modify, then click OK.

4 On the Restrictions tab, fill in the property pages you want.

Click for details on any page.

Page Description

Password Restrictions Sets up a login password.

Login Restrictions • Enable or disable the account.

• Limit the number of concurrent login sessions.

• Set a login expiration and lockout date.

Time Restrictions Restricts the times when the user can be logged in. If you

set a restriction and the object is logged in when the
restricted time arrives, the system issues a five-minute
warning and then (after five minutes) logs the object out if it
isn’t logged out already.If the user will log in remotely, see

“Login Time Restrictions for Remote Users” on page 99.

Address Restrictions Restricts the network locations (workstations) that this user

can log in from. If you don’t set restrictions on this page, the
user can log in from any network location.

Account Balance Sets up an accounting of this user's server usage.

Intruder Lockout Lets you work with this account if it has been locked

5 Click OK.

because of intruder detection. To manage the intruder
detection setup, use the Intruder Detection property page of
the parent container.

Managing Objects 97

Setting Up Intruder Detection for All Users in a Container

1 In Novell iManager, click the Roles and Tasks button .

2 Click eDirectory Administration > Modify Object.

3 Specify the name and context of a container object, then click OK.

4 On the General tab, select the Intruder Detection page.

5 Select from the following options:

Option Description

Detect Intruders Enables the intruder detection system for the user accounts in the

container.

Incorrect Login Attempts Specifies the number of consecutive failed login attempts that are

allowed before intruder detection is activated. If a person uses any
of the user accounts in this container to log in and fails
consecutively more than this number of times, intruder detection is
activated. The number is stored in the Login Intruder Limit
property of the container.

novdocx (ENU) 01 February 2006

Intruder Attempt Reset
Interval

Lock Account After Detection Specifies whether to disable login if intruder detection is activated

Days, Hours, Minutes These three fields specify the length of time that login is disabled

Specifies the time span in which consecutive failed logins must
occur for intruder detection to be activated. Enter the number of
days, hours, and minutes.

on a user account in this container. If you don’t check this check
box, no action is taken when intruder detection is activated. If you
check this check box and the system locks a user account due to
intruder detection, you can unlock the account by unchecking the
Account Locked check box on the Intruder Lockout property page
of the User object.

when intruder detection is activated on a user account in this
container. Enter the number of days, hours, and minutes you
want, or accept the default of 15 minutes. After the specified time
elapses, the system re-enables login for the user account. The
contents of these fields are stored in the Intruder Lockout Reset
Interval property of the container.

6 Click OK.

3.2.3 Setting Up Login Scripts

A login script is a list of commands that executes when a user logs in. It is typically used to connect
the user to network resources like files and printers. Login scripts execute on the user’s workstation
in the following order:

1. Container login script

2. Profile login script

3. User login script

98 Novell eDirectory 8.8 Administration Guide

During login, if the system doesn't find one of these login scripts, it skips to the next one in the list.
If none are found, the system executes a default script that maps a search drive to a folder on the
user’s default server. The default server is set on the Environment property page of the user object.

Creating a Login Script

1 In Novell iManager, click the Roles and Tasks button .

2 Click eDirectory Administration > Modify Object.

3 Specify the name and context of the object that you want to create the login script on.

To Have the Login Script Apply To Create It On

One user only The User object

One or more users that haven't been created yet A Template object

All the users in a container The container object

A set of users in one or more containers A Profile object

novdocx (ENU) 01 February 2006

4 Click OK.

5 On the General tab, select the Login Script page.

6 Enter the login script commands you want.

See the Login Script Commands Guide (http://www.novell.com/documentation/lg/noclienu/

index.html) for more information.

7 Click OK.

Assigning a Profile to a User

Associating a profile with a User object causes the profile’s login script to execute during the user’s
login. Make sure that the user has Browse rights to the Profile object and Read rights to the Login
Script property of the profile object.

See “Viewing Effective Rights to an eDirectory Object or Property” on page 66 for more
information.

1 In Novell iManager, click the Roles and Tasks button .

2 Click User > Modify User.

3 Specify the name and context of the User object that you want to create the login script on.

4 Click OK.

5 On the General tab, select the Login Script page.

6 To associate a profile object with this object, enter the name and context of the profile object in

the Profile field.

7 Click OK.

3.2.4 Login Time Restrictions for Remote Users

On the Time Restrictions property page of a User object, you can restrict the times when the user can
be logged in to eDirectory. (By default, there are no login time restrictions.) If you set a login time

Managing Objects 99

restriction and the user is logged in when the restricted time arrives, the system issues a warning to
log out within five minutes. If the user is still logged in after five minutes, he or she is logged out
automatically and loses any unsaved work.

If a user logs in remotely from a different time zone than the server processing the login request, any
login time restrictions that have been set for the user are adjusted for the time difference. For
example, if you restrict a user from logging in Mondays from 1:00 a.m. to 6:00 a.m. and the user
logs in remotely from a time zone that is one hour later than the server, the restriction effectively
becomes 2:00 a.m. to 7:00 a.m. for that user.

1 In Novell iManager, click the Roles and Tasks button .

2 Click Users > Modify User.

3 Specify the name and context of the User or Users you want to modify, then click OK.

4 On the Restrictions tab, click Time Restrictions.

5 Select from the following options:

Option Description

novdocx (ENU) 01 February 2006

Time Grid Each cell in the time grid represents a half hour on a particular

day of the week. Red cells represent restricted times (when
this object cannot be logged in). Gray cells represent
unrestricted times (when the object can be logged in). To
create a time restriction, click the desired times to make them
dark gray. You can also select multiple times by holding down
the Shift key, clicking a cell, then dragging across the
corresponding cells. The login time restrictions you set are
stored in the Login Allowed Time Map property of this object.

Add Time Restrictions To add a time restriction, select a gray cell, then select this

option.

Remove Time Restrictions To remove a time restriction, select a red cell, then select this

option.

Update Click this button to enable the selection.

Reset Click this button to reset the time grid to the way it was before

you opened this property page.

6 Click OK.

3.2.5 Deleting User Accounts

1 In Novell iManager, click the Roles and Tasks button .

2 Click Users > Delete User.

3 Specify the name and context of the User or Users you want to delete.

4 Click OK.

100 Novell eDirectory 8.8 Administration Guide