C#.NET身份模拟问题：无法通过LogonType 4或5实现身份模拟

Let’s walk through why your LogonType 4 (Batch) and 5 (Service) logons are failing, even though LogonType 9 works and you’ve added the user to the relevant groups. Here are the key areas to check and fix:

1. Verify Local Security Policy Permissions (Critical!) #

Adding the user to AdminL_LocalLogonAsBatchJob and AdminL_LocalLogonAsService groups is a good start, but you need to ensure these groups are actually granted the corresponding rights in the Local Security Policy:

• Open secpol.msc
• Navigate to Local Policies > User Rights Assignment
• Check Log on as a batch job: Confirm your AdminL_LocalLogonAsBatchJob group (or the specific user) is listed here.
• Check Log on as a service: Do the same for AdminL_LocalLogonAsService group/user.

Note: Group membership changes might require a user logoff/logon (or even a server restart) to take full effect.

2. Use the Correct Logon Provider for Batch/Service Logons #

You’re currently using LOGON32_PROVIDER_DEFAULT (0), but for Batch and Service logon types, the recommended providers are LOGON32_PROVIDER_WINNT50 (3) or LOGON32_PROVIDER_WINNT40 (2). The default provider may not handle these logon types reliably in all environments. Try adjusting your ImpersonateUser call to pass 3 as the provider when using LogonType 4 or 5:

// Example for Batch logon
ImpersonateUser(domain, userName, password, 4, 3);

3. Capture and Analyze Exact Win32 Error Codes #

Your code captures the error message, but the specific numeric error code (from Marshal.GetLastWin32Error()) will pinpoint exactly what’s failing. Common errors for Batch/Service logons include:

• ERROR_LOGON_FAILURE (1326): Invalid credentials, or the user lacks permission for the requested logon type.
• ERROR_ACCOUNT_RESTRICTION (1327): The account has restrictions (e.g., logon hour limits, or blocked logon locations).
• ERROR_PRIVILEGE_NOT_HELD (1314): The calling process doesn’t have the required privilege to perform the logon.

Add debug output for the apiError value to narrow down the issue quickly.

4. Check Account-Specific Restrictions #

Even with the right group memberships, the user account might have built-in restrictions:

• Open Active Directory Users and Computers (or Local Users and Groups) for the account.
• On the Account tab, verify:
  • Logon Hours don’t block access at the current time.
  • Log On To settings allow the account to logon from this server.
  • The account isn’t disabled, and its password hasn’t expired.
• For service logons, ensure the account is explicitly allowed to act as a service (some domain policies may restrict this).

5. Fix Token Handling and Memory Management in Your Code #

Your code has a few issues that could cause instability or unexpected behavior:

a. Missing Memory Cleanup #

You’re using Marshal.SecureStringToGlobalAllocUnicode but never freeing the allocated memory, which will lead to memory leaks. Add cleanup logic in a finally block:

try {
    // Your existing LogonUser logic here
} finally {
    // Free the allocated unmanaged memory
    if (UserNamePointer != IntPtr.Zero) Marshal.ZeroFreeGlobalAllocUnicode(UserNamePointer);
    if (PasswordPointer != IntPtr.Zero) Marshal.ZeroFreeGlobalAllocUnicode(PasswordPointer);
    if (DomainNamePointer != IntPtr.Zero) Marshal.ZeroFreeGlobalAllocUnicode(DomainNamePointer);
}

b. Static Impersonation Context Thread Safety #

The winImpersonationContext static field is shared across all threads, which will cause race conditions if multiple threads attempt to impersonate simultaneously. Instead, store the context in a thread-local variable or return it from ImpersonateUser so the caller can manage it directly.

c. Token Duplication (Optional but Recommended) #

For some logon types, the token returned by LogonUser may not have sufficient privileges for impersonation. Try duplicating the token to get a dedicated impersonation token:

// Add these DllImports
[DllImport("advapi32.dll", SetLastError = true)]
private static extern bool DuplicateTokenEx(IntPtr hExistingToken, uint dwDesiredAccess, IntPtr lpTokenAttributes, int ImpersonationLevel, int TokenType, out IntPtr phNewToken);

[DllImport("kernel32.dll", SetLastError = true)]
private static extern bool CloseHandle(IntPtr hObject);

// Inside your loggedOn block:
IntPtr impersonationToken;
if (DuplicateTokenEx((IntPtr)userToken, 0x00020000 /* TOKEN_IMPERSONATE */, IntPtr.Zero, 2 /* SecurityImpersonation */, 1 /* TokenImpersonation */, out impersonationToken)) {
    WindowsIdentity identity = new WindowsIdentity(impersonationToken);
    winImpersonationContext = identity.Impersonate();
    CloseHandle(impersonationToken); // Clean up the duplicated token
}

6. Test with Local vs Domain Accounts #

If using a domain account, confirm the server can reach the domain controller. For local accounts, verify the account exists on the server and has the correct permissions. Sometimes domain Group Policy Objects (GPOs) can override local security settings, so check if any GPOs are restricting logon rights for the user.

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