0

I've been asked to write a C# application to run on a Windows 7 machine to display the time of day, weather, etc.. That I can do. What I'm looking for is guidance to run the application on a Windows7 machine without logging as a user. In essence the machine would simply be a CPU with a screen. No keyboard or mouse. I've seen deployments done on MS-PixelSense (use to be MS-Surface) using a service ID.

If I need to signin, user policies kick in, screen savers enable, etc.. I'm assuming if I use an automatic Service ID, I can let the application override most of the settings keeping the screen on and needed privileges assigned / locked down to the service ID.
Any information / suggestions are appreciated....

Robert Fleming
  • 145
  • 4
  • 15
  • What do you mean by "Service ID" ? Do you mean what I know as a "technical user account", which is basically just a normal user account, but not corresponding to a real person ? Shall this machine become a member of an Active Directory domain or be a stand alone system ? How shall this machine communicate with other machines ? Do you think of something like autologin feature (see e.g. http://www.computerperformance.co.uk/windows7/windows7_auto_logon.htm) – Rainer Schaack Feb 25 '15 at 23:32
  • The goal of the application is to turn a low powered windows7 machine into an advertisement display. content would feed from a central network drive. Once configured I'd expect tosimply turn the unit on, and windows would launch the designated application. No user interface required for signon, But the account would still need enough privledge to access the network. My understanding of a service id is much like the one assigned to IIS when installed. I'd lean on that, except it is not allowed to run any user interface... – Robert Fleming Mar 02 '15 at 21:35
  • I have done a kiosk implementation with ~100 machines with Windows XP. I will check this under Windows 7 soon. I will give a answer here with some suggestions and tips. Give me a few days ... – Rainer Schaack Mar 05 '15 at 07:28
  • Yes, I just tested my control service under Windows 7, so I can say that this is working fine. In addition, I found another software (www.logonexpert.com), which I am testing now. (It took a bit since I created a new virtual test environment). I will inform you as soon as I made my first experiences with this SW. (Tuesday / Wednesday) – Rainer Schaack Mar 09 '15 at 19:39
  • Cool.. Appreciate the insight.. – Robert Fleming Mar 10 '15 at 20:22

1 Answers1

1

First, some background informations:

Accessing a network share

If a process running on your client wants to access a (CIFS) share, it has to be run under a user account (or "Service ID") which has access rights to this share. There is a way (if the client is a member of Active Directory) that the machine name appended with $ (which is in fact the machine account’s name in AD) has to be entered in the ACL (Share / NTFS), but this is not a very "usual" way.

See also https://serverfault.com/questions/41130/network-service-account-accessing-a-folder-share

Windows Service running under a user account (aka technical account or Service ID)

A service running under a user account cannot access the GUI. There are some tricks, and some years ago I wrote a tool which allows a service to start another GUI program, where the GUI is displayed above the Ctrl-Alt-Del dialog. But this does not work under Windows 7 anymore. But even a service which runs under local system cannot display a GUI on the logon screen. You would have to write a Credential Provider.

See

Windows service showing a GUI when no user is logged in

https://stackoverflow.com/a/3074040/4547223

Another very deep technically article. It says it is possible to display a GUI on the secure desktop / logon screen. I have not yet tested this myself:

http://calebdelnay.com/blog/2012/01/displaying-a-program-on-the-windows-secure-desktop

Autologon

The most well known way is still the "classic" autologin.

See https://security.stackexchange.com/questions/10170/how-secure-is-windows-auto-logon for some explanations and links. The medium secure way is to store the password as LSA secret (can be done in C# with P/Invoke or with some tools).

If I need to signin, user policies kick in, screen savers enable, etc.

Yes, but this can be handled, you probably have to create an own AD OU with an own policy for that.

I'm assuming if I use an automatic Service ID, I can let the application override most of the settings keeping the screen on and needed privileges assigned / locked down to the service ID.

A service ID /technical account is basically the same as a normal personal user account. In some Active Directory enterprise environments a technical account has restrictions that it cannot log on interactively and other restrictions. But it still IS a "user account"

Logonexpert (http://www.logonexpert.com/)

I tested this (trial version). It is a nice, small tool which does it’s job. It is more safe than "normal autologon", however in the end, it is not much different from normal classic autologon. One benefit: it stores the password more recurely, but in theory, some hacker may still decompile the program and find out a way to decrypt it. And more important for you: Beside the more safe password store, it does not gain you much. You still have a user login same as normal autologon.

A few suggestions

Probably you can use a local user account on the client system and use normal autologon mechanism. And then you should consider that the client system does not poll for new data on a network share, but instead another server program (implemented as a service, running under a technical domain account) pushes data on a network share on the client.

Doing it this way, the client code does not need to access network shares, with the benefit, that a malicious attacker also has no access to network shares.

If you really need to access a network share from the local user context, you can probably logon to the server, as explained in my answer here:

https://stackoverflow.com/a/28749093/4547223

You have to to change the registry code part with the access to the CIFS share.

But doing it this way, you again have a password, which you have to encrypt and store. I do not recommend this.

In the end...

Windows does not make it easy what you want to do. If you are not strictly bound to Windows, you can consider using a Raspberry Pi with Raspbian (a Debian derived Linux). You can install Chromium browser, which displays a web page on the server and updates automatically. We use this with great success for some time.

Community
  • 1
  • 1
Rainer Schaack
  • 1,558
  • 13
  • 16
  • thanks for the in depth look. I'm kind of stuck with the O/S and environment due to company IT policies, and as with most orgs they want me to do it on the (perceived) cheap. I think the AutoLogon is the right answer for this. I'll have to give it a try and tailor a solution to fit. – Robert Fleming Mar 11 '15 at 14:26