Storage Gateway AD rights from another domain

To add Active Directory groups from another domain to your AWS Storage Gateway SMB file share quickly, you can use the Gateway Admin permissions feature rather than trying to set permissions through Windows Explorer, which is taking too long with your millions of files.

Here's how to do it:

1. Open the AWS Storage Gateway console
2. Select your gateway
3. From the Actions dropdown menu, choose "Edit SMB settings" and then "Local Group settings"
4. In the Gateway Admins section, add the Active Directory users and groups from the other domain that you want to grant permissions to
5. Add one user or group per line, including the domain name (for example: otherdomain\GroupName)
6. Save your changes

This approach grants these users Gateway Admin permissions, allowing them to manage files on the share. They'll be able to use the Shared Folders Microsoft Management Console snap-in to force-close files that are open and locked.

If you need more fine-grained control, you could also consider:

1. Setting permissions at higher-level folders rather than individual files
2. Being cautious with turning on inheritance and updating permissions recursively, as this would update all objects in the S3 bucket and could take a long time with millions of files

Note that when you edit Gateway Admins, it will disconnect and reconnect all SMB file shares, so plan for a brief interruption in service.
Sources
Configure local groups for your gateway - AWS Storage Gateway
SMBLocalGroups - Storage Gateway
Using Windows ACLs to limit SMB file share access - AWS Storage Gateway

In general with AD, it's strongly advised against to use various groups to grant access rights directly. Instead, you should have a dedicated group for each of your resource and permission combinations. For a file share, for example, a group could be something like "DIR_filegw_finance_READ" or "DIR_filegw_marketing_MODIFY". These groups would be in the same AD domain as the target resource (the File Gateway in this case), and they would be configured with "local" scope.

All the permissions in the file system would be granted only to this static set of AD groups that never change after the share/folder structure is created.

Inside these "DIR_filegw_*" local groups, you would add the respective groups from any AD containing users, service accounts, etc. as members. In AD design, these would be called "role groups." Conceptually, role groups are meant to contain acting principals, such as users and service accounts, and each group answers the questions "who they are" and "what they do for this company/organisation." For example, role groups could be called "ROLE_finance_department", "ROLE_marketing_department", and "ROLE_corporate_internal_audit". Importantly, the role groups must be of "global" or "universal" scope to work across trust relationships.

Permissions groups, on the other hand, would be named such as to describe "what access" they grant "to which resources". For example, "DIR_filegw_finance_READ" grants "read access" to "the file gateway's 'finance' folder/share".

You would combine these two groups, for example like this:

• DIR_filegw_finance_READ members: ROLE_finance_department, ROLE_corporate_internal_audit
• DIR_filegw_marketing_MODIFY members: ROLE_marketing_department
• DIR_filegw_marketing_READ members: ROLE_corporate_internal_audit

When you needed to grant access to a new group in a remote AD, you would simply add the new group from the other AD in one or more of the existing DIR_* permissions groups in AD, not making any changes to the file system permissions.

For your immediate issue, this may not be helpful if your groups aren't structured like this. However, the file permissions in File Gateway for S3 are stored in S3 object metadata, so changing them requires creating a copy of each object in S3 to get the object metadata to reflect the new permissions. This is a time-consuming operation at best and can also have a cost impact, depending on the S3 storage class of your objects and whether your file gateway is in the same AWS region as the S3 bucket.