LDAP operations
Understand what LDAP operations can be performed on the projected backend.
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.
- 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.
Table 1. System projected backend behavior for search operations Search requested Search base Search scope Search filter Comments Return information for os400-sys=SystemA, (optionally) for the containers under it, and (optionally) for the objects in those containers. os400-sys=SystemA.acme.com base, sub, or one objectclass=* objectclass=os400-root objectclass=container objectclass=os400-usrprf Return the appropriate attributes and their values based on the scope and filter specified. Hardcoded attributes and their values are returned for the system objects' suffix and the container under it. Return all user profiles. cn=accounts, os400-sys=SystemA.acme.com one or sub os400-gid=0 Only the distinguished name (DN), objectclass, and os400-profile values are returned for projected user profiles. If any other filter is specified, LDAP_UNWILLING_TO_PERFORM is returned. Return all group profiles. cn=accounts, os400-sys=SystemA.acme.com one or sub (!(os400-gid=0)) Only the distinguished name (DN), objectclass, and os400-profile values are returned for projected user profiles. If any other filter is specified, LDAP_UNWILLING_TO_PERFORM is returned. Return all user and group profiles. cn=accounts, os400-sys=SystemA.acme.com one or sub os400-profile=* Only the distinguished name (DN), objectclass, and os400-profile values are returned for projected user profiles. If any other filter is specified, LDAP_UNWILLING_TO_PERFORM is returned. Return information for a specific user or group profile such as the user profile JSMITH. cn=accounts, os400-sys=SystemA.acme.com one or sub os400-profile=JSMITH Other attributes to be returned can be specified. Return information for a specific user or group profile such as the user profile JSMITH. os400-profile=JSMITH, cn=accounts, os400-sys=SystemA.acme.com bas, sub, or one objectclass=os400-usrprf objectclass=* os400-profile=JSMITH Other attributes to be returned can be specified. Even though a scope of one level can be specified, the search results would return no values because there is nothing below the user profile JSMITH in the DIT. Return all user and group profiles starting with A. cn=accounts, os400-sys=SystemA.acme.com one or sub os400-profile=A* Only the distinguished name (DN), objectclass, and os400-profile values are returned for projected user profiles. If any other filter is specified, LDAP_UNWILLING_TO_PERFORM is returned. Return all group profiles starting with G. cn=accounts, os400-sys=SystemA.acme.com one or sub (&(!(os400-gid=0)) (os400-profile=G*)) Only the distinguished name (DN), objectclass, and os400-profile values are returned for projected user profiles. If any other filter is specified, LDAP_UNWILLING_TO_PERFORM is returned. Return all user profiles starting with A. cn=accounts, os400-sys=SystemA.acme.com one or sub (&(os400-gid=0) (os400-profile=A*)) Only the distinguished name (DN), objectclass, and os400-profile values are returned for projected user profiles. If any other filter is specified, LDAP_UNWILLING_TO_PERFORM is returned.
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.9The 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 / *EXCLUDEThe 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.
Parent topic:
Operating system projected backend
Related concepts
Enterprise Identity Mapping (EIM)