获取文件共享NTFS权限脚本返回跨域用户SID而非用户名问题

I’ve dealt with this exact issue before—let’s break down what’s happening and how to fix it:

When you add a new domain user to NTFS permissions, Windows doesn’t instantly resolve the SID to a human-readable username. The file properties UI (the Security tab) might show the SID at first, but it runs a background process to query your domain controller and update the display once it gets a result. Your script, though, pulls permission data immediately before that background resolution finishes, which is why you’re seeing raw SIDs instead of usernames.

Here are three practical fixes to solve this:

• Add a deliberate delay (quick but inconsistent)
  If you can afford to wait, add a sleep command before your script fetches permissions. For example, in PowerShell:

  # Wait 10 seconds to let Windows resolve SIDs
  Start-Sleep -Seconds 10
  # Pull NTFS permissions after the delay
  Get-Acl -Path "C:\YourSharedFolder" | Select-Object -ExpandProperty Access
  

  Heads up: The required delay depends on network speed and domain controller response time, so this isn’t 100% reliable across all environments.

• Manually resolve SIDs in your script (most dependable)
  Instead of relying on the system’s pre-resolved names, have your script translate SIDs to usernames directly using Windows’ security APIs. In PowerShell, you can implement this with:

  $acl = Get-Acl -Path "C:\YourSharedFolder"
  foreach ($accessRule in $acl.Access) {
      try {
          $username = ([System.Security.Principal.SecurityIdentifier]$accessRule.IdentityReference).Translate([System.Security.Principal.NTAccount]).Value
          Write-Host "User: $username | Permissions: $($accessRule.FileSystemRights)"
      } catch {
          # Handle cases where SID can't be resolved (e.g., domain controller offline)
          Write-Host "Unresolved SID: $($accessRule.IdentityReference) | Permissions: $($accessRule.FileSystemRights)"
      }
  }
  

  This skips the system’s cached resolution and queries the domain controller directly, so you’ll get the username as long as the DC is reachable.

• Refresh local security cache (supporting step)
  Stale Kerberos or security cache can slow down SID resolution. You can purge the Kerberos cache with:

  klist purge
  

  Or refresh group policy to ensure your local machine has the latest domain user data:

  gpupdate /force
  

  This can speed up the system’s automatic resolution, but it’s still best paired with manual SID translation in your script for consistent results.

One important note: If your domain controller is offline or unreachable, even manual resolution will fail and you’ll still see SIDs—adding error handling (like the try/catch block above) will make your script more robust.

内容的提问来源于stack exchange，提问作者Justin Beagley