The Oracle access control model doesn't differentiate between user attributes and operational attributes.
In the Oracle access control model, using
targets both user and operational attributes. Using an exclusion list like
targetattr!="userPassword" automatically targets all operational attributes
in addition to all user attributes except
userPassword. This presents several
significant security holes here users are unintentionally given access to operational
attributes. In some cases, it could allow users to exempt themselves from password policy
The server treats operational attributes differently from user attributes and never
automatically includes operational attributes. For example,
targets all user attributes but no operational attributes, and
targetattr!="userPassword" targets all user attributes except
userPassword but no operational attributes.
You can target specific operational attributes by including the names in the list, such as
targetattr="creatorsName||modifiersName". You can target all operational
attributes by using the
"+" character. For example,
targetattr="+" targets all operational attributes but no user attributes,
targetattr="*||+" targets all user and operational attributes.
The following example searches for all immediate children of
ou=People,dc=example,dc=com. The attributes returned are restricted to
givenName, and all operational attributes.
ldapsearch --bindDN uid=admin,dc=example,dc=com --bindPassword password \ --baseDN ou=People,dc=example,dc=com --searchScope one '(objectclass=*)' \ sn givenName "+"
You can use compound filters to search for a subset of the entries in the
ou=People,dc=example,dc=com subtree. The following example limits the
returned entry amount to 200, and the server will spend no more than 5 seconds processing
ldapsearch --bindDN uid=admin,dc=example,dc=com --bindPassword password \ --baseDN ou=People,dc=example,dc=com --searchScope sub --sizeLimit 200 \ --timeLimit 5 "(&(sn<=Doe)(employeeNumber<=1000))" ds-entry-unique-id \ entryUUID