Authentication and Policy With LDAP

The HP-UX AAA Server software includes LDAP policy implementation. LDAP adds the ability to create complex authorization policies by allowing Boolean expressions to be represented in a tree-structured list of policy objects.

If you only need to retrieve user IDs and passwords from the LDAP server, you can go directly to the steps for HP-UX AAA Server configuration (see “Configuring the LDAP Server ”). No special configuration is necessary for the LDAP server.

If you wish to implement simple or complex policy decisions, HP recommends that you review all the ProLDAP documentation. This information will help you configure the HP-UX AAA Server and LDAP servers by familiarizing you with:

Specific attributes and object classes
Procedure for extending a standard LDAP schema
Procedure for creating a directory file using the LDIF format

The LDAP Information Model

The Directory Tree

The basic unit of information in an LDAP directory is the entry. An entry is composed of a distinguished name and attribute-value pairs. An entry has a set of attribute-value pairs that are required, and a set that are allowed. These are determined by the object classes to which the entry belongs. All other A-V pairs are prohibited.

Entries are arranged in a tree-structured hierarchy. In the directory file, these entries may be expressed in standard text-based LDIF format (see “Creating an LDIF File ” for more information about how to create an LDIF file).

The LDAP Schema

The total set of attribute types and object classes known to the directory is referred to as the directory's schema.

Attribute types (or attributes) contain information about specific data elements of the entry. In an entry, each attribute listed will have one or more attribute values. See “AAA Server Attribute Types ” for more information about attribute types.

Object classes are used to group related attribute types. Each directory entry belongs to one or more object classes. The object classes an entry belongs to determine the attribute types that are required and those that are allowed in an entry. The designer of the directory determines which object classes each entry belongs to, based on the information required by the directory design.

In order to implement policy (retrieving any profile information in addition to user ID and password), the standard schema contained in the directory server must be extended to include attributes and object classes used by the HP-UX AAA Server. Schema files are provided for the certified directory server products (installed in /opt/aaa/examples/proldap by default).




	CAUTION: Several schema files may be installed with an LDAP server. Modifying schema files may result in problems. Never delete unused schema elements from the standard schema. No additional operational or administrative overhead is required and deletion could create future problems.

Directory entries are usually written using the LDIF text format. This ASCII text format is used to export data from and import data into a directory server. See the IETF RFC 2849 (http://www.ietf.org/rfc.html) for more information on this file format.

An LDIF file consists of a series of lines. The first line is always the Distinguished Name (DN). The following lines are the attributes of the entry. There is one A-V pair per line.

Figure 16-1 “Tree Structure of Complex Policy” illustrates the tree structure of a complex policy. Several policy entries are shown. The policy entry named policyitem5 is represented in LDIF file format.

Figure 16-1 Tree Structure of Complex Policy

Creating an LDIF File

For AAA Server policy implementation, the LDIF file stores information about user profiles and authorization policies.

User profiles contain information used by the AAA Server software's LDAP AATV and CHK_DENY AATV to:

Perform authentication using the uid and userpassword attribute types
Perform simple authorizations using aaaCheck and aaaDeny attribute types
Point to complex authorization policy entries by using a policy pointer and DN as an A-V pair in the aaaCheck attribute type

The LDIF files must contain a user profile for each user. User profiles are represented in the LDIF file by user entries (see “User Entries ”). Authorization policies contain information used by the POLICY AATV to evaluate complex authorization policies.

The LDIF file can contain complex authorization policies, if such policies are required to express the desired policy implementation. Policy entries are used whenever it is necessary or useful to represent a policy as a tree-structured hierarchy. For example, it is necessary to use policy entries to represent complex policies that include Boolean expressions such as “this OR that” and “this AND that.”

A policy logically consists of two parts: a policy condition and a policy profile, which are represented by a policy entry in the LDIF file.

AAA Server Attribute Types

Most of the attributes in the AAA Server provided schema file(s) are RADIUS attributes or vendor-specific attributes. These RADIUS attributes are defined in RFC 2865 and RFC 2866. Definitions of vendor-specific attributes can be found in vendor documentation. Table 16-1 “Attribute Type” describes the various attributes that you can use.

Table 16-1 Attribute Type

Attribute Type	Description
`aaaPO`	Name of a policy object
`aaaPI`	Name of a policy item
`aaaOperator`	An operator used in a policy condition
`aaaEvaluator`	An operator used in a policy profile
`aaaTReply`	A message sent back when a policy condition or policy profile evaluates to True
`aaaFReply`	A message sent back when a policy condition or policy profile evaluates to False
`aaaCheck`	An attribute that must be present in the user entry in order for the entry to evaluate to True
`aaaDeny`	An attribute that must NOT be present in the user entry in order for the entry to evaluate to True
`aaaReply`	A response sent back from the server (e.g., a session time limit)

AAA Server Object Classes

Object classes determine the attribute types required or allowed in a directory entry. The provided schema file(s) contain contains object classes used by AAA server in directory entries, for example:

The aaaPerson object class represents what set of attributes a user entry must or may contain. It assumes that the standard LDAP schema inetOrgPerson object class (refer to RFC 2798) exists and that it includes the attributes uid and userpassword.
The aaaPolicy object class represents a policy object by the set of attributes a policy entry must or may contain to define a Boolean condition.
The aaaPolicyItem object class represents a policy item by the set of attributes a policy entry must contain to evaluate an attribute's value.
The aaaPolicyOC object class represents the set of specific attributes evaluated in a policy item.




	NOTE: Netscape Directory Server has a limitation. It currently allows a maximum of 100 attributes per object class. Since the policy implementation requires that many more than that be available, the LDAP implementation assigns attributes to object classes in sets of 100 or less. These classes are all included in the AAA Server provided schema file. The `aaaPolicyOC` object class is a superset of all these object classes.

User Entries

User entries contain information used by LDAP and CHK_DENY actions to perform authentication using the uid and userpassword attributes.

User entries must contain any A-V pairs required by the aaaPerson object class.

In an LDIF entry, a user entry is represented as follows:

dn: attr=value, attr=value, . . .
uid: value
userPassword: value
ObjectClass: aaaPerson
User-ID: value
User-Password: value
aaaCheck: RADIUS-Attr=value
aaaDeny: RADIUS-Attr=value
aaaReply: RADIUS-Attr=value

dn: Distinguished name that identifies a directory entry in the LDAP schema by using a series of comma-separated attributes and attribute values, where the left-most value specifies the actual directory object and the right-most value specifies the directory root point. For example, ou=people, o=yourcompany.com points to the organizational unit, people, located below the organization, yourcompany.com, directory branch.
uid: LDAP attribute that identifies a user in the LDAP schema below the branch specified by dn. If this attribute is specified as the filter in the LDAP authfile entry, it must be included in all user entries for that realm; otherwise, the field is optional.
userpassword: LDAP attribute that identifies the password for the user.
ObjectClass: Indicates what A-V pairs must or may be used in the user entry, according to A-V pairs defined in the aaaPerson object class. This attribute is not required for user ID/user password authentication, but it is required if you wish to add User-ID, User-Password; or check, reply, or deny items to the user profile for policy decisions. In addition to or instead of aaaPerson, other object classes (e.g., the Person class from the standard LDAP schema) may be specified.
User-ID: RADIUS attribute, defined in the aaaPerson object class, which may be used to identify a user (as an alternative to uid). If this attribute is specified as the filter in the LDAP authfile entry, it must be included in all user entries for that realm; otherwise, the field is optional.
User-Password: RADIUS attribute, defined in the aaaPerson object class.
aaaCheck, aaaDeny, aaaReply: Specify any A-V pair(s) defined in the dictionary file that you wish to use as a check, deny, or reply item for the user.

Below is an example of an LDIF entry:

dn: uid=deshen,ou=Groups,dc=cup,dc=hp,dc=com
objectclass: top
objectclass: aaaperson
cn: deshen
sn: deshen
uid: deshen
userpassword: slyec
aaareply: Reply-Message=”Hello, deshen”

Policy Entries

Policy entries are used whenever it is necessary or useful to authenticate or authorize a user according to a complex set of conditions. For example, it is necessary to use policy entries to represent policies that include Boolean expressions. Policies are expressed using two kinds of policy entries:

Policy items that evaluate a specified attribute-value pair against the A-V pair contained in an Access-Request belong to the aaaPolicy object class.
Policy objects that test a condition by defining a Boolean expression based on the policy items associated with the policy object. A policy object can contain policy items, as well as other policy objects, which in turn may contain policy objects and items. The LDAP implementation limits the number of levels a policy can have to sixty-four. These objects belong to the aaaPolicyItem and aaaPolicyOC object classes.

A policy entry consists of a set of A-V pairs. These entries define how policy is applied as a response to a user request. In an LDIF entry, a policy item must be applied as follows:

dn: attr=value, attr=value, . . .
ObjectClass: aaaPolicyItem
ObjectClass: aaaPolicyOC
aaaPI: PolicyItemName
aaaEvaluator: Evaluator
Policy-Attr: value
aaaTReply: RADIUS-Attr = value
aaaFReply: RADIUS-Attr = value

dn: Distinguished name that identifies a directory entry in the LDAP schema by using a series of comma-separated attributes and attribute values, where the left-most value specifies the actual directory object and the right-most value specifies the directory root point.
ObjectClass: The A-V pairs that must be used in the policy item entry, according to A-V pairs defined in the aaaPolicyItem and aaaPolicyOC object classes.
aaaPI: Name of the policy item
aaaEvaluator: The relational operator to use in evaluating the specified condition. Policy conditions belong to the aaaPolicy object class, also defined in the AAA Server-provided schema files. Table 16-2 lists the various relational operators you can use

Table 16-2 Relational Operators

Operator	Description
=	Equal to
!=	Not equal to
>	Greater than
<	Lesser than
>=	Greater than or equal to
<=	Lesser than or equal to

TReply, FReply: Each specify an A-V pair that must be added to the reply according to the evaluation of the item. At least one aaaTReply or one aaaFReply must be included. If the item evaluates to true, any specified aaaTReply A-V pairs are added to the reply. If the item evaluates to false, any specified aaaFReply A-V pairs are added to the reply.
Policy-Attr: value: The policy item represented by the entry will be evaluated by comparing the specified A-V pair with the one in the Access-Request. For example, if aaaEvaluator is =, the policy item will evaluate to true if the specified attribute value equals the value stored in the request for that attribute; otherwise, the item will evaluate to false.




	IMPORTANT: Policy items cannot handle tagged string or tagged integer attribute values.

Policy Objects

In an LDIF entry, a policy object must be represented as follows:

dn: attr=value, attr=value, . . .
ObjectClass: aaaPolicy
aaaPO: PolicyName
aaaOperator: Operator
aaaTReply: RADIUS-Attr=value
aaaFReply: RADIUS-Attr=value

dn: Distinguished name by identifying a directory entry in the LDAP schema by using a series of comma-separated attributes and attribute values, where the left-most value specifies the actual directory object and the right-most value specifies the directory root point.
ObjectClass: The A-V pairs that can be used in the policy object entry, according to A-V pairs defined in the aaaPolicy object classes.
aaaPO: Name of the policy object
aaaOperator: Boolean operator to use in evaluating the policy object. When AND is specified, the policy object will only evaluate to true if all the policy objects and items associated with the policy object evaluate to true; otherwise, the policy object will evaluate to false. When OR is specified, the policy object will evaluate to true if any one of the policy objects or items associated with it evaluates to true. lists the Boolean operators you can use.

Table 16-3 Boolean Operators

Operator	Description
&&&	Logical AND. If the policy object evaluates to false, all policy items associated with the object are still evaluated to determine whether reply items must be returned for each policy item.
\|\|\|	Logical OR for all policy items and objects. If the policy object evaluates to false, all policy items associated with the object are still evaluated to determine whether reply items should be returned for each policy item.
&&	Logical AND. If the policy object evaluates to false, only the policy items that were evaluated before the object evaluated to false will be returned as policy items.
\|\|	Logical OR. If the policy object evaluates to false, only the policy items that were evaluated before the object evaluated to false will be returned as policy items.

aaaTReply, aaaFReply: Each specify an A-V pair that will be added to the reply according to the evaluation of the condition. If the object evaluates to true, any specified aaaTReply A-V pairs are added to the reply. If the object evaluates to false, any specified aaaFReply A-V pairs are added to the reply.




	IMPORTANT: Policy objects cannot handle tagged string or tagged integer values.

Using Indirection

You can also use indirection to compare an attribute value with or assign it to another attribute value. To compare or assign attribute values to each other with indirection follow a Test = Indirect = Value$Pos$Len syntax, where Test is the attribute to check or assign a value to, and Value is the attribute with the value to check against or assign to the Test attribute. $Pos and $Len are optional parameters that allow you to test or assign a substring of the specified Value attribute. Pos indicates the index position in the attribute's value to begin the substring, and if specified Len determines the length.

When used as the policy attribute (Policy-Attr: value) in a policy item, indirection checks values. When used in a policy item or object as aaaTReply or aaaTFalse attribute, it assigns a value.

A policy item that checked if the Port-Id exceeded its limit and returned a reply-item accordingly, discarding the request when the limit is exceeded, can be defined as follows:

dn: aaapi=less,aaapo=indirection,c=us
ObjectClass: aaaPolicyItem
ObjectClass: aaaPolicyOC
aaaPI: less
aaaEvaluator: <=
Port-Id <= Indirect = Port-Limit
aaaTReply: Decision = Indirect = Interlink-Proxy-Action
aaaFReply: Decision = Abandon
aaaFReply: Authentication-Type = Blackhole

Dynamic Access Control Decisions

Three unique attributes can be used with LDAP to define policies that control access periods, and account and password expiration date and time. Listed below are the three attributes that you can use:

Time-of-Day 24 hour clock in hh:mm format.
Day-Of-Week A string, representing the day of the week (spelled out or three letter abbreviation), or a number from 0 to 6, where 0 represents Sunday and 6 represents Saturday.
Date-Time 24 hour clock in yyyy:mm:dd:hh:mm format.

A policy to restrict access to weekday work hours can be defined with the following LDIF entries:

dn: aaapo=workhours,c=us
objectclass: aaaPolicy
aaaPO: workhours
aaaTTL: 500
aaaOperator: &&&
aaaTReply: Reply-Message="User passed policy requirements"
aaaFReply: Reply-Message="User failed policy requirements"

dn: aaapo=day,aaapo=workhours,c=us
objectclass: aaaPolicy
aaaPO: day
aaaTTL: 500
aaaOperator: &&&

dn: aaapo=time,aaapo=workhours,c=us
objectclass: aaaPolicy
aaaPO: time
aaaTTL: 500
aaaOperator: &&&

dn: aaapi=less,aaapo=day,aaapo=workhours,c=us
ObjectClass: aaaPolicyItem
ObjectClass: aaaPolicyOC
aaaPI: less
aaaEvaluator: <
Day-Of-Week: 5

dn: aaapi=less,aaapo=time,aaapo=workhours,c=us
ObjectClass: aaaPolicyItem
ObjectClass: aaaPolicyOC
aaaPI: less
aaaEvaluator: <
Time-Of-Day: 17:00

dn: aaapi=greater,aaapo=day,aaapo=workhours,c=us
ObjectClass: aaaPolicyItem
ObjectClass: aaaPolicyOC
aaaPI: greater aaaEvaluator: >
Day-Of-Week: 1

dn: aaapi=greater,aaapo=time,aaapo=workhours,c=us
ObjectClass: aaaPolicyItem
ObjectClass: aaaPolicyOC
aaaPI: greater
aaaEvaluator: >
Time-Of-Day: 8:00

Configuring the LDAP Server

On the machine hosting the LDAP server, LDAP configuration files must be modified or created in order to implement authorization.

For security reasons, the LDAP Server should be on the same machine as the HP-UX AAA Server, or both servers must be on the same secure network. You can specify LDAP authentication for realms or decision groups.

Each realm can be configured with up to four redundant LDAP accessible directories, which are used by the server when it performs load balancing and failover.




	NOTE: The following procedures are required if your user entries are using attributes defined in the `aaaPerson` object class. If you are only storing user profiles based on the core LDAP schema (to retrieve the user ID and password), the following procedures are not necessary.

To Configure Netscape Directory Server v6

Copy /opt/aaa/examples/proldap/55iaaa-radius.ldif to the LDAP server schema directory (with HP’s Netscape Directory Server the path usually is /var/opt/netscape/servers/slapd-<hostname>/config/schema).
Restart the directory server.
Create an LDIF file for your user profiles and import to the directory.

To Configure iPlanet Directory Server v5

Copy /opt/aaa/examples/proldap/55iaaa-radius.ldif to the LDAP server schema directory (/var/opt/iplanet/servers/slapd-<hostname>/config/schema).
Restart the directory server.
Create an LDIF file for your user profiles and import to the directory.

To Configure OpenLDAP 2.0.x

Copy iaaa-radius.schema from /opt/aaa/examples/proldap/ to the OpenLDAP server (usually /usr/local/etc/openldap/schema).
Modify the slapd.conf by adding the following lines:
include /usr/local/etc/openldap/schema/cosine.schema
include /usr/local/etc/openldap/schema/inetorgperson.schema
include /usr/local/etc/openldap/schema/iaaa-radius.schema
Restart the directory server.
Create an LDIF file for your user profiles and import to the directory.