We want to enforce at minimum a PIN and an inactivity timeout on our Windows Store App.
The Exchange Active Sync (EAS) policy API looks like the right thing to use but it should be used with much caution.
You can either check for compliance or enforce compliance
MaxInactivityTimeLockValue should work for the minimum time before the screen locks
The trouble is that the check RequestedPolicy.CheckCompliance() never succeeds. I have tried it on a Surface 2 RT that has lock screen set to 2 mins and a Windows 8.1 Desktop that had a screen saver set to display after 1 minute and show password on resume.
Both of these fail the following check
RequestedPolicy.MaxInactivityTimeLock = TimeSpan.FromSeconds(300);
ComplianceResult = RequestedPolicy.CheckCompliance();
I would expect ComplianceResult.Compliant to be True but it never is. Has anyone ever managed to get this work as expected?
EDIT
Once set i cannot see any way of undoing this on my Surface RT.
I have found a way that the user can do it in this article, Reset EAS Policies However I still cannot see a way of unenforcing in code.
Thanks
As far as I can tell you can only check for compliance of a Policy if one has already been set. If no policy has been set, even if you would be compliant with it, CheckCompliance will return false.
There is no way of Enforcing PIN there is only a way of disabling what Microsoft calls "convenience logons", these are:
Picture password
PIN
Seeing as any user would have needed to already have a user name and password to get the account on the Windows 8.1 device there will always be at least a username\password combo
Related
We have run into an issue where there are corresponding event viewer entries that show something regarding Security-SPP at the same time the windowsupdate.log file started writing its checks for automatic updates.
Prior to that entry, the update settings were set by Group Policy. My question: Is it possible for Security-SPP to re-enable automatic updates and/or override what has been determined for group policy?
I have been informed by a number of individuals that the windows update service must have its startup type set to "DISABLE" or it runs the risk of getting started by another service such as SPP or other AV programs.
It is a possible way to protect the system in the case of a zero day or other important update.
I've a fingerprint reader on my laptop and I installed fprintd to connect using it.
That works very well but there is this problem : When I remote connect to my laptop then I do a su/sudo command, I'm asking to swipe my finger. It works if I'm near the computer... but I'd prefer to disable it for cases I'm distant. Is there a way to do that ?
There is a bug filed for that in ubuntu which does not seem to have been resolved yet. That suggest there is no native way in fprint to do that. The workaround suggested by one user in there is to wait for the timeout.
From what I see pam can be configured in a certain way to fall back to password in case no print can be read by fprint. Archwiki says
auth sufficient pam_fprintd.so
auth include system-login
in /etc/pam.d/system-local-login not sure if that applies for your system too (for good measure here is someone configuring it in gentoo).So you should be able to allow pam to fall back on password with the right configuration.
I want to reiterate my comment for users that still don't know: Fingerprints (or biometrics in general) are not secure means of authentication (as the simpelest of the many flaws: you leave them all over your computer when you touch it).
There is a workaround:
Start two remote sessions.
On the first one, perform a sudo pwd. This will fire the fingerprint.
On the second, perform your desired command: sudo apt-get upgrade(or whatever). Since the fingerprint is blocked by the first session, it will skip directly to password authentication. No timeout.
I want to prevent the Phone display from switching off when my App is open and in the foreground.
Is there an API to do so?
I asked a similar question a while ago on the dev-webapps mailing list. Frédéric is correct in that you can use the navigator.requestWakeLock('screen') to obtain a lock, however it is a myth that you always need to release the lock.
To qoute one of the replies to my question above:
You do not have permission to hold the lock past the user leaving or
closing the app. So the lock will be automatically [released] for you. We'll even
re-grab the lock when the user brings the app back from the background so
no need to do that either
I have tested this in both hosted apps and packaged app, and that is exactly how it will work. So, if you intend to keep the screenlock for as long as your app is open, then all you have to do is to add this to your app:
navigator.requestWakeLock('screen');
However, if you want to give user a setting option to prevent the app from locking, then you would need to keep the reference to the lock and release it as soon as user changes the setting. Otherewise you are good to go. You can find more information about requestWakeLock on MDN.
You can use the requestWakeLock function to achieve this by doing
var lock = navigator.requestWakeLock('screen');
However, don't forget to unlock the screen later by doing
lock.unlock();
User downloads an App (which assume is a game) from server. I need to enforce time constraint on how long a user can run an Application on a system.
eg. Starting from the time of installation, user can use the Application till only 5 days.
My problem is, if I depend on system time/day etc for implementing this logic, user might change the system time and overcome the logic.
Platform: Linux/C++
P.S.: I have to assume a case in which user decides to not connect to internet at all after he downloaded the Application. Since I don't have network access so can't rely on server based storage about Application's installation date/time etc.
Can someone give a clue how this kind of behavior is implemented in Applications which give a trial period of their usage?
Edit:
I am adding the Algo which I am thinking:
At installation time :
At the time of installation store the current system date.
Store this info in an encrypted form into a file DRM.txt
On App startup :
Open the file and decrypt the installation date.
Get the current date from system.
Match if the application is allowed to be executed according to the number of days that have passed since user installed it.
If allowed, start the App else give error msg and return.
Problem:
Let at the time of installation system date is 19/12/2012 and user is allowed to use the App only for 4 days that is till 22/12//2012. Thus, 19/12/2012 is stored into DRM.txt.
After 4 days user changes the system date back to 20/12/2012, then my logic to check will allow this Application to run.
Hope this clarifies what I am trying to say.
This can be achieved through encryption, for example storing a date into an encrypted file, note that this won't prevent reverse engineering, etc, etc, etc
Save and check the time when start and stop the APP.
If the current time is much shorter than the saved time, then you can think it is cheating.
I tried to change the role size (upwards) in an Azure role and got the following error after uploading
"The role size specified for role 'Website' in the newly uploaded package differs from the role size for this role in the currently deployed service. Changing the size of the role will cause all local data on the role instance to be lost. Please use the Force flag if you want to allow the loss of local data."
which leads to the question - is there a force flag? Where is it? How do I set it?
Its just appeared!
An update to the Management Portal today (20 Oct 2011) has added an "Allow VM size or role count to be updated" tick box to the Upgrade Deployment dialog. So I guess that's the shiny new Force Flag!
The information I've heard on the Azure forums is that it is not possible to modify the role size without a full redeploy (and this has been my experience as well).
Over time Microsoft has allowed more things to be modified during an upgrade and Mark Russinovich may have suggested in a Mix or TechEd presentation that role size modification would be supported some point in the future.
The error message you are receiving may be an early artefact of the implementation of a size upgrade enhancement. The research I've done (and I have done a LOT of asking around) would indicate that the "Force Flag" mentioned is not actually implemented yet - although I'm more than happy to be proven wrong.
Right now, the vmsize is inside of the package (cspkg) which is sent to AppFabric. It's a decision which is part of the build/packaging. So, to change it, you need to change the VMSize, build the package and then [re]deploy.
If you have a running system, you can avoid down time by using VIP Swap. It will basically stand up another AT[s] in the staging slot with your new VM size and then swap over to it.
So, there's more moving parts involved but you can still change it with virtually no impact.