Mucho strangeness: passwords not propagating to AD, and other annoyances

Question

Hi all,
I'm dealing with a few problems in IDM at the moment, and am looking at a small grab-bag of symptoms, which may or may not be linked to each other or to the problem at all.
The main current problem is that passwords aren't propagating into our Active Directory servers, although they did in the past.
First a quick summary of our environment, we are running IDM 5.5, we have a central mysql DB which is the source of user infromation, 3 different tables, one for each class of user. Activesync is in use to watch these tables, and we have a custom user form for each table too.
We are feeding account data into an LDAP server, which is working fine, and to a pair of Active Directory Servers, one for testing/development, and one intended to be for production, except the 'production' server isn't actually in production yet.
Password information is held in the mysql tables, in 2 different forms, 1) pre-encrypted unix hashes, and pgp-encrypted plaintext, we use the pgp-encrypted plaintext to feed the AD servers, and the unix-hashes for the LDAP.
Amongst other things the custom forms are calling locally written java code to reverse the pgp-encryption.
Because the AD boxes weren't in production, we don't know when things broke, or what may have changed to cause the breakage.
The symptoms I've found are as follows:
- account creation on AD works, including the initial password,
- password changes are not going through to the AD servers,
- changes to other fields in the mysql tables, do propagate (ie, changes to names, email adresses, vacation settings),
- Our custom user form gets run 3 times, on any change to an account within the mysql tables,
- The first time the form is run, the waveset.accountId is, sometimes, null, (maybe this is on account creation?)
- The first time the form is run, activeSync.pgp_pass (our pgp encrypted plaintext password) is always null,
- on an attempted password change, the task log doesn't show that it is trying to change the password, only that the Acocunt was 'updated',
- on changing any other field, the task log shows that it was changing that field, although it does show other fields that may have been changed,
- the catalina.out (we run tomcat), does show that the passwords are being correctly decrypted from the pgp form,
I'm stuck at this point, can anyone make any suggestions?

Answer 1

Hi Again,
This reply is just to let people know what happened with the issues I listed above.
- The user form being run 3 times, I don't fully understand this one, but I did reduce the amount of work the form did by turning the pgp decryption from a Expansion, to a Derivation field type.
- the empty attributes, the first time the form is run, does appear to be due to the first appearance of a user account, ie waveset.accountId is empty because it hadn't been generated yet for this user,
The basic problem of the passwords not puching out was a naming issue, when we first developed the software to decrypt the passwords, we put it in global.pass, and in the schema maps, placed entries like pass->userPasswordAt that point the system worked, then we decided to be more explicit and decided to name the attribute password instead.
Which meant the schema map was now working with the password. namespace and the password.password attribute, which in turn meant the password distribution failed, because we didn't set password.confirmPassword, or the pasword.selectAll attributes.
We were lazy, and didn't expect what looked like a attribute name change to be able to change anything, so we didn't notice the passwords stopped propagating.
As you can see from the above we are still learning how this all works :-(