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. https://www.netiq.com/documentation/...a/befh3g6.html

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...