As we were preparing everything for these changes, we ran across numerous references to custom IBM schema fields that were being used by the password sync process (when using LDAP as the store), but really very little detail about what the schema change did and how it was used. I don’t like to apply schema updates without a few more details, so I will try to explain some of it here.
To find the schema updates, go to the etc folder under the pwd_plugins folder. Here you will find an ldif file named ibm-diPersonSchemaForAD.ldif. This file makes the following changes:
- ibm-diPerson – This is essentially the equivalent to a user or contact. It is the top level field that contains all of the following attributes.
- secretKey – I honestly am not sure what this is being used for. I do not see any changes being made to this attribute when a password change occurs.
- ibm-diUserId – This stores the samaccountname of the account where the password was changed. This lets you tie the account to an existing AD user.
- ibm-diPassword – This is where the captured password is stored. It is in plain text unless you configure the pwsync.props file to encrypt the password. I’ll discuss some other methods that can be used to secure this password later.
- ibm-diExtendedData – This appears to store the common name of the user whose password was changed.
- ibm-diCustomData – Using the pwsync.props file, you can pass custom data to this field. An example of the custom data may be the server name on which the password change was intercepted.
- ibm-diTimestamp – This is the timestamp of when the password change was intercepted. It doesn’t seem to get filled in on the initial creation of the ibm-diPerson (first password change), but does seem to get filled in on subsequent changes.
Once the schema has been added to AD, these new attributes are available for use by the password sync process. Now you will want to create an OU where the new ibm-diPerson objects can be created by the password sync process. (I called mine TDI.) You will also want to create a service account. (The service account information is stored in the pwsync.props file.) Here is where you can add an additional layer of security to the password sync process. Typically, new objects can be read by anyone. I would recommend changing the security on the new OU so that only domain admins and the new service account can read the OU and objects in it. (As always, I recommend using a group to delegate those permissions.)
Once everything is working, you will see new objects created in the OU.
On the object, you can see these attributes created:
One of the interesting parts about the ibm-diPassword is that it is of the type String(Octet). While it is viewable in Attribute Editor as plain text, it requires conversion to read the attribute otherwise.