Want to run 'setup.exe' as admin from VFP app

[randymce]

I wrote a VFP9 app that we use to install software on our network by launching external installers on from the network(ex: f:\setup\setup.exe). Now that we're switching everyone from Windows PowerUsers to Standard users - it runs the installers, but the installers fail. What I am doing now to get around this is running an external script from my VFP app with 'runnas.exe' using credentials of the local root user (I know the password.) Then, in that script (which now has local admin rights), I add the Standard user to the Admin group, launch 'CPAU.exe' to run the installer off the network with credentials of the current user (which now has admin rights as well as drives mapped, etc), then remove the Standard user from the Admin group. It works because most of our users don't have Windows user passwords (and CPAU allows me to pass a blank password - something 'runas' won't.) HOWEVER - if the user has a password it fails. So now I prompt the user for the password then use what was typed in. What I need help on is ... GEEZ, seems like there ought to be a better way. I've looked at a Win32 API call that seems related:

http://www.news2news.com/vfp/?group=-1&function=696

But I have to admit I'm getting well out of my territory. Does anyone have any idea of how I might do this more elegantly? Particularly by using the Win32 API rather than these external command line apps? Or at very least, if I could check for a blank password so I don't have to prompt those without passwords to type it in? (I suspect I haven't included enough info - my head has been spinning all day on this - I apologize in advance if I'm not clear.)

 

[JRB-Bldr]

"we're switching everyone from Windows PowerUsers to Standard users"
Not always the best thing to 'blindly' do without an analysis of needs.

There is an Administrative Group (and Standard User Group) within the local workstation in addition to the Administrative Group at the Server level.

I have found that I can set the users to Local Administrator, but to Server Administrator and everything works well for them - depending on where/how your data files are located and the security settings on them. That gets around many local workstation security issues.

However if the problem is with access to the Server files, then you have to work with your Network Administrator to get the necessary Server security permissions set to that your users can access them freely with their own logins.

What you have done is only a partial 'band-aid' for the purposes of Installation but the users will continue to encounter issues since they, themselves, don't have the necessary rights. Maybe you would need to move all Server files to another directory which DID allow them use.

Keep in mind that as your users migrate to Vista (shudder!!!) or Windows 7 you may encounter even more security/permissions issues due to some of the so-called 'enhancements' they add to local workstation environments.

Good Luck,
JRB-Bldr

 

[randymce]

My mistake - I had a feeling I wasn't clear enough.

Yes - we are aware of the 'needs' and there's nothing 'blind' about what we're doing. We've migrated to Vista x64 over a year ago, and are familiar with elevating processes and working with UAC limitations, etc. What I'm talking about here is adding/removing the domain user to the LOCAL Admin group in order to run a network setup.exe app without failing. What I'm unclear about isn't that I'm out of my territory about the entire project... merely that I'm out of my territory in terms of using the Win32 API to try to perform the function I've been able to do with command line util's. My solution (aka band-aid, a good choice of words - and yes, it's only for the installer) isn't elegant by any stretch. So I'm hoping someone may be able to help me find something more elegant. I've spent some time on this and it's not a trivial problem. In fact, the solution that we've come up with is actually quite clever, albeit not slick. I just think that there MUST be a better way. Wish I had a better handle on the API calls.

Again - I've tried, but I still suspect I might not be as clear as I hoped to be. If anyone has any ideas, even if you're unsure, I'd like to hear them. I can post code, cmd line apps, etc. if it helps.

 

[Olaf Doschke]

Don't know how to add a user to the local admin group or do any window account modifications, but AFAIK the more elegant solution is to do this kind of setup during system start before the user logon.

Bye, Olaf.

 

[craigber]

I don't think you'll find a way to do this. If there was, malware could exploit it go get around UAC.

Craig Berntson
MCSD, Visual FoxPro MVP,

http://www.craigberntson.com/blog

 

[JRB-Bldr]

"adding/removing the domain user to the LOCAL Admin group"

I guess that I am still not clear.

Is your problem that the users cannot access directories/files on their LOCAL workstation or on the SERVER without having to type in some Admin password?

Regardless, by setting the users up as Standard Users you have reduced their privileges to the point where they cannot do the work they need under their un-modified user login rights.
The idea of changing user rights back and forth is un-necessarily complex and not likely to work.

Either get your network admin to set the users themselves up with the necessary rights to do their work - or - set the appropriate R&W rights to the necessary directories to allow them to get their work done.

Good Luck,
JRB-Bldr

 

[JRB-Bldr]

One additional thought comes to mind in light of my comment immediately above.

Create a new User Group (say: VFP User) in Active Directory and assign that group to the VFP users in addition to their Standard User group login assignment.

Then have your Network Administrator set up special directory access rights to those directories where needed for users with that User Group assignment.

Then other Standard Users (if there are any) would not have access to those directories and those users would only have specialized access rights to those directories which were set up as needed.

Good Luck,
JRB-Bldr

 

[randymce]

Holy cow - this just isn't working. I think I may have ventured too far off the VFP path. My fault, sorry about that. Just a couple quick notes of follow-up to try to wrap it up before I end this effort (in case someone else is viewing who is in a similar situation... which I'm beginning to doubt, but oh well.)

1. We have a solution, and as I've said, it's clever and works fine. It isn't terribly complex, but it just isn't super elegant. It also requires me knowing the local Admin-user password for all the users for the code - not something any malware could exploit.
2. We can do automated installs via Group Policy & MSI's, etc. I have no problem with that. This particular app is for 'optional' installers that let the user perform them "on-demand" from my custom app.
3. There has never been a network privilege problem - the privilege problem is that Win Standard users don't have the rights to install apps on their workstation. This hasn't happened upon by accident, it is by design. We don't want users installing anything that we haven't approved and added to our custom 'setup' app. Our workaround makes that possible. (And, if there was, I'm also the net admin - so that'd be easy.)
4. The last thought on using a directory with "special VFP" access rights is a great idea. We use that for securing specific data that other VFP apps need access to that can't be available to users with Excel and inquiring minds. It is a slick solution, and I'm using it on a new custom app I'm selling to new customer. Unfortunately, it doesn't help me modify the domain user's local rights as I need to.

I'll try to do some more work on the Win32 API call approach - and if/when I get anything, I'll be sure to share it with everyone. Thanks for your help.