Modify AD Create Request in Before Create Rule

Identity Security Cloud (ISC) ISC Discussion and Questions
, , , ,
1

Hello, We are trying to manipulate attributes of an account that is to be created.
The Before Create Rule is running successfully and is calculating the values as they should be calculated and the env:request variable is manipulated properly. This can be clearly seen in the logs I am getting.

The issue is that the account is still created using the original values. Is it not possible to manipulate a Create Request via a Before Create Rule?

    $cn = GetCnForNewAccount $givenName $lastName

    $dn = GetDnForNewAccount $cn $costCenter

    $sAMAccountName = GetSAMAccountName $givenName $lastName

    $upn = GetUserPrincipalName $givenName $lastName

    $mailNickname = GetMailNickname $givenName $lastName

function Update-Attr([string]$name, [string]$value) {
    if ($env:Request -match "name=`"$name`"") {
        # Update existing
        $env:Request = $env:Request -replace "(<AttributeRequest [^>]*?name=`"$name`" value=)`"[^`"]*`"", "`${1}`"$value`""
    } else {
        # Add new before the end of the request
        $newTag = "`n  <AttributeRequest op=`"Add`" name=`"$name`" value=`"$value`" />"
        $env:Request = $env:Request -replace '</AccountRequest>', "$newTag`n</AccountRequest>"
    }
}

Update-Attr "sAMAccountName" $sAMAccountName
Update-Attr "displayName" $cn
Update-Attr "userPrincipalName" $upn
Update-Attr "mailNickname" $mailNickname

Above is the relevant code, but as I said, the logs show that the original request and the manipulated one have the same structure.

Eventhough the creation seems to use the old Request SailPoint is displaying this message. Eventhough the original Request and the manipulated XML have both all relevant values set properly

image
image413Ă—107 2.54 KB

2

Hi @fayadm Why do you think that that error message is being caused by provisioning using the original request? Are you sure it is not because of another reason?

3

Is there any specific thing being done in Before Create Rule which is not achievable by Create Account Provisioning Policy or Before Provisioning Rule?

4

According to your provisioning message, the account was created properly, but some of it’s attributes were not.

Have you confirmed that the account was actually created?

If so, can you review the attributes on the account with the attributes sent in the Create Plan to determine which ones were not set/updated properly?

1 Like
5

I can, not be 100% sure but the logs surely confirm that the original Request is sent. i could see that accounts created before I uploaded the rule are containing all attributes.

My biggest issue is that I am not able to replace the original request with the one I modified.

6

Yes, there are operations on different attributes that must be done, which is not possible to be done by Create Account Provisioning and we wanted to have the most possible control over the rule and be able to change it quickly, that is why we would rather choose it than a cloud before provisioning rule

7

It seems like only the necessary ones are being set, that being: dn, cn, sAMAccountName

8

Are you provisioning the “Domain Users” group during the creation process? We ran into something similar recently and that was the cause, once we removed that from the birthright role we stopped getting that error.

9

Hi @fayadm It looks like the `if` condition is not returning true. If this logic is inside the loop, it should update the record, but the error says to create an account, which means it is going to the else condition. You can print the logs in the script above and see where it went wrong.
if ($env:Request -match “name=`”$name`“”) {

I hope this will help.

Thanks,

PVR.

10

No I am provisioning other memberships and this is also happening when I create an account after an access request.

11

The issue was that I have given the whole country name to the attribute country code, which expects only 2 chars