c# search possible reasons for: impersonation fails with logon type LOGON32_LOGON_NEW_CREDENTIALS

Question

We have in our domain an application where people can upload files to a dfs share. As information is sensitive, only a service account has read/write access to that share. That means, we have to impersonate the filestream to be able to up-(and down-) load the files.

the code we're using is quite standard

public Impersonation(string Username, string Password, string Domain, logonType LogonType = LogonType.LOGON32_LOGON_INTERACTIVE, ProviderType ProviderType = ProviderType.LOGON32_PROVIDER_DEFAULT) 
{
    int lastError;

    try {
        UndoImpersonation();

        wic = WindowsIdentity.Impersonate(IntPtr.Zero);

        if (!WindowsIdentity.GetCurrent().Name.ToLower().Contains(Username.ToLower())) {
            if (LogonUser(Username, Domain, Password, (int)LogonType, (int)ProviderType, out token)) {
                LogWriter.Debug("Token after LogonUser: " + token.ToString());
                if (DuplicateToken(token, (int)ImpersonationLevel.SecurityImpersonation, out tokenDuplicate)) {
                    LogWriter.Debug("Duplicate Token: " + tokenDuplicate.ToString());
                    copyIdentity = new WindowsIdentity(tokenDuplicate);
                    wic = copyIdentity.Impersonate();
                } else {
                    lastError = Marshal.GetLastWin32Error();
                    LogWriter.Error("DuplicateToken failed with error: " + lastError);
                    throw new Win32Exception(lastError);
                }
            } else {
                lastError = Marshal.GetLastWin32Error();
                LogWriter.Error("LogonUser failed with error: " + lastError);
                throw new Win32Exception(lastError);
            }
        } else {
            LogWriter.Error("Double impersonation detected: WindowsIdentity: " + WindowsIdentity.GetCurrent().Name.ToLower() + " //// Username: " + Username.ToLower());
        }
    } catch (Exception ex) {
        LogWriter.Error(ex);
        throw;
    }
}

we are calling that procedure with LOGON32_LOGON_NEW_CREDENTIALS and LOGON32_PROVIDER_WINNT50. That works for most people (>90%), and most of them have no admin rights on their machine. But in some cases, we see a "part of the path not found" exception in our application log when creating the corresponding stream. In that case, we retry to create the streams with other logon_types (e.g. LOGON32_LOGON_INTERACTIVE, LOGON32_PROVIDER_WINNT40 and/or -50). We do not get any other error but "a part of the path could not be found".

but in our error log, we see in that case that: impersonating with "new credentials" is logged with the original user's accound. that means, that impersonation didn't take place! (I repeat: it works for almost the whole company) the other tries (using interactive) are logged as service account, that means the impersonation succeeded, but that kind of logon type has no rigths to access the share (because we still get that "part of the path not found").

My question is: What can be the reason or where can we look, why some people can't impersonate using "new credentials"?

Can there be a group policy, active directory settings, registry settings?