Moving discussion to Engine Drivers as suggested by dgersic.

bartvdb wrote:
> Sjoerdk;241341 Wrote:
> > There are uses cases for this:

> Agreed. In our case the token is used in a loopback driver updating a
> newish user object. Other use cases are imaginable.
> Anyways, I've just received confirmation from NetIQ that it makes no
> sense to check user-specific rules in a password policy when generating
> a random password.

I disagree regarding that point.
There is a benefit in checking user specific rules in a password policy (for example to ensure that the generated password doesn't fail Active Directory complexity rules pertaining to values of user-specific attributes)

> The token works again when using a duplicate password policy without
> "Require unique passwords" and "Exclude passwords that match attribute
> values." But since we use the same password policy, that workaround is
> a hassle, not a fix.

There are plenty of use cases for this, some deployments require a random generated password on a regular basis (for example if smartcard authentication is used, there might be a requirement to set the all user's password to a new random value every day)
That's what the "Random Password Generator Job" is designed for.

Again, this applies to "existing" users

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below...