[Solved] Daemon on Windows with updating display

[avra]

One of the ways to achieve what you need could be to automatically login to a known user and start your custom shell instead of explorer.exe. That application could display what you want, and show a fake login screen to allow authenticated users to proceed to desktop or start different application for each user. Although you can mimic different environment for different users this way, things complicate if you really need each user to have his own desktop like different users have when logged into Windows. Not impossible but complicated, so if you need this special case then some other approach would be easier.

[TyneBridges]

John is talking about organizational use:
... so presumably he's got AD set up there and company IT can determine what can run on those machines, not the users.

That's right - as long as I keep my bosses happy, I can control what runs.

Avra's idea is interesting - we use a mandatory profile but each user has his/her own documents and a small quota of disc space. My reservation is that the fake login screen might clash with the processes I already have in place for each user, to check disc space and account expiry and to log Internet activity.

[TyneBridges]

Apologies for bombarding the forum with queries. I wasn't sure whether to post this in the Windows subforum, or as a continuation of this topic.

People have been very helpful. As some readers know, I've struggled with this project from the start. I have made progress (have got the timer to work and can run my GUI app, but not see it). I found some example code that seemed to do just what I wanted:

http://stackoverflow.com/questions/3070152/running-a-process-at-the-windows-7-welcome-screen

Unfortunately it was written in C#, a language I don't know at all. By reading between the lines I think I've managed to translate most of this. However, I'm stuck on the following line.

Code: [Select]

if (!DuplicateTokenEx(userToken, 0x10000000, ref tokenAttributes, SECURITY_IMPERSONATION_LEVEL.SecurityImpersonation,
            TOKEN_TYPE.TokenImpersonation, out newToken)) {
            log("ERROR: DuplicateTokenEx returned false - "         
My Pascal version:

Code: [Select]

     If Not DuplicateTokenEx(UserToken, MAXIMUM_ALLOWED, tokenAttributes, SecurityImpersonation, TokenPrimary, newToken) then
        Writeln(DLog, 'Failed to duplicate security token');   
Lazarus throws an error on the fifth of the six parameters.

      dmain.pas(189,110) Error: Incompatible type for arg no. 5: Got "TOKEN_TYPE", expected "_TOKEN_TYPE"
      
The same error is thrown if the parameter value is TokenImpersonation and I can only guess at what it means. Do I need a pointer instead of a direct reference and, if so, how do I amend the parameter? (Adding ^ before TokenPrimary just gives a different error). 

[ChrisF]

...and can run my GUI app, but not see it...

I'm not sure to understand what you mean with "GUI app", so I could be wrong (just discard the following remarks, in this case).

But, if you mean a GUI app running inside your service, you can't.

'Till Windows XP, it was possible. There was an option to allow a given service to interact with  the Desktop. But since Windows Vista, services run in a particular session (session 0), and so this option is no more allowed (for security purposes).

If you want to interact with the Desktop, you need to have a specific GUI application able to "communicate" directly with your service (generally through named pipes).

*** Edit *** : These remarks have been already done by a few other users in this topic. Sorry.

[ChrisF]

BTW, DuplicateTokenEx compiles fine here:

Code: [Select]

...
 If Not DuplicateTokenEx(UserToken, MAXIMUM_ALLOWED, tokenAttributes, SecurityImpersonation, TOKEN_TYPE.TokenImpersonation, newToken) then
...


[TyneBridges]

...and can run my GUI app, but not see it...

I'm not sure to understand what you mean with "GUI app", so I could be wrong (just discard the following remarks, in this case).

But, if you mean a GUI app running inside your service, you can't.

No - I can get the service to start the separate GUI executable (which is not a service, isn't interactive with the user, and is just meant to show an updating status) but it isn't visible. I know it's meant to run in the desktop 'Winsta0\Winlogon' and that's the difficult bit. If I can get over this hurdle, I will go on to the communication between the two apps, using IPC.

Someone else has told me that the application didn't compile because some of the parameters are addresses ("ref" in C#) and therefore should be preceded by @. When I added this to the appropriate ones (I think) it still didn't compile for me.

[ChrisF]

Not sure about what you mean by "... the application didn't compile..." . As indicated before, the API call you've indicated as having a trouble is correct here.

For instance, this is OK for the compilation (though not working properly - you need to initialize the concerned variables first):

Code: [Select]

uses windows, jwawindows;

var DLog: TextFile;

procedure test;
var UserToken, newToken: HANDLE;
var tokenAttributes: SECURITY_ATTRIBUTES;
begin
   If Not DuplicateTokenEx(UserToken, MAXIMUM_ALLOWED, @tokenAttributes, SECURITY_IMPERSONATION_LEVEL.SecurityImpersonation, TOKEN_TYPE.TokenImpersonation, newToken) then
      begin
         Writeln(DLog, 'Failed to duplicate security token');
      end;
end;


Anyway, I don't want to be negative, but I'm not sure this method is the right choice.

I don't know it, neither the concerned API calls, but:
-as spotted before, this method won't work in Windows XP (and you've indicated it, in one of your previous post). At least, if might work, but with a different code,
-I'm not even sure it will be working as this in Windows 8 (and further). With their new "Modern UI" interface activated by default, it's quite possible that the logon process has changed; and so that it won't work exactly as for Vista/Windows 7,
-elevating the privileges like this (logon process), and for a non essential application, seems to be quite dangerous to me. Because of  the possible security issues, Microsoft could feel the same in the future; and so, forbid it (or change it).

Considering what you are trying to do (i.e. displaying infos in the screen), what about a screen saver ?

It's certainly not perfect, but at least it should be quite easy to make one. Furthermore you can have a different one in the logon than the one for the windows user(s), and with a different delay (as a short one, for instance, let's say 10 seconds). And it seems it's still working the same in Windows 7 (Ref: http://answers.microsoft.com/en-us/windows/forum/windows_7-desktop/no-screen-saver-at-windows-7-welcomelog-in-screen/a437ee54-6f7f-48fd-8413-7338480948d8 ).

A test should be done before (i.e. as a proof of concept), on various windows versions. Plus it's possible it's not working with Windows 8 (because of the Modern UI), but I guess a simple try could be easy.

[TyneBridges]

Anyway, I don't want to be negative, but I'm not sure this method is the right choice.

I don't know it, neither the concerned API calls, but:
-as spotted before, this method won't work in Windows XP (and you've indicated it, in one of your previous post). At least, if might work, but with a different code,
-I'm not even sure it will be working as this in Windows 8 (and further). With their new "Modern UI" interface activated by default, it's quite possible that the logon process has changed; and so that it won't work exactly as for Vista/Windows 7,
-elevating the privileges like this (logon process), and for a non essential application, seems to be quite dangerous to me. Because of  the possible security issues, Microsoft could feel the same in the future; and so, forbid it (or change it).

Considering what you are trying to do (i.e. displaying infos in the screen), what about a screen saver ?

It's certainly not perfect, but at least it should be quite easy to make one. Furthermore you can have a different one in the logon than the one for the windows user(s), and with a different delay (as a short one, for instance, let's say 10 seconds). And it seems it's still working the same in Windows 7 (Ref: http://answers.microsoft.com/en-us/windows/forum/windows_7-desktop/no-screen-saver-at-windows-7-welcomelog-in-screen/a437ee54-6f7f-48fd-8413-7338480948d8 ).

A test should be done before (i.e. as a proof of concept), on various windows versions. Plus it's possible it's not working with Windows 8 (because of the Modern UI), but I guess a simple try could be easy.

Thanks for the hints. Chris. For the foreseeable future, my project will only need to work on Windows 7, which is also the OS I'm testing it on.

I hadn't thought of using a screen saver but, bearing in mind the way it should operate, will that actually work? The trickiest thing is to get a status display (showing whether the PC is booked, whether the service point is open etc) before a user logs on. Doesn't a screen saver only activate during a user's session (i.e. after they log on) when there's no activity for the specified period?

Edit: I see from your linked post that it's possible to enable it before logon, but can it be given facilities like other applications to connect with external databases, update its content on a timer etc? Obviously I will investigate these things before doing the work but you may already know.

[TurboRascal]

No - I can get the service to start the separate GUI executable (which is not a service, isn't interactive with the user, and is just meant to show an updating status) but it isn't visible. I know it's meant to run in the desktop 'Winsta0\Winlogon' and that's the difficult bit. If I can get over this hurdle, I will go on to the communication between the two apps, using IPC.

You shouldn't try starting GUI executables from the service because it still counts as "service interacts with desktop", which is forbidden. The whole point is that you start both applications separately, and then communicate by IPC; it also makes sense, because services are privileged processes, and you really don't want a GUI-based "status monitor" app to be privileged. The monitoring app should be started as a normal app, like from the registry Run sections, Start Menu Startup folder, startup/login scripts etc.

Perhaps you could try researching into the original, Unix daemons; if you know how they work, it all makes perfect sense.

[TyneBridges]

You shouldn't try starting GUI executables from the service because it still counts as "service interacts with desktop", which is forbidden. The whole point is that you start both applications separately, and then communicate by IPC; it also makes sense, because services are privileged processes, and you really don't want a GUI-based "status monitor" app to be privileged. The monitoring app should be started as a normal app, like from the registry Run sections, Start Menu Startup folder, startup/login scripts etc.

Perhaps you could try researching into the original, Unix daemons; if you know how they work, it all makes perfect sense.

Obviously I still have a lot to learn. I don't know how to get the GUI app to run and be visible on the desktop Winsta0\Winlogon, unless it's started from the service, with extra privileges as discussed. I think I understood from early on that it could be started via the registry or even via Group Policy, but there seem to be no options there to make it visible on the pre-logon desktop.

[taazz]

This has gone long enough. Forget about writing a daemon to control the user login in any meaningful way, for that you need a GINA dll on XP and a Credential Provider on vista and later. For gina a good start is https://sourceforge.net/projects/knightgina/, for a CP read the following http://twrightson.wordpress.com/2012/01/02/capturing-windows-7-credentials-at-logon-using-custom-credential-provider/ to get a better idea on what is going on. With delphi you can write an activeX library and choose to implement the corresponding  interface of ICredentialProvider on lazarus I guess that you need to find the definition and create them by hand. In any case with a credential provider you can limit what the end user sees on the screen as well as auto login based on what ever method you desire eg a smart card that has the users credentials on it or read them from a database on the network. That only leaves the auto log off from a service application and this http://stackoverflow.com/questions/5207506/logoff-interactive-users-in-windows-from-a-service should give a guide on what you need to do.

That took me a hole 15 minutes to find on google so it is safe to assume  I have never implement something similar my self.

[BigChimp]

Guys, if people would take the trouble of actually reading the thread before commenting you would have found many of you are rehashing things that have already been said.
(Yep, guess who mentioned dear Gina first? )

I don't think this going around in circles is very useful...

[taazz]

Yes I know that my answer repeats the same point of view from previous posts it was mend as an emphasis factor and at the same I added links to avoid being a useless post.

[TyneBridges]

Thanks for the input, Taazz. Unfortunately writing a Credential Provider is completely beyond me (I'm just not that good a programmer) so I am still looking for any viable way to avoid that. The main problem with the system I want to replace is that it's very prone to crashing. However, it doesn't seem to use a Credential Provider, as it's happy to log on users and then log them off again if the logon was "illegal". I will settle for doing the same, which should be much easier, using the ExitWindowsEx function.

[taazz]

Well you have all the info you require to do it properly and you still want to do it the wrong way because

I'm just not that good a programmer

What gives you the confidence that you will do a better job than the program you already have?
Keep ignoring the OS documentation and you will probably fall in a bigger mess that you already have.