LDAP operations

The following are the LDAP operations that can be performed using the projected user profiles.

Bind

An LDAP client can bind (authenticate) to the LDAP server using a projected user profile. This is accomplished by specifying the projected user profile distinguished name (DN) for the bind DN and the correct user profile password for authentication. An example of a DN used in a bind request would be os400-profile=jsmith,cn=accounts,os400-sys=systemA.acme.com.

A client must bind as a projected user to access information in the system projected backend.

Two additional mechanisms are available to authenticate to the directory server as a projected user:

• GSSAPI SASL bind. If the operating system is configured to use Enterprise Identity Mapping (EIM), the directory server queries EIM to determine if there is an association to a local user profile from the initial Kerberos identity. If there is such an association, the server will associate the user profile with the connection and it can be used to access the system projection backend. For more information about EIM, see the EIM topic.
• OS400-PRFTKN SASL bind. A profile token can be used to authenticate to the directory server. The server associates the profile token user profile with the connection.

The server performs all of the operations using the authority of that user profile. The projected user profile DN can also be used in LDAP ACLs like other LDAP entry DNs. The simple bind method is the only bind method that is allowed when a projected user profile is specified on a bind request.

Search

The system projected backend supports some basic search filters. You can specify the objectclass, os400-profile, and os400-gid attributes in search filters. The os400-profile attribute supports wildcards. The os400-gid attribute is limited to specifying (os400-gid=0), which is an individual user profile, or !(os400-gid=0), which is a group profile. You can retrieve all attributes of a user profile except the password and similar attributes.

For certain filters, only the DN objectclass and os400-profile values are returned. However, subsequent searches can be conducted to return more detailed information.

The following table describes the behavior of the system projected backend for search operations.

Compare

The LDAP compare operation can be used to compare an attribute value of a projected user profile. The os400-aut and os400-docpwd attributes cannot be compared.

Add and modify

You can create user profiles using the LDAP add operation and you can also change user profiles using the LDAP modify operation.

Delete

User profiles can be deleted using the LDAP delete operation. To specify the behavior of the DLTUSRPRF OWNOBJOPT and PGPOPT parameters, two LDAP server controls are now provided. These controls can be specified on the LDAP delete operation. Refer to the Delete User Profile (DLTUSRPRF) command for more information about the behavior of these parameters.

The following are the controls and their object identifiers (OIDs) that can be specified on the LDAP delete client operation.

• os400-dltusrprf-ownobjopt                1.3.18.0.2.10.8
  
  The control value is a string of the following form:
  • controlValue ::= ownObjOpt [ newOwner]
  • ownObjOpt ::= *NODLT / *DLT / *CHGOWN
  The ownObjOpt control value specifies the action to be taken if the user profile owns any objects. The value of *NODLT indicates not to delete the user profile if the user profile owns any objects. The *DLT value indicates to delete the owned objects and the *CHGOWN value indicates to transfer ownership to another profile.

  The newOwner value specifies the profile to which ownership is transferred. This value is required when ownObjOpt is set to *CHGOWN.

  Examples of the control value are the following:

  • *NODLT: specifies that the profile cannot be deleted if it owns any objects
  • *CHGOWN SMITH: specifies to transfer the ownership of any objects to the SMITH user profile.
• The object identifier (OID) is defined in ldap.h as LDAP_OS400_OWNOBJOPT_CONTROL_OID.
  • os400-dltusrprf-pgpopt                   1.3.18.0.2.10.9
    

    The control value is defined as a string of the following form:

    controlValue ::=pgpOpt [   newPgp [   newPgpAut ] ]
    pgpOpt ::= *NOCHG / *CHGPGP
    newPgp ::= *NONE / user-profile-name
    newPgpAut ::= *OLDPGP / *PRIVATE / *ALL / *CHANGE / *USE / *EXCLUDE
    

    The pgpOpt value specifies the action to be taken if the profile being deleted is the primary group for any objects. If *CHGPGP is specified, newPgp must also be specified. The newPgp value specifies the primary group profile name or *NONE. If a new primary group profile is specified, the newPgpAut value can also be specified. The newPgpAut value specifies the authority to the objects that the new primary group is given.

  Examples of the control value are the following:
  • *NOCHG: specifies that the profile cannot be deleted if it is the primary group for any objects.
  • *CHGPGP *NONE: specifies to remove the primary group for the objects.
  • *CHGPGP SMITH *USE: specifies to change the primary group to the SMITH user profile and to grant *USE authority to the primary group.
  If either of these controls is not specified on the delete, the defaults currently in effect for the QSYS/DLTUSRPRF command are used instead.

ModRDN

You cannot rename projected user profiles because this is not supported by the operating system.

Import and Export APIs

The QgldImportLdif and QgldExportLdif APIs do not support importing or exporting data within the system projected backend.