Strategies for implementing station admins?

[Daklu]

Last Thurs I found out a client wants the test system to have protected "administrator" functions such as station calibration routines and setting up the system for new DUTs. They'd prefer station security tie in directly to the operator's windows logon.

The simplest thing I can think of is to restrict write permissions to the config file directory and attempt to write a dummy file if any administrator functions are invoked. If the write succeeds, allow the process to continue. If not, disallow it. The upside is that this also prevents non-authorized users from modifying the config files outside of the application. The downside is that it's all controlled through Windows admin utilities.

Has anyone ever done anything like this?

[Mads]

Most of the software I make have different levels of access. I also need to allow the customer to turn off all file IO and print options. Logins should time out after a while in case someone has forgotten to log off.

One of the easiest ways to achieve this is to include a key in the tag of all menu items with restrictions, buttons etc- and then either automatically grey out and disable these (you can write a generic VI that scans the GUI for these when a window is opened) depending on the access of the current user, and/or filter any events if the key in the tag/name requires elevation. How easy this is to implement in your code depends on how the GUI is handled. I typically put the GUI handling in separate VIs if it is of a certain size and complexity, and this makes it easy to apply access rights checks on incoming events.

A user configuration panel is nice to have, unless you get those by other means. I have one that allows me to give users local and/or remote access to the system. The in-built server then checks the user list if it gets a session request from a remote client. The same GUI offers the possibility to turn off user checks locally, in case the server is not running anything else and is sufficiently protected by Windows.

[silmaril]

Many customers want some kind of password protection for their configuration.

But at the same time, most of them don't want anything too complex (aka expensive) or bothersome to work with.

So we often end up with an application that can be used without logging in and a password to get administrative privileges (or sometimes two levels of passwords).

The problem with this: If it's only a password with no connection to individual user names, you can be sure that everyone will know it rather sooner than later. In many cases you will find a post-it with the password on the screen after three days.

If each user has his own password, you need to have a user management interface and someone has to create all the users. This might perhaps be done at the initial setup, but after three months, everyone will usually log in as "admin" with the password "1234".

The only thing I can image that really works, even in "undisciplined" environments (aka 90% of the industries):

Have the user identify himself with his legic chip. The same one that he uses to pay for his coffee from the vending machine and his lunch from the factory canteen.

People usually tend not to give those away to others carelessly.

It might even be possible to encode the priviliges in the administrative interface in the office that hands out these chips. This way there would be no need to have any user administration on the machine.

I've never actually tried this, but I'd really love to.

[mje]

Well, determining if you're running under an administrator privilege is easy enough:

But like you implied, you're probably going to have to serialize that config info somewhere, so you're going to need a file. Restricting the ownership of the config file to the administrator group is probably what you want, and successfully being able to open it for write operations should clue you into if you're good to go.

-m

[Tim_S]

Last Thurs I found out a client wants the test system to have protected "administrator" functions such as station calibration routines and setting up the system for new DUTs. They'd prefer station security tie in directly to the operator's windows logon. [snip] Has anyone ever done anything like this?

We have a security service that is separate from the windows login. The login is Windows-like and is only for the test program. We have Windows auto-login to an operator account with restricted Windows permissions and locked-down operating system level security.

Your client thinks they want to use the Windows login, I would contend this isn't what they want as each time they want to calibrate or perform some administrative task they would have to put the machine in a safe state, shut down the test program, log out of windows, log back in to windows, launch the test program, do what they want to do, rinse and repeat. All of that can be exceptionally time consuming especially if you are leveraging certain applications that take a long time (5 minutes) to launch (*cough* Siemens OPC server) every time you log in.

Tim

[Mark Smith]

If you're deploying to Windows 7, the UAC stuff should work for you. If you drop the protected config information in the Program Data folder, then it's automatically protected for write access to only users logged in with administrator privileges. You can use the shell32 call MJE pointed out to set properties on your program depending on detected user privileges. And if you need to modify files you can do that while the standard user is logged on by using the UAC dialog that will allow the write if the user can supply administrator credentials.

Mark

[jdunham]

The downside is that it's all controlled through Windows admin utilities.

That's not a downside. This puts the ongoing maintenance of permissions on IT where it belongs. You just document that it they need to control write access to your designated folder. I would probably put it in a folder called <Public Application Data>/Company/AppName/AdminSettings.

Your idea of testing the ability to write before accepting input from the user is very polite.

[Tim_S]

That's not a downside. This puts the ongoing maintenance of permissions on IT where it belongs. You just document that it they need to control write access to your designated folder. I would probably put it in a folder called <Public Application Data>/Company/AppName/AdminSettings.

Are you referring to test program permission (e.g., modify test plans and calibrate) or operating system permission (e.g., directory/folder and device access)?

Tim

[jdunham]

Are you referring to test program permission (e.g., modify test plans and calibrate) or operating system permission (e.g., directory/folder and device access)?

I'm not sure if I understand your question exactly, but I was commenting on the OP's idea of implementing test program permissions by means of the operating system permissions.

[Tim_S]

Are you referring to test program permission (e.g., modify test plans and calibrate) or operating system permission (e.g., directory/folder and device access)?

I'm not sure if I understand your question exactly, but I was commenting on the OP's idea of implementing test program permissions by means of the operating system permissions.

I see permissions on the test PC as two things: access to the features of the test program and access to the operating system. The test program has permissions including calibration, maintenance (manual) operations, test execution, and test and limit editing. The operating system has permissions to access files and directory, programs, and system and user configurations. I believe IT should and must be involved with the operating system permissions, but is (at most) optionally involved in the test program permissions.

Tim

[jdunham]

I see permissions on the test PC as two things: access to the features of the test program and access to the operating system. The test program has permissions including calibration, maintenance (manual) operations, test execution, and test and limit editing. The operating system has permissions to access files and directory, programs, and system and user configurations. I believe IT should and must be involved with the operating system permissions, but is (at most) optionally involved in the test program permissions.

I think I agree that those should be separate, but you should leverage the OS infrastructure to implement the test program permissions.

If you use your own password system, it's totally insecure. The OS people put tons of work into a secure infrastructure for authentication, and you can't really hope to compete with that. Once two people need to know the same password, they are going to write it down, usually on a post-it affixed to the monitor, or if they want extra security, they will tape it to the back of the monitor!

It's much better to use per-person authentication and the assignment of roles, rather than just having an "admin" password. If some person is fired, their access to your test system will cease as soon as IT shuts off their login. If IT is too slow to change users' test program roles when needed, they can give local supervisors a limited admin role on those folders and control the access, but it's still all done on the OS side. All of this comes for free and all the developer needs to do is set up the roles.

[Daklu]

Thanks to everyone for responding. There are lots of good ideas here. I'm going to have to talk to the client again and get more details about how they expect use the station administrator mode before I implement anything. Tim and Jeff (**crosses fingers hoping my memory hasn't failed me**) both raised valid concerns and their discussion prompted another question I hadn't considered before:

In corporate environments where IT locks users out of the windows administrators group, is it still possible for plain vanilla users to create custom user groups and control access to them on a per-user basis? (This station will be deployed on Win 7.) It's been well over 10 years since I've worked for a company that paranoid of protective of the users. I've done it many times myself, but then I'm always an administrator on my machines.

Well, determining if you're running under an administrator privilege is easy enough:

I ran your snippet (well, recreated it since I can't drag it to a block diagram using Win7 and IE09... probably more permission issues...) and I'm not getting the right answer out of it. It tells me I'm not an admin, even though clearly I am. Help files recommend using CheckTokenMembership instead of IsUserAnAdmin, but if I go that route there a lot more stuff I need to understand.

And in a mostly unrelated side note, I stumbled across this little oddity...

(I have this nagging feeling that there is a significant difference between the yellow node and the orange node, but for the life of me I can't remember what it is.)

[crelf]

We use active directory - you can create groups, and add memebers to thsoe groups: then query the groups for their members - if the logged on user belongs ot the group, then enable the functionality. This is beneficial for several reasons, including the ability to decouple "admin"-like functions from actual software application admins and local (or network) PC admins (these two groups are rarely the same, so there's little reason to couple them), and also that you can manage user access remotely using native controls (I know ppl often shy away from asking their IT departments to do anything, but all they need to do is create the groups, and give you permission to add/remove people to/form them). It's simple, and it's easy to control.

[jgcode]

(I have this nagging feeling that there is a significant difference between the yellow node and the orange node, but for the life of me I can't remember what it is.)

I believe it is to do with the reentrant\thread setting in the Call Library Function's configuration dialog.

[mje]

Orange nodes are configured to run in the UI thread, yellow ones run in any thread. For IsUserAnAdmin() I don't think it should make a difference, but many other Win32 API calls must actually be called via the UI thread (specifically ones which are not marked as thread safe). Come to think of it the documentation for IsUserAnAdmin doesn't comment on thread safety, so it should probably be forced into the UI thread.

I'm not sure why you're supplying an initial value to the return variable? Does LabVIEW even let you do that (it shouldn't).

Also noted this gem in the docs:

This function is available through Windows Vista. It might be altered or unavailable in subsequent versions of Windows.

Darn.

[Daklu]

I'm not sure why you're supplying an initial value to the return variable?

I didn't when I was trying to figure out how to get it to work. It's just something weird I stumbled upon.

Does LabVIEW even let you do that (it shouldn't).

Only if you know the secret pass-phrase and sacrifice a box of stale Peeps in a WalMart parking lot.

[asbo]

I'm not sure why you're supplying an initial value to the return variable? Does LabVIEW even let you do that (it shouldn't).

I've seen this before and for some reason I was left with the distinct impression that it did some sort of pre-allocation or maybe passed by-ref. Of course, this is hardly more than weak speculation, and the pre-allocation bit doesn't really make sense with LV's memory management model. I'd love to hear if this is anything more interesting than a no-op.

[jdunham]

Tim and Jeff (**crosses fingers hoping my memory hasn't failed me**)

My bad, I hardly ever sign my posts.

Jason

[Daklu]

Jason

Doh! Sorry.

(Though I did figure out why Jeff popped into my head.)

Only if you know the secret pass-phrase and sacrifice a box of stale Peeps in a WalMart parking lot.

BTW, the secret pass-phrase is ctl-space, ctl-d. (Make sure you have quick drop installed.)

I made up the part about sacrificing Peeps.

[Tim_S]

If you use your own password system, it's totally insecure. The OS people put tons of work into a secure infrastructure for authentication, and you can't really hope to compete with that. Once two people need to know the same password, they are going to write it down, usually on a post-it affixed to the monitor, or if they want extra security, they will tape it to the back of the monitor!

It's much better to use per-person authentication and the assignment of roles, rather than just having an "admin" password. If some person is fired, their access to your test system will cease as soon as IT shuts off their login. If IT is too slow to change users' test program roles when needed, they can give local supervisors a limited admin role on those folders and control the access, but it's still all done on the OS side. All of this comes for free and all the developer needs to do is set up the roles.

It seems we have a difference in philosophy. I don't believe I need to compete with OS security; I believe I need to "keep my little sister out". The security level needed for a plant test station is quite minimal in that it needs to keep honest-people-honest and prevent the idle individual from making undesired changes. I agree they should not be taping the passwords to the front of the monitor or Sharpie the password inside of the rack door (yes, customers do this). Someone who is fired loses physical access to the test station upon being escorted out of the building and would have to go through the much more secure plant network to gain access from the outside.

I should note the systems I put together do not have government security clearances on them or anything of the like. I can see using an operating system login for such systems, especially when you exceed confidential data.

We use active directory - you can create groups, and add memebers to thsoe groups: then query the groups for their members - if the logged on user belongs ot the group, then enable the functionality. [snip...]

Interesting. I shall have to look into this.

Tim

[Daklu]

It seems we have a difference in philosophy. I don't believe I need to compete with OS security;

I don't think Jason is suggesting a competing security system; he's saying use the functionality provided by the OS. (i.e. Windows login.)

Ultimately the decision is driven by customer requirements. If they want a single password for all valid operators or if they don't have a good IT infrastructure, I expect I'd go more along the lines of what you suggested. If they want finer-grained control and have the infrastructure to back it up, using the available windows security functions seems like a better solution.