HP UX Direry Server manual Deciding between roles and groups, About class of service

Page 49

Each role has members, entries that possess the role. Members can be specified either explicitly (meaning each entry contains an attribute associating it with a role) or dynamically (by creating a filter that assigns entries to roles according to an attribute contained in the entry). How role membership is specified depends on the type of role. There are three types of roles:

•Managed roles create an explicit, enumerated list of members. Managed roles are added to entries using the nsRoleDN attribute.

•Filtered roles assign entries to the role depending on the attribute contained in each entry by specifying an LDAP filter. Entries that match the filter are said to possess the role.

•Nested roles create roles that contain other roles. The roles nested within the parent role are specified using the nsRoleDN attribute.

4.3.2Deciding between roles and groups

Both methods of grouping entries have advantages and disadvantages. Roles reduce client-side complexity at the cost of increased server complexity. With roles, the client application can check role membership by searching the nsRole attribute. From the client application point of view, the method for checking membership is uniform and is performed on the server side.

Dynamic groups, from an application point of view, offer no support from the server to provide a list of group members. Instead, the application retrieves the group definitions, then runs the filter. For static groups, the application must make sure the user is part of a particular UniqueMember attribute value. The method for determining group membership is not uniform.

Managed roles can do everything that static groups can do, while filtered roles can filter and identify members as dynamic groups do.

Even though roles are easier to use, more flexible, and reduce client complexity, they do so at the cost of increased server complexity. Determining role membership is more resource intensive because the server does the work for the client application.

4.3.3 About class of service

A class of service (CoS) shares attributes between entries in a way that is invisible to applications. With CoS, some attribute values may not be stored with the entry itself. Instead, they are generated by class of service logic as the entry is sent to the client application.

For example, the directory contains thousands of entries that all share the common attribute facsimileTelephoneNumber. Traditionally, to change the fax number required updating each entry individually, a large job for administrators that runs the risk of not updating all entries. With CoS, the attribute value can be generated dynamically. The facsimileTelephoneNumber attribute is stored in one location, and each entry retrieves its fax number attribute from that location. For the application, these attributes appear just like all other attributes, despite not actually being stored on the entries themselves.

Each CoS is comprised of the several entries in the directory:

•The CoS definition entry identifies the type of CoS. It is stored as an LDAP subentry below the branch it affects.

•The template entry contains a list of the shared attribute values. Changes to the template entry attribute values are automatically applied to all the entries sharing the attribute.

The CoS definition entry and the template entry interact to provide attribute values to their target entries, the entries within their scope. The value they provide depends upon the following:

•The entry's DN (different portions of the directory tree might contain different CoS).

•A service class attribute value stored with the entry.

The absence of a service class attribute can imply a specific default CoS.

4.3 Grouping directory entries

49

Page 48 Page 50
Image 49
Page 48 Page 50
Contents HP-UX Directory Server deployment guide Page Table of Contents Designing the directory tree Designing the replication process 103 141 125145 155 About directory services Introduction to directory servicesAbout global directory services About Ldap Introduction to Directory ServerOverview of the server frontend Overview of the basic directory tree Server plug-ins overviewExpanded directory tree for example corp Directory Server data storageAbout directory entries Directory design overviewDistributing directory data Performing queries on directory entriesDeploying the directory Design process outlineOther general directory resources Page Introduction to directory data Planning the directory dataInformation to include in the directory Information to exclude from 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 design process overview Designing the directory schemaStandard schema Schema formatStandard attributes Syntaxes support in Directory Server Standard object classesViewing the default directory schema Mapping the data to the default schemaMatching data to schema elements Data mapped to default directory schema Customizing the schemaGetting and assigning object identifiers When to extend the schemaNaming attributes and object classes Strategies for defining new object classesNew object classes appear in LDAPv3 schema format as follows Creating custom schema files Deleting schema elementsStrategies for defining new attributes Naming schema files Custom schema best practicesUsing user defined as the origin Maintaining consistent schemaDefining schema in a single file Defining attributes before object classesMaintaining consistency in replicated schema Schema checkingSelecting consistent data formats Other schema resources Introduction to the directory tree Designing the directory treeDesigning the directory tree Choosing a suffixNaming 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 entriesAbout roles Grouping directory entriesNaming other kinds of entries 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 Effects of virtual views on performance Views and other directory featuresCompatibility with existing applications Directory tree for an international enterprise Directory tree design examplesDirectory tree for an ISP Other directory tree resourcesPage Topology overview Designing the directory topologyDistributing the directory data 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 Introduction to replication Designing the replication processReplication concepts Unit of replicationSuppliers and consumers Read-write and read-only replicasReplication and changelogs Data consistency Common replication scenariosReplication agreement 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 access control Using replication with other Directory Server featuresReplication and Directory Server plug-ins Replication and database linksSee Creating custom schema files for more information Schema replicationReplication and synchronization Windows synchronization overview Designing synchronizationSynchronization agreements Changelogs Planning windows synchronizationControlling synchronization Resource requirementsDefining 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 synchronizeDefining an update strategy Synchronizing passwords and installing password servicesEditing the sync agreement NtUserDomainId Values for cn attributes Password policiesContraints on the initials attribute Values for street and streetAddressNtGroupId Name Designing a secure directory Unauthorized accessAbout security threats Unauthorized tamperingDetermining access rights Denial of serviceAnalyzing security needs Ensuring data privacy and integrity Overview of security methodsConducting regular audits Example security needs analysisAnonymous access Selecting appropriate authentication methodsSimple password Simple password over SSL/TLS Certificate-based authenticationSimple authentication and security layer Proxy authenticationDesigning a password policy Preventing authentication by account deactivationHow password policy works Designing a secure directory Designing a password policy Password policy checking process Password change after reset Password policy attributesUser-defined passwords Grace login limit Password expirationPassword syntax checking Expiration warningPassword minimum age Password lengthPassword history Password storage schemes Designing a password policy in a replicated environmentDesigning an account lockout policy About the ACI format Designing access controlPermissions TargetsAllowing or denying access Setting permissionsBind rules Precedence ruleWhere to place access control rules When to deny accessUsing filtered 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 connectionsDirectory design examples Local enterprise schema designDesign example a local enterprise Local enterprise data designLocal 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 designDesign example a multinational enterprise and its extranet Local enterprise tuning and optimizationsLocal enterprise operations decisions Multinational enterprise data design Multinational enterprise schema designMultinational enterprise directory tree 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 Contacting HP Support and other resourcesRelated information 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