HP UX Direry Server manual Naming group entries, Naming organization entries

Page 47

attribute instead of the uid attribute if the enterprise does not assign employee numbers or user IDs for temporary or contract employees.

•employeeNumber

For employees of the inetOrgPerson object class, consider using an employer assigned attribute value such as employeeNumber.

Whatever is used for an attribute-data pair for person entry RDNs, make sure that they are unique, permanent values. Person entry RDNs should also be readable. For example, uid=bjensen, dc=example, dc=com is preferable to uid=b12r56A, dc=example,dc=com because recognizable DNs simplify some directory tasks, such as changing directory entries based on their distinguished names. Also, some directory client applications assume that the uid and cn attributes use human-readable names.

Considerations for person entries in a hosted environment If a person is a subscriber to a service, the entry should be of object class inetUser, and the entry should contain the uid attribute. The attribute must be unique within a customer subtree.

If a person is part of the hosting organization, represent them as an inetOrgPerson with the nsManagedPerson object class.

Placing person entries in the dit The following are some guidelines for placing person entries in the directory tree:

•People in an enterprise should be located in the directory tree below the organization's entry.

•Subscribers to a hosting organization need to be below the ou=people branch for the hosted organization.

4.2.3.2Naming group entries

There are four main ways to represent a group:

•A static group explicitly defines is members. The groupOfNames or groupOfUniqueNames object classes contain values naming the members of the group. Static groups are suitable for groups with few members, such as the group of directory administrators. Static groups are not suitable for groups with thousands of members.

Static group entries must contain a uniqueMember attribute value because uniqueMember is a mandatory attribute of the groupOfUniqueNames object. This object class requires the cn attribute, which can be used to form the DN of the group entry.

Group membership is determined by the member attribute on the group entry, but group membership for all groups is reflected in the user's entry in the memberOf attribute. The name of every group to which a user belongs is listed as a memberOf attribute. The values of those memberOf attributes are managed by the Directory Server.

•A dynamic group uses an entry representing the group with a search filter and subtree. Entries matching the filter are members of the group.

•Roles unify the static and dynamic group concept. See “Grouping directory entries” for more information.

In a deployment containing hosted organizations, we recommend using the groupOfUniqueNames object class to contain the values naming the members of groups used in directory administration. In a hosted organization, we also recommend that group entries used for directory administration be located under the ou=Groups branch.

4.2.3.3 Naming organization entries

The organization entry name, like other entry names, must be unique. Using the legal name of the organization along with other attribute values helps ensure the name is unique, such as o=example_a+st=Washington, o=ISP,c=US.

Trademarks can also be used, but they are not guaranteed to be unique.

4.2 Designing the directory tree

47

Page 46 Page 48
Image 47
Page 46 Page 48
Contents HP-UX Directory Server deployment guide Page Table of Contents Designing the directory tree Designing the replication process 103 145 125141 155 About global directory services Introduction to directory servicesAbout directory services Overview of the server frontend Introduction to Directory ServerAbout Ldap Overview of the basic directory tree Server plug-ins overviewExpanded directory tree for example corp Directory Server data storagePerforming queries on directory entries Directory design overviewAbout directory entries Distributing directory dataDeploying the directory Design process outlineOther general directory resources Page Information to exclude from the directory Planning the directory dataIntroduction to directory data Information to include in the directoryPerforming a site survey Defining directory needsIdentifying the applications that use the directory Characterizing the directory data Identifying data sourcesConsidering a data master Determining level of serviceDetermining data ownership Determining data access Documenting the site survey Example Tabulating data ownership and accessRepeating the site survey Page Schema format Designing the directory schemaSchema design process overview Standard schemaStandard attributes Syntaxes support in Directory Server Standard object classesMatching data to schema elements Mapping the data to the default schemaViewing the default directory schema Data mapped to default directory schema Customizing the schemaStrategies for defining new object classes When to extend the schemaGetting and assigning object identifiers Naming attributes and object classesNew object classes appear in LDAPv3 schema format as follows Strategies for defining new attributes Deleting schema elementsCreating custom schema files Naming schema files Custom schema best practicesDefining attributes before object classes Maintaining consistent schemaUsing user defined as the origin Defining schema in a single fileSelecting consistent data formats Schema checkingMaintaining consistency in replicated schema Other schema resources Choosing a suffix Designing the directory treeIntroduction to the directory tree Designing the directory treeNaming multiple suffixes Suffix naming conventionsBranching the directory Creating the directory tree structureExample environment directory tree Identifying branch pointsDirectory tree for example isp Initial branching of the directory tree for example corp Replication considerationsDirectory branching for example isp Access control considerationsNaming person entries Naming EntriesNaming organization entries Naming group entriesNaming other kinds of entries Grouping directory entriesAbout roles Deciding between roles and groups About class of serviceAbout virtual DIT views Virtual directory information tree views10 Examples of a flat and an organizationally-based DIT 11 a combined DIT using views 12 a DIT with a virtual DIT view hierarchy Advantages of using virtual DIT viewsExample of virtual DIT views Compatibility with existing applications Views and other directory featuresEffects of virtual views on performance Directory tree for an international enterprise Directory tree design examplesDirectory tree for an ISP Other directory tree resourcesPage Distributing the directory data Designing the directory topologyTopology overview Storing suffix data in separate databases About using multiple databasesDirectory tree spread across multiple databases About suffixesAbout knowledge references Using referralsStructure of an Ldap referral About default referralsSmart referrals Using smart referrals to redirect requestsRedirecting a query to a different server and namespace 10 a circular referral pattern Tips for designing smart referralsDeciding between referrals and chaining Using chainingUsage differences Evaluating access controlsThis illustration, the following steps are performed Overview of directory index types Using indexes to improve database performanceEvaluating the costs of indexing Page Unit of replication Designing the replication processIntroduction to replication Replication conceptsReplication and changelogs Read-write and read-only replicasSuppliers and consumers Replication agreement Common replication scenariosData consistency Multi-master replication Single-master replicationMulti-master replication configuration two suppliers Multi-master replication configuration B four suppliers Replication traffic in a multi-master environment Cascading replicationCascading replication scenario Replication traffic and changelogs in cascading replication Mixed environmentsCombined multi-master and cascading replication Defining a replication strategyReplicated selected attributes with fractional replication Conducting a replication surveyManaging disk space required for multi-master replication Replication resource requirementsReplication across a wide-area network Using replication for high availabilityUsing replication for load balancing Using replication for local availabilityEffects of replication and remote lookup on the network Example of network load balancingCalculating Directory Server load Example of load balancing for improved performanceExample replication strategy for a large site Example replication strategy for a small siteReplication and database links Using replication with other Directory Server featuresReplication and access control Replication and Directory Server plug-insSee Creating custom schema files for more information Schema replicationReplication and synchronization Synchronization agreements Designing synchronizationWindows synchronization overview Resource requirements Planning windows synchronizationChangelogs Controlling synchronizationDefining the connection type Managing disk space for the changelogInteraction with a replicated environment Determining the subtree to synchronizeMulti-master Directory Server Windows domain synchronization Identifying the directory data to synchronizeEditing the sync agreement Synchronizing passwords and installing password servicesDefining an update strategy NtUserDomainId Values for cn attributes Password policiesContraints on the initials attribute Values for street and streetAddressNtGroupId Name Unauthorized tampering Unauthorized accessDesigning a secure directory About security threatsAnalyzing security needs Denial of serviceDetermining access rights Example security needs analysis Overview of security methodsEnsuring data privacy and integrity Conducting regular auditsAnonymous access Selecting appropriate authentication methodsSimple password Proxy authentication Certificate-based authenticationSimple password over SSL/TLS Simple authentication and security layerHow password policy works Preventing authentication by account deactivationDesigning a password policy Designing a secure directory Designing a password policy Password policy checking process User-defined passwords Password policy attributesPassword change after reset Expiration warning Password expirationGrace login limit Password syntax checkingPassword history Password lengthPassword minimum age Designing an account lockout policy Designing a password policy in a replicated environmentPassword storage schemes About the ACI format Designing access controlPermissions TargetsPrecedence rule Setting permissionsAllowing or denying access Bind rulesUsing filtered access control rules When to deny accessWhere to place access control rules Viewing ACIs Get effective rights Using ACIs Some hints and tricks Use Ldap search filters cautiously Database encryptionOther security resources Securing server to server connectionsLocal enterprise data design Local enterprise schema designDirectory design examples Design example a local enterpriseLocal enterprise directory tree design Database topology Local enterprise topology designSupplier architecture Local enterprise replication designSupplier architecture for Example Corp Supplier consumer architectureSupplier and consumer architecture for Example Corp Local enterprise security designLocal enterprise operations decisions Local enterprise tuning and optimizationsDesign example a multinational enterprise and its extranet Multinational enterprise directory tree design Multinational enterprise schema designMultinational enterprise data design Entry for the l=Asia entry appears in Ldif as follows Directory tree for Example Corp. Internationals extranet Multinational enterprise topology designServer topology 11 Server topology for Example Corp. Europe 12 Server topology for Example Corp. Internationals extranet Multinational enterprise replication design13 Supplier architecture for Example Corp. Europe Multinational enterprise security design Directory design examples Related information Support and other resourcesContacting HP HP-UX documentation set HP-UX Directory Server administration server guideTypographic conventions Troubleshooting resources144 Glossary Access rightsCGI DIT GSS-API Ldap NIS PTA Sasl TCP/IP 154 Index Index OID Sasl 159
Related manuals
Manual 96 pages 26.31 Kb Manual 68 pages 26.36 Kb Manual 18 pages 3.79 Kb Manual 72 pages 14.95 Kb

UX Direry Server specifications

HP UX Directory Server is a robust and scalable solution designed for managing directory information within enterprise networks. Developed by Hewlett-Packard (HP), this server offers an extensive set of features tailored to meet the needs of organizations that require an efficient way to store, manage, and retrieve identity and access data.

One of the key features of HP UX Directory Server is its ability to handle large directories with significant volumes of data. Built on a highly optimized architecture, it provides excellent performance and can support millions of entries without sacrificing speed or reliability. This capability makes it an ideal choice for large-scale deployments in enterprises that require high availability and responsiveness.

In addition to its scalability, HP UX Directory Server supports a wide range of protocols, including LDAP (Lightweight Directory Access Protocol), which ensures seamless integration with diverse applications and systems across various platforms. The server maintains standards compliance, which facilitates interoperability and simplifies administration tasks.

Security is a top priority for HP UX Directory Server, offering an array of features to protect sensitive information. It supports secure data transmission via TLS/SSL protocols, ensuring encrypted communication between clients and servers. Advanced access controls allow administrators to define fine-grained permissions, helping to safeguard directory data against unauthorized access.

Another salient feature of HP UX Directory Server is its replication capabilities. The server can replicate directory data across multiple instances, ensuring data consistency and availability in distributed environments. This feature is essential for businesses operating across different geographical locations or requiring failover solutions for disaster recovery.

HP UX Directory Server also comes equipped with tools for data management, including an intuitive administration console for configuring and monitoring the server. Additionally, it offers customizable schema capabilities, enabling organizations to tailor the directory structure to fit their specific needs.

Integration with existing identity management solutions is streamlined through connectors and APIs, allowing organizations to extend their directory services and enhance user experience.

In summary, HP UX Directory Server is a powerful directory management solution that combines scalability, security, and integration flexibility. Its support for industry standards, advanced replication, and comprehensive administrative tools makes it an essential asset for organizations seeking to manage identity and access efficiently. By leveraging this technology, businesses can improve their operational efficiency and ensure a secure and organized approach to directory management.
Top Page Image Contents