UAC - A Required Privilege is not held by the Client

[stanlyn]

Hi,

I need to change the local systems date and time from within my app. The article I'm using as a base is

http://www.tek-tips.com/viewthread.cfm?qid=1019836

When I run it on Win10 I get "A required privilege is not held by the client" dialog. It does not ask to elevate. I have also need this functionality before, for writing to the registry's hkey\local machine and some other usages.

So, How do I elevate this so the process can run WITHOUT making security changes to the client's system. It is ok to ask the user for permission to elevate. Currently, I'm asking the user to change the date to current values. The purpose of this is to do it for them.

Thanks,
Stanley

 

[Mike Lewis]

Stanley, I'm sorry I can't directly answer your question. No doubt other people here will be able to help.

But I have ask why you want to do this.

It would normally be considered bad behaviour for an application to make that sort of change to a user's system. After all, you are not the only program running on that machine. Other programs also need to know the date and time, and it could affect their performance if you take it on yourself to change them.

If your aim is to simulate other dates for use by your application, there are plenty of utilities around that will do what you want. I use run called RunAsDate (from

http://www.nirsoft.net).

I use it during program development, for example to test month-end routines that the application only allows to be run at certain times, or to simulate a number of successive accounting periods.

The point about that utility is that it doesn't actually change the system date or time, it simply feeds the date and time that you specify into your application. If that's what you want, I would suggest you take that approach.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[stanlyn]

Hi Mike,

It would normally be considered bad behavior for an application to make that sort of change to a user's system.

It is also bad behavior for users to manipulate their system's date in order to circumvent a licensing schema. For this, I have implemented other stronger solutions, but it used to be a problem.

I've considered your approach before, but when a users computer's clock is off by days and my app is using date() and datetime() functions for calculations, event logging and authentications, the event reports are no longer correct as their date values are incorrect. Bad Data... Imagine what a report that selects a timestamp date would look like if user1's date was correct and user2's date was 2 days off. Bad data, and that is what I'm trying to solve.

I need an elevation solution to this as I have other usages that this would be good for.

Thanks,
Stanley

 

[stanlyn]

Mike,

How hard would it be to have all of VFP's date and datetime functions use "RunAsDate"'s return value for vfp's date functions to run against instead of the system's date and time functions? This way I can get the correct date from a machine I control using a time server or a sql statement like:

	If lnHandle > 0		&& Good connection
		* Get date from License Server
		aa = 'select CONVERT (date, GETDATE())'
		If SQLExec(lnHandle, aa) = 1
			If Reccount('SqlResult') < 1
				llFoundMatch = .F.	&& Empty, Match NOT Found
			Else
				lcOldDateType = Set('date')
				Set Date YMD
				ldSqlToday = Ctod(Strtran(Alltrim(SqlResult.Exp),'-','/'))
				Set Date &lcOldDateType
				Release lcOldDateType
			Endif

			Use In Select('SqlResult')
		Endif

Then let that date be what the app uses as the system date. I understand that vfp's date and time functions are really wrappers to sys32 calls.

Any thoughts?
Stanley

 

[Tore Bleken]

If a user manipulates the date in order to circumvent the licensing schema and then get the wrong data, then you are the winner!!

The only possibility to really avoid this problem is to read the date from internet, and use that date in your program.

 

[stanlyn]

Hi tbleken,

Yes I'm getting the date from a reliable source, (a server that I control). Just wondering how much work would be involved in refactoring all the date math and functions to use this fetched current date from an outside source.

Is it ok and good practice to enforce setting the date correctly and those that do not or will not, just end/quit the program. Not sure if I want those folks as customers... Any thoughts?

Stanley

 

[Mike Lewis]

How hard would it be to have all of VFP's date and datetime functions use "RunAsDate"'s return value for vfp's date functions to run against instead of the system's date and time functions?

To achieve that, you have to do precisely nothing. Just use DATE(), DATETIME() and all the others as usual. The date you get will be the one that you specified to RunAsDate, not the real system date.

But is that what you want? It would be up to the user to launch RunAsDate (which in turn launches your app). If you were worried about the user circumventing your security by changing the system date, think how much easier it would be for them to circumvent your security by giving the wrong date to RunAsDate.

Getting the date from an external server sounds like a better bet - provided you accept that your whole application will fail if you can't connect to the server for any reason.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[stanlyn]

Hi Mike,

But is that what you want? It would be up to the user to launch RunAsDate (which in turn launches your app). If you were worried about the user circumventing your security by changing the system date, think how much easier it would be for them to circumvent your security by giving the wrong date to RunAsDate.

We have to run it this way...
Can I run RunAsDate from within VFP WITHOUT elevating anything. If so I can do the sql script I posted earlier to get an accurate date, then set RunAsDate to this date. All steps has to be run from within VFP as we do not have control over the user's motives. If an elevation is required, then we are back to the original question...

Thanks,
Stanley

 

[Mike Lewis]

Can I run RunAsDate from within VFP WITHOUT elevating anything

That's now how RunAsDate is designed to work, but it might well be possible.

The normal approach would be to run RunAsDate first, passing it your specified "fake" date and time, and the name and path of your VFP application. RunAsDate normally runs interactively, with the above information being entered by the user in a form.

However, it also has a command-line option. So you could run it from within your VFP application (using RUN or ShellExecute()) and have it launch another instance of the application. Or, you could create a separate launcher program, which gets the date and time from your server, then launches RunAsDate, which in turn launches your main app.

As far as I know, you don't need to elevate anything.

Note that the above is just based on my reading of the documentation. Before going any further, why don't you download the utility from Nirsoft, and give it a try. It's free, and it only takes a moment to install.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

when a users computer's clock is off by days

What you describe is a sysop problem and shouldn't be yours. Today you can configure windows to sync system time with time servers, that's the job of the OS, not yours.

And if you want to detect user manipulating system date/time to circumvent expirations, you already said you use other means of ending a test phase. You can also get time from internet, as said already. And what hinders you to do this instead of datetime(). No need to change system date, you can get server time as your way to get time not only in an initial calibration call, simply make it your normal datetime determination.

Bye, Olaf.

 

[stanlyn]

Hi Olaf,

What you describe is a sysop problem and shouldn't be yours. Today you can configure windows to sync system time with time servers, that's the job of the OS, not yours.

True, but the support calls comes to us when something doesn't look right.

you already said you use other means of ending a test phase.

Yes I do...

And what hinders you to do this instead of datetime().

The app uses a lot of date and datetime functions, therefore having correct dates is crucial to the system's integrity.

you can get server time as your way to get time not only in an initial calibration call, simply make it your normal datetime determination

The only way I can see this working for datetime is having a timer always running in the background and when I need a datetime() value I would need to add or subtract it from the timer values that was initialized earlier from a call to an outside source by an offset value.

I would rather not go to this extreme. Currently, as I initially said, if the date is incorrect by comparing the computer's date with a call to an external source, I put up a dialog stating the system date needs corrected. I also put up the date as shown on their system and I put up the correct date from the external source for them to see. I further explain why their data would be wrong if left un-changed. Then the OK button reruns the stack via the rerun command while cancel quits the app. This conversation started when I asked how can I automatically elevate the process so I can change it for them instead of running the rerun command after they go out and change it. I'm just trying to help the user out here...

Thanks,
Stanley

 

[Tore Bleken]

You ask "Is it ok and good practice to enforce setting the date correctly and those that do not or will not, just end/quit the program. Not sure if I want those folks as customers... Any thoughts?" Yes, it's good practice to exit the program with a warning that the program needs the correct date or it won't work.

 

[Olaf Doschke]

Well, instead of asking for a manual one time correction of system time, that later on may go off again, you could point the on site sysop to the possibility to set up a time server for syncing of system time totally automatic.

For non domain clients:

http://mintywhite.com/windows-7/7ma...-sync-system-clock-with-internet-time-how-to/

For domain clients:

https://technet.microsoft.com/en-us/library/cc816884(v=ws.10).aspx

This one time effort will then at least make your request for setting system time much more seldom, thus bearable instead of elevating your application to be able to set system time itself. It's still the worst plan to do that in my oppinion.

Your idea about setting up a timer for needing less internet requests is fine in the performance aspect, but overdone, if there is a domain server synced with correct time, you can also find out server time via eg SQL Server [tt]SELECT GetDate() as dtNow[/tt] or creating a file on a domain share and determining file time.

Bye, Olaf.

 

[stanlyn]

Hi tbleken,

Yes, it's good practice to exit the program with a warning that the program needs the correct date or it won't work.

Exactly what I do as explained in my last post above, last paragraph.

Now, How can I help the customer by correcting his problem for him automatically. As originally stated, it is ok to ask the user to elevate.

Thanks,
Stanley

 

[Dan Freeman]

Now, How can I help the customer by correcting his problem for him automatically.

If you tell the user what needs to be corrected, you've done your job.

Any software that fundamentally messes with my computer, like changing the system date, will be immediately uninstalled.

 

[Olaf Doschke]

In bigger companies users may be restricted to make many settings included system time, let alone elevate, so even implementing an elevation feature in your application, you won't get forward with this very far. I'd go for the advice how to set up syncing system time and quit after stating that your application only allows a grace difference of 1 minute from the time you got from your internet request.

Bye, Olaf.

 

[stanlyn]

Hi Dan and Olaf,

If you tell the user what needs to be corrected, you've done your job.

If I can change it for them, then I've only done half my job. The dialog I put up explains the issue and they have the option to allow the change or not. And, if they choose to not fix the stated issue that will eventually cause us issues like (why are the numbers wrong?), then we will refuse to run and the user would be doing us both a favor of uninstalling it. I'm perfectly ok with that...

Our apps do not go on dev machines like yours and mine where we need to mess with the date stuff from time to time. They go on workstations where non-dev work gets done.

Olaf, The restriction imposed by Active directory and other security policies that you have stated are real and may politically be hard to get compliance. Therefore, I am dropping its implementation for this particular case. I'll advise them on what is wrong and how to correct it as I do now and quit if they don't correct it.

However, we still need an answer to the original question which has not been answered. How do I elevate a call within VFP? How do I get it to ask for elevation permission when running a command that is being stopped by UAC? If I had this answered, then I could do the other half of my job.

Thanks, Stanley

 

[Olaf Doschke]

I don't even know how to elevate a single SetSystemTime API call or such, I don't think it's possible, the finest granular level of granting privileges may be a new process, maybe a new thread. Since VFP can't spawn new threads (without usng trickery like Calvin Hsia has done), you are rather bound to starting another EXE. So what I would do is creating a separete EXE for setting system time and call that with runas.

VFP embeds a standard manifest into EXEs you build, which states requestedExecutionLevel is "asInvoker", meaning no requirement, the process starts with whatever privileges the user has. You can change that by putting a separate your.exe.manifest file before building an exe and having the requestedExecutionLevel set to "requireADministrator". Notice, this will not make your EXE run as admin, it will prompt for a login/authenticate to normal users and create a UAC prompt for confirmation from an administrative user, even if he is logged with an admin account, including the native "Administrator" account.

There is no way an exe runs with elevated privileges without notice and confirmation/login of an administrator.

So what you gain from an adminstrative user is just needing one click for you to set system time instead of doing that manual. Is that really worth the hassle? If a user has admin privileges, he can set up the syncing with internet time or domain time, where a domain controller syncs with internet time, and then that problem is over. So please, get over whith it and don't do it. It's no essential and luxurous feature to anybody.

Bye, Olaf.

 

[stanlyn]

Olaf,

There is no way an exe runs with elevated privileges without notice and confirmation/login of an administrator.

As said several times before, I would expect that and is perfectly ok. Now if I had software on my system that changes things without letting me know why and allow me to have the final say in the matter, then I too like Dan would un-install.

So please, get over whith it and don't do it. It's no essential and luxurous feature to anybody.

But you are missing the point here....

I can see this useful in other more necessary situations, such as the need to install a driver or dependency. Why not offer to assist the user in getting the prerequisites complied with. If my app needs a special addon or a barcode font, why not offer to install it from within my app. I know this could and should be done at setup, and I also know that building such elaborate installer packages is not easy as well. Installing an addon might not be so obvious at setup.

Thanks,
Stanley

 

[Olaf Doschke]

Why not offer it at usage just in time when needed and as fix on the go and while you're at it anyway? Simply because of one thing: Setup of software and usage of software are two separate steps.

And the big disadvantage of UAC prompts is, they don't tell a user more than the name of the EXE requiring elevation, not what it does. This interface is poor and not for end users anyway.

Bye, Olaf.