# slapo-constraint

## NAME



           slapo-constraint - Attribute Constraint Overlay to slapd
    


## SYNOPSIS



           ETCDIR/slapd.conf
    


## DESCRIPTION



           The constraint overlay is used to ensure that attribute values
           match some constraints beyond basic LDAP syntax.  Attributes can
           have multiple constraints placed upon them, and all must be
           satisfied when modifying an attribute value under constraint.
    
           This overlay is intended to be used to force syntactic regularity
           upon certain string represented data which have well known
           canonical forms, like telephone numbers, post codes, FQDNs, etc.
    
           It constrains only LDAP _add_ , _modify_ and _rename_ commands and only
           seeks to control the _add_ and _replace_ values of _modify_ and _rename_
           requests.
    
           No constraints are applied for operations performed with the _relax_
           control set.
    


## CONFIGURATION



           These **slapd.conf** options apply to the constraint overlay. They
           should appear after the **overlay** directive.
    
           **constraint_attribute <attribute_name>[,...] <type> <value>**
           **[ <extra> [...]]**
                  Specifies the constraint which should apply to the comma-
                  separated attribute list named as the first parameter.
                  Eight types of constraint are currently supported - **regex** ,
                  **negregex** , **size** , **count** , **uri** , **neguri** , **set** , and **negset**.
    
                  The parameter following the **regex** or **negregex** type is a
                  Unix style regular expression (See regex(7) ). The
                  parameter following the **uri** or **neguri** type is an LDAP URI.
                  The URI will be evaluated using an internal search.  It
                  must not include a hostname, and it must include a list of
                  attributes to evaluate.
    
                  The parameter following the **set** or **negset** type is a string
                  that is interpreted according to the syntax in use for ACL
                  sets.  This allows one to construct constraints based on
                  the contents of the entry.
    
                  The **size** type can be used to enforce a limit on an
                  attribute length, and the **count** type limits the number of
                  values of an attribute.
    
                  Extra parameters can occur in any order after those
                  described above.
    
                  **< extra> : restrict=<uri>**
    
                  This extra parameter allows one to restrict the application
                  of the corresponding constraint only to entries that match
                  the _base_ , _scope_ and _filter_ portions of the LDAP URI.  The
                  _base_ , if present, must be within the naming context of the
                  database.  The _scope_ is only used when the _base_ is present;
                  it defaults to **base**.  The other parameters of the URI are
                  not allowed.
    
           **constraint_allowempty FALSE | TRUE**
                  Historically, **slapo-constraint** rejected Modify/Add requests
                  with an empty sequence of modifications. This was not
                  intentional and if this option is **TRUE** , such modifications
                  will be allowed so long as they are otherwise valid.  The
                  default is **FALSE** to maintain backwards compatibility.
    
           Any attempt to add or modify an attribute named as part of the
           constraint overlay specification which does not fit the constraint
           listed will fail with a LDAP_CONSTRAINT_VIOLATION error.
    


## EXAMPLES



                  overlay constraint
                  constraint_attribute jpegPhoto size 131072
                  constraint_attribute userPassword count 3
                  constraint_attribute mail regex ^[[:alnum:]]+@mydomain.com$
                  constraint_attribute mail negregex ^[[:alnum:]]+@notallowed.com$
                  constraint_attribute title uri
                    ldap:///dc=catalog,dc=example,dc=com?title?sub?(objectClass=titleCatalog)
                  constraint_attribute cn neguri
                    ldap:///ou=People,dc=example,dc=com?cn,sn?sub?(objectClass=inetOrgPerson)
                  constraint_attribute cn,sn,givenName set
                    "(this/givenName + [ ] + this/sn) & this/cn"
                    restrict="ldap:///ou=People,dc=example,dc=com??sub?(objectClass=inetOrgPerson)"
    
           A specification like the above would reject any **mail** attribute
           which did not look like **< alphanumeric string>@mydomain.com **or that
           looks like **< alphanumeric string>@notallowed.com**.  It would also
           reject any **title** attribute whose values were not listed in the
           **title** attribute of any **titleCatalog** entries in the given scope.
           (Note that the "dc=catalog,dc=example,dc=com" subtree ought to
           reside in a separate database, otherwise the initial set of
           titleCatalog entries could not be populated while the constraint
           is in effect.)  With the type "neguri" (negated "uri"), it would
           ensure uniqueness of one (or more) attributes against one (or
           more) other attributes. A specification like the above would
           reject any **cn** attributes whose **any** values **was already listed** in
           another **cn** or **sn** attributes of any **inetOrgPerson** entries in the
           given scope.  Finally, it requires the values of the attribute **cn**
           to be constructed by pairing values of the attributes **sn** and
           **givenName** , separated by a space, but only for entries derived from
           the objectClass **inetOrgPerson**.  Should the type "negset" have been
           used instead of "set", the condition would have been reversed.
    


## FILES



           ETCDIR/slapd.conf
                  default slapd configuration file
    


## ACKNOWLEDGEMENTS



           This module was written in 2005 by Neil Dunbar of Hewlett-Packard
           and subsequently extended by Howard Chu and Emmanuel Dreyfus.
           **OpenLDAP Software** is developed and maintained by The OpenLDAP
           Project <http://www.openldap.org/>.  **OpenLDAP Software** is derived
           from the University of Michigan LDAP 3.3 Release.
    


* * *