Password Policy-violation exporting to AD from FIM 2010

When working on a customer case I had some trouble exporting new users from FIM to AD through AD MA. The connector gave me an “Policy-violation” all the time. I through that I had some problems with the password generator, and that my generated passwords didn`t match the complexity requirement or that the flow rules didn`t flow the initial password into fim mv from fim portal. I searched everywhere and came to the conclution that my password generated by function evalutor in FIM did just in fact match the complexity requirement by the domain gpo, and it was present in the metaverse. So. What could this be…

Maby my customer had set a fined-grained password policy on the OU i`m trying to manage ? No, nothing there. They used the default domain gpo. With the following password policy:

The function evaluator workflow in fim generated the password as following:

If I tried to reset the users password manually through ADUC it also failed, so by then I knew by fact that this problems couldn`t be related to FIM. But the weird thing was that this didn’t happen every time.

So. After alot of braindraining and testing. I found out that when you use password complexity requirements the password cannot contain the first characters in the users AccountName or DisplayName. Probably a lot of you know this. But I think that the documentation is a bit light on this. So I just wanted to let you know my experience with this. 🙂

Solution: I changed my function evaluator to this:

This is from Microsoft documentation:

The Passwords must meet complexity requirements policy setting determines whether passwords must meet a series of guidelines that are considered important for a strong password. Enabling this policy setting requires passwords to meet the following requirements:

  1. Passwords may not contain the user’s samAccountName (Account Name) value or entire displayName (Full Name value). Both checks are not case sensitive.
    The samAccountName is checked in its entirety only to determine whether it is part of the password. If the samAccountName is less than three characters long, this check is skipped.
    The displayName is parsed for delimiters: commas, periods, dashes or hyphens, underscores, spaces, pound signs, and tabs. If any of these delimiters are found, the displayName is split and all parsed sections (tokens) are confirmed to not be included in the password. Tokens that are less than three characters are ignored, and substrings of the tokens are not checked. For example, the name “Erin M. Hagens” is split into three tokens: “Erin”, “M”, and “Hagens”. Because the second token is only one character long, it is ignored. Therefore, this user could not have a password that included either “erin” or “hagens” as a substring anywhere in the password.
  2. The password contains characters from three of the following categories:
    • Uppercase letters of European languages (A through Z, with diacritic marks, Greek and Cyrillic characters)
    • Lowercase letters of European languages (a through z, sharp-s, with diacritic marks, Greek and Cyrillic characters)
    • Base 10 digits (0 through 9)
    • Non-alphanumeric characters (special characters) (for example, !, $, #, %)
    • Any Unicode character that is categorized as an alphabetic character but is not uppercase or lowercase. This includes Unicode characters from Asian languages.