5
votes

We are developing an application with an internal user accounts system, but would like to be able to use credentials from Active Directory and/or Windows accounts. To that end we store the User SID in a field in the application's users table. Our login mechanism functions like this:

The problem that has come up is this: we have been using LOGON32_LOGON_NETWORK for the logon_type, but we have now run into some security configurations where "Access this computer from the network" is denied, meaning the Network logon type is prohibited.

My question is what logon type should we be using for this situation? Interactive? We are not actually using the Logon token for anything other than extracting the user's SID. Our application has its own internal groups and permissions; we do not use Windows groups or permissions in any way. From the perspective of Windows and the domain controller, all we are doing is logging on and quickly logging off.

Or are we looking at this in a completely wrong way, and we should be using some other login method entirely?

Thanks

3
Is this a desktop application or a web app? Why not use Kerberos to authenticate the user against AD?MvdD
Desktop. We've already written the login stuff and we're hoping to just have to change that one parameter. Also we want to be able to use local Windows accounts in addition to AD.smead
Desktop? So the user is already logged on? Why does your application need them to log on again, why not just use the existing SID? (More importantly, you do realize that the user will be able to easily bypass your logon mechanism and log into your application as any other user?)Harry Johnston
The LogonUser call takes place in a service running on the SYSTEM account. I don't see how they would be able to spoof an SID without Admin rights on the computer.smead
Yes, if it's a service that's OK. Jumping to conclusions there, sorry. And since the user must be interactively logged on, LOGON32_LOGON_INTERACTIVE is a perfectly sensible choice. Note however that named pipes (and most other IPC mechanisms) allow you to determine the identity of the user without having to reauthenticate them.Harry Johnston

3 Answers

2
votes

I also have been surprised to find out that the LogonUser() with the LOGON32_LOGON_NETWORK type fails when user right "Access this computer from the network" is not granted for Everyone on local computer.

I use the following workaround:

  • First try LogonUser() with the LOGON32_LOGON_NETWORK type.
  • If it fails with error ERROR_LOGON_TYPE_NOT_GRANTED, call LogonUser() with the LOGON32_LOGON_NEW_CREDENTIALS type and the LOGON32_PROVIDER_WINNT50 logon provider.
0
votes

You can communicate with the SSPI services to validate a user's credentials and acquire a token, without requiring special privileges. This requires a lot of obscure code and

See http://support.microsoft.com/kb/180548 for an example; the SSPLogonUser function is where the token is acquired.

0
votes

The convention is to use LOGON32_LOGON_BATCH, as documented:

This logon type is intended for batch servers, where processes may be executing on behalf of a user without their direct intervention. This type is also for higher performance servers that process many plaintext authentication attempts at a time, such as mail or web servers.

(emphasis mine).

The system administrators may still need to reconfigure the server to grant batch logon access to the users in question, but because this does not grant the user access to any Windows functionality (e.g., the ability to use Remote Desktop, to connect to a network share, or to log on interactively if they somehow gain access to the console) this should not be a problem.