Network vs. interactive logon

Windows recognizes different types of logon with subtly different security implications. Bitvise SSH Server can be configured, on a per-account or per-group basis, to use either of the following two logon types:

  • Network logon. By default, this logon type is configured in SSH Server Advanced settings for both Windows and virtual group settings entries. This logon type is therefore used, by default, for all accounts.

    Use of the Network logon type allows the user to log in via SSH even if the underlying Windows account is not granted the Windows security privilege Log on locally. However, on Windows Server 2003, the default filesystem permissions normally block access to cmd.exe and other command line tools when a logon session does not have the Interactive logon type.

  • Interactive logon. Use of the Interactive logon type requires a Windows account to be granted the Windows security privilege to Log on locally. By default, this logon type is not used by the SSH Server because a significant number of Windows servers are configured in such a way that this privilege is not granted for non-Administrator accounts.

    For some purposes, the Interactive logon type is required. For example, it is not possible to access server-side printers in an SSH terminal session unless the SSH user is either an administrator, or has the Interactive logon type. The Interactive logon type is also required on Windows Server 2003 for terminal shell access.

Selecting the right logon type

We recommend that users who require terminal shell access use the Interactive logon type. It will usually also make sense for them to log in via SSH as Windows users, not as virtual accounts.

On the other hand, we recommend that users who will use only file transfer and/or tunneling use the Network logon type. If this use is outside of a domain environment, it may also make sense (less overhead) to create for these users virtual accounts, which are internal to Bitvise SSH Server, instead of creating a separate account in Windows for each user.

Windows security settings affecting logon types

Essential Windows security settings that affect logon types are configured in the Group Policy Editor. This can be opened using the Windows Run dialog (Windows key + R) and starting: gpedit.msc. The settings are located under:

Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment

There are four main settings that affect whether login will be possible using the two logon types:

  • Deny log on locally. For accounts that match this setting, login will be prohibited using the Interactive logon type, even if the account matches the setting Allow log on locally.

  • Allow log on locally. For accounts that match this setting, login will be permitted using the Interactive logon type, unless the account also matches the setting Deny log on locally.

  • Deny access to this computer from the network. For accounts that match this setting, login will be prohibited using the Network logon type, even if the account matches the setting Access this computer from the network.

  • Access this computer from the network. For accounts that match this setting, login will be permitted using the Network logon type, unless the account also matches the setting Deny access to this computer from the network.

To be allowed logon using a particular logon type, an account must match the corresponding Allow setting, and must not match the corresponding Deny setting.

Technical clarification of logon type 8: NETWORK_CLEARTEXT

When the Network logon type is used, the SSH Server actually uses Windows logon type 8, which is NETWORK_CLEARTEXT. This is not a security issue.

Windows logon types are described by Microsoft as part of documentation for the LogonUser API. At the time of this writing, authoritative descriptions of logon types NETWORK and NETWORK_CLEARTEXT are as follows:

  • LOGON32_LOGON_NETWORK: "This logon type is intended for high performance servers to authenticate plaintext passwords. The LogonUser function does not cache credentials for this logon type."

  • LOGON32_LOGON_NETWORK_CLEARTEXT: "This logon type preserves the name and password in the authentication package, which allows the server to make connections to other network servers while impersonating the client. A server can accept plaintext credentials from a client, call LogonUser, verify that the user can access the system across the network, and still communicate with other servers."

Since 2013, misunderstandings of this logon type have proliferated. This appears to be thanks to this paper by a forensics student, which butchered the description as follows:

  • NetworkCleartext: "This is a kind of network logon where the password is sent over the network in the clear text. This is logged as logon type 8. Windows server doesn't allow connection to shared file or printers with clear text authentication. (...)"

This passage is a misunderstanding. Regardless, it is easier to find and read than LogonUser documentation. Thus, it has become cited in online answers, even though it directly contradicts the authoritative descriptions.

What "NETWORK_CLEARTEXT" means is: (1) the login is made over the network, and (2) the server where the login is performed has access to the original password, and can use it to impersonate the user to access further resources as part of the logon session. It does not mean that a password is sent, at any time, over the network unencrypted.

The use of NETWORK_CLEARTEXT - or another logon type that caches credentials, e.g. INTERACTIVE - is required if the session needs to have access to network resources. If NETWORK is used, Windows will not cache the logon credentials, and access to network shares on the user's behalf will not be possible without additional configuration.

The main distinction between logon types NETWORK_CLEARTEXT and INTERACTIVE is that the former requires the user to hold the Windows security privilege Access this computer from the network, whereas the latter requires Log on locally. Beyond this, the logon process is very similar. If you log into Windows via the local keyboard, this is much the same as when the SSH Server calls LogonUser with logon type INTERACTIVE. With NETWORK_CLEARTEXT, the logon process is also much the same; except that the user must hold a different Windows security privilege.

In no event does the SSH Server receive or send the password unencrypted over the network. The password is obtained either locally from the SSH Server's password cache, or is sent by the user over an encrypted SSH session. The SSH Server then passes the password to the Windows LogonUser function. For domain accounts, this will cause Windows to authenticate with the domain controller. As far as we know, Windows also does not send the password unencrypted over the network.