E-3
Cisco Security Appliance Command Line Configuration Guide
OL-10088-01
Appendix E Configuring an External Server for Authorization and Authentication
Configuring an External LDAP Server
• Loading the Schema in the LDAP Server
• Defining User Permissions
• Reviewing Examples of Active Directory Configurations
Reviewing the LDAP Directory Structure and Configuration Procedure
An LDAP server stores information as entries in a directory. An LDAP schema defines what types of
information such entries store. The schema lists classes and the set of (required and optional) attributes
that objects of each class can contain.
To configure your LDAP server to interoperate with the security appliance, define a security appliance
authorization schema. A security appliance authorization schema defines the class and attributes of that
class that the security appliance supports. Specifically, it comprises the object class
(cVPN3000-User-Authorization) and all its possible attributes that may be used to authorize a security
appliance user (such as access hours, primary DNS, and so on). Each attribute comprises the attribute
name, its number (called an object identifier or OID), its type, and its possible values.
Once you have defined the security appliance authorization schema and loaded it on your server, define
the security appliance attributes and permissions and their respective values for each user who will be
authorizing to the server.
In summary, to set up your LDAP server:
• Design your security appliance LDAP authorization schema based on the hierarchical set-up of your
organization
• Define the security appliance authorization schema
• Load the schema on the LDAP server
• Define permissions for each user on the LDAP server
The specific steps of these processes vary, depending on which type of LDAP server you are using.
Organizing the Security Appliance LDAP Schema
Before you actually create your schema, think about how your organization is structured. Your LDAP
schema should reflect the logical hierarchy of your organization.
For example, suppose an employee at your company, Example Corporation, is named Terry. Terry works
in the Engineering group. Your LDAP hierarchy could have one or many levels. You might decide to set
up a shallow, single-level hierarchy in which Terry is considered a member of Example Corporation. Or,
you could set up a multi-level hierarchy in which Terry is considered to be a member of the department
Engineering, which is a member of an organizational unit called People, which is itself a member of
Example Corporation. See Figure E-1 for an example of this multi-level hierarchy.
A multi-level hierarchy has more granularity, but a single level hierarchy is quicker to search.