Can anyone provide a clear explanation of the difference between LOGON32__LOGON_INTERACTIVE and LOGON32_LOGON_NETWORK when used with LogonUser?
The MS documentation is here.
But I'm not clear what should be used. The scenario is similar to a telnet server that Windows users (local to the server, and domain users) are logging into - I want to impersonate the user in the thread. They may want to delete files or whatever.
Look at http://www.bitvise.com/wug-logontype for a thorough discussion of the issue and a recommendation:
We recommend that users who require
terminal shell access use the
'interactive' logon type.
Related
What's the differences between these two chrome policy registers AuthServerWhitelist and AuthNegotiateDelegateWhitelist?
I started doubting when I've found out those two registers while I was trying to automate a login for an intra-net.
First I tried out with AuthServerWhitelist and it didn't work.
Then I set up both AuthServerWhitelist and AuthNegotiateDelegateWhitelist and it worked.
I cannot see right now what's the difference, although I read they have two different functions.
Chromium Policies list link
Thanks a lot in advance!!
The difference between the two is related to Kerberos, impersonation levels and the difference between impersonation and delegation.
In simple terms (I'm not an expert):
AuthServerWhitelist specifies which servers are allowed for integrated authentication. By default, however, this only supports impersonation not delegation.
So, if you add a server to AuthServerWhitelist, you can, for example, log in to a website which can then impersonate your user. However, let's say that website would further want to connect and authenticate to an SQL Server database on behalf of your user. That would not work since this is delegation.
Adding the server additionally to AuthNegotiateDelegateWhitelist should enable that delegation use-case, provided you are using Kerberos (Negotiate) and everything has been set up correctly.
Maybe important for all of you searching, the Key AuthNegotiateDelegateWhitelist got renamed to AuthNegotiateDelegateAllowlist in case you are running into trouble now.
Ok, so I'm guessing the answer to this question is no (sensing privacy issues here), but let's check anyway.
Is it possible to read the username of the computer user (think SSO)? This could perhaps be read from the owner of the Firefox process.
I'm not really seeing anything about it in the SDK docs, and searching for username just gives me a bunch of password managers.
api-utils/environment provides access to the user's shell environment variables:
https://addons.mozilla.org/en-US/developers/docs/sdk/latest/packages/api-utils/environment.html
Here is some basic usage:
https://builder.addons.mozilla.org/package/156370/latest/
Depending on what info you need, you can run system commands with the priviledges of Firefox itself to get info from, say, the Windows registry. You should be aware that malicious use of code like this would not be allowed when your add-on is reviewed by the Mozilla Addons site.
Is there a reliably way to determine the last user name to login to the system? I've looked at LsaEnumerateLogonSessions() and LsaGetLogonSessionData() however they require elevation on Vista and later (which I'm keen to avoid). WMI has the same problem (presumably it's just calling Lsa behind the scenes).
I've also looked at "SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI\LastLoggedOnUser" in HKLM, but in testing that's unreliable and doesn't get updated.
I'm really only interested in console logons, rather than Fast User Switching or TS logons.
I've read various articles, but have yet to come up with a good solution.
You might be able to use Audit Logon events - this requires your service to have a user access right to see the Security log, but not be a full Administrator.
Eventid 528 indicates who logged on, you'd have to find the most recent instance of this.
We have developed a ASP.NET 3.5 web application with Web Server 2008 and has implemented a custom authentication solution using active directory as the credentials store. Our front end application uses a normal login form to capture the user name and password and leverages the Win32 LogonUser method to authenticate the user’s credentials. When we are calling the LogonUser method, we are using the LOGON32_LOGON_NETWORK as the logon type.
The issue we have found is that user profile folders are being created under the C:\Users folder of the web server. The folder seems to be created when a new user who has never logged on before is logging in for the first time. As the number of new users logging into the application grows, disk space is shrinking due to the large number of new user folders getting created.
I need to get the token back after the authentication (authenticated \ password locked \ wrong password ) its futher use and based on logic showing different web pages
Has anyone seen this behavior with the Win32 LogonUser method?
Please answer the following issue:
Is it possible to disable this behavior to create the folder as taking 2.78 MB of space for every new user and it eating my disck space?
I have tried LOGON32_LOGON_BATCH but it was giving an error 1385 in authentication user.
For any solution related to LOGON32_LOGON_BATCH, can you please confirm if that will stop creating the folders at location C:\users.
Also for any possible solution I need either
I am able to disable the folder to be created at C:\user or
Any other option to authenticated user which will not creat folders.
Pass LOGON32_LOGON_BATCH and grant the users permission to log on as a batch job on that machine using Group Policy.
The MSDN documentation for LogonUser recommends LOGON32_LOGON_BATCH as the logon type for web services:
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. The
LogonUser function does not cache
credentials for this logon type.
Have you tried that?
You don't write any information about the version of products (.NET, Windows Server which you use) and the best answer on your question can depend on this. Moreover the best way for your solution depend on what you want to do with the users token after logon. Do you really want to use this token or you want only verify the user? So I try to answer most general on your question.
In general, error 1385 (ERROR_LOGON_TYPE_NOT_GRANTED) means following (see http://support.microsoft.com/kb/155012/en):
A user has requested a type of logon,
such as interactive or network, that
was not granted. An administrator has
control over who may logon
interactively and through the network.
There are SE_BATCH_LOGON_NAME and SE_DENY_BATCH_LOGON_NAME (NTSecAPI.h) privileges which can be disabled/enabled in your case (see http://msdn.microsoft.com/en-us/library/bb545671%28VS.85%29.aspx for description). Use Process Explorer started with administrator rights (see http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx) to see which privileges has a process and which from there are enabled (see "Security" tab of a process). If your account used for the application pool don't have SE_BATCH_LOGON_NAME granted or this privilege is not enabled before call of LogonUser, you should add the corresponding code in your program.
By the way sometimes you don't really want to do much with an user account and want only verify a password. To do this you can use an old way with SSPI (see http://support.microsoft.com/kb/180548/en) which are used inside of LogonUser implementation. This way is the most smart and quick way to verify an user account which I know.
You can look at "The SSPI Workaround" (see http://alt.pluralsight.com/wiki/default.aspx/Keith.GuideBook/HowToGetATokenForAUser.html) for more information of usage SSPI in .NET 2.0.
Let's say we have an application that has a number of features and each feature as a permission set of users that are allowed to use that feature. The application is designed to be always-on, but at different times during the day we want different users to log on and use it.
Rather than reinvent the wheel and create yet another user account and password system, we'd like to use built-in Windows user accounts (for authentication) and Windows groups (for feature access).
Is it possible to leave the application running but have different users come along and log in and log out of the application without logging out of the Windows session?
There is a mechanism called Impersonation (link points to .NET documentation, but the core Windows APIs provide similar features). It allows you to programmatically run code in a context of a different user than the one currently being logged in. There are, however, other security implications to the model you describe. In particular: how do you protect the rest of the workstation your program is running on?
Well, you could certainly have the application get the user's windows credentials. You could also simply query for group membership without requesting any credentials. More specific information will help with a more specific answer. For instance, what language are you working in?