Property Pattern Questions

Question

I have three questions regarding property patterns.

First, is it possible to have a property pattern required only on a creation, and not on a modification of a user account? Or is it possible to bypass this for admins but not other security groups? This comes into play in a new date field I want to require for new users going forward, but wouldn't necessarily apply to any existing/past accounts.

Second, we use a unique username script that fires before the creation of a user account. Illegal characters are being allowed. For example, one instance allowed a space in the user logon name ("De Silva" allowed "de silva" as a username). Another instance recently allowed an apostrophe for a name like O'Neal. Of course, display names and full names we prefer to keep special characters, but all of these extras should be filtered out or disallowed for email aliases and user logon names upon creation. So, is the unique username script somehow bypassing the property pattern requirements?

Third, I'm using a custom attribute called CustomAttributeTimestamp1 which I'll use for new user provisioning. I want that to be a required field but never seems to force it required on the form even though it's designated as required.

Answer 1

Hello,

First, is it possible to have a property pattern required only on a creation, and not on a modification of a user account? This comes into play in a new date field I want to require for new users going forward, but wouldn't necessarily apply to any existing/past accounts.

In such a case, we would suggest creating all new users in a certain OU/Container. Then, you can use two separate Property Patterns, one applied to the OU/Container where you create users, and one more that would apply to all other locations except that OU/Container. This can be used in a combination with a Business Rule that would automatically move all newly created users to the OU you need, say, based on a certain property of the user's account. So, when a user is created, the account is always created in a certain OU, where a certain Property Pattern defines value constraints and generation templates for new users only. Then, after creation, the user will be moved to another OU, where another Property Pattern is applied.

To implement such a solution:

1. Modify the Activity Scope of the Property Pattern used for new users so that it would include the OU/Container where you want to create users. For information on how to accomplish this task, see Modifying Property Pattern Activity Scope.
   
2. Modify the Activity Scope of the Property Pattern used for existing users so that it would exclude the OU/Container where you want to create users. For example, you can include All objects in the Activity Scope of the Pattern, and then add one more assignment for the OU/Container where you want to create users and check the Exclude the selection option in the Assignment Options dialog box as described in step 5 of the above help article.
   
3. For an example on how to move newly created users to the OU you need, see Move Newly Created Users to a Specific OU

Second, we use a unique username script that fires before the creation of a user account. Illegal characters are being allowed. For example, one instance allowed a space in the user logon name ("De Silva" allowed "de silva" as a username). Another instance recently allowed an apostrophe for a name like O'Neal. Of course, display names and full names we prefer to keep special characters, but all of these extras should be filtered out or disallowed for email aliases and user logon names upon creation. So, is the unique username script somehow bypassing the property pattern requirements?

The thing is that not allowing spaces/other characters (such as characters with umlaut) would also require another script triggered before creating a user. For examples of such scripts, see the 5th and the 6th Examples in step 5 of the Validate/Modify User Input Using a Script Tutorial. If you employ such scripts, then the best approach in such a case would be probably to combine the scripts in a single script that is called only once.

If you want, you can post here or send to our support email (adaxes@softerra.com) the scripts that you use for character replacement and for making sure that the username is unique, and we'll assign our script guy to work on the scripts.

Third, I'm using a custom attribute called CustomAttributeTimestamp1 which I'll use for new user provisioning. I want that to be a required field but never seems to force it required on the form even though it's designated as required.

How do you create the users? Is it a Home Page Action or you just use the Create user Operation? Also, did you specify the default value for the property in your Property Pattern?

Comments

Thanks for the reply.

I have #3 working. The problem there was I had inadvertently mapped the wrong field and now works as expected.

Regarding #1, this will impact the existing workflow a little, as our accounts are by default in a certain OU unless a particular attribute is set. Regardless, thank you for the suggestion on this.

Regarding #2, I'll send our current script to support to see if the illegal character fix can be incorporated.

Thank you.

---

Hello,

The following script combines the check for username uniqueness and replaces special characters in username. You can use it in your Business Rule executed before creating a user instead of your script that checks for username uniqueness. In the script, $map specifies, which characters to replace and the replacement characters. Modify it to your requirements.

Import-Module Adaxes

function ReplaceCharacters($value)
{
    $map =@{ "å"="a"; "ö"="o"; "ä"="a";"ü"="u"; "ñ"="n"; "é"="e"; " "=""; "'"="" } # TODO: modify me

    foreach ($key in $map.Keys)
    {
        $value = $value.Replace($key, $map[$key])
    }

    return $value
}

function IsUserNameUnique($username)
{
   $user = Get-AdmUser $username -erroraction silentlycontinue
   return $user -eq $Null
}

# Get the username
$username = $Context.GetModifiedPropertyValue("samAccountName")
# Replace special characters in username
$username = ReplaceCharacters $username

# Check if the username is unique
$uniqueUsername = $Null
if (IsUserNameUnique($username))
{
    $uniqueUsername = $username
}

# If the username is not unique, generate a unique one
if ($uniqueUsername -eq $NULL)
{
    $firstName = $Context.GetModifiedPropertyValue("givenName")
    if ($firstName -ne $NULL)
    {
        # Add characters from first name, one by one
        $firstName = ReplaceCharacters $firstName
        for ($i = 0; $i -le $firstName.length; $i++)
        {
            $initial = $initial + $firstName[$i]
            $uniqueUsername = $username + $initial

            if (IsUserNameUnique($uniqueUsername))
            {
                break
            }

            $uniqueUsername = $Null
        }
    }
}

if ($uniqueUsername -eq $NULL)
{
    for ($i = 1; $True; $i++)
    {
        $uniqueUsername = $firstName + $username + $i
        if (IsUserNameUnique($uniqueUsername))
        {
            break
        }
    }
}

# Update User Logon Name (pre-Windows 2000)
$Context.SetModifiedPropertyValue("samAccountName", $uniqueUsername)
$Context.LogMessage("User Logon Name (pre-Windows 2000): $uniqueUsername", "Information")

# Get domain name
$domaiName = $Context.GetObjectDomain("%distinguishedName%")

# Update User Logon Name
$Context.SetModifiedPropertyValue("userPrincipalName", "$uniqueUsername@$domaiName")
$Context.LogMessage("User Logon Name: $uniqueUsername@$domaiName", "Information")