SDBM operational behavior
Table 1 shows how SDBM behaves during different LDAP operations.
Target DN | LDAP operation behavior |
---|---|
suffixDN |
|
profiletype=User,suffixDN |
|
profiletype=Group,suffixDN |
|
profiletype=Facility,suffixDN |
|
cn=setropts,suffixDN |
|
profiletype=Connect,suffixDN |
|
racfid=XYZ111,profiletype=User,
suffixDN |
|
racfid=GRP222,profiletype=Group,
suffixDN |
|
racfuserid=XYZ111+racfgroupid=GRP222,
profiletype=Connect,suffixDN |
|
profilename=ABC.RES,profiletype=Facility,
suffixDN |
|
If LDAP is running with an SDBM backend, the ldap_modify and ldap_add APIs can return LDAP_OTHER or LDAP_SUCCESS and completed a partial update to an entry in RACF. The results match what occurs if the update is done by using the RACF ALTUSER, ALTGROUP, CONNECT, RALTER, and PERMIT commands. If several RACF attributes are being updated and one of them is in error, RACF might still update the other attributes, without, in some cases, returning an error message. If there is a RACF message, LDAP always returns it in the result.
This is further complicated when adding or modifying a general resource profile because this can involve multiple RACF commands: a RDEFINE or RALTER command followed by one or more PERMIT commands. If one of the commands fails, processing ends but the resource profile is still updated with the results of the prior successful commands.
- When adding a connection entry that exists, the entry is modified using the specified attributes. There is no indication returned that the entry existed.
- When modifying a connection entry that does not exist, the entry is added using the specified attributes. There is no indication returned that the entry did not exist.
- In LDAP, the format of the value of the Kerberos principal name attribute,
krbPrincipalName, is userid@realm. In SDBM,
the userid portion of the name is case-sensitive while the
realm portion of the name is not. However, the entire attribute value is
processed as case-sensitive in a compare operation. In addition, SDBM only operates on the RACF local realm. If the realm specified in the value is not the
local realm, the operation fails. For example, when searching in SDBM for a user entry using the
search filter
krbPrincipalName=krbuser1@MYREALM.COM
, the search fails ifMYREALM.COM
is not the RACF local realm.To facilitate using the krbPrincipalName attribute, the attribute value can be specified without the @realm portion. In this case, the realm is assumed to be the RACF local realm. For example, when adding a user entry withkrbuser1
as the userid portion of that Kerberos principal name, the krbPrincipalName attribute can be specified as
orkrbPrincipalName: krbuser1
wherekrbPrincipalName: krbuser1@MYREALM.COM
MYREALM.COM
is the RACF local realm.The krbPrincipalName value returned by SDBM from a search is always the complete principal name, userid@realm, where realm is the RACF local realm.
- There are several SDBM attributes whose value is a RACF
user, group, or class name. For convenience, this value can be specified either as just the RACF name or as the complete LDAP DN. For example, when adding a
user with a default group of
grp222
, the racfDefaultGroup attribute can be specified as
orracfDefaultGroup: grp222
whereracfDefaultGroup: racfid=grp222,profiletype=group,sysplex=myplex
sysplex=myplex
is the SDBM suffix.The value returned by SDBM from a search is always the complete LDAP DN.
- For multi-value attributes, the RACF ALTUSER and RALTER
commands do not always support the ability to both add a value and replace the existing value. As a
result, SDBM does not always respect the type of modification (add versus replace) that is specified
in a modify command.
- Values for the following multi-value attributes are always added to the existing value (even if
replace is specified):
racfAttributes, racfAudit, racfClassAct, racfClassName, racfConnectAttributes, racfGenCmd, racfGeneric, racfGenList, racfGlobal, racfLevelKeyword, racfLogonDays, racfLogOptionsAlways, racfLogOptionsDefault, racfLogOptionsFailures, racfLogOptionsNever, racfLogOptionsSuccessess, racfMemberList, racfMFAFactor, racfMFAPolicy, racfMformKeyword, racfMonitorKeyword, racfRacList, racfResourceAttributes, racfSecurityCategoryList, racfSetroptsAttributes, racfStatistics, racfVolumeList
. - Values for the following multi-value attributes always replace the existing value (even if add
is specified):
racfCdtinfoFirst, racfCdtinfoOther, racfDlfdataJobNames, racfDomains, racfIcsfSymExportCerts, racfIcsfSymExportKeys, racfMfpolicyFactors, racfMscopeSystems, racfNetviewOperatorClass, racfOperatorClass, racfResourceAudit, racfResourceGlobalAudit, racfRoutcodeKeyword, racfRslKey, racfTslKey
. - Values for the following multi-value attributes either are added to the existing values or
replace the existing values, depending on the new and existing values:
racfAuthKeyword, racfAccessControl, racfIcsfAsymUsage, racfMFAFactorStatus, racfMFAFactorTags
.
For single-value attributes, there is no difference between using an add modification or a replace modification to set the value. For either type of modification, the value is added if the attribute value does not exist and the value replaces the existing attribute value, if there is one.
- Values for the following multi-value attributes are always added to the existing value (even if
replace is specified):
- In order to update attributes related to CICS®, CICS must be set up on your system; otherwise, errors result.
- For modify, if a request is made to delete a specific attribute value for an attribute where
specific values cannot be selectively deleted, an LDAP_UNWILLING_TO_PERFORM error code is returned.
Similarly, if a request is made to delete the entire attribute for an attribute where specific
values to delete must be specified, an LDAP_UNWILLING_TO_PERFORM error code is returned.
The following attributes require that specific values deleted be specified:
racfAudit, racfClassAct, racfClassName, racfGenCmd, racfGeneric, racfGenList, racfGlobal, racfMemberList, racfMFAFactorTags, racfRacList, racfStatistics, racfVolumeList
.The following attributes allow specifying specific values to delete but also support deleting the entire attribute:
racfAccessControl, racfAttributes, racfConnectAttributes, racfMFAFactor, racfMFAPolicy, racfResourceAttributes, racfSecurityCategoryList, racfSetroptsAttributes
.All other attributes that have a delete command in RACF only allow deleting the entire attribute. If an attempt is made to delete any attribute that has no corresponding delete command in RACF, an LDAP_UNWILLING_TO_PERFORM error code is returned.
- The racfCopyProfileFrom attribute is used to specify any combination of the RACF RDEFINE FCLASS, FGENERIC, FROM, and FVOLUME keywords and
values to indicate a resource profile to use as a model when creating a new resource profile. The
value that is specified for this attribute must be syntactically correct for an RDEFINE command and
is inserted as is in the command. For example, the following uses the RES.MODEL resource profile in
the FACILITY class as a
model:
racfcopyprofilefrom: FROM(RES.MODEL) FCLASS(FACILITY)
- The racfAccessControl attribute is used to manage the access control lists for
a general resource profile. Each attribute value is used to create a separate RACF
PERMIT command. Each value must be a syntactically correct RACF PERMIT command, without the class and profile names. SDBM adds the class
and profile names before issuing the RACF PERMIT command. It
also adds the DELETE keyword for a modify request to delete the value.Note: When issuing multiple RACF PERMIT commands for the same resource, the order of the PERMIT commands can be critical. SDBM issues a PERMIT command for each racfAccessControl value in the order that SDBM receives the values. If you specify multiple add, replace, and delete changes to an attribute in a single modify operation, many ldapmodify utilities (including the z/OS® client ldapmodify utility) might reorder the changes to put all the changes of the same type together. Therefore, the values as presented to SDBM might not be in the original order and the results of the PERMIT commands might not be as you want. To avoid this, separate different racfAccessControl attribute changes into separate modify operations.When LDAP returns the racfAccessControl value during a search operation, the value might contain the COUNT field if this is part of the RACF output, for example:
racfaccesscontrol: ID(X) ACCESS(READ) COUNT(5)
If SDBM finds the COUNT field in a racfAccessControl value during an add or modify operation, the field is removed from the value before the value is used to generate a RACF PERMIT command. This allows LDAP search output to be used as add or modify input.
When you are using the racfAccessControl attribute in a compare operation, the comparison is done only on the value that is specified for the ID keyword within the attribute value. The rest of the attribute value is not used. If the ID value is contained in any access control list within the resource profile, the compare returns LDAP_COMPARE_TRUE. If the attribute value does not have the ID keyword, has more than one ID value, or the value is not contained in any access list within the resource profile, compare returns LDAP_COMPARE_FALSE. Basically, a racfAccessControl compare operation can be used to determine if a specific RACF user or group appears in the access control lists within a resource profile.
- The following attributes are only PERMITted on the RACF ALTUSER command, not the ADDUSER command. As a result, SDBM only supports
these attributes on a modify request: racfMFAFactor,
racfMFAFactorStatus, racfMFAFactorTags,
racfMFAPolicy, and racfMFAPWFallback.
In LDAP, the format of the value of racfMFAFactorStatus is factorname:status.
The format value of racfMFAFactorTags is factorname:tagname:tagvalue.
The
racfMFAPWFallback
field is part of theUser Base
and is defined in RACF with a default value. If it is queried in SDBM, this attribute is returned to LDAP, whether or not any other MFA field has been set.The factorname portion indicates the factor that is manipulated. Only one factor can be manipulated in a single RACF ALTUSER command, and therefore, on a single modify request. For example, the MFA-related attributes can be specified as follows:racfMFAFactor: factor01 racfMFAFactorStatus: factor01:active racfMFAFactorTags: factor01:tag1:abc racfMFAFactorTags: factor01:tag2:def racfMFAPWFallback: nopwfallback racfMFAPolicy: pol01 racfMFAPolicy: pol02
The following example can be used to delete one specific tag from the factor,factor01
:changetype: modify delete: racfMFAFactorTags racfMFAFactorTags: factor01:tag1
The following example can be used to delete all tags from the factor,factor01
:changetype: modify delete: racfMFAFactorTags racfMFAFactorTags: factor01:
You can also delete the entire attribute,
racfMFAFactor
, which removes all existing tags and status from a user's profile.