Shaitan00

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,

Issue resolved - the actual MSDN link works fine, the issue was that I was not correctly porting the code to C# and my LogonUser p/invoke was incorrectly implemented with ENUMS which caused for valid results (thus no errors or exceptions) but provided with invalid token types for performing the LoadUserProfile. (http://support.microsoft.com/kb/196070/en-us) Thanks to all that helped...!

Is there a way to force a logoff (knowing this is not recommended) of the current interactive (logged-on) user and then login with a new user account (interactive - not using stuff like LogonUser and other impersonation tricks) to simulate someone physically pressing LOGOFF and then selecting a new account to LOGON...? The issue is that my service creates a new user account programatically - and I need to find a way to create its corresponding user profile. From what I can see the only way that works would be to physically logoff the current user, and then login as the new user (which will create the User Profile for HKCU, Documents & Settings, etc...). Sounds a little crazy but I can't find a better way... So, I need to find a way to programmatically force the logoff & logon actions (from my running Windows Service under LocalSystem) - I have all the credentials and access rights needed ... Are there system function calls I can use? For Logoff I think I can use WTSLogoffSession(...), still trying to get it to work but seems promising - however I have no clue what to do about logon... Alternitively if there is a better approach to solve my problem I am all ears :) Any help or hints would be much appreciated... Thanks,

I have a tool which I use to programmatically create local user accounts as follows: DirectoryEntry NewUser = dirEntryLocalMachine.Children.Add("UserName", "user"); NewUser.Invoke("SetPassword", new object[] { "Passsord" }); NewUser.Invoke("Put", new object[] { "Description", "Description" }); NewUser.CommitChanges(); [/Code] The account is created fine but at at this point the User Profile does not exists (no HKEY CURRENT USER, no Documents & Settings, etc...), I was doing some research into this and found the following MSDN article that says calling LoadUserProfile(...) will actually create the profile if it does not exist: http://support.microsoft.com/kb/196070/en-us So I added the code as follows: [Code] IntPtr hToken = IntPtr.Zero; bool bLogon = LogonUser( sName, sDomain, sPassword, LOGON32_LOGON_NETWORK, LOGON32_PROVIDER_DEFAULT, out hToken ); PROFILEINFO profileInfo = new PROFILEINFO(); profileInfo.dwSize = Marshal.SizeOf(profileInfo); profileInfo.dwFlags = 1; profileInfo.lpUserName = sName; bool bLoad = LoadUserProfile(hToken, ref profileInfo); [/Code] Now, both bLogon and bLoad are true, no exceptions occur, everything "seems" to work fine ... The contents of profileInfo are not updated (I would have assumed field like .lpProfilePath should have good values) and GetUserProfileDirectory() fails to find the path (obviously - it doesn't exist) - I also check manually and there is nothing under "documents & settings" for the new account. Anyone have any clues as to what I am doing wrong? Any help would be much appreciated. Thanks,

Simplified Question: My system has 2 accounts (USER and ADMIN), the user is always logged on as USER but at some specific times a process (Tool.exe) is launched under the ADMIN account (by a LocalSystem Service using CreateProcessAsUser(...)), almost everything works fine except for the fact that the process (Tool.exe) is supposed to display status to the user using CreateWindow(...). When Tool.exe is running (as ADMIN) and the user is logged-on as USER the window is not shown (obviously)... Is there a way to show the window of Tool.exe running under ADMIN to the user logged-on as USER? Any help would be much appreciated... Thanks,

My system has 2 accounts (USER and ADMIN) and a service (Service.exe) running under LocalSystem. The user logs into the USER account, the LocalService can then launch a process (CreateProcessAsUser(...)) as the ADMIN user. The process the Service runs (Tool.exe) is a legacy C++ application that performs a job and also displays information to the user by using CreateWindow(...), but when launching it by the Service the Window does not show... When the process is created by the Service I first load the Profile & Environment of the ADMIN user so that the correct context is used ... (was still hoping the Window would display to USER) Now, initialy I thought this would cause a problem as ADMIN is running the process so why would the CreateWindow(...) output in the USER desktop, so I tried with a simple command-line test.exe app and when launched as ADMIN the Command Prompt window appeared - so why does that work fine where-as the CreateWindow(...) doesn't display correctly? Any clues on how I can get the STATUS (using CreateWindow in Tool.exe) running under ADMIN to show in the USER logged-on session? Can I use the ENVIRONMENT somehow, I tried the following thinking it might work but didn't: startInfo.lpDesktop = @"WinSta0\Default"; startInfo.dwFlags = STARTF_USESHOWWINDOW; startInfo.wShowWindow = SW_SHOW; [/Code] The Window is created as follows (in Tool.exe): [Code] HWND hwnd = CreateWindow ( "Tool", "Tool WINDOW", WS_POPUP | WS_VISIBLE, 0,0,uWidth,uHeight, NULL, NULL, hInstance, Text ); [/Code] Is the lpDesktop wrong (not exactly sure how this works)? I know how crazy this sounds - I just would rather not have to launch another ToolDisplay.exe as USER which communicates with Tool.exe as ADMIN as a display when the Tool.exe used to handle everything on its own - so checking to see if there isn't some nice way to handle this... Any help would be much appreciated... Thanks,

I need to find a reliable way to update a running Windows Service (Service.exe). The service is run under the LocalSystem account whereas the logged-in user is in a non-admin User account. My current solution would be as follows: - The Service.exe checks for updates (files) regularily - When an update it found it starts another service (Launcher.exe) that would stop the Service.exe, copy over the files, restart Service.exe, then stop itself After doing some online-reading and from some of my previous forum posts I beleive this would be the appropriate solution - but before I go ahead I wanted to check with all the guru's and see if I am forgetting something important or if there is a better way. I did read-up on some method of self-updating (loading & unloading assemblies, etc...) but it just seemed very unsure and I need this to be as robust as possible - if it fails it means someone needs to manually intervene. Any help or hints would be much appreciated. Thanks,

At my company we have a product which pretty much interacts with everything you can imagine... registry, databases, devices, etc... it is composed of many parts but the entire application is launched by a single executable (start.exe) which is responsbile for launching everything else - this is all legacy code and run under a USER account. Currently this is launched as a STARTUP item (or by double-clicking on the desktop icon) in Windows, meaning when the user logins into the USER account the application (start.exe) automatically kicks off, under this account it has all the permissions it needs to run and everything has been fine for years... Now comes the change - I have written a service (Serv.exe) that is running as LocalSystem - this service is responsible for updating the various software components of our product and works as follows: - when the product detects an update it signals the LocalSystem service (Serv.exe) and then terminates itself - Serv.exe will then perform all the updating Now, after everything is done, the product (via start.exe) needs to be launched again automatically ... and this is where I need some advice ... what is the best way to restart the product (start.exe)? Right now I use the LocalSystem Service (Serv.exe) and impersonate the USER account as follows: - CreateEnvironmentBlock for the USER - CreateProcessAsUser(start.exe) as the USER with the corresponding EnvBlock - DestroyEnvironmentBlock But is this really 100% equivalent to double-clicking on the icon in the USER account context? I need to ensure that everything is identical when it is either launched on STARTUP of USER or by Impersonation from Serv.exe (LocalSystem) - is there a risk involved? Will I still have the same rights/abilities with all databases? registry? device interaction? etc.. By loading the EnvBlock I seem to get everything I need but ... is this not a good way to do it...? Kind of hoping for some guidance and advice from the pro's out there ... Any help or hints would be much appreciated. Thanks,

I made the change and it didn't help ... Is it possible I may need to load the ADMIN account profile somehow? Or use ImpersonateLoggedOnUser but pass the Token for the ADMIN account?

I would have assumed JOB.exe being a LocalSystem Service would apply to all cases, logged-in user or impersonated ... could it be that I need to load some kind of context?

JOB.exe is legacy software that monitors registry and file system changes - sadly I don't have the source code available to show exactly how it works but ... it works fine for the logged-in user. Do I maybe have to do something special to my CreateProcessAsUser() to load the environment? Profile? etc... I also noticed that accessing HKEY_CURRENT_USER doesn't seem to work ...

Yes the task being launched under the ADMIN account is actually making the changes I am expecting. Yes JOB.exe succesfully monitors the logged on user, and if I logon as admin it works then also.

There is a LocalSystem Service (Job.exe) which performs a certain absolutly required task (for example: file system watching), this service is run for all users (at least when they logon). There is another LocalSystem Service (Serv.exe) which uses CreateProcessAsUser(...) to launch a process as a different (admin) user. There are 2 accounts, USER (which is the one logged-on) and ADMIN. So this is the scenario ... User logs in to USER account (non-admin) and both LocalSystem Services (Job.exe & Serv.exe) start and work without any problems... Then at a certain point Serv.exe calls CreateProcessAsUser() using the ADMIN account in order to launch an administrative task (note that USER is currently logged in). So far everything is fine - but now a problem happens - the process run by CreateProcessAsUser(...) under the ADMIN is not subject to the LocalSystem service JOB.exe - for example if JOB.exe monitors file-system changes and logs them if I launch a task with CreateProcessAsUser(...) under ADMIN that changes files I would assume JOB.exe would log these - but it does NOT ... So it looks like JOB.exe is NOT running in the context of the ADMIN account when launched using CreateProcessAsUser(...), this is a big deal for me - I need to ensure JOB.exe LocalSystem service is absolutly always running - even when CreateProcessAsUser(...) is used... Is there anything I can do to solve this problem? any help would be much appreciated. Can I load the environment? profile? something to kick-in JOB.exe so that it actually works? Thanks,

I have a class (NamedPipeManager) which has a thread (PipeThread) that waits for a NamedPipe connection using (ConnectNamedPipe) and then reads (ReadFile) - these are blocking calls (not-overlapped) - however there comes a point when I want to unblock them - for example when the calling class tries to stop the NamedPipeManager... How can I interupt it? Using Thread.abort? Thread.interrupt? Is there a proper way to handle this? Refer to the code below which illustrates my current situation main() { NamedPipeManager np = new NamedPipeManager(); ... do stuff ... ... do stuff ... np.Stop(); // at this point I want to stop waiting on a connection } class NamedPipeManager { private Thread PipeThread; public NamedPipeManager { PipeThread = new Thread(new ThreadStart(ManagePipes)); PipeThread.IsBackground = true; PipeThread.Name = "NamedPipe Manager"; PipeThread.Start(); } private void ManagePipes() { handle = CreateNamedPipe(..., PIPE_WAIT, ...); ConnectNamedPipe(handle, null); // this is the BLOCKING call waiting for client connection ReadFile(....); // this is the BLOCKING call to readfile after a connection has been established } public void Stop() { /// This is where I need to do my magic /// But somehow I need to stop PipeThread PipeThread.abort(); //?? my gut tells me this is bad } }; [/Code] So, in function Stop() - how would I gracefully unblock the call to ConnectNamedPipe(...) or ReadFile(...)? Any help would be appreciated. Thanks,

I am using Named Pipes to transfer data from a client (C++) to a server (C#), the client does the following: struct MESSAGE { char cCommand[8]; string sParameter; }; MESSAGE msg; strcpy(msg.cCommand, "COMMAND"); strcpy(msg.sParameter, "DO SOMETHING"); DWORD dwWrote = 0; WriteFile (hpipe, &msg, sizeof(msg), dwWrote, NULL); [/Code] Then, at the receiving end the C# server does the following: [Code] IntPtr chRequest; bool fSuccess = ReadFile(hPipeInst, chRequest, uSize, cbRead, OverlappedPtr); if (fSuccess) byte[] temp = Encoding.ASCII.GetBytes(Marshal.PtrToStringAnsi(chRequest)); [/Code] Now, at the receiving end, I need to transform the temp (byte[]) back into the STRUCT or something equivalent so I can access the members cCommand and sPatameter - but at this point I have no clue how to proceed... In reality doesn't need to be a struct, I just need to extract the data itself. Note - the STRUCT MESSAGE is something I came up with, meaning that it can be changed if a different format would be helpful in the reconstruction (add the length of sParameter for example?), I just need a COMMAND and PARAMETER to be transfered in a single block (if possible). Requirements are simple: - COMMAND is a fixed-length 8-characters long string that indicates what action needs to be performed - PARAMETER is a variable-length (unless this causes issues) parameter dependant on each COMMAND For example: COMMAND = TRANS PARAMETER = C:\FILE.txt C:\NewFolder\FILE.TXT (this is just to illustrate, there are a lot more applications) If possible I would like to extract it as a chunk of data (byte[]) and then pass it along to my application where it could be decomposed, not a fan of reading in the size, then a field, then a size, then a field - that requires that my Communication be overly linked with my implementation. If there is a more suitable way to implement this transfer please let me know... advice would be welcome... Any help would be much appreciated. Thanks,