Exchange Send As - ACL not in canonical order

Question

Hello,

We are experiencing the following issue:

1. Use Adaxes to Create a new user and mail enable the user.
2. try to use Adaxes to assign Send As rights to another user.

Result:

The ACL for the object "CN=username,OU=Users,DC=domain,DC=com" is not in canonical order (Deny/Allow/Inherited) and will be ignored.

We are using Exchange 2007 Sp3 UR10 and Adaxes version 3.5.9329.0.

This behavior does NOT occur if we create the account using the Exchange console, however the error DOES occur if we try to assign the Send As permssion using the Exchange console if the account was created in Adaxes.

Please help.

Comments

Hello,

To help us troubleshoot the issue, can you do the following:

1. On the computer where your Exchange Server is installed, open Exchange Management Shell.

2. Execute the following PowerShell line in the Shell:
   Get-ADPermission user_dn | Format-List > path_to_file,
   where:

   • user_dn - DN (distinguished Name) of a user that you are experiencing issues with,
   • path_to_file - path to an output file that will be created after executing the command.

   Example:
   Get-ADPermission "CN=John Doe,OU=Users,DC=domain,DC=com" | Format-List > C:\JohnDoe_permissions.txt

3. Execute the same line, but with a user account created in Exchange console (an account that you are not experiencing issues with) and save the output to another file.

4. Send both the files to our support email (support[at]adaxes.com) so that we can study them.

---

Email sent.

Pleae help asap... this is a critical issue.

Answer 1

We managed to identify the cause of the issue. The thing is that when the User cannot change password Account Option is set for a user, the user's ACL is built incorrectly. This is a bug in Adaxes that will be fixed in the next release, thank you for the bugreport!

To fix the issue until a fix is available, you can use the following script that will regenerate the ACL:

$ADS_RIGHT_DS_CONTROL_ACCESS = 0x100
$UserChangePasswordRightGuid = "{ab721a53-1e2f-11d0-9819-00aa0040529b}"

function MoveDenyAce($dacl, $trusteeType)
{
    for ($i = 0; $i -lt $dacl.Count; $i++)
    {
        $ace = $dacl[$i];
        if (($ace.AceFlags -band [System.Security.AccessControl.AceFlags]::Inherited) -ne 0)
        {
            continue
        }
        if (($ace.AccessMask -ne $ADS_RIGHT_DS_CONTROL_ACCESS) -or 
            ($ace.ObjectAceType -ne $UserChangePasswordRightGuid))
        {
            continue
        }
        if ($ace.AceQualifier -ne 'AccessDenied')
        {
            continue
        }
        if (-not $ace.SecurityIdentifier.IsWellKnown($trusteeType))
        {
            continue;
        }
        $dacl.RemoveAce($i);
        $dacl.InsertAce(0, $ace)
    }

}

$Context.TargetObject.GetInfoEx(@("ntSecurityDescriptor"), 0)
$securityDescriptorPropertyEntry = $Context.TargetObject.GetPropertyItem("ntSecurityDescriptor", "ADSTYPE_OCTET_STRING")
$securityDescriptorBinary = $securityDescriptorPropertyEntry.Values[0].OctetString
$rawSecurityDescriptor = New-Object "System.Security.AccessControl.RawSecurityDescriptor" @($securityDescriptorBinary, 0)

$dacl = $rawSecurityDescriptor.DiscretionaryAcl
MoveDenyAce $dacl 'SelfSid'
MoveDenyAce $dacl 'WorldSid'
$rawSecurityDescriptor.DiscretionaryAcl = $dacl

$securityDescriptorBinary = new-object byte[] $rawSecurityDescriptor.BinaryLength
$rawSecurityDescriptor.GetBinaryForm($securityDescriptorBinary, 0)
$Context.TargetObject.Put("ntSecurityDescriptor", $securityDescriptorBinary)
$Context.TargetObject.SetInfoEx(@("ntSecurityDescriptor"))

You can use Adaxes Business Rules and the Run a program or PowerShell script action to execute the script automatically once the User cannot change password Option is set. For example, if you set the User cannot change password in a Business Rule, you can insert the Run a program or PowerShell script action that will execute the above script after setting the User cannot change password Account Option. To do this:

1. Launch Adaxes Administration Console.
2. In the Console Tree, navigate to and select the Business Rule that sets the User cannot change password Account Option.
3. Select the set of actions and conditions that sets the User cannot change password Account Option and click the Add Action button.
   
4. Select the Run a program or PowerShell script action and paste the above script.
   
5. Click OK.
6. Use the arrow buttons at the bottom of the actions and conditions of the Business Rule to place the newly create action right after the User cannot change password Account Option is set.
   
7. When done, save the Business Rule.

Alternatively, if the Account Option is set creating a new user, you can create a Business Rule that will launch the above script right after creating a new user in AD. to do this:

1. Create a new Business Rule.
2. On the 2nd step of the Create Business Rule wizard, select User and After Creating a User.
   
3. on the 3rd step, add the Run a program or PowerShell script action and paste the above script.
   
4. Click OK.
5. Click the Add Condition button.
   
6. Select the If certain Account Options are enabled/disabled condition type.
7. Check the two checkboxes opposite the User cannot change password option.
   
8. Finish creation of the Business Rule.

Comments

Thank you for your quick and detailed reply.

I have implemented and tested the workaround and it seems to work good.

do you have an ETA when the fix will be released?

Thanks.

---

Hello,

The fix will be included in Adaxes 2013.2 that is expected to be released in late September.

---

Hello,

Adaxes 2013.2 is finally available. Now, Adaxes builds correct ACLs when the User cannot change password Account Option is set for a user. With the new version, you can get rid of the workaround provided in Exchange Send As - ACL not in canonical order. You can download Adaxes 2013.2 here.

Upgrade Instructions.

For a complete list of new features and improvements, see What's New.