This is a weird one, and since it is not something that happens
consistently, it is hard for me to provide a valid trace. That being
said, I am really seeking ideas around what to look at...

I have an AD driver (the RL is on Windows 2003), and for the most part
it is provisioning accounts with the userAccountControl set as 544,
which is the desired state. However, it is occaisionally provisioning
them with 546, and it seems to be in batches. My logic in the driver
basically depends on the login disabled setting (which is mapped
appropriately through the schema map). From beginning to end, the
accounts come out of a text file (text driver) into meta, and then are
sent out to an EDIR F&P tree, and EDIR LDAP/Authentication tree, and
Active Directory. In all places, the accounts are login disabled=false,
except sometimes in AD they end up with a 546.

As far as password policies, on AD it is set to no complexity, 6
characters, no remembering (can use same password) - so it is pretty
relaxed. Furthermore, with all of the newly created, but disabled
accounts, the sAMAccountName and userPrincipleName are both populated.
The password is generated on the text driver, and is set to a
combination of initials and 8-digit birthdate, all of which exist in the
text file, and subsequently in the metadirectory.

Am I missing some AD quirkiness besides having required fields and a
password generated? Could it be that the account is created then on
another iteration of the channels that it sets the password and for some
reason does not automagically fix the userAccountControl setting?

I have implemented this driver a number of times, and I have never seen
this sporadic behavior. I don't know if I am just missing something or
if I need to start looking at the AD environment to see if something is
going on within it.



Greg Pearson
gregpearson's Profile:
View this thread: