Currently I have a windows service written in C# (running as LocalSystem) which creates a user account, needed for impersonation, by using the DirectoryEntry to add the user/password and associated UserFlags. Then it simply uses this account to perform some tasks (using impersonation) using the LogonUser() functionality - works perfectly.

However this account should ONLY be used for impersonation by my service, a user should NEVER be able to login (even if he has the credentials) locally or via the network.

To accomplish this I tried setting the Local Policies for “Deny logon locally” and “Deny access to this computer from the network” and added the user my service creates. Now however impersonation fails with the following:
Logon failure: the user has not been granted the requested logon type at this computer (1385)

So, I guess this is NOT the right way to do it … but I need to secure lockdown the account so it can only be used by my service for impersonation purposes and to ensure that no one else can ever logon to the account (even if they have all the credentials).

Is there something in LSA I can use? Or using the DirectoryEntry code similar to when the account was created? Is there a way to allow for an account to exist but not allow users to interactively logon?

Any help would be much appreciated.
Thanks,

Dani AI

Generated

Short answer: ERROR_LOGON_TYPE_NOT_GRANTED (1385) means Windows blocked the specific logon type your service requested. Local security rights are applied by logon type, so the account can be locked down for interactive/network logons yet still be usable for service-style impersonation if you choose the correct logon type and grant the corresponding right.

A practical fix: have the service call LogonUser with a non-interactive logon type such as LOGON32_LOGON_BATCH (or LOGON32_LOGON_SERVICE) and grant that account the matching right ("Log on as a batch job" or "Log on as a service") in User Rights Assignment. Keep the account out of normal interactive groups (and in interactive/network deny lists if you want human logons blocked). Note that deny rights take precedence only for the logon types they cover; switching the LogonUser logon type avoids the denial that produced 1385. ’s point about impersonation privilege is relevant, but the privilege alone won’t bypass a denied logon type.

Example (illustrative) P/Invoke pattern to try LOGON32_LOGON_BATCH:

[DllImport("advapi32.dll", SetLastError=true, CharSet=CharSet.Unicode)]
static extern bool LogonUser(string user, string domain, string pass, int logonType, int provider, out IntPtr token);

const int LOGON32_LOGON_BATCH = 4;
const int LOGON32_PROVIDER_DEFAULT = 0;

IntPtr token;
if (LogonUser("svcuser", ".", "secret", LOGON32_LOGON_BATCH, LOGON32_PROVIDER_DEFAULT, out token)) {
    using (var id = new WindowsIdentity(token)) {
        using (var ctx = id.Impersonate()) {
            // perform work
        }
    }
    CloseHandle(token);
}

If this still fails, check the Security event log for the exact substatus, verify the account is not disabled, and confirm the right was added to the correct machine/policy. If you are in a domain, prefer Managed Service Accounts / gMSA or set the account’s "Log On To" (userWorkstations) to the service host and avoid storing long-lived credentials.

Recommended Answers

All 2 Replies

After setting Deny logon locally did you set Impersonate a client after authentication? It's what ASPNET does to prevent logging in, might work for you.

Doesn't seem to help ... I added it and still my impersonation fails ... I am going to play and see maybe some combinations of the 3 policies ...
Thanks for the idea ...

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.