Having googled, the general advice is to create a standard, non-administrator account.
I just tried that. I only had one account, my own, which is an administrator and then created a second (not the Guest account). I logged out of my own account and into the new one and tried to change the time. Windows 7 popped up a box asking if my main account would allow this (and prompting for its password).
I have been told "it shall not be possible to change system date/time". I intended to deliver a PC with only a standard account and my s/w, but can't (I think) prevent the user from creating an administrative account and changing date/time.
Can I prevent this programatially from Delphi, or do I just have to say that if the user wants to be destructive I can't prevent it?
Generally this kind of restrictions are set using the Windows Group Policy
From delphi you can use the Group Policy API or the RSoP WMI Classes.
In your application, you can actually detect user changing system time while your application is running.
You will receive WM_TIMECHANGE when system time change.
When startup, you can saved the gettickcount (As StartTickCount) and now (As StartTime). When checking, you can check if the different between tickcount and the different between time match (allow a small discrepancy) and know the different. However, if the user change system time away from your application, this trick do not work. Maybe you can have a service which is auto start checking for this.
If you need to change back to original time, here is some resources :
CHANGE the system TIME
btw, in OS level, a normal user cannot create an admin user.
Related
Is there a strategy/approach that can be built to bring an ASP.NET MVC application into "single user mode" gracefully? By "single user mode" I mean something that when activated will block all new user access/logins, but allow existing users to complete their sessions and log out.
SCENARIO: I need to republish an active MVC application during the day in order to patch errors. Since we are conducting a new release I need to be able to do these patches sometimes a few times a day to squash bugs. Our users are all over the world and I don't have the ability to contact them individually to tell them of the patch, especially if it is a quick fix that is needed. So far I've just been republishing which means for some users their sessions will be destroyed, they will get errors when trying to navigate from one screen or form to another, etc.
What I would like is a feature that will let me log in as the site admin (custom Identity auth), flip a switch, and from that point forward (unless I flip the switch again) no new logins will be accepted. I would also need the ability to monitor sessions and ideally mark individual sessions for termination immediately if necessary, which I'm not sure is possible out of the box at all.
If there is no NuGet package or at least some code sample out there that can do it I'm considering rolling my own. One approach is giving the app admin a screen to set a boolean Application variable that is then checked during each user's login. If that Application variable is true then the authentication logic redirects the user to a friendly message that logins are disabled. Session management would be trickier, maybe have the base controller update an Application variable (dictionary?) on each page load, and then the admin can view a screen that shows a list of those sessions and can flag them for termination? And then the next time a flagged user loads a screen the base controller logs them out since they were flagged for termination. But I'm not sure if there will be threading/deadlock/etc issues with everyone accessing this Application variable repeatedly like that.
For reference, the application is used by about 3-5K different users per day, about 25-30k screen/page views per day. Backend is a combination of Oracle and SQL Server but that shouldn't matter, unless it would be better to track the session info in the DB.
This is not a hard requirement, but the impact on the users when the site goes down can be severe, so I want to make it as graceful as possible. Right now it is crude.
I'm starting to create a lot more features for users in my app. I've run into some app structure issues.
lets say I have User Fooman
Fooman wants to edit his account, delete some objects(wall posts), update his friends list etc.
Fooman is logged in to do all of these. But footman isn't the one using the device at the moment. It's fooman son (foobaby). Foobaby decides to just be a son and delete things erroneously. I have an option for users to delete their account client side. I present them an alert view to confirm that's the choice they meant to select. After they confirm that, another view populates with a 'Destroy' (or delete button) that will delete the User, plus all relations/pointers/data connected to it. Before that button is enabled a password validation check is required so it's not done by a foobaby. However, with Parse, this has proved to be problematic client side. I don't use cloud functions because, well, simply put, at this point in time my app is one platform and doesn't really need to use it.
Is there any workaround anyone has come up with that's quick/efficient, API friendly for validating a textField.text with the [PFUser currentUser].password whilst maintaining security of course.
I code in Objective-C :)
Note: I have tried numerous things but nothing seems to work outside of trying to log them in against the user input (UITextField), which doesn't feel like the right way to do it in my opinion.
I think it's an unusual requirement. The idea of a logged-in user is that the app trusts the user. A persisted logged-in user on the device means that the app trusts whomever is holding the device. So FooBaby is trusted, because FooDad let him hold the phone.
Some apps put up a barrier to establish thoughtfulness, like the Parse data browser requiring that you type the name of a class before you drop it. But this establishes thoughtfulness, not trust. (For a child, I guess it also establishes minimal competence, in case FooBaby knows how to press buttons, but not how to spell).
Otherwise, I can't think of how to do it besides requiring a login, which you mentioned you find unappealing (though you didn't say why). Excluding that, I don't think there's a way to do it without spoiling security with something like keeping an in-the-clear copy of the password.
Anyone know how to remove users in PlasticSCM when the server is configured to use Active Directory security?
The cm au/du commands are meant to activate or deactivate users.
But users are not 'added' to Plastic as such.
When a user does an operation in Plastic, it will be automatically added provided you have enough licences and the user has permissions to access the system (you've set the correct ACLs).
Suppose you just have a 20 users license:
You simply install the license (copy the plasticd.lic file)
Then the first user access the system, it will be 'activated'
Second user accesss, second 'activation', it happens automatically
Then suppose you already have 20 developers using Plastic and one of them leaves and a new one enters, then you have to deactivate the old one and activate the new one, but only then.
Hope it helps.
My application needs to read an option on startup to check if it should start in read-only mode. The option should not be allowed to be changed by the user.
I usually do this now using a value set in the HKLM\Software section of the system registry. The administrator sets the value and the users can't change it (they don't have rights to modify entries in HKLM).
The problem is that on a terminal server (or Citrix) machine this affects all users. I'd like to figure out a way to do this on a per-user basis. How do others handle this? Is there a section in the system registry for this kind of per user setting that the user can't change?
Thanks for any suggestions or comments!
This is essentially what the HKEY_CURRENT_USER\Software\Policies key is for, i.e. a key within the user-specific part of the registry that is by default read-only to the user himself.
By convention the key hierarchy should complement the one you already have under HKEY_CURRENT_USER\Software, e.g. if your regular user preferences are stored under HKEY_CURRENT_USER\Software\MyCompany\MyProgram then the protected user preferences (or "policies" in MS lingo) should be stored under HKEY_CURRENT_USER\Software\Policies\MyCompany\MyProgram
Note that it is recommended to only set values under this key via Group Policy Objects and never by direct registry access.
The concept of a per-user settings area that the user can't change doesn't really make sense - if they're user settings, "you" (the user) expect to be able to change them.
I can think of two alternatives:
Write your settings in HKLM, but have
a different setting for each user and a global fallback setting for users without the setting set
Write them in HKCU, but use the
registry security APIs to prevent
them writing to it. You will probably need
permissions greater than theirs to
prevent them undoing the permission
changes. I don't really like this
option, but if you want to follow it
you probably want to start with the
RegGetKeySecurity and
RegSetKeySecurity APIs. This
article might be interesting as
well.
Personally I think the first option would be the easiest, and also would involve less dodgy stuff in the user's registry tree. Hope that helps!
How about two settings?
1) Set a flag in HKLM specifying that read-only is the default behavior on this machine.
2) For any users that need full access, set a token in HKCU which enables full access.
The token could be a cryptographic hash of some salt plus the username, so it couldn't be copied to give permission to another user.
Why don't you store options in your own database? It seems reasonable and handy enough (at least to me 8) ) No problems with making "portable" version of your product. No users bothering any settings you don't want them to bother.
Whats wrong with HKCU instead of HKLM? This would be per-user. Unfortunately it could be changed by the user if the user knew how to edit the registry and find the key.
Take one of the files coming with your program, that should not be altered (at least not by the restricted user). If there is no such file, create one just for this purpose.
Let the administrator set read only rights to that file for those restricted users.
In the program check whether you have write access to that file.
I have been assigned an assignment to create such a service in delphi which will track the logged in user activity on the computer. For this i have to
I want my service to be run in the background and should store the name of every ACTIVE window in particular time events.
Learn how to create windows service in delphi
How should I get started?
Create a Windows service in Delphi:
http://www.devarticles.com/c/a/Delphi-Kylix/Creating-a-Windows-Service-in-Delphi/
You will want to do some research in the CBT hooks provided by the Microsoft SDK. They include the ability to be notified each time a window is created, among other things.
The Service code from Aldyn is able to track logged in users. Not sure if it is what you want, but it must surely be a good start. The vendor goes through fits of activity and sleep, so be sure it does what you want as-is.
Aldyn SvCOM