2.6 Configuring Policies

LDAP Proxy uses policies to analyze and act on the incoming requests and outgoing responses. Every request or response is sequentially passed to and processed by the policies defined.

The <list-policy> node of the XML configuration file lists all the policies configured for the LDAP Proxy. All the additional policies must be defined in this node.

Every policy defined while configuring the proxy has a rule associated with it. The rule is made up of the following elements:

  • A condition or a group of conditions.

  • An action that must be performed on the incoming request and outgoing responses if the condition evaluates to true.

  • A default action that must be performed if the condition evaluates to false.

NOTE:You must not configure a policy with more than one action at a time. For example, if you configure a Search Request policy with the do-modify-search and do-restrict-view actions and then restart the LDAP Proxy, the first action is overwritten by the second action.

The following table provides high-level information about the policies which can be configure along with various components of the Proxy server.

Policy Name

Listener

Policy Engine

Back-end Groups

Connection Route Policy

 

Search Request Policy

 

 

Map Schema Policy

 

 

Replace String Policy

 

 

Client Network Policy

 

 

Operation Restriction Policy

 

 

2.6.1 Adding a New Policy

To add a policy, follow these steps:

  1. Open the nlpconf.xml file from the /etc/opt/novell/ldapproxy/conf directory in any XML editor.

  2. To add a policy, create an instance within the <list-policy> node. Use the sample configuration as a pattern. You must define the policy as the first policy in the node.

  3. Define a name to identify the policy, a set of conditions, an action, and a default action for the policy.

  4. To add more policies, repeat Step 2 to Step 3.

  5. Save the nlpconf.xml file.

2.6.2 Generic Configuration Parameters of Policy

Before adding a new policy, you must understand the various configuration parameters that are used to configure policies:

id-policy: The identity of the policy. The value of this attribute is used to refer to the policy that is being configured. It must be a unique alphanumeric value. This is a mandatory attribute.

Policies configuration parameters can have the following child elements:

  • <description>: An explanation about the policy. This is an optional element used for reference purposes.

  • <rule>: The rule associated with the policy that is configured. Every policy has a rule.

    This element can have the following child elements:

    • <conditions>: The condition to be evaluated. Each policy can have multiple conditions defined. You can define same or different conditions multiple times based on your requirement. If a policy has multiple conditions, each condition should be combined by the logical operators such as <and>, <or>, <not> in the xml file.

      This element can have the several child elements. For more information, seeUnderstanding the Condition Elements for Policies.

    • <actions>: The action to be performed if the condition evaluates to true.

    • <actions-default>: The default action to be performed if the condition evaluates to false.

      NOTE:For Connection Route Policy, only <do-deny> and <do-nothing> action elements are supported under the <actions-default> condition elements.

Supported Condition and Action Elements for Policies

The below table provides the matrix of supported condition and action elements for each policy.

Policy Name

Supported Condition Elements

Supported Action Elements

Connection Route Policy

NOTE:While using the <if-srch-*> conditions in the Connection Route Policy, you must always use the <if-message-type> condition. For more information, see Configuring a Connection Route Policy for Routing a Request Based on Search Request.

Search Request Policy

Map Schema Policy

Replace String Policy

Client Network Policy

Operation Restriction Policy

Understanding the Condition Elements for Policies

Each policy can have one or more conditions defined. The following condition elements are used by various policies:

<if-ip-addr>

This condition is used to match an individual IP address. You must define the attribute op specifying the matching operation. The allowed values for op are equal or not-equal.This condition supports both ipv4 and ipv6 addresses. Provide ipv6 address within square brackets.

For instance, you can define the <if-ip-addr> condition as follows:

<if-ip-addr op="equal">151.155.123.12</if-ip-addr> or 
<if-ip-addr op="equal">[2015::34]</if-ip-addr>

<if-port>

This condition is used to match an individual TCP Port number in the range of 1-65536. You must define the attribute op specifying the matching operation. The allowed values for op are equal, not-equal, less-or-equal, or greater-or-equal.

For instance, you can define the <if-port> condition as follows:

<if-port op="equal">389</if-port>

<if-network-addr>

This condition is used to match an IP subnet. You must define the attribute op specifying the matching operation. The allowed values for op are equal or not-equal. This condition supports both IPv4 and IPv6 subnets. Provide IPv6 address within square brackets. This element can have the following child elements:

  • <network-addr>: This is a mandatory element which is used to specify the subnet address.

    You must define one of the following two elements:

  • <subnet-mask>:Provide the subnet mask as a value to this element.

  • <subnet-bits>:Provide the subnet mask as a value to this element. This element must have a valid subnet bits value.

    NOTE:If you are using a IPv6 network address, use only the <subnet-bits> element.

For instance, you can define the <if-network-addr> condition as follows:

  • IPv4 subnets:

    <if-network-addr>
    <network-addr>164.99.178.0</network-addr>
    <subnet-bits>24</subnet-bits>
</if-network-addr>

  • IPv6 subnets:

    <if-network-addr>
    <network-addr>[2015::f4]</network-addr>
    <subnet-bits>64</subnet-bits>
</if-network-addr>

<if-bind-dn-container>

This condition is used to match the LDAP bind DN container in an incoming bind request. You must define the attribute op specifying the matching operation. The allowed values for op are equal, not-equal.

You can also define value for the optional attribute match. The allowed values are case-igonre and case-exact. If the attribute match is not defined, the default value will be case-ignore.

For instance, you can define the <if-bind-dn-container> condition as follows:

<if-bind-dn-container op="equal" match="case-ignore">ou=provo,o=novell</if-bind-dn-container>

<if-bind-dn>

This condition is used to match the LDAP bind DN in an incoming bind request. You must define the attribute op specifying the matching operation. The allowed values for op are equal, not-equal.

You can also define value for the optional attribute match. The allowed values are case-igonre and case-exact. If the attribute match is not defined, the default value will be case-ignore.

For instance, you can define the <if-bind-dn> condition as follows:

<if-bind-dn op="equal" match="case-ignore">cn=admin,ou=provo,o=novell</if-bind-dn>

<if-regex-match>

This condition is used to evaluate search filters in a search request using a regular expression. This new condition allows you to use POSIX Extended Regular Expressions to evaluate the search filters. The allowed value for field is srch-filter.

For instance, you can define the <if-regex-match> condition as follows:

<if-regex-match field="srch-filter"> [POSIX Extended Regular Expression] </if-regex-match>

The below example allows mail= searches only when the domain is .com. For other domains, the request is blocked.

<if-regex-match field="srch-filter">mail=\w*@\w*\.com</if-regex-match>

<if-srch-selection-attr>

This condition is used to match the LDAP search selection attribute in an incoming search request. You must define the attribute op specifying the matching operation. The allowed values for op are equal, not-equal.

You can also define value for the optional attribute match. The allowed values are case-igonre and case-exact. If the attribute match is not defined, the default value will be case-ignore.

For instance, you can define the <if-search-selection-attr> condition as follows:

<if-srch-selection-attr op="equal" match="case-ignore">acl</if-srch-selection-attr>

<if-srch-base>

This condition is used to match the LDAP search base in an incoming search request. You must define the attribute op specifying the matching operation. The allowed values for op are equal, not-equal.

You can also define value for the optional attribute match. The allowed values are case-igonre and case-exact. If the attribute match is not defined, the default value will be case-ignore.

For instance, you can define the <if-search-base> condition as follows:

<if-srch-base op="equal" match="case-ignore">o=novell</if-srch-base>

<if-srch-filter>

This condition is used to match the LDAP search filter in an incoming search request. You must define the attribute op specifying the matching operation. The allowed values for op are equal, not-equal.

You must also define the filter-type attribute to match on the standard LDAP search filter types. Correspondingly the allowed values for this attribute are substrings, greater-or-equal, less-or-equal, present, approx-match or equality-match.

This condition has an optional child element:

  • <filter-attribute>: This element is used to match on the attributes present in the LDAP search filter. You can also define value for the optional attribute match. The allowed values are case-igonre and case-exact. If the attribute match is not defined, the default value will be case-ignore.

If filter-attribute element is not specified, the condition will apply on all LDAP search requests irrespective of the attributes.

For instance, you can define the <if-srch-filter> condition as follows:

<if-srch-filter filter-type="present" op="equal">
    <filter-attribute match="case-ignore">cn</filter-attribute>
</if-srch-filter>

<if-srch-scope>

This condition is used to match the LDAP search scope in an incoming search request. You must define the attribute op specifying the matching operation. The allowed values for op are equal, not-equal.

The allowed values for this condition are base-object, one-level, and sub-tree, corresponding to the standard LDAP search scopes.

For instance, you can define the <if-srch-scope> condition as follows:

<if-srch-scope op="equal">sub-tree</if-srch-scope>

<if-message-type>

This condition is used to match the LDAP message type in an incoming request. You must define the attribute op specifying the matching operation. The allowed values for op are equal, not-equal. The allowed values for this condition are mentioned below corresponding to the standard LDAP message types:

  • ldap-bind-request

  • ldap-bind-response

  • ldap-search-request

  • ldap-search-result-entry-response

  • ldap-search-result-reference-response

  • ldap-search-result-done-response

  • ldap-modify-request

  • ldap-modify-response

  • ldap-add-request

  • ldap-add-response

  • ldap-delete-request

  • ldap-delete-response

  • ldap-moddn-request

  • ldap-moddn-response

  • ldap-compare-request

  • ldap-compare-response

  • ldap-extended-request

  • ldap-extended-response

  • ldap-abandon-request

  • ldap-intermediate-response

  • ldap-unbind-request

For instance, you can define the <if-message-type> condition as follows:

<if-message-type op="equal">ldap-add-request</if-message-type>

Understanding the Action Elements for Policies

Each policy must have one action and one default action defined. When the condition evaluates to true, the specified action will be performed. When the condition evaluates to false, the default action will be performed. The following actions are allowed to be defined as Actions and Default Actions:

<do-allow>

This action element is used to allow the connection flow through to the next policy in the configuration without modifying the LDAP request. This element doesn’t have any child elements.

<do-nothing>

This action element serves the same functionality as <do-allow>. In some policies, <do-nothing> element is allowed. For more information, see Supported Condition and Action Elements for Policies.

<do-deny>

This action element is used to stop the connection flow to the next policy. Client will see an LDAP error message saying Insufficient access rights when this action element is executed.

<do-map-schema>

This action element is used to map the schema based on attributes. This element has a child element called attributes. The child element attributes can have multiple child elements called map-attribute. Each map-attribute defines a schema mapping on one attribute.

For instance, you can define the <do-map-schema> element as follows:

<do-map-schema>
    <attributes>
        <map-attribute name="cn">FirstName</map-attribute>
        <map-attribute name="sn">LastName</map-attribute>
    </attributes>
</do-map-schema>

In the above example, the schema mapping is defined as follows:

  • The cn attribute maps to the FirstName attribute.

  • The sn attribute maps to the LastName attribute.

<do-modify-search>

This element is used to modify an LDAP search request. This element allows the following child elements:

  • <description>: An explanation about the modify search request.

  • <base>: This element is used to specify modifications that are done on the search base. You must define the attribute op specifying the modify operation. The allowed values for op are replace and append.

  • <scope>: This element is used to specify the scope of the search request. The three types of search scope are base-object, one-level, and sub-tree.

  • <time-limit>: This element is used to specify the time limit of the search request.

  • <size-limit>: This element is used to specify the size limit of the search request.

  • <derefalias-reset>: This element is used to reset the alias dereferencing value set by the client. Corresponding to the standard LDAP derefalias options- never, always, search, find, the allowed values for this element are 0, 1, 2, 3 respectively.

  • <selection-attributes>: This element is used to specify modifications to the LDAP search selection attribute list.Using this element, you can add, delete or replace attributes in the selection list. Correspondingly the following three child element are allowed in this element:

    • <add>

    • <delete>

    • <replace>

    Each of the above elements allows any number of <value> child elements to specify the attribute names which are to be added, deleted or replaced. The <replace> element has a mandatory name attribute to specify the selection attribute to be replaced.

For instance, you can define selection attributes as follows:

<do-modify-search>
    <base op="append">ou=sales,o=novell</base>
    <scope>subtree</scope>
    <time-limit>20</time-limit>
    <size-limit>120</size-limit>
    <derefalias-reset>2</derefalias-reset>
    <selection-attributes>
        <add>
            <value>localEntryID</value>
        </add>
        <delete>
            <value>creationTimeStamp</value>
        </delete>
        <replace name="*">
            <value>cn</value>
            <value>sn</value>
        </replace>
    </selection-attributes>
</do-modify-search>

<do-restrict-view>

This element is used to modify the LDAP search result in order to restrict the result entries to return specific elements. You can define the following child elements to modify the LDAP search result:

  • <attributes>: Shows the attributes of the directory tree.

  • <objectclasses>: Shows the objectclass of the directory tree.

  • <containers>: Shows the containers of the directory tree.

Each of the above elements allows any number of <value> child elements. You must define the attribute op specifying the operation. The allowed values for op are show-only and hide.

For instance, you can define the <do-restrict-view> action as follows:

<do-restrict-view>
    <attributes op="show-only">
        <value>cn</value>
        <value>objectClass</value>
    </attributes>
    <objectclass op="show-only">
        <value>inetOrgPerson</value>
        <value>groupOfNames</value>
    </objectclass>
    <container op="hide">
        <value>o=security</value>
        <value>o=support</value>
    </container>
</do-restrict-view>

<do-send-monitor-response>

This is a special action element which is used to enable the live monitoring feature of LDAP Proxy. This element must be used in a policy connected to a dedicated listener and this listener can be used for live monitoring of the Proxy server. For more information on how to use NLPManager on this listener, see Configuring Monitoring Activities.

<do-use-route>

This action element is used to route the incoming LDAP requests to a load balancer. This element also allows us to connect multiple policies before routing the request to a load balancer. The following child elements are allowed in this policy:

  • <ref-policy>: This child element is used to connect other policies using their policy id. All policies except Client Network Policy are allowed. Multiple <ref-policy> elements can be used to connect multiple policies. The order of <ref-policy> elements will determine the order of the policy execution.

    NOTE:All id-policy that you have mentioned in the above element, must be predefined within the <list-policy> element.

  • <ref-load-balancer>: This element is used to route the incoming request to a back-end server group. The value specified here should be the id of a load balancer element defined earlier within the <list-load-balancer>.

  • <ref-hash-balancers> : This element is used to configure a hash-based route policy with a group of load balancers. The value of this element must be a common pattern on the load balancer ids. This element has two attributes; num-buckets and hash-route-all. num-buckets takes a numerical value specifying the number of hash-buckets.

    hash-route-all is a boolean attribute. If this is set to true, all LDAP incoming requests including binds are routed through the hash policy.

    NOTE:For a given Connection Route policy, you can have either have the <ref-load-balancer> element or the <ref-hash-balancers> element and not both.

<do-replace-string>

This element is used to match & replace strings on the attribute values in the LDAP request and response. The operation will be performed on the attribute(s) which are specified in the <attributes> child element. The <attributes> child element can have multiple <value> elements specifying each attribute. The LDAP DN attribute is always operated on irrespective of the attributes specified.

The actual match & replace operation is specified using an <order> element. The <order> element can have multiple <replace> elements. Each <replace> element has a pair of <from> and <to> elements. Each <replace> element is used to perform a single match replace operation. In LDAP request, when the value specified in <from> is matched and replaced with the values specified in <to>. In an LDAP response, <to> element is matched and replaced with the value in the <from> element. Each replace operation specified within the <order> element happens on the LDAP request in the same order. In an LDAP response, the operations are performed in the reverse order.

For instance, you can define the <do-replace-string> as follows:

<do-replace-string>
    <attributes>
        <value>manager</value>
        <value>seeAlso</value>
    </attributes>
    <order>
        <replace>
            <from>o=company</from>
            <to>ou=marketing,o=company</to>
        </replace>
        <replace>
            <from>o=something</from>
            <to>ou=something,o=company</to>
        </replace>
    </order>
</do-replace-string>

2.6.3 Use Cases with Examples

You can perform the following tasks using policies for LDAP Proxy:

Accepting or Denying a Client Connection (Client Network Policy)

The Client Network policy is an optional policy that acts as a directory firewall. This policy helps to accept/reject clients depending on the IP/subnet addresses. Configuring this policy, you can either allow Proxy to establish connection to a client that resides in a particular internal network or reject the requests that are coming from a specific IP address in a particular location subnet.

The Client Network policy must be defined in the <list-policy> node of the XML configuration file.

For instance, if you want to define a simple Client Network policy that has one condition and its relevant action and default action. Any incoming client requests from a network with an IP address equal to 192.168.1.0 and with subnet bits equal to 24 must be allowed to establish a connection.

From LDAP Proxy 1.5 onwards, it is possible to specify IPv6 addresses of specific hosts or subnets to which client network restriction policy should apply, as shown in Example 3. This works similar to IPv4 addresses.

You can define the configuration as follows:

<list-policy>
<policy-client-network id-policy="client-policy">
  <rule>
   <comment>Allow clients from a particular network</comment>
   <conditions>
     <if-network-addr op="equal">
      <network-addr>192.168.1.0</network-addr>
      <subnet-mask>255.255.255.0</subnet-mask>
     </if-network-addr>
     <if-network-addr op="equal">
      <network-addr>[2021::89]</network-addr>
      <subnet-bits>64</subnet-bits>
     </if-network-addr>
   </conditions>
   <actions>
     <do-allow/>
   </actions>
   <actions-default>
    <do-deny/>
   </actions-default>
  </rule>
</policy-client-network>
<list-policy>

Examples

Example 1
<list-policy>
 <policy-client-network id-policy="client-policy">
  <rule>
   <comment>Allow clients with network IP address as 164.99.148.12 and subnet-bits as 24 to establish a connection</comment>
   <conditions>
    <or> 
     <if-network-addr op="equal">
      <network-addr>192.168.5.0</network-addr>
      <subnet-bits>24</subnet-bits>
     </if-network-addr>
     <and>
      <if-ip-addr op="equal">151.155.123.12</if-ip-addr>
      <if-port op="less-or-equal">1024</if-port>
     </and>
    </or>
   </conditions>
   <actions>
     <do-allow/>
   </actions>
   <actions-default>
    <do-deny/>
   </actions-default>
  </rule>
 </policy-client-network>
<list-policy>

Example 1 specifies a Client Network policy identified as client-policy. Any incoming client request from either a network having an IP address equal to 192.168.1.0 and having subnet-bits as 24 or a client having an IP address 151.155.123.12 and port number less than or equal to 1024 is allowed to establish a connection.

Example 2
<list-policy>
 <policy-client-network id-policy="restrict-a-network">
  <rule>
   <conditions>
    <if-network-addr op="equal">
     <network-addr>192.168.5.0</network-addr>
     <subnet-mask>255.255.255.0</subnet-mask>
    </if-network-addr>   
   </conditions>
   <actions>
    <do-deny/>
   </actions>
   <actions-default>
    <do-allow/>
   </actions-default>
  </rule>
 </policy-client-network>
</list-policy>

Example 2 specifies a Client Network policy identified as restrict-a-network. Any incoming client requests from a network having IP address equal to 192.168.0.0 and having subnet-mask as 255.255.254.0 cannot establish a connection.

Example 3
<policy-client-network id-policy="allow_my_company_network" disabled="false">
       <rule>
             <conditions>
                   <or>
                   <if-network-addr op="equal">
                          <network-addr>192.168.5.0</network-addr>
                          <subnet-mask>255.255.255.0</subnet-mask>
                   </if-network-addr>
                   <if-network-addr op="equal">
                          <network-addr>[2021::89]</network-addr>
                          <subnet-bits>64</subnet-bits>
                   </if-network-addr>
                   <if-network-addr op="equal">
                          <network-addr>[2015:c5::ad]</network-addr>
                          <subnet-bits>63</subnet-bits>
                   </if-network-addr>
                          <if-ip-addr op="equal">[2045:ec:54::de]</if-ip-addr>
                          <if-ip-addr op="equal">132.0.0.0</if-ip-addr>
                   </or>
             </conditions>
             <actions>
                    <do-allow/>
             </actions>
             <actions-default>
                    <do-deny/>
             </actions-default>
       </rule>
</policy-client-network>

In a Example 3, a Client Network policy identified as allow_my_company_network. Any incoming client requests from a network having the following IP addresses and subnet-masks can establish a connection:

  • Network address 192.168.5.0 with subnet mask 255.255.255.0

  • Network address [2021::89] with 64 subnet bits

  • Network address [2015:c5::ad] with 63 subnet bits

  • IPv6 address [2045:ec:54::de]

  • IPv4 address 132.0.0.0

Restricting LDAP Operations (Operation Restriction Policy)

The Operation Restriction policy is an optional policy that is used to restrict certain LDAP operations. Using this policy you can restrict few LDAP operations such as Bind, Search, Modify, Add, Delete, Moddn, Compare, and Extended Requests.

The Operation Restriction policy must be defined in the <list-policy> node of the XML configuration file.

For instance, if you want to define an Operation Restriction policy, restrict-operation, that denies all modify operations on the back-end server and allows only read-only operations and sends them to the back-end group. The configuration can be defined as follows:

<list-policy>
 <policy-client-restriction id-policy="restrict operation">
  <rule>
   <conditions>
    <or>
     <if-message-type op="equal" >ldap-bind-request</if-message-type>
     <if-message-type op="equal" >ldap-add-request</if-message-type>
     <if-message-type op="equal" >ldap-modify-request</if-message-type>
     <if-message-type op="equal" >ldap-delete-request</if-message-type>
    </or>     
   </conditions>
   <actions>
    <do-deny/>
   </actions>
   <actions-default>
    <do-allow/>
   </actions-default>
  </rule>
 </policy-client-restriction>
</list-policy>

Example

<list-policy>
 <policy-client-restriction id-policy="restrict operation">
  <rule>
   <conditions>
    <or>
     <if-message-type op="equal" >ldap-bind-request</if-message-type>
     <if-message-type op="equal" >ldap-search-request</if-message-type>
    </or>     
   </conditions>
   <actions>
    <do-allow/>
   </actions>
   <actions-default>
    <do-deny/>
   </actions-default>
  </rule>
 </policy-client-restriction>
</list-policy>

This example specifies that this policy node is used before the request is sent to the load balancer. The back-end group behaves like a directory used for performing searches only.

Configuring Access Control Based on Users (Operation Restriction Policy)

The nlpconf_AccessBasedOnUsers.xml is a sample configuration file in the /etc/opt/novell/ldapproxy/conf-sample directory which configures a particular set of servers to behave as read-only for all users except users from specific groups.

<policy-operation-restriction id-policy="restrict_operations" disabled="false">
       <rule>
           <conditions>
               <or>
                  <if-message-type op="equal">ldap-modify-request</if-message-type>
                 <if-message-type op="equal">ldap-add-request</if-message-type>
                 <if-message-type op="equal">ldap-delete-request</if-message-type>
                 <if-message-type op="equal">ldap-moddn-request</if-message-type>
               </or>
           </conditions>
           <actions>
              <do-deny/>
           </actions>
           <actions-default>
              <do-allow/>
           </actions-default>
       </rule>
</policy-operation-restriction>

<policy-connection-route id-policy="support_users" disabled="false">
       <rule>
           <conditions>
                <if-bind-dn-container op="equal" match="case-ignore">
                ou=support,o=my_company</if-bind-dn-container>
           </conditions>
           <actions>
                <do-use-route>
                     <ref-policy>restrict_operations</ref-policy>
                     <ref-load-balancer>backend_grp1</ref-load-balancer>
                </do-use-route>
            </actions>
            <actions-default>
                <do-nothing/>
            </actions-default>
       </rule>
</policy-connection-route>

Mapping the Back-End Server Schema with the Application-Specific Schema (Map Schema Policy)

The Map Schema policy is an optional policy that is used to map the back-end server schema to the application-specific schema.

The Map Schema policy must be defined in the <list-policy> node of the XML configuration file.

For instance, if you want to define a Map Schema policy to map the attribute names of a directory to custom attribute names. You can configure the policy as follows:

<policy-map-schema id-policy="schema-map">
  <rule>
   <comment>Maps the attribute-names of the directory to custom atrribute-names</comment>
   <actions>
    <do-map-schema>
     <attributes> 
      <map-attribute name="cn" syntax="dn">CommonName</map-attribute>
      <map-attribute name="c" syntax="dn">country</map-attribute>
      <map-attribute name="o" syntax="dn">organization</map-attribute>
     </attributes>
    </do-map-schema>    
   </actions>
   <actions-default>
    <do-nothing/>
   </actions-default>
  </rule>
</policy-map-schema>

Mapping the Schema Based on the Network and Users (Map Schema Policy)

When the identity of an incoming request is established, the Map Schema policy checks the attribute name specified in the client request and matches these names to the relevant attribute names in the back-end server schema. For example, you can use this policy to configure the proxy for following users:

  • For users from ou=finance , ou=hr, ou=sales, ou=marketing, map attributes cn to commonName and sn to surName

  • For users from ou=eng_dept, map attributes cn to FirstName and sn to LastName

  • For users from ou=support and other users, do not map the schema

For more information about the elements and attributes that are used to define a Map Schema policy, refer to Generic Configuration Parameters of Policy.

Example 1:

<policy-map-schema id-policy="fin_mktg_hr_sales_schema" disabled="false">
            <rule>
                <actions>
                    <do-map-schema>
                        <attributes>
                            <map-attribute name="cn">commonName</map-attribute>
                            <map-attribute name="sn">surName</map-attribute>
                        </attributes>
                    </do-map-schema>
                </actions>
                <actions-default>
                    <do-nothing/>
                </actions-default>
            </rule>
</policy-map-schema>

This example specifies that this policy node is used to map client request attribute name cn to commonName and sn to surName for users from ou=finance, ou=hr, ou=sales and ou=marketing.

Example 2:

<policy-map-schema id-policy="eng_schema" disabled="false">
            <rule>
                <actions>
                    <do-map-schema>
                        <attributes>
                            <map-attribute name="cn">FirstName</map-attribute>
                            <map-attribute name="sn">LastName</map-attribute>
                        </attributes>
                    </do-map-schema>
                </actions>
                <actions-default>
                    <do-nothing/>
                </actions-default>
            </rule>
</policy-map-schema>

This example specifies that this policy node is used to map client request attribute name cn to FirstName and sn to LastName for users from ou=eng_dept.

Evaluating Incoming Search Request (Search Request Policy)

The Search Request policy is an optional policy which evaluates an incoming search request, then process it either by modifying or by denying the request.

You must define the Search Request policy in the <list-policy> node of the XML configuration file.

For instance, if you want to define a Search Request policy as search-policy, with the search scope as sub-tree and the filter-type as present. You want the match attribute to be defined as case-ignore, which means that the container can be either cn or CN. If any of these conditions are found to be true, then the search request is denied. You can define the configuration as follows:

<list-policy>
 <policy-search-request id-policy="search-policy">
  <rule>
   <comment>deny subtree search with cn=* filter or allow attributes requests except "acl"</comment>
   <conditions>
    <or>
     <if-srch-selection-attr op="equal" match="case-ignore">acl</if-srch-selection-attr>
     <if-srch-scope op="equal">sub-tree</if-srch-scope>
     <if-srch-filter filter-type="present" op="equal">
       <filter-attribute match="case-ignore">cn</filter-attribute>
     </if-srch-filter> 
    </or>     
   </conditions>
   <actions>
    <do-deny/>
   </actions>
   <actions-default>
    <do-allow/>
   </actions-default>
  </rule>
 </policy-search-request>
</list-policy>

Examples

Example 1
<list-policy>
 <policy-search-request id-policy="search-restriction">
  <rule>
   <conditions>
    <or>
     <if-srch-base op="equal" match="case-ignore">ou=dept1,ou=dept4,o=my_company</if-srch-base>
     <if-srch-base op="equal" match="case-ignore">ou=dept2,o=my_company</if-srch-base>
    </or>     
   </conditions>
   <actions>
    <do-allow/>
   </actions>
   <actions-default>
    <do-deny/>
   </actions-default>
  </rule>
 </policy-search-request>
</list-policy>

Example 1 uses the search only if the search base is either ou=dept1, ou=dept4,o=my_company or ou=dept2,o=my_company.

Example 2
<list-policy>
 <policy-search-request id-policy="cn-monitor">
  <rule>
   <actions>
    <do-send-monitor-response/>
   </actions>
   <actions-default>
    <do-allow/>
   </actions-default>
  </rule>
 </policy-search-request>
 <policy-connection-route id-policy="monitor-admin">
  <rule>
   <comment>allow all</comment> 
   <conditions>
    <if-bind-dn op="equal">cn=admin,o=mycompany</if-bind-dn>        
   </conditions>
   <actions>
    <do-use-route>
     <ref-policy>cn-monitor</ref-policy>
     <ref-load-balancer>back-dynld</ref-load-balance>
    </do-use-route>
   </actions>
   <actions-default>
    <do-nothing/>
   </actions-default>
  </rule>
 </policy-connection-route>
</list-policy>

Example 2 specifies that a monitor request <do-send-monitor-response> is described in a search policy, cn-monitor. This search policy is referred in a Connection Route policy, monitor-admin.

Example 3
<proxy-configuration>
  <proxy-paths>
    <dir-config>/etc/opt/novell/ldapproxy/conf</dir-config>
    <dir-log>/var/opt/novell/ldapproxy/log</dir-log>
  </proxy-paths>
  <list-listener>

<!--  Listener for LDAP requests .... All the ldap request should go to this Listener (IP & Port) -->
    <listener id-listener="listener1">
      <service protocol="ldap">
        <addr-ipv4>192.168.1.2</addr-ipv4>
        <port>389</port>
      </service>
      <ref-policy-connection-route>conn-route-policy</ref-policy-connection-route>
    </listener>

<!--  Listener for Live Monitor  -->
    <listener id-listener="listener2">
      <service protocol="ldap">
        <addr-ipv4>192.168.1.3</addr-ipv4>
        <port>1389</port>
      </service>
      <ref-policy-connection-route>monitor-policy</ref-policy-connection-route>
    </listener>

  </list-listener>
  <list-backend-server health-check-interval-secs="60">
    <backend-server id-backend-server="Backend1" max-connections="0" capability="1">
      <service protocol="ldap">
        <addr-ipv4>192.168.0.111</addr-ipv4>
        <port>389</port>
      </service>
      <health-check max-response-time-ms="5000">
        <req-ldap-bind>
          <bind-dn>cn=wyld,ou=users,o=sna</bind-dn>
        </req-ldap-bind>
      </health-check>
    </backend-server>
    
   <backend-server id-backend-server="Backend2" max-connections="0" capability="1">
      <service protocol="ldap">
        <addr-ipv4>192.168.0.112</addr-ipv4>
        <port>389</port>
      </service>
      <health-check max-response-time-ms="5000">
        <req-ldap-bind>
          <bind-dn>cn=wyld,ou=users,o=sna</bind-dn>
        </req-ldap-bind>
      </health-check>
    </backend-server>
  </list-backend-server>
  
  <list-load-balancer>
    <lb-conn-based id-load-balancer="backend-grp1">
      <ref-backend-server>Backend1</ref-backend-server>
      <ref-backend-server>Backend2</ref-backend-server>
    </lb-conn-based>
  </list-load-balancer>
  <list-policy>
    <policy-search-request id-policy="monitor_request">
        <rule>
               <actions>
      <do-send-monitor-response/>
    </actions>
    <actions-default>
      <do-allow/>
    </actions-default>
  </rule>
    </policy-search-request>

    <policy-connection-route id-policy="conn-route-policy" disabled="false">
      <rule>
        <comment>
    Route all connections to the backend-grp1
  </comment>
        <actions>
          <do-use-route>
            <ref-load-balancer>backend-grp1</ref-load-balancer>
          </do-use-route>
        </actions>
        <actions-default>
          <do-nothing/>
        </actions-default>
      </rule>
    </policy-connection-route>

<policy-connection-route id-policy="monitor-policy" disabled="false">
      <rule>
        <comment>
    Policy for Live Monitor
  </comment>
        <actions>
          <do-use-route>
      <ref-policy>monitor_request</ref-policy>
            <ref-load-balancer>backend-grp1</ref-load-balancer>
          </do-use-route>
        </actions>
        <actions-default>
          <do-nothing/>
        </actions-default>
      </rule>
    </policy-connection-route>
  </list-policy>
</proxy-configuration>

Example 3 specifies that a listener listener2 is configured for live monitoring. listener2 includes a Connection Route policy monitor-policy. This policy includes the monitor_request policy for live monitoring, which contains the monitor request policy <do-send-monitor-response>.

Setting a Search Base for User Identities (Search Request Policy)

The nlpconf_SearchBasedOnUserIdentity.xml is a sample configuration file available in the /etc/opt/novell/ldapproxy/conf-sample directory which enables a proxy server to automatically append a search base to default containers when a base is supplied. For more information on configuring a Search Request Policy, refer to Evaluating Incoming Search Request (Search Request Policy).

For instance, if you want to define a Search Restriction Policy to enable Proxy server to replace ou=finance and o=my_company, define your configuration as follows:

</policy-search-request>
        <policy-search-request id-policy="finance_search_help" disabled="false">
            <rule>
                <conditions>
                    <if-srch-base op="equal" match="case-ignore"/>
                </conditions>
                <actions>
                    <do-modify-search>
                        <base op="replace">ou=finance,o=my_company</base>
                    </do-modify-search>
                </actions>
                <actions-default>
                    <do-allow/>
                </actions-default>
            </rule>
        </policy-search-request>

In the above example, the proxy server will automatically replace ou=finance, o=my_company as a search base to default containers when a base is supplied.

Preventing Wild Card Search Filters (Search Request Policy)

The nlpconf_PreventWildSearch.xml is a sample configuration file in the /etc/opt/novell/ldapproxy/conf-sample directory which enables the Proxy server to prevent substring searches reaching to the back-end servers. For more information on configuring a Search Request Policy, refer to Evaluating Incoming Search Request (Search Request Policy).

For instance, if you want to define a Search Restriction Policy to enable LDAP Proxy server to prevent substring searches such as cn=* reaching to the back-end servers, define your configuration as follows:

<policy-search-request id-policy="search_filter" disabled="false">
            <rule>
                <conditions>
                    <if-srch-filter filter-type="substrings" op="equal">
                        <filter-attribute match="case-ignore">cn</filter-attribute>
                    </if-srch-filter>
                </conditions>
                <actions>
                    <do-deny/>
                </actions>
                <actions-default>
                    <do-allow/>
                </actions-default>
            </rule>
        </policy-search-request>

In the above example, the proxy server prevents users from sending the cn=* type of LDAP searches.

Routing an Incoming Request to a Back-End Server Group (Connection Route Policy)

The Connection Route policy is a mandatory policy that is used to route an incoming request to the appropriate back-end server group.

By default, one Connection Route policy is defined in the <list-policy> node and the defined Connection Route policy is referred in the <list-listener> node in the configuration file. You can add more Connection Route policies to this configuration.

For instance, if you want to define a Connection Route policy, all-clients, to specify that an incoming request from either a network IP address 192.168.1.1 with 24 subnet bits or a base ou=dept1,o=my_company must be routed and analyzed by the search policy defined as search-policy. It is then passed on to the back-end server group called connld. You can define the configuration, as follows:

<list-policy>
 <policy-connection-route id-policy="all-clients" request-route-dit="backend-tree-name">
  <rule>
   <conditions>
    <or> 
    <if-network-addr op="equal">
     <network-addr>192.168.1.1</network-addr>
     <subnet-bits>24</subnet-bits>
    </if-network-addr>
    <if-bind-dn-container op="equal" match="case-ignore">ou=dept1,o=my_company</if-bind-

dn-container>
    </or>   
   </conditions>
   <actions>
    <do-use-route>
     <ref-policy>search-policy</ref-policy>
     <ref-load-balancer>connld</ref-load-balance>
    </do-use-route>
   </actions>
   <actions-default>
    <do-nothing/>
   </actions-default>
  </rule>
 </policy-connection-route>
</list-policy>

Additional Configuration Parameters for Connection Route Policy

The following additional elements and attributes are required to configure Connection Route policies:

<policy-connection-route>: Specifies that the element configured is a Connection Route policy. This element must have the following attributes:

  • id-policy: The identity of the policy. The value of this attribute is used to refer to the policy that is being configured. This is a mandatory attribute. You must specify this attribute to enable the modify entry cache configuration.

  • request-route-dit: The name of the Directory Information Tree that the back-end server is hosting. The name must not conflict with the policy IDs. This is an optional attribute and is also referred to as ModDNCache. If this attribute is specified, the cache configuration is enabled and a request is routed to the back-end server that has the latest copy of the entry in the request.

    Multiple LDAP Proxy servers can be configured to share the ModDNCache, so that information about any modification that occurs through any of the proxy is available on all the proxy servers.

  • moddncache-enable-for-bind: This is an optional attribute. While specifying this attribute, you can configure the Proxy server to enable modify DN cache and have the user binds follow it, if the user object is present in the cache. However, if the user object is not present in the cache, you can configure LDAP Proxy to follow the default load balancing and routing mechanism.

  • moddncache-expiry-time: This attribute is used to specify the duration for which the cache should be effective. You can set a value between 300 seconds and 86400 seconds. The cleanup thread event runs every two minutes, and if the administrator specifies 10 minutes as cache timeout, cache entries may get cleared between 10 to 12 minutes.

    The following is a sample configuration that uses the moddncache-expiry-time attribute:

    <policy-connection-route id-policy="conn-route-policy" request-route-dit="ldap_proxy_tree" moddncache-enabled-for-bind="true" moddncache-expiry-time="1800"> 
           <rule> 
               Rule definition... 
           </rule> 
           <persistent-moddn-cache> 
                   <redis redis-auth-username="redis_admin">
                       <addr-ipv4>192.168.1.2</addr-ipv4>
                          <port>6379</port> 
                   </redis> 
           </persistent-moddn-cache> 
</policy-connection-route>

In the preceding example, a connection route policy conn-route-policy is defined and the ModDNCache and moddncache-enable-for-bind attributes are enabled. An expiry time of 1800 seconds for the cache is also defined.

The <policy-connection-route> element can also have the following additional child elements:

  • <persistent-moddn-cache>: If the LDAP Proxy server is restarted, the in-memory ModDNCache is erased. This causes further modify requests to be routed to any of the back-end servers, depending on the configuration of the load balancer. You can store the ModDNCache in a persistent storage to prevent loss of the data even if the LDAP Proxy server is restarted.

    For information about configuring the Redis server, see Configuring the Redis Server.

    • redis-auth-username: This attribute is used when redis is configured for authentication. You must specify the username of the redis administrator and ensure that the password for this user is stored in the local secret store using the passwdstore utility.

    • <addr-ipv4>/<addr-ipv6>: The IP address of the system on which LDAP Proxy is installed.

    • <port>: The port on which the listener listens for incoming requests.

    The following is a sample configuration of a persistable ModDNCache interface:

    <list-policy>
  <policy-connection-route id-policy="conn-route-policy" request-route-dit="ldap_proxy_tree" >
           <rule>
                Rule definition...
           </rule>
           <persistent-moddn-cache>
                   <redis redis-auth-username="redis_admin">
                          <addr-ipv4>127.0.0.2</addr-ipv4>
                          <port>6379</port>
                   </redis>
           </persistent-moddn-cache>
  </policy-connection-route>

Configuring a Hash-Based Route Policy

Hash-Based Route Policy is an optional policy which allows you to choose the load balancers based on priority. You can associate a connection route policy with a group of load balancers. The type of the load balancers may vary based on your need. You can have a group of priority based load balancers or a mix of different types of load balancers, as shown in the following example:

<list-load-balancer>
   <lb-conn-based id-load-balancer="backend-grp1">
     <ref-backend-server>Backend1</ref-backend-server>
     <ref-backend-server>Backend2</ref-backend-server>
   </lb-conn-based>

   <lb-dynamaic-load-based id-load-balancer="backend-grp2">
     <ref-backend-server>Backend3</ref-backend-server>
     <ref-backend-server>Backend4</ref-backend-server>
   </lb-conn-based>

   <lb-priority-based id-load-balancer="backend-grp3">
     <ref-backend-server>Backend2</ref-backend-server>
     <ref-backend-server>Backend1</ref-backend-server>
   </lb-priority-based>

</list-load-balancer>
<policy-connection-route id-policy="conn-route-policy">
        <rule>
             <actions>
                   <do-use-route>
                          <ref-hash-balancers num-buckets="3">
                                backend-gr
                          </ref-hash-balancers>
                   </do-use-route>
             </actions>
             <actions-default>
                     <do-nothing/>
             </actions-default>
        </rule>
</policy-connection-route>

In the above sample, the configuration includes a connection route policy conn-route-policy with a hash balancer pattern backend-grp. When this policy is configured, the LDAP Proxy expects three load balancers: backend-grp1, backend-grp2, and backend-grp3. If they are not available, then LDAP Proxy fails to start.

If you want to hash route all requests (including the bind requests), set the hash-route-all attribute to true, as shown in the following example:

<ref-hash-balancers num-buckets="3" hash-route-all="true">                                   
       backend-grp
</ref-hash-balancers>

Configuring a Connection Route Policy to Block Anonymous Binds

To configure a Route Policy to block anonymous binds, set a condition in the connection route policy, as shown in the following example:

<policy-connection-route id-policy="conn-route-policy">
   <rule>
     <conditions>
         <if-bind-dn op="not-equal"></if-bind-dn>
     </conditions>
      <actions>
      <do-use-route>                                                   
        <ref-load-balancer>backend-grp1</ref-load-balancer>
      </do-use-route>
      </actions>
      <actions-default>
      <do-nothing/>
      </actions-default>
   </rule>
 </policy-connection-route>

In the above example, a Connection Route policy identified as id-policy includes a condition to block anonymous binds and route all connections to the back-end server identified as backend-grp1. If bind dn is blank, the LDAP proxy will not do anything.

Configuring a Connection Route Policy for Routing a Request Based on Search Request

Routing based on search requests is evaluated only if the search request is on anonymous connection. In-order to handle the bind, policy chain should have at least one route which will be used for the non-search requests. To configure a connection route policy based on a search request is shown in the below example:

<policy-connection-route id-policy="sample_conn">
   <rule>
     <conditions>
        <or>
        <and>
           <if-message-type op="equal">ldap-search-request</if-message-type>
           <if-srch-base op="equal">o=acme</if-srch-base>
        </and>
           <if-message-type op="not-equal">ldap-search-request</if-message-type>
        </or>
     </conditions>
     <actions>
        <do-use-route>
           <ref-load-balancer>Default_LoadBalancer</ref-load-balancer>
        </do-use-route>
     </actions>
     <actions-default>
        <do-nothing/>
     </actions-default>
   </rule>
</policy-connection-route>

In the above example, anonymous search requests go to the Default_LoadBalancer when the search base is o=acme. Any request other than a search request, passes the condition.

Replacing a String Sequence in Directory Attribute Values (Replace String Policy)

The Replace String policy is an optional policy that is used to replace a string sequence in the attribute values of a directory.

The Replace String policy must be defined in the <list-policy> node of the XML configuration file.

The Replace String policy replaces the values from the object DN and the attributes specified in the policy. For instance, if you want to define a Replace String policy to replace the DN, manager, and also attribute values from o=company to ou=marketing, o=company and o=subsidiary to o=company, you can configure the policy, as follows:

<list-policy>
 <policy-replace-string id-policy="replace-string" disabled="false">
  <rule>
   <conditions>
    <or>
     <if-message-type op="equal">ldap-add-request</if-message-type>
     <if-message-type op="equal">ldap-add-response</if-message-type>
     <if-message-type op="equal">ldap-delete-request</if-message-type>
     <if-message-type op="equal">ldap-modify-request</if-message-type>
     <if-message-type op="equal">ldap-moddn-request</if-message-type>
     <if-message-type op="equal">ldap-search-request</if-message-type>
     <if-message-type op="equal">ldap-search-result-entry-response</if-message-type>
     <if-message-type op="equal">ldap-search-result-entry-referenceresponse</if-message-type>
     <if-message-type op="equal">ldap-bind-request</if-message-type>
     <if-message-type op="equal">ldap-bind-response</if-message-type>
     <if-message-type op="equal">ldap-compare-request</if-message-type>
     <if-message-type op="equal">ldap-search-result-done-response</if-message-type>
    </or>
  </conditions>
  <actions>
   <do-replace-string>
    <attributes>
     <value>manager</value>
     <value>seeAlso</value>
    </attributes>
    <order>
      <!-- In the oreder. Will come out after first hit -->
      <replace>
        <from>o=comapny</from>
        <to>ou=marketing,o=company</to>
      </replace>
      <replace>
        <from>o=subsidiary</from>
        <to>o=company</to>
      </replace>
     </order>
    </do-replace-string>
   </actions>
   <actions-default>
     <do-nothing/>
   </actions-default>
  </rule>
 </policy-replace-string>
</list-policy>

2.6.4 Handling Attribute OIDs in Policies

As indicated in RFC 4512 section 2.5, attributes can also be referred to by their OIDs. This means that policies can be easily bypassed when attribute OIDs are used in the incoming request.

LDAP Proxy provides a map file for default attribute names, which is called nlpschemaconf.xml, located in the /etc/opt/novell/ldapproxy/conf directory. This file contains attribute name OID maps for the default schema provided by directories such as NetIQ eDirectory, Active Directory, Sun ONE, IBM Tivoli, and Oracle OID.

However, OIDs related to custom schemas are not supported and need to be handled manually. For example, to add an attribute name OID map for attributeTypes “2.16.840.1.113719.1.1.4.1.59.12 NAME 'myattribute' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12”, add the following node to the nlpschemaconf.xml file:

<attribute oid="2.16.840.1.113719.1.1.4.1.59.12 ">
   <name>myattribute</name>
</attribute>