LDAP-UX Client Services B.05.00 Administrator's Guide

organization wishes to register printers in the directory server, and the organization has a policy
that “Top Secret” documents may only be printed on a restricted set of printers. The organization
could have all printers that are eligible for printing “Top Secret” documents created with the
entitySecurityLevel attribute value set to “Top Secret”. The conventions used with the
attributes in the preceding table, such as defining acceptable value sets, are entirely up to the
policies of the organization. The “Top Secret” printer is just one example of such a convention.
While the usage of the schema as defined in this section is entirely optional and up to the
organization, when classifying objects, organizations should consider standardizing key strings.
For example, a limited set of key strings should be defined for an object’s role, enabling the use
of LDAP search filters to easily identify all objects of the same role. For information about how
to use the above schema for identifying classes of systems, see “Classifying hosts” (page 179).
Most of the attributes described in Table 2-1 (page 32) are multi-valued. For example, you can
define more than one role for an object by specifying the entityRole attribute with multiple
values.
For more information about the schema described in this section, see the /etc/opt/ldapux/
schema/ldapux50.xml and /etc/opt/ldapux/schema/ssh_schema.xml files.
2.3.2.3 Security framework
When a new directory server instance is created, the guided installation defines a simple access
control framework that provides basic protection for data stored in that directory server.
In most directory server deployments, the general policy is to manage public data while
maintaining high data integrity. The guided installation creates access control instructions that
instantiate such a policy. Most attributes in the directory server are considered public to the
organization in which it is deployed. The guided installation establishes controls such that those
attributes can be managed by a limited (privileged) set of individuals. There are exceptions to
this policy. For example, the user’s password (stored in the userPassword attribute) is private.
Another exception is that, to protect data integrity, most attributes are modifiable only by a
limited set of privileged administrators. However, some attributes may be modified by users
themselves. For example, a user may modify his own userPassword. Because the base access
policy assumes most information is public, at least within the organization, HP recommends
that this access control policy be reviewed before you store private or confidential data in the
directory server. You can modify the ACIs to suit your organization's unique privacy and integrity
requirements. A review of the ACIs created by the guided installation are described in the
following subsections. For more specific information about the access control instructions and
how to modify them, see the HP-UX Directory Server administrator guide.
2.3.2.3.1 Proxy users
One of the primary principles of the base security policy is that, although most information is
considered public, the scope of users considered public is limited to those who can authenticate
to the directory server. This means that information managed in the directory server subtree is
visible only to users who can bind and authenticate to the directory server. This policy is enforced
by the following ACI:
dn: dc=mydomain,dc=example,dc=com
aci: (targetattr!="userPassword || nisSecretKey")(version 3.0; acl "[ALL:READ:
NOT-PRIVATTRS] Enable proxied access"; allow (read, search, compare) userdn
="ldap:///all";)
Basically, this ACI states that if the name of the attribute (any attribute defining managed
information) is neither userPassword nor nisSecretKey, then it is visible to anyone who
can bind to the directory server (ldap:///all).
To assure that HP-UX hosts can retrieve user, group, and other information from the directory
server, the HP-UX OS must bind to the directory server on behalf of the users using the OS. To
do this, a proxy entry must be created in the directory server that represents the host and its OS.
2.3 Guided installation (autosetup) 33