Restore Security cannot resolve SIDs (4377765)

The scenario is: Taking security backups from one file server, and need to restore them to a different server with the same paths, files and folders, with the servers located on different domains, which due to technical impediments cannot see each other, therefore it is not possible to trust the two forests. 

Problem: We need to insert the SIDs into the ACLs of the new server to be able to clone groups and users and then use a mapping file to match the identities we backed up to the new domain. When we restore the security backup, everything is fine, except security restore because the SIDs can't be resolved.

The behavior described is due to the way SIDs are processed by the system when importing or cloning objects. When a SID is presented, the system (via the API) attempts to resolve it by looking up the SID in its database or querying relevant systems, such as domain controllers, to match it with an actual user or group. This process involves a timeout mechanism to ensure the system doesn’t hang indefinitely while waiting for a resolution.

For each SID, there is typically a 20-second timeout period where the system waits for a response when attempting to resolve that SID. If the SID is recognized (i.e., it matches a known user or group), the system will proceed normally. However, if the SID is unrecognized, the system continues attempting to resolve it until the timeout is reached, which can cause delays—sometimes up to 20 seconds per unrecognized SID.

While this timeout duration can be adjusted or configured depending on your environment, standard APIs typically do not allow invalid SIDs to be accepted during a security injection or cloning operation. The system enforces this because security integrity is a priority. Invalid or unrecognized SIDs could lead to security risks, such as incorrect mappings or misconfigurations, which could compromise the system’s security posture.
That said, even though the unrecognized SIDs are still imported, the security resolution process ensures that any SID injected must be valid within the context of the system’s user/group structure. If an SID cannot be resolved, it’s generally considered invalid and may not be allowed to complete the operation unless explicitly handled through custom processes or extended API features.

To summarize:
•    The system will always attempt to resolve each SID, and there is a timeout mechanism in place (typically 20 seconds per SID).
•    Unresolved or unrecognized SIDs can still be imported, but they cannot be used in a security context unless the system can validate them as valid entities (e.g., matching them to known users/groups).
•    Adjusting the timeout or API behavior may be possible, but invalid SIDs are generally not accepted during security injections to maintain system integrity.
If performance is a concern, reviewing the network or resolving bottlenecks related to SID resolution might help speed up the process, but security checks will still need to be enforced.

Note: injecting an unresolvable SID into an ACL is insecure.