Service Account granted Full Control to users Home Directory

Question

I have a Business Rule where "After User Creation", "Create the home directory".

This works fine and adds the user Modify Access to their home directory, but it also Adds the service account with Full Control access to the folder.

This is not desirable as the account is already an administrator and does not need to be given explicit access.

Is there a way to suppress this behavior?

Answer 1

Hello,

You cannot configure Adaxes not to add the explicit permissions, but you can revoke them immediately after creating the home directory. To do this, you need to modify your Business Rule that creates the home directory:

1. Launch Adaxes Administration Console.
2. Navigate to and select your Business Rule that creates the home folders.
3. Right-click the action that creates the home folders and click Add New Action.
   
4. Paste the following script from the repository: Remove permissions for Adaxes default service administrator to access user's home directory.
5. Select Run a program or PowerShell script.
   
6. Enter a short description and click OK.
7. Save the Business Rule.

Comments

I created the action, and it does not work. The service account is still there.

There is no error when the script runs.

Per the linked script

Note: By default, if a home directory is created for a user via Adaxes, the default service administrator will be assigned Full Access permissions for the home directory.
If you remove the permissions, Adaxes will be unable to perform operations with the home directory, for example, move or delete it.

I find this kind of strange as the service account used to create the folder and set the permissions is an Administrator and therefore has Full Control permission by default. I do not see why it would be necessary to explicitly give the service account Full Control.

---

Hello,

I do not see why it would be necessary to explicitly give the service account Full Control.

This happens because Adaxes service runs under the credentials of Adaxes default service administrator and authenticates using those credentials. So, the account is granted Full Control for home folders because it actually creates them.

The service account is still there.

Could you clarify the following:

1. Does your Business Rule also share the home folder? If it does, did you set the script to run before or after sharing the folder?
2. Are the computer where Adaxes server runs and the file server where the folders are created located in the same forest?
3. Could you post here or send us to support[at]adaxes.com a screenshot of the actions in your Business Rule?

---

Could you clarify the following:
1.Does your Business Rule also share the home folder? If it does, did you set the script to run before or after sharing the folder?
2.Are the computer where Adaxes server runs and the file server where the folders are created located in the same forest?
3.Could you post here or send us to support[at]adaxes.com a screenshot of the actions in your Business Rule?

1. No it does not share the home folder.
2. Yes both are in the same subnet and same domain.
3. Done

---

Hello,

We've received your e-mail. In the settings of your Create the home directory action, you've enabled the Inherit permissions from parent directory option. Are you sure that the permissions for Adaxes default service administrator are not inherited from the parent folder where the home folder is located?

To check this, we suggest using an updated version of the script now available in the Script Repository. That version will give a warning if any permissions are provided to Adaxes service administrator when such permissions are inherited from a parent folder.

---

Hi,

No, the service account does not have explicit permissions to the parent folder and is not being inherited. When viewing the permission, it is not gray and when looking at the Advanced Security Settings, it says "Inherited from: None".

I tried the new script and it does not give me any warnings.

I tried unchecking "Inherit permissions from the parent directory" and disables the inheritance and the only permissions listed are the user, the service account, and the local administrators group. SYSTEM and CREATOR OWER are not listed as they normally are when the permission is inherited.

---

Hello,

the only permissions listed are the user, the service account, and the local administrators group.

As far as we understand from your 1st post, the permissions granted to the service administrator are Full Access. Is that correct? What about the permissions granted to the local Administrators group? As far as we understand, the service administrator is a member of the group?

Can you send us screenshots of the permissions?

---

Sorry, after taking a look at the permissions, the account that is being given explicit permissions is actually the account used to logon to the domain (right click domain, "change logon information" , not the service account.

The account used to logon to the domain is different because when I setup the server for our POC, I used a different account that already had Admin rights. I plan to give the Adaxes Service Account admin rights, but have not yet.

Here is a screenshot of the Advance Permissions:

Because Administrators is being inherited, I do not need that or, the Logon Account (s-xxxxx) explicitly specified. The only account I want given explicit permissions is the user who the folder was created for.

FYI, here is the rule used to create the Home Directory:

---

Hello,

The thing is that by default, Adaxes creates home directories using credentials of Adaxes default service administrator. However, if the default service administrator does not have sufficient permissions to list the contents of the network share where the home directory needs to be created, Adaxes attempts to create a home directory using credentials of the user account used to logon to the domain. In your case, it looks like the default service administrator does not have sufficient permissions for the network share, and credentials of the domain logon account are used to create home directories.

To remedy the issue, you need to run the following PowerShell script after creating the home directory. It will remove permissions for the domain logon account.

Import-Module Adaxes

# Get home directory path
try
{
    $homeDirectoryPath = $Context.TargetObject.Get("homeDirectory")
}
catch
{
    $Context.LogMessage("The user doesn't have a home directory", "Warning")
    return
}

# Bind to the Configuration Set Settings container
$configSetSettingsPath = $Context.GetWellKnownContainerPath("ConfigurationSetSettings")
$configSetSettings = $Context.BindToObject($configSetSettingsPath)

# Get Security Identifier of the service administrators
$adminManager = $configSetSettings.AdministratorManager
$adminsSidsBytes = $adminManager.Administrators
$adminSids = New-Object "System.Collections.Generic.HashSet[System.String]"
foreach ($sidBytes in $adminsSidsBytes)
{
    $sid = New-Object "Softerra.Adaxes.Adsi.Sid" @($sidBytes, 0)
    [void]$adminSids.Add($sid)
}

# Get user SIDs of user account used for access to the domain
$domainName = $Context.GetObjectDomain("%distinguishedName%")
$managedDomainsPath = $Context.GetWellKnownContainerPath("ManagedDomains")
$managedDomainsPathObj = New-Object "Softerra.Adaxes.Adsi.AdsPath" $managedDomainsPath
$managedDomainPath = $managedDomainsPathObj.CreateChildPath("DC=$domainName")
$managedDomain = $Context.BindToObject($managedDomainPath)
$logonName = $managedDomain.LogonName
if (-not([System.String]::IsNullOrEmpty($logonName)))
{
    $user = Get-AdmUser -Filter {userPrincipalName -eq $logonName} -AdaxesService localhost -Server $domainName -ErrorAction SilentlyContinue
    if ($user -ne $NULL)
    {
        [void]$adminSids.Add($user.Sid)
    }
}

# Get home directory Access Control List
$acl = Get-Acl -Path $homeDirectoryPath

# Find and remove administrative users from the Access Control List
$accessRules = $acl.Access
for ($i = $accessRules.Count - 1; $i -ge 0; $i--)
{
    $accessRule = $accessRules[$i]
    $isInherited = $accessRule.IsInherited
    foreach ($identityReference in $accessRule.IdentityReference)
    {
        # Translate identity to SID
        $sid = $identityReference.Translate("System.Security.Principal.SecurityIdentifier").Value
        if (!($adminSids.Contains($sid)))
        {
            continue
        }

        # Check whether permissions are inherited from a parent container
        $userIdentity = $identityReference.Value
        $userPermissions = $identityReference
        if ($isInherited)
        {
            $Context.LogMessage("Cannot remove permissions '$userPermissions' for '$userIdentity' because the access rule is inherited from a parent container", "Warning")
            continue
        }

        [void]$acl.RemoveAccessRule($accessRule)
    }
}

# Assign the modified Access Control List
$folder = Get-Item $homeDirectoryPath
$folder.SetAccessControl($acl)

ExpandCopy code

For this purpose, add the Run a program or PowerShell script action to the Business Rule that creates the home directories immediately after the action that creates home directories.

---

Hi,

I have applied this script but I am getting the error:

[!] Cannot find path \\homedrivehere because it does not exist.
[!] Cannot bind argument to parameter 'AclObject' because it is null.

---

Hello,

It looks like the account that is used to run the script does not have sufficient permissions to access the home directory. The account is specified in the Run As section of the Run a program or PowerShell script action that is used to run the script. By default, the account of Adaxes default service administrator (the user that you specified during Adaxes installation) is used.

To remedy the issue, you can use one of the following options:

• Grant the necessary permissions to the account that is used to run the script.

• Specify an account that has sufficient permissions to access home directories and modify permissions. To do this:

  1. In the Run As section, select This account.
  2. Click Specify.
     
  3. Specify an account that has sufficient permissions and click OK.
  4. Save the changes.

---

Hi, sorry for not replying sooner but I have been rather busy.

I tried the updated script, and the results are the same. The Local Administrators group and the account used to Login to the Domain permissions are still explicitly listed as in my previous post.

---

Hello,

Can you view the account used to login to the domain in the Administration Console and check whether the user Logon name property is populated for that account?

Also, you never mentioned that the local Administrators group should be removed from the list. Should the permissions for the local Administrators group also be removed?

---

Ah, I figured it out. I had restricted Adaxes from all service accounts in my licensing so it could not control the object.

My bad. You can mark this as Solved.