LDAP Directory Services

1
acf2src
1
X.500 Directories are an integral part of corporate network infrastructures. They allow for the storing and retrieval of data that needs to be centrally located in the company. User information such as email address, office or cube number, and phone extensions are just some of the items that others in the company need to access.
Not only is more and more data Uniform Resource Locator being stored and accessed from directories, more applications are use this information rather than keeping their own copies. These applications are also being extended to authenticate user IDs and passwords to these directories to provide a centralized password repository. CA ACF2 can be utilized as this central repository.
When you want to host the repository on a platform other than the mainframe or to use a repository other than CA ACF2, an issue that needs to be resolved is how to synchronize the data between the CA ACF2 security database and this other repository.
For transmitting the data from the other platform to the mainframe, the CA LDAP provides the interface that the other platform can use to send changes to CA ACF2. For transmitting the data from the mainframe to the other repository, a built-in feature named LDAP Directory Services (LDS) allows CA ACF2 to interface with and transmit data to the remote repository. Unlike other products and services that use pull technology on a scheduled basis; this proactive approach pushes the change as it occurs, providing a real-time update of the changed data.
How LDAP Works
LDS uses the LDAP protocol and native TCP/IP to communicate the changes to the remote repository. Servers enabled with Secure Sockets Layer (SSL) technology protect unauthorized parties from viewing sensitive information during a secure session. Using the XREF mapping record, you configure which LID fields are to be sent to the remote repository and what the remote attribute name is.
Even though the field names in CA ACF2 do not match to the remote directory attribute names, using this mapping table allows for integration with anything that supports the LDAP protocol. This setup eliminates the need for specialized interfaces designed for a specific product.
When CA ACF2 uses LDS to connect to the remote LDAP directory, it is the client application to the remote LDAP Server. Using the standard LDAP protocol, CA ACF2 formats the add, modify, or delete request and sends it to the remote LDAP Server through native TCP/IP. This remote directory can be anything that supports LDAP APIs.
How Does LDS Work
This sample implementation shows how CA ACF2 uses LDS to connect to a remote LDAP directory. When it does so, it is the client application to the remote LDAP Server. Using the standard LDAP protocol, CA ACF2 formats the add, modify, or delete request and sends it to the remote LDAP Server through native TCP/IP.
TCP/IP and SSL
CA ACF2 LDS uses TCP/IP to propagate packets of information in clear text data over the internet and other TCIP/IP networks to LDAP servers that are listening. CA ACF2 supports SSL technology and allows an SSL-enabled LDAP server to authenticate itself to CA ACF2 and CA ACF2 to authenticate itself to the SSL-enabled LDAP server. Highly sensitive information, such as passwords, are protected if your site chooses to exploit SSL technology.
Records Summary
Each record has a unique set of fields. These predefined record Ids are listed in the following table, together with their basic functions.
Record ID
Function
OPTIONS
Defines global LDS options available
LDAP
Contains LDAP server information
XREFLDAP
Allows mapping of LDAP attributes to CA ACF2 logonid fields
Valid Commands
Administrative commands that INSERT, CHANGE, and DELETE logonid fields are eligible for LDS, including password changes during system entry validation. Only logonid fields that are mapped to an LDAP directory server can be sent by LDS. All other CA ACF2 data such as infostorage records, resource rules, and access rules are not eligible for LDS and are not transmitted to remote LDAP servers.
Only fields specified on the command line may be transmitted to the LDAP server using LDS. If a model USING logonid is specified on an INSERT command, the logonid fields copied directly from the model logonid are not eligible to be pushed out to the LDAP server unless explicitly specified on the INSERT command. For more information, see the XREF field in Control LDS LDAP Record.
LDS is not a synchronization facility for multi-valued field data. For example, if in a CHANGE command a REPLACE is issued for a multi-valued field, LDS notifies the LDAP directory server of the specific values INSERTED or DELETED from the multi-valued field list. If the data between the mapped multi-valued fields are not synchronized before the LDS update, it may remain as such. Therefore, a CHANGE request for a logonid field that contains multiple values may result in different values for the multi-valued field on the mapped LDAP directory entry.
The Control GSO OPTS record defines global options available to CA ACF2. The LDS parameter on the Control GSO OPTS record indicates that the LDS interface can be used.
Modify the Control GSO OPTS Record
To change the Control GSO OPTIONS record to include LDS, use the following commands:
ACF ACF SET CONTROL(GSO) CHANGE OPTS LDS
Refresh the Control GSO OPTS Record
To refresh the Control GSO OPTS record, use the following operator command:
F ACF2,REFRESH(OPTS),TYPE(GSO)
Password and Password Phrase Considerations
Administrative commands that INSERT, CHANGE, and DELETE User Profile PWPHRASE record fields are also eligible for LDS. These fields include PWPHRASE, PWP-EXP, and PWP-MAXD which must be mapped in the XREF field of the LDAP or XREFLDAP record to LDAP attributes on the LDAP server. CA ACF2 issues a separate LDAP modify request to ADD, REPLACE, or DELETE the password phrase fields only if the user associated with the PWPHRASE profile record is defined to the system.
Control LDS Records
The following sections explain how to create, modify, refresh, LDS records. It also describes how to start and stop LDS.
Control LDS OPTIONS Record
The Control LDS OPTIONS record defines global system options available to LDS. It also specifies the name of an outbound journal file and an attribute that specifies whether the journal process begins when LDS starts.
When LDS starts and DEBUG is indicated on the options record, CA ACF2 spins off diagnostic output logs to the following DDNAMEs: CEEDUMP, SYSOUT, SYSPRINT, STDERR, and SYDOUT. The sysout class and destination for the diagnostic log output are specified by SYSCLASS and SYSDEST field respectively.
The diagnostic output logs and the LDS Journal are dynamically allocated and opened by CA ACF2 and should not be overridden in the started procedure.
Record ID
Fields
OPTIONS
DATASET(
journal file data set name
)
DEBUG|NODEBUG
JOURNAL|NOJOURNAL
LDSRCVR(
recovery file data set name
)
LDSRING(
keyring ringname
)
RECOVERY|NORECOVERY
RETRY(
nn
)
SYSCLASS(A
|class
)
SYSDEST(LOCAL
|destination
)
TIMEOUT(30
|sss
)
  • DATASET(
    journal file data set name
    )
    Defines the name of the journal file that contains the loggings of the LDS requests. The data set must be predefined and cataloged. Use the supplied INITLDSJ job in the CAX1JCL0 library to create the LDS journal files
  • DEBUG|
    NODEBUG
    Specifies that diagnostic messaging is captured during processing to the LDAP server and directed to the CA ACF2 started task SYSOUT. The default is NODEBUG.
    If option NODEBUG is selected or defaulted, no debug tracing occurs. If DEBUG is selected, tracing occurs for those nodes whose Control LDS LDAP records also specify DEBUG. If the node's Control LDS LDAP record specifies or defaults to NODEBUG, no tracing occurs for the node, regardless of the DEBUG setting on the Control LDS Options record. Changes to the debug setting on the Options record are not effective until the Options record is refreshed, LDS is stopped and restarted, or CA ACF2 is stopped and restarted.
  • JOURNAL|
    NOJOURNAL
    Specifies whether the LDS Journal processing is started when LDS starts. The use of the LDS journal file is optional. You can choose to run without the journal file by setting the NOJOURNAL attribute on the Control LDS OPTIONS record. The specification here is a global setting. If you specify the JOURNAL option on the Control LDS LDAP record, you can control journaling for each server. The default is NOJOURNAL.
  • LDSRCVR(
    recovery file data set name
    )
    Specifies the name of the file used by the LDS recovery process at LDS initialization. It is a 44-byte character data set name. The LDS recovery file is created, initialized, and catalogued before starting the LDS recovery processing. You may use the supplied INITLDSR job in the CAX1JCL0 library to create the LDS recovery file.
    You must specify a different ACFRCVR data set for each system (LPAR) which runs LDS. The recovery file CANNOT be shared between concurrently active systems.
  • LDSRING(
    keyring ringname
    )
    Specifies the ring name of the KEYRING record to which the CERTAUTH and PERSONAL certificate information for LDS processing is obtained. The userid associated with the KEYRING record must be ACF2. The ringname can be up to 237 characters in length.
    This field is only valid when establishing SSL connections.
  • RECOVERY
    |NORECOVERY
    Specifies that LDS recovery processing is enabled at LDS initialization. LDSRCVR must also be specifies for recover to be enabled. The default is RECOVERY.
  • RETRY(
    nn
    )
    Indicates the number of consecutive, unsuccessful attempts to deliver an LDS command to an ACTIVE LDAP server before the LDAP node is DEACTIVATED by CA ACF2. Valid values are 1 through 10. The default is 3.
    When an LDAP node exceeds the RETRY and TIMEOUT limits indicated in the GSO OPTS record, LDS DISCONNECTs from the LDAP server. Issue the LDS SHOW command to display the STATUS of the LDAP nodes in the system.  If the STATUS is DISCONNECTED, you must issue the operator command 'F ACF2,LDS(ACTIVE),LDAPNODE(ldapnode)' to re-establish a connection handle to the LDAP server.
  • SYSCLASS(
    A
    |class
    )
    Specifies the JES SYSOUT class for diagnostic log output. SYSCLASS is a 1-byte character alphanumeric field. This option cannot be refreshed and can only be activated at LDS startup. The default value is A.
  • SYSDEST(
    LOCAL
    |
    destination
    )
    Specifies the JES SYSOUT destination for diagnostic log output. SYSDEST is a 1-8 byte character field consisting of alphanumeric or national characters. This option cannot be refreshed and can only be activated at LDS startup. The default value is LOCAL.
  • TIMEOUT(
    30
    |sss
    )
    Indicates the number of seconds that CA ACF2 waits to receive a response from the LDAP server before the LDAP request is timed out. Valid values are 1 through 999. The default is 30 seconds.
    When an LDAP node exceeds the RETRY and TIMEOUT limits indicated in the GSO OPTS record, LDS will DISCONNECT from the LDAP server. Issue the LDS SHOW command to display the STATUS of the LDAP nodes in the system.  If the STATUS is DISCONNECTED, you must issue the operator command 'F ACF2,LDS(ACTIVE),LDAPNODE(ldapnode)' to re-establish a connection handle to the LDAP server.
    A refresh of the LDS OPTIONS record is automatically issued during LDS initialization. You may issue a refresh of the LDS OPTIONS record at any time LDS is active but only DEBUG, RETRY, and TIMEOUT are updated.
Create the Control LDS OPTIONS Record
Use the following commands to create the control LDS OPTIONS record:
ACF SET CONTROL(LDS) SYSID(TEST) CONTROL insert options journal dataset(caldap.ldsjrnl) recovery ldsrcvr(caldap.ldsrcvr) debug timeout(15) TEST / OPTIONS LAST CHANGED BY ADMIN01 ON 01/31/04-16:46 DATASET(CALDAP.LDSJRNL) DEBUG JOURNAL LDSRCVR(CALDAP.LDSRCVR) RECOVERY RETRY(3) LDSRING()SYSCLASS(A) SYSDEST(LOCAL) TIMEOUT(15) CONTROL
Refresh the LDS LDAP Record
The LDAP refresh process builds the LDAP record table with Control LDS LDAP and Control LDS XREFLDAP records. LDAP records must meet the following criteria to propagate logonid changes to networked LDAP servers:
  • LDAP records must be ACTIVE with the INSERT, CHANGE, or DELETE command indicated to propagate logonid administration. If INSERT or CHANGE is specified on the Control LDS LDAP record, the XREF field data must be specified for information to be propagated.
  • If the NEXTKEY field is specified on the Control LDS LDAP or Control LDS XREFLDAP record, the Control LDS XREFLDAP record with the qualifier specified in the NEXTKEY field must exist.
  • The NEXTKEY field can chain a maximum of twenty-five different Control LDS XREFLDAP records to a single Control LDS LDAP record. NEXTKEY field values reference Control LDS XREFLDAP records and cannot be duplicated in the sequence.
To activate the LDAP directories and refresh the Control GSO LDAP and Control LDS XREFLDAP records, issue the following command:
F ACF2,REFRESH(LDAP),TYPE(LDS)
The REFRESH command works only when the LDS facility has been activated.
LDS Journal
LDS uses the journal file to provide a historical record of outbound LDAP requests to LDAP servers. LDS uses one journal file for outbound requests to all LDAP servers. All requests and corresponding messages are journaled.
The LDS journal file is defined in the Control LDS OPTIONS record in the DATASET parameter. The journal file must be created, cataloged, and initialized before starting the LDS journal processing. Use the supplied INITLDSJ job in the CAX1JCL0 library to create the LDS journal files. The number of journal entries written to the LDS journal is limited by the size of the file. When the journal file becomes full, the LDS journal wraps to the top of the file and overwrites older journal entries.
The data set is dynamically allocated by CA ACF2. Do not add it to the started procedure.
The use of LDS journal file is optional. You can choose to run without the journal file by setting the NOJOURNAL attribute on the LDS OPTIONS record or you may specify the NOJOURNAL option on the LDS LDAP RECORD. You may start and stop the journal file processing at any time as long as LDS is active.
Start and Stop the LDS Journal
Start the LDS journal when LDS is active:
F ACF2,LDS(JOURNAL)
Stop the LDS journal when LDS is active:
F ACF2,LDS(NOJOURNAL)
LDS STATUS
Verify if LDS is active:
F ACF2,LDS(STATUS)
The following messages appear:
  • ACF79919 - LDS active
  • ACF79904 - LDS not active
LDS Recovery
LDS uses the recovery file to store LDS request data for each defined LDAP server in the network. If an LDAP server fails to communicate with LDS due to the LDAP server being down, exceeding the configured time-out or a busy condition, LDS requests are saved in the recovery file for later transmission. As transaction data is processed, the data is removed from the recovery file and written to the LDS journal file if LDS JOURNAL is active.
To activate LDS recovery at LDS startup, the RECOVERY parameter must be indicated and the LDSRCVR parameter must specify a valid LDS recovery file on the LDS OPTIONS record. The recovery file must be created, cataloged, and initialized before starting LDS. Use the supplied INITLDSR job in the CAX1JCL0 library to create the LDS recovery file. The number of recovery entries written to the LDS recovery file is limited by the size of the file. When the recovery file becomes 80% full and 100% full, a message is displayed on the operator console. The LDS recovery file does not wrap to the top of the file and overlay older data. When the recovery file becomes full, transaction data can no longer be saved on the recovery file
The use of the LDS recovery file is optional. You can choose to run without the recovery file by setting the NORECOVERY option on the LDS OPTIONS record. Recovery can only be activated at LDS initialization.
The data set is dynamically allocated by CA ACF2. Do not add it to the started procedure.
Removing LDS Recovery File Records
To delete LDS Recovery Records from the LDS Recovery File by LDAPNODE or a given date, enter the following command:
F ACF2,LDS(REMOVE), LDAPNODE(LDAP.xxxxxxxx), UNTIL(date)
The UNTIL parameter must be a valid date in the default date format specified by the CA ACF2 options. The LDAPNODE parameter must indicate the complete LDS LDAP Record ID including suffix, for example:
F ACF2,LDS(remove), LDAPNODE(ldap.test), UNTIL(01/01/04)
You may specify LDAPNODE and UNTIL parameters, but at least one must be indicated. Also, LDS must be active for this command to be accepted.
LDSRPT Report
The LDSRPT report lists all LDS requests stored in the LDS Recovery File. LDS recovery retrieves records containing information pertaining to administrative commands that INSERT, CHANGE, and DELETE logonid fields as well as password changes that are eligible for LDS processing. There are no REPORT parameters for this program.
Sample JCL
The following is sample JCL to run the LDSRPT report:
//LDSRPT EXEC PGM=CAS4LRPT //STEPLIB DD DSN=CAI.CAILIB,DISP=SHR //LDSRCVR DD DSN=CALDAP.LDSRCVR,DISP-SHR //SYSPRINT DD SYSOUT=*
Sample LDSRPT Report Output
The report title displays the date and time the report was generated. The report summary displays the total number of LDS recovery records on the LDS Recovery File. The following is a sample of the LDSRPT report output.
04.182) TIME 12.33 - <acf> Security LDS Recovery Report - PAGE 1 Date Time LDAP Node ID User LDS Recovery Data 2004121 153451 LDAP.LISLE2 LDSETA2 INS LID(LDSETA2 ) OBJECTCLASS(ACF2LID), ADD Name(1534 ), ADD objectclass(AC 2004121 153451 LDAP.LISLE2 LDSETA2 F2LID) 2004121 154026 LDAP.LISLE2 LDSETA2 DEL LID(LDSETA2 ) OBJECTCLASS(ACF2LID) 2004121 160905 LDAP.LISLE2 LDSETA1 MOD LID(LDSETA1 ) OBJECTCLASS(ACF2LID), REP Name(1608 ) 2004121 162455 LDAP.LISLE2 LDSETA3 MOD LID(LDSETA3 ) OBJECTCLASS(ACF2LID), REP Name(1624 ) 2004121 162936 LDAP.LISLE2 LDSETA2 INS LID(LDSETA2 ) OBJECTCLASS(ACF2LID), ADD Name(THIRD ), ADD objectclass(AC 2004121 162936 LDAP.LISLE2 LDSETA2 F2LID) DATE 06/30/04 (04.182) TIME 12.33 - <acf> Security LDS Recovery Report - PAGE 2 - Total number of LDS records processed is 05
Control LDS LDAP Record
The Control LDS LDAP record defines the LDAP servers in the network and information required to appropriately communicate logonid administrative changes.
Information required to write, update, or delete entries in the LDAP directory is defined in the LDS LDAP record. This information includes:
  • Administrator distinguished name (DN)
  • Administrator password
  • URL of the LDAP server
  • Name of the objectClass of the entry on the LDAP directory
  • Command type of logonid administration
  • Map of the LDAP attributes to CA ACF2 logonid record fields
  • Additional options
Record ID
Fields
LDAP.
qualifier
ACTIVE|NOACTIVE
ADMINDN
(LDAP administrator distinguished name
)
ADMPSWD (
LDAP administrator password
)
APPLNAME (
application name
)
BITDEFLT (
character/YN
|
field type/format
)
BROADCST|NOBROADCST
CHANGE|NOCHANGE
CODEPAGE(
character
)
DATEFMT(
date format
|MMDDYYYY)
DEBUG|NODEBUG
DELCHILD|NODELCHILD
DELETE|NODELETE
INSERT|NOINSERT
JOURNAL|NOJOURNAL
LDSLABEL(
certificate label
)
LDAPINST(
AttributeName/AttributeValue/AttributeType,…)
NEXTKEY(
qualifier of next LDS LDAP record
)
OBJCLASS(
LDAP objectClass
)
PSWDASIS|NOPSWDASIS
PSWDLOWR|
NOPSWDLOWR
URL(
Uniform Resource Locator
)
USEEXTOP|NOUSEEXTOP
USERDNS(
User Distinguished Name syntax
)
XREF(
LIDfield1/LDAPattribute1Name/
LDAPattribute1FieldType/
LDAPattribute1DataFormat/LDAPattribute1Length, …
)
  • LDAP.qualifier
    Must be 1 to 8 characters long. The period is required.
  • ACTIVE|
    NOACTIVE
    Indicates the LDAP record is active and communication with the LDAP server specified is attempted. To activate an LDAP record, INSERT, CHANGE, or DELETE must also be specified. The default is NOACTIVE.
  • ADMINDN(
    LDAP administrator distinguished name
    )
    Indicates the LDAP administrator distinguished name used for binding to the LDAP server and administering the LDAP request. This field is required. The following examples indicate the string substitutions that are allowed for this field:
Symbolic
String Substitution
%N
Substitutes the administrator's name (20 bytes) from the administrator's LID record
%L
Substitutes the administrator's logonid (8 bytes) from the administrator's LID record
Note the following behaviors:
  • If there are embedded spaces or commas in the ADMINDN, enclose the entire string in single quotes.
  • The LDAP administrator password or the APPLNAME field must be specified. Each LDAP request requires an administrator distinguished name and a password. There are two ways of providing the password:
Specify the administrator password in the Control LDS LDAP record.
Identify the administrator and the SSIGNON profile data record used for generating PassTickets by specifying the APPLNAME in the Control LDS LDAP record.
  • ADMPSWD(
    LDAP administrator password
    )
    Indicates the LDAP administrator password used with the ADMINDN for binding to the LDAP server. This field cannot be modeled. This field is 128 bytes long and allows mixed-case characters.
  • APPLNAME(
    application name
    )
    Specifies the application name of the SSIGNON profile data record that contains the administrator's encryption key used for generating PassTickets. The administrator's userid is used with the PassTicket for binding to the LDAP server and administering the LDAP request.
    You should not specify an APPLNAME in the LDAP record unless you also specify a %N or %L symbolic in the ADMINDN field. Specifying an APPLNAME with a hard-coded ADMINDN results in a PASSTICKET generation failure and subsequent bind failure when attempting to connect to the target node at LDS startup.
  • BITDEFLT(
    field type/format|
    character/YN
    )
    Indicates the default field type and format for bit fields specified in the XREF field that is sent to the LDAP server.
    When a logonid bit field is turned off and the FLAGS attribute specifies NEVER, LIMIT or NULL in the ACCFDR @CFDE macro definition, LDS interprets this condition as a DELETE function of the bit field rather than a REPLACE. The default for this field is CHARACTER/YN.
    Available options are:
Options
BINARY/01
Binary 1 or 0 when the bit is ON or OFF, respectively
BINARY/REV01
Binary 0 or 1 when the bit is ON or OFF, respectively
CHARACTER/01
1 or 0 when the bit is ON or OFF, respectively
CHARACTER/REV01
0 or 1 when the bit is ON or OFF, respectively
CHARACTER/YN
Y or N when the bit is ON or OFF, respectively
CHARACTER/REVYN
N or Y when the bit is ON or OFF, respectively
CHARACTER/TF
T or F when the bit is ON or OFF, respectively
CHARACTER/REVTF
F or T when the bit is ON or OFF, respectively
This default can be overridden per bit field specified in the XREF parameter.
  • BROADCST|
    NOBROADCST
    Specifies to capture all logonid administrator commands that are indicated for this LDAP record (for example, INSERT, CHANGE, and DELETE) regardless if the LID record affected is flagged for LDS propagation. The default is NOBROADCST.
  • CHANGE|
    NOCHANGE
    Specifies that command LID change processing is propagated to the LDAP server. The default is NOCHANGE.
  • CODEPAGE(
    character
    )
    Indicates a twenty byte character field to specify which character encoding table is to be used to translate characters as they are passed into the system. If no CODEPAGE is specified, EBCDIC IBM-1047 is assumed.
  • DATEFMT(
    date format
    |
    MMDDYYYY
    )
    Indicates the default format for date fields specified in the XREF field. Valid date formats are MMDDYYYY, DDMMYYYY, YYYYMMDD, MMDDYY1, DDMMYY1, and YYMMDD1.
    For example:
    • MM
      Represents a two-digit month.
    • DD
      Represents a two-digit day.
    • YY
      Represents a two-digit year.
    • YYYY
      Represents a four-digit year.
    • Number 1
      Represents a '/' (forward slash) delimiter in the date field.
    The default date format is MMDDYYYY. Year designations of 70-99 assume a date in the 20th century (1970-1999); year designations of 00-69 assume a date in the 21st century (2000-2069).
    For example, if the ACTIVE date for the logonid record is April 7, 2001, the date field is converted to the following formats:
DATEFMT
Format Example
MMDDYYYY
04072001
DDMMYYYY
07042001
YYYYMMDD
20010407
MMDDYY1
04/07/01
DDMMYY1
07/04/01
YYMMDD1
01/04/01
The default date format (MMDDYYYY) can be overridden per date field specified in the XREF parameter. See the XREF field for further information.
  • DEBUG|
    NODEBUG
    Bit Option field turns tracing on during LDS processing to this node. The default is NODEBUG.
  • DELCHILD|
    NODELCHILD
    Bit Option field indicates to delete child objects when a delete command of the base object is issued to this node. The default is NODELCHILD.
  • DELETE|
    NODELETE
    Specifies that CA ACF2 command LID delete processing are propagated to the LDAP server. The default is NODELETE.
  • INSERT|
    NOINSERT
    Specifies that CA ACF2 command LID insert processing is propagated to the LDAP server. The default is NOINSERT.
  • JOURNAL
    |NOJOURNAL
    Specifies that requests to this server are journalled journal is active. The default is JOURNAL.The use of the LDS journal is optional.
  • LDSLABEL(
    certificate label
    )
    Specifies the label of the PERSONAL certificate that is connected to the CA ACF2 LDSRING indicated on the LDS OPTIONS record. The label can be up to 32 characters in length. It can contain blanks and mixed-case characters.
  • LDAPINST(
    AttributeName/AttributeValue/AttributeType,…
    )
    Maps LDAP installation specific information that is appended to all insert and change LDS requests only for this node. This is used when you always need to send an attribute/value pair no matter what was changed or inserted on the LID.
  • NEXTKEY(
    qualifier of LDS XREFLDAP record
    )
    Specifies the qualifier name of the LDS XREFLDAP record that contains more XREF field values to be mapped to this LDAP server. The Control LDS XREFLDAP record provides the capability to define additional CA ACF2 logonid fields and the cross-references to the LDAP attribute names.
  • OBJCLASS(
    LDAP objectClass
    )
    When an INSERT is sent as an LDAP add, this specifies the objectClass of the entry that is to be added to the remote LDAP directory. The maximum length is 24 characters.
  • PSWDASIS
    |NOPSWDASIS
    Indicates the case sensitivity format of the user's password to be propagated, if the password field is specified in the XREF field. If PSWDASIS is specified, the password is sent in the same case as typed by the user or administrator. In this case, the password can consist of mixed-case text. If NOPSWDASIS is specified, the password is propagated in uppercase format. The default is PSWDASIS.
    When a user changes a password during system entry validation, LDS automatically propagates the new password to the LDAP servers interested in the password field. The user receives no indication that LDS processing was involved. LDS must be active and the LDS option must be specified in the logonid record.
  • PSWDLOWR|
    NOPSWDLOWR
    Specifies the case sensitivity format of the user's password to be propagated, if the password field is specified in the XREF field. PSWDLOWR works in conjunction with the PSWDASIS function. When NOPSWDASIS and PSWDLOWR are specified, the password is sent in the lowercase format. In this case, the password consists of all lowercase text. If NOPSWDASIS and NOPSWDLOWR are specified, the password is propagated in uppercase format. The default is NOPSWDLOWR.
    When a user changes a password during system entry validation, LDS automatically propagates the new password to the LDAP servers interested in the password field. The user receives no indication that LDS processing was involved. LDS must be active and the LDS option must be specified in the logonid record.
  • URL(
    Uniform Resource Locator
    )
    Specifies the Uniform Resource Locator (URL) used to identify the LDAP server. There is a maximum of three URL entries allowed. The entries specify the primary followed by the backups. The syntax of the LDAP URL should be as follows:
    ldap://host.domain:port
    or
    ldaps://host.domain:port
    • ldap/ldaps
      Specifies a connection using the LDAP protocol. ‘ldap’ starts an unencrypted connection, where ‘ldaps’ starts an encrypted connection.
    • host.domain
      Specifies the name or IP address of the remote LDAP server. This defaults to localhost.
    • port
      Specifies the port number of the remote LDAP server. This defaults to 389.
  • USEEXTOPT|
    NOUSEEXTOP
    Use this option when a remote LDAP Server does not support the ldaps URL to establish an SSL connection. After configuring the URL with ldap above, enable this option and LDS establishes the unencrypted connection and then try to turn it into an encrypted connection using the LDAP extended operation function call. The default is NOUSEEXTOP.
  • USERDNS(
    User Distinguished Name Syntax
    )
    Indicates the user distinguished name syntax that refers to the entry on the LDAP server where the changes are applied. This is a required field. The maximum length is 254 characters.
    The following table indicates the string substitutions allowed for this field:
    Symbolic
    String Substitution
    %N
    Substitute the user's name (20 bytes) from the user's LID record For example: USERDNS('acf2lid=%N, host=prod, o=company, c=usa')
    %L
    Substitute the user's logonid (8 bytes) from the user's LID record. For example: USERDNS ('acf2lid=%L, host=prod, o=company, c=usa')
    Note: If there are embedded spaces or commas in the USERDNS, enclose the entire string in single quotes.
  • XREF(
    LIDfield1/LDAPattribute1Name/LDAPattribute1FieldType/ LDAPattribute1DataFormat/LDAPattribute1Length, …
    )
    Specifies the names of the CA ACF2 logonid fields and the corresponding LDAP directory attributes to be synchronized to the LDAP directory for insert or change command processing. The XREF field must contain a valid mapping if INSERT or CHANGE is indicated on the LDAP record.
    • LIDfield
      Specifies the external logonid field name from CA ACF2 logonid record that is mapped to the LDAP attribute name on the LDAP directory. For a list of external field names, see Logonid Records.
      Specifying the parameter keyword USING as an XREF LID field allows mapping of the one- to eight-character model logonid on the INSERT subcommand to the LDAP directory server. For example, specifying XREF(LID/Acf2lid, USING/UsingLid,PASSWORD/userPassword) on the LDAP record and the command INSERT USING(OLDLID) NEWLID PASSWORD(SECRET), allows the NEWLID, OLDLID and SECRET values to be mapped to the respective LDAP attribute names Acf2lid, UsingLid and userPassword on the LDAP server. Logonid fields copied directly from the model logonid are not eligible for transmission to the LDAP server unless explicitly specified on the XREF mapping parameter and the INSERT command.
      The LIDfield is a required parameter and must be delimited by a '/' (forward slash).
      The logonid record contains some fields that are used internally by CA ACF2 processing and not modified directly by a security administrator or user. Logonid fields that are not inserted or modified by CA ACF2 command administration or by a user are not supported by LDAP and cannot be specified as an XREF field parameter. These fields include:
      Logonid Field
      Description
      ACC-CNT
      Count of system accesses
      ACC-DATE
      Date of last system access
      ACC-SRCE
      Source of last system access
      ACC-TIME
      Time of last system access
      CSDATE
      Cancel/suspend/mon date
      CSWHO
      User with set cancel/suspend/mon
      HOMENODE
      Node where lid is stored
      PRVPSWD1
      Password history 1
      PRVPSWD2
      Password history 2
      PRVPSWD3
      Password history 3
      PRVPSWD4
      Password history 4
      PRV-TOD1
      Date/Time of PRVPSWD1
      PRV-TOD2
      Date/Time of PRVPSWD2
      PRV-TOD3
      Date/Time of PRVPSWD3
      PRV-TOD4
      Date/Time of PRVPSWD4
      PSWD-SRC
      Password source
      PSWD-TIM
      Password time
      PSWD-TOD
      Password time of date
      PSWD-XTR
      Halfway encrypted password flag
      UPD-TOD
      Date of update
      The CRE-TOD logonid field, which indicates the date and time that a logonid was created, can be modified by CA ACF2 command administration. It is not supported by LDAP and cannot be specified as an XREF field parameter.
    • LDAPattributeName
      Specifies the LDAP attribute of the entry on the LDAP directory that corresponds to the logonid field name on the logonid record. The attribute name can contain only alphanumeric characters and dashes.
      The LIDfield and LDAP attribute name are required parameters and must be delimited by '/' (forward slash ).
      The following parameters are optional and can also be specified:
    • LDAPattributeFieldType
      Specifies the LDAP attribute data type and indicates how CA ACF2 converts the LID data to the LDAP attribute data before sending it to the LDAP server. For example, LID character fields may be transmitted as UTF-8 encoded character strings. LID binary and LID hexadecimal fields may be transmitted as EBCIDIC binary data. LID bit fields may be transmitted as either character or binary data. LID date fields may be transmitted as character date fields.
      Valid LDAP attribute data type types include the following:
      • BINARY- EBCDIC hexadecimal value
      • BINARYSQ - EBCDIC hexadecimal value enclosed with single quotes
      • BINARYDQ - EBCDIC hexadecimal value enclosed with double quotes
      • CHARACTER - UTF-8 encoded character value
      • CHARACTERSQ - UTF-8 encoded character value enclosed with single quotes
      • CHARACTERDQ - UTF-8 encoded character value enclosed with double quotes
      • DATE - UTF-8 encoded character date
      • DATESQ - UTF-8 encoded character date enclosed with single quotes
      • DATEDQ - UTF-8 encoded character date enclosed with double quotes
      • UNICODE - UTF-16LE encoded character value
      • UNICODESQ - UTF-16LE encoded character value enclosed with single quotes
      • UNICODEDQ - UTF-16LE encoded character value enclosed with double quotes
      If this parameter is not specified, the default field type is CHARACTER. Note the following:
      • If LDS is started and no LDAP records are defined, LDS automatically shuts down.
      • Likewise, if LDS is running and a refresh of LDAP records is issued with no LDAP records defined as active, LDS automatically shuts down.
      • The UNICODE LDAP attribute data types can be specified with the LDAP attribute data format of UTF16LE, UTF16BE, UTF32LE, and UTF32BE. The data format translates the LID field into the corresponding UTF selection. The default LDAP attribute data format for UNICODE is UTF16LE.
    • LDAPattributeDataFormat
      Specifies the data format of the LDAP attribute name. If this parameter is not specified, the default data type is taken from the DATEFMT field if this is a LID date field or from the BITDEFLT field if this is a LID bit field. If this parameter is indicated, LDAPattributeFieldType parameter must be specified.
      The following are examples of LDAP attribute field type/data formats for logonid date fields:
      LDAPAttributeField Type
      LDAPAttributeData Format
      Example Date
      DATE
      MMDDYYYY
      April 7, 2001 converts to 04072001
      DATE
      DDMMYYYY
      April 7, 2001 converts to 07042001
      DATE
      YYYYMMDD
      April 7, 2001 converts to 20010407
      DATE
      MMDDYY1
      April 7, 2001 converts to 04/07/01
      DATE
      DDMMYY1
      April 7, 2001 converts to 07/04/01
      DATE
      YYMMDD1
      April 7, 2001 converts to 01/04/07
      Bit fields are ON if the specific privilege or authority has been granted and OFF if not specified or granted. The LID fields can be converted to character 'Y', 'N', 'T', 'F', '0', '1', binary 0 or 1.
      The following are examples of LDAP attribute field type/data formats for logonid bit fields:
      LDAPAttributeField Type
      LDAPAttributeData Format
      BIT is ON
      BIT is OFF
      CHARACTER
      YN
      'Y'
      'N'
      CHARACTER
      REVYN
      'N'
      'Y'
      CHARACTER
      TF
      'T'
      'F'
      CHARACTER
      REVTF
      'F'
      'T'
      CHARACTER
      01
      '1'
      '0'
      CHARACTER
      REV01
      '0'
      '1'
      BINARY
      01
      X'1'
      X'0'
      BINARY
      REV01
      X'0'
      X'1'
    • LDAPattributeLength
      A number from 1 to 1024 that represents the maximum data length of the LDAP attribute value. If this is not specified, the default length is the logonid field length from which the LDAP attribute has been mapped.
      Optional fields are positional and must be delimited by a '/' (forward slash).
    Create the Control LDS LDAP Record
    The following is an example of creating an LDS LDAP record.
    acf acf set control(lds) insert ldap.cpu2 active insert delete pswdasis objclass(acf2lid) url('ldap://nnnn.nnn.nnn.nnn:389') userdns('acf2lid=%L, host=cpu2, o=cai, c=usa') admindn('acf2lid=admin') admpswd(password) xref(name/Name) nextkey(cpu2xrf) JGP / LDAP.CPU2 LAST CHANGED BY FRANK01 ON 11/27/01-15:42 ACTIVE ADMINDN(acf2lid=admin) APPLNAME() BITDEFLT(CHARACTER/YN) NOBROADCST NOCHANGE DATEFMT(MMDDYYYY) DELETE INSERT LDSLABEL NEXTKEY(CPU2XRF) OBJCLASS(acf2lid) PSWDASIS URL(ldap://nnnn.nnn.nnn.nnn:389) USERDNS(acf2lid=%1, host=cpu2, o=cai, c=usa) XREF(NAME/Name)
    Refresh the LDS LDAP Record
    The LDAP refresh process builds the LDAP record table with Control LDS LDAP and Control LDS XREFLDAP records. LDAP records must meet the following criteria to propagate logonid changes to networked LDAP servers.
    • LDAP records must be ACTIVE with the INSERT, CHANGE, or DELETE command indicated to propagate logonid administration. If INSERT or CHANGE is specified on the Control LDS LDAP record, the XREF field data must be specified for information to be propagated.
    • If the NEXTKEY field is specified on the Control LDS LDAP or Control LDS XREFLDAP record, the Control LDS XREFLDAP record with the qualifier specified in the NEXTKEY field must exist.
    • The NEXTKEY field can chain a maximum of twenty-five different Control LDS XREFLDAP records to a single Control LDS LDAP record. NEXTKEY field values reference Control LDS XREFLDAP records and cannot be duplicated in the sequence.
    To activate the LDAP directories and refresh the Control GSO LDAP and Control LDS XREFLDAP records, issue the following commands:
    F ACF2,REFRESH(LDAP),TYPE(LDS)
    The REFRESH command works only when the LDS facility has been activated.
    Control LDS XREFLDAP Record
    The Control LDS XREFLDAP record defines additional logonid fields and the cross-references to the LDAP attribute names. Recall that the XREF field in the Control LDS LDAP record ties the logonid record field to LDAP attribute name in the LDAP directory.
    The Control LDS XREFLDAP record is intended to be an extension of the XREF field of the Control LDS LDAP record. The XREF field ties the logonid record field to the attributes of objects in the LDAP directory.
    The NEXTKEY field references the qualifier name of the Control LDS XREFLDAP record that indicates that additional fields are to be propagated. Create a Control LDS XREFLDAP record if the Control LDS LDAP record requires additional XREF field information.
    Record ID
    Fields
    XREFLDAP.
    qualifer
    NEXTKEY(
    qualifier of next LDS XREFLDAP record
    )
    XREF(
    LIDfield1/LDAPattribute1Name/
    LDAPattribute1FieldType/LDAPattribute1FieldFormat/
    LDAPattribute1FieldLength,...
    )
  • XREFLDAP.qualifier
    Must start with a period and must be one to seven characters long.
  • NEXTKEY(
    qualifier of next LDS XREFLDAP record
    )
    Specifies the qualifier of the next Control LDS XREFLDAP record that contains more XREF field values to be mapped to the requesting LDAP server.
  • XREF(
    LIDfield1/LDAPattribute1Name/LDAPattribute1FieldType/LDAPattribute1DataFormat/LDAPattribute1Length,...
    )
    Specifies the name of the logonid fields and the corresponding LDAP directory attributes to be synchronized to the LDAP directory for insert or change logonid command processing. The LID1field and LDAPattribute1Name are required parameters and must be delimited by '/' (forward slash).
The following parameters are optional and can also be specified:
  • LDAPattribute1FieldType
  • LDAPattribute1DataFormat
  • LDAPattribute1Length
Note: Optional fields are positional and must be delimited by a '/' (forward slash). In addition, there must be at least one XREF field parameter defined in the XREFLDAP record.
Create the Control LDS XREFLDAP Record
Use the following commands to create the XREFLDAP record:
acf acf set control(lds) insert xrefldap.cpu2xrf xref(password/userPassword, phone/Phone) JGP / XREFLDAP.CPU2XRF LAST CHANGED BY FRANK01 ON 11/27/01-15:45 NEXTKEY() XREF(PASSWORD/userPassword PHONE/Phone)
Refresh the Control LDS XREFLDAP Record
The LDAP refresh process builds the LDAP record table with Control LDS LDAP and Control LDS XREFLDAP records. LDAP records must meet the following criteria to propagate logonid changes to networked LDAP servers.
  • LDAP records must be ACTIVE with the INSERT, CHANGE, or DELETE command indicated to propagate logonid administration. If INSERT or CHANGE is specified on the Control LDS LDAP record, the XREF field data must be specified for information to be propagated
  • If the NEXTKEY field is specified on the Control LDS LDAP or Control LDS XREFLDAP record, the Control LDS XREFLDAP record with the qualifier specified in the NEXTKEY field must exist.
  • The NEXTKEY field can chain a maximum of twenty-five different Control LDS XREFLDAP records to a single Control LDS LDAP record. NEXTKEY field values reference Control LDS XREFLDAP records and cannot be duplicated in the sequence.
To activate the LDAP directories and refresh the Control GSO LDAP and Control LDS XREFLDAP records, issue the following command:
F ACF2,REFRESH(LDAP),TYPE(LDS)
The REFRESH command works only when the LDS facility has been activated.
Enabling SSL
If an SSL connection is to be established between CA ACF2 and an LDAP server, ensure the following steps have been completed before starting LDS.
  • Generate the digital certificates from a Certificate Authority such as CA ACF2
  • Configure CA ACF2 to obtain the generated digital certificates utilized for SSL
  • Configure the LDAP server for SSL with the generated digital certificates
This section provides a sample list of steps used to setup SSL support for CA ACF2 LDS.
Step 1
The following is an example of the CA ACF2 commands used to generate the certauth, sitecert and personal certificates used by the LDAP.TEST node for SSL:
acf gencert certauth.acfca expire(12/12/12) label(acf2=certauth) subjsdn(cn=acf2-certauth,ou=esac,o=ca,c=us) gencert sitecert.acf2ca expire(12/12/12) label(site-cert-ldap) signwith(certauth.acf2ca) subjsdn(cn=site-cert-ldap,ou=esac,o=ca,c=us) gencert acf2.acf2ca expire(12/12/12) label(acf2-user-cert) signwith(certauth.acf2ca) subjsdn(cn=acf2-user-cert,ou=esac,o=ca,c=us)
Step 2
The following is an example of the CA ACF2 commands used to export the digital certificates to a data set for SSL configuration on the LDAP server.
export acf2.acf2ca dsname('acf2ca.usercert') label(acf2-user-cert) password(password) export certauth.acf2ca dsname('acf2ca.certauth') label(acf2-certauth) password(password) export sitecert.acf2ca password(password) dsname('acf2ca.sitecert') label(site-cert-ldap) password(password)
Step 3
The following is an example of the CA ACF2 commands used to create the ACF2.LDS KEYRING record and connect the digital certificates for SSL.
acf set profile(user) div(keyring) insert acf2.lds ringname(acf2-lds-keyring) connect certdata(certauth.acf2ca) keyring(acf2.lds) connect certdata(acf2.acf2ca) keyring(acf2.lds) connect certdata(sitecert.acf2ca) keyring(acf2.lds)
Step 4
The following is an example of the CA ACF2 commands used to create the LDS OPTIONS record that points to the ACF2.LDS KEYRING record for SSL.
set control(lds) insert options retry(3) sysclass(A) sysdest(LOCAL) timeout(30) ldsring(acf2-lds-keyring) journal dataset(uniscax1.ldsjrnl) recovery ldsrcvr(uniscax1.ldsrcvr) F ACF2,REFRESH(OPTIONS),TYPE(LDS)
Step 5
The following is an example of the CA ACF2 commands used to create the LDS LDAP record LDAP.TEST that points to the digital certificate acf2-user-cert which is connected to the ACF2.LDS KEYRING record.
set control(lds) insert ldap.test active debug admindn('cn=Manager,c=us') admpswd(secret) insert change delete ldslabel(acf2-user-cert) objclass(inetOrgPerson) userdns('cn=%l,ou=esac,o=ca,c=us') url(LDAPS://123.456.78.99:636) xref(name/cn,NAME/sn,PASSWORD/userPassword) F ACF2,REFRESH(LDAP),TYPE(LDS)
Start LDS to obtain all the certificates connected to the ACF2.LDS KEYRING during initialization and establish an SSL encrypted connection to the LDAP.TEST server.
F acf2,lds(start)
Starting LDS
To start LDS, use the following command:
F ACF2,LDS(START).
The Control LDS OPTIONS, LDAP, AND Control LDS XREFLDAP records are automatically refreshed during initialization of LDS.
Stopping LDS
To stop LDS, use the following command:
F, ACF2,LDS(STOP)
LDS Logonid Field
The LDS logonid field specifies whether logonid administrative changes for a user are propagated to the LDAP servers defined by Control LDS LDAP and Control LDS XREFLDAP records. The LDS field also indicates that an LDAP request is created when the user changes their password during the signon process.
Create LDS Logonid Field
Use the following command to add LDS capability to a logonid:
acf acf change user01 lds
To display the changed logonid, use the following command:
list user01 USER01 USER01 PRIVILEGES ACCOUNT CICS JOB SECURITY TSO LDS ACCESS ACC-CNT(4) ACC-DATE(11/19/01) ACC-SRCE(A55TG003) ACC-TIME(15:43) PASSWORD PSWD-DAT(00/00/00) PSWD-INV(0) PSWD-TOD(11/07/01-11:48) PSWD-VIO(0) PSWDCVIO(0) PSWD-XTR TSO CHAR(BS) DFT-PFX(FRANK01) DFT-SOUT(A) DFT-SUBM(A) INTERCOM JCL LGN-ACCT LGN-MSG LGN-PERF LGN-PROC LGN-RCVR LGN-TIME LGN-UNIT LINE(ATTN) MAIL MODE MSGID NOTICES TSOFSCRN TSORBA(000096) TSORGN(4,096) TSOSIZE(4,096) WTP STATISTICS CRE-TOD(10/08/01-11:41) SEC-VIO(0) UPD-TOD(11/19/01-15:43) CICS CICSCL(404040) RESTRICTIONS PREFIX(USER01)
LDS is located in the privileges section.
SHOW LDS Subcommand
The SHOW LDS subcommand displays the LDS status and options, the active LDAP records, and the logonid field information that is propagated to an LDAP server.
The SHOW LDS command uses standard masking conventions to specify a range of active LDAP records. The following example shows the results after issuing the SHOW LDS command with a MASKED qualifier value.
acf show lds(cpu2-) -- LIGHTWEIGHT DIRECTORY ACCESS PROTOCOL -- CURRENT LDS STATUS: ACTIVE CURRENT LDS JOURNAL STATUS: ACTIVE LDS JOURNAL DATASET NAME: CALDAP.LDSJRNL CURRENT LDS RECOVERY STATUS: ACTIVE LDS RECOVERY DATASET NAME: CALDAP.LDSRCVR CURRENT SYSID: TEST LDSRING: OPTIONS: DEBUG RETRY(3) SYSCLASS(A) SYSDEST(LOCAL) TIMEOUT(30) ACTIVE LDAP RECORD LIST: - LDAP.CPU2 STATUS: CONNECTED OPTIONS: ACTIVE BROADCST CHANGE DEBUG DELCHILD DELETE INSERT JOURNAL PSWDASIS NOPSWDLOWR USEEXTOP OBJCLASS: ACF2LID NEXTKEY: *** NO NEXTKEY DEFINED *** CODEPAGE: *** NO CODEPAGE DEFINED *** URL: LDAP://xxx.xxx.xxx.xx:389 USERDNS: acf2lid=%l,host=xxx,o=xx,c=xx LDSLABEL: XREF: LID: ATTRIBUTE: NAME name PASSWORD USERPASSWORD
The following example shows what you might see when issuing the SHOW LDS command with an LDAP record that was deactivated.
LDS deactivates the LDAP node record for several reasons, an incorrect administrator password was supplied to the LDAP server or the limit of consecutive LDAP requests that have timed-out was exceeded. Analyze the previous messages for the specific type of error. Verify the LDS LDAP record field values for the URL, the ADMINDN, ADMPSWD (LDAP administrator password), or the APPLNAME (application name) is correct. Verify the LDAP server and the communication services are running. Issue the REFRESH or LDS(ACTIVE) operator command for the LDS LDAP record to reactivate this node.
acf show lds -- LIGHTWeight-DIRECTORY ACCESS PROTOCOL -- CURRENT LDS STATUS: ACTIVE CURRENT LDS JOURNAL STATUS: ACTIVE LDS JOURNAL DATASET NAME: CALDAP.LDSJRNL CURRENT LDS RECOVERY STATUS: ACTIVE LDS RECOVERY DATASET NAME: CALDAP.LDSRCVR CURRENT SYSID: TEST LDSRING: NONE OPTIONS: DEBUG RETRY(3) SYSCLASS(A) SYSDEST(LOCAL) TIMEOUT(30) ACTIVE LDAP RECORD LIST: - LDAP.CPU2 STATUS: DISCONNECTED OPTIONS: NOACTIVE BROADCST CHANGE DEBUG DELCHILD DELETE INSERT JOURNAL PSWDASIS NOPSWDLOWR USEEXTOP OBJCLASS: ACF2LID NEXTKEY: *** NO NEXTKEY DEFINED *** CODEPAGE: *** NO CODEPAGE DEFINED *** URL: LDAP://xxx.xxx.xxx.xx:389 USERDNS: acf2lid=%l,host=xxx,o=xx,c=xx LDSLABEL: NONE XREF: LID: ATTRIBUTE: NAME name PASSWORD USERPASSWORD
The following is an example of the SHOW LDS command when LDS is not active.
acf show lds -- LIGHTWeight-DIRECTORY ACCESS PROTOCAL -- CURRENT LDS STATUS: INACTIVE CURRENT LDS JOURNAL STATUS: INACTIVE LDS JOURNAL DATASET NAME: NONE CURRENT LDS RECOVERY STATUS:INACTIVE LDS RECOVERY DATASET NAME: NONE CURRENT SYSID: NONE LDSRING: NONE OPTIONS: NODEBUG RETRY(0) SYSCLASS() SYSDEST() TIMEOUT(0) ACTIVE LDAP RECORD LIST: THERE ARE NO ACTIVE LDAP RECORDS IN THIS SYSTEM acf
The following is an example of the SHOW LDS command when LDS is active and the LDAP node is connected.
acf show lds -- LIGHTWeight-DIRECTORY ACCESS PROTOCOL -- CURRENT LDS STATUS: ACTIVE CURRENT LDS JOURNAL STATUS: ACTIVE LDS JOURNAL DATASET NAME: CALDAP.LDSJRNL CURRENT LDS RECOVERY STATUS: ACTIVE LDS RECOVERY DATASET NAME: CALDAP.LDSRCVR CURRENT SYSID: TEST LDSRING: NONE OPTIONS: DEBUG RETRY(3) SYSCLASS(A) SYSDEST(LOCAL) TIMEOUT(30) ACTIVE LDAP RECORD LIST: - LDAP.CPU2 STATUS: CONNECTED OPTIONS: ACTIVE BROADCST CHANGE DEBUG DELCHILD DELETE INSERT JOURNAL PSWDASIS NOPSDWLOWR USEEXTOP OBJCLASS: ACF2LID NEXTKEY: *** NO NEXTKEY DEFINED *** CODEPAGE: *** NO CODEPAGE DEFINED *** URL: LDAP://xxx.xxx.xxx.xx:389 USERDNS: acf2lid=%l,host=xxx,o=xx,c=xx LDSLABEL: NONE XREF: LID: ATTRIBUTE: NAME name PASSWORD USERPASSWORD
LDSNODES Logonid Fields
The LDSNODES logonid field further restricts the propagation of user changes to a target LDAP node or group of LDAP nodes defined by Control GSO NODELIST records.
The LDS logonid field must be defined for the LDSNODES field to be activated by CA ACF2. The LDSNODES fields are validated at LDS processing time. If the LDSNODES value is not defined to the CA ACF2 system at the time of LDS processing, the system defaults to propagate the information to all active LDAP nodes.
Create LDS and LDSNODES Logonid Fields
Follow these steps:
  1. Issue the following commands at the ACF prompt:
    insert johndoe name(john doe) password(secret) lds ldsnodes(email)
  2. Display the changes by issuing Issue the following commands at the ACF prompt:
    list .....
    The logonid record displays.
    JOHNDOE JOHNDOE JOHN DOE PRIVILEGES LDS LDSNODES(EMAIL) ACCESS ACC-CNT(0) ACC-DATE(00/00/00) ACC-TIME(00:00) PASSWORD KERB-VIO(0) KERBCURV() PSWD-DAT(00/00/00) PSWD-INV(0) PSWD-TOD(10/27/06-13:17) PSWD-VIO(0) PSWDCVIO(0) PWP-VIO(0) TSO DFT-PFX(JOHNDOE) STATISTICS CRE-TOD(10/27/06-13:17) SEC-VIO(0) UPD-TOD(10/27/06-13:17) RESTRICTIONS PREFIX(JOHNDOE) LID
    LDS and LDSNODES are located in the privileges section.