Can we disable editing for a specific registry key used by our application. I want only my applicaton to make changes into the registry and other cant see or edit them.
Yes and no.
The registry acts as any other file on the system. You can set specific access modifiers on each key. So if you set the access keys so that only a certain user can see/edit them that is what will happen. For that to work though, your program will have to run impersonated as that user.
If a user starts another program or regedit as the same user, he will also be able to modify/see that key.
An administrator will always be able to see/modify that key. Even if he's not the owner and the admin rights have been removed, he can still make himself owner again.
Related
I have created an application, which works for all the windows users (Local, AD, Azure etc). For every user, I'm storing some data inside HKEY_CurrentUer\TESTApp\ registry. Now in the custom credential provider (LOGINUI) once the user enters the credential Wants to read that user HKEY_{...}\TESTApp\ details to know more about the user.
I can successfully store user details in HKEY_CurrentUer\TESTApp\ registry and read details from HKEY_USERS\SID\TESTApp\ if he already login's in.
Now I have the following question,
Is it possible to do the same for not logged in or log out users using either username/SID?
Is there any other HKEY place where I can store the user details and can easily read using username/SID without admin permission? For now, I want to maintain the user details in the machine itself (no cloud).
At last, if the above two is not possible, can I create and read a file with key-pair values in my app workspace without any permission issue?
Since I'm new to windows app development, correct me if I'm doing wrong. THANKS in advance.
HKEY_USERS\SID will be created only after successfully logon on this machine and continue to reside after logout.
If you are talking about logon scenario for credential provider CPUS_LOGON means that your credential provider is working with highest privileges for application - as a SYSTEM user, and you can read and write practically everywhere.
I have a program that read and write registry files in order to remember window position etc. This is very simple when it comes to just being the administrator but not so much when you are just a user on the system.
I use advanced installer if you have any cool suggestions on that end.
Where should register parameters be located in order for each user to use my application with their own registry values?
Is that path general enough so the program can locate that folder without running into issues?
Edits/Updates:
Question 1: Where are you putting things if not in HKEY_CURRENT_USER?
Answer: When i put the files under HKEY_CURRENT_USER it would only place it under that user. So if I were to install the program as administrator, it would only be that user that has the files. As i'm using advanced installer, i'm unsure if that falls under some settings value.
Statement 1 from Bogdan Mitrache:
If you prefer, you can also leverage the self healing support from Windows Installer (supported by Advanced Installer too) to have the installer write the default settings under HKCU for each user launching the app, even if installed by the administrator. Here is an example with files, but it applies for registry too: advancedinstaller.com/user-guide/qa-self-healing.html
Response: This is a good solution except for the issue that I have a conditional installation. The user can choose to install one or the other feature where both of them uses these registry values. This is probably why it is not working for me. I'm going to look over duplicating the files in a logical sense in AI.
The correct way to handle this is to store default values (such as during installation) in HKEY_LOCAL_MACHINE (if at all), and then later store user-specific values in HKEY_CURRENT_USER.
When the app needs to read a value, check in HKEY_CURRENT_USER first, and if not found then check in HKEY_LOCAL_MACHINE (or use a hard-coded default).
When the app needs to store a value, store it only in HKEY_CURRENT_USER.
And yes, this does mean that if your app is being run by an admin, by default it is going to read the value from the admin's key, and store the value in the admin's key. And that is perfectly OK, because the admin is the user of the app at that time. If the app is being run by a non-admin, then the values will be relative to that user instead.
In a situation where the app is running as an admin user but needs to read/store a value in another user's HKEY_CURRENT_USER key (for instance, when a non-admin user is logged into Windows and the app is running with UAC elevation using another user's login), then the app can open the HKEY_CURRENT_USER key of the other user by either:
impersonating the other user and then using RegOpenCurrentUser().
load the other user's profile by using LoadUserProfile(), which returns a handle to the loaded user's HKEY_CURRENT_KEY key (amongst other things).
If you want to access another user's HKEY_CLASSES_ROOT key instead of HKEY_CURRENT_USER, you can use RegOpenUserClassesRoot().
I need to delete some local machine registry keys, I tried all registry delete routines but the result is through admin account I cant do it. how can I set access rights of my application to system account using windows API routines???
I also used this routine RegDeleteKey but returned value 5 means access denied, I run my application under full admin rights
even manually open regedit with admin rights, I wont be able to delete local machine registry keys. for purpose I need system account rights.
i opened regedit with system account rights and i was able to delete local machine keys successfully. now i need to do this programmatically
You either need to run your application as an administrator (Run as administrator in the context menu of Explorer), or you need to add a manifest to your application, indicating that your application needs administrator rights. In the latter case, a UAC dialog will ask you for administrator credentials.
I want to display icon overlay in user context and my software installs without admin access.
Is it possible?
No, this is not possible icon overlays are system level refer to http://msdn.microsoft.com/en-us/library/windows/desktop/hh127455%28v=vs.85%29.aspx
Notice that you need admin access to add the keys mentioned in the link as well as the registry path in HKEY_LOCAL_MACHINE which will enable the effect all users. This behavior is the same for Windows Vista, 7 and 8.
No, you cannot register your overlay handler without admin access, but since explorer.exe runs with current user's credentials, you can implement some configuration checking in order to display the overlay (or not).
For example, you can check for a particular key under HKCU or for a configuration file under %APPDATA% folder.
I am designing a Service to run under LocalSystem account on Win2000, XP and Vista. It will need access to users registry hives, sometimes for extended periods of time, both when the users are logged-in, and also, when they are not logged-in (IF the profile is local. If the profile is Roaming and not loaded, I will not attempt to load it.)
If the user is logged-on, I can get the Users access token by various means (E.g. from its Explorer process, or by receiving Logon events from the Service Control Manager) then use ImpersonateLoggedOnUser and RegOpenCurrentUser to access the User's hive. However, what are the implications if the User selects LogOff from the start menu while I am impersonating and have his hive open? Will the logoff be prevented? Will my impersonation be terminated?
If the user is not logged on, I can use RegLoadKey to directly open the hive NTUSER.DAT. (Impossible for a logged-on user). But what are the implications of this if the user decides to log-on (I suppose the hive will be locked and the logon either prevented, or may experience difficulty?)
I will be setting up some test projects to explore these ideas however, regardless of their apparent results, these questions are theoretical in terms of what type of problems might, or would, be caused by the user loggin in/out during these actions by the service.
Caveat: ImpersonateLoggedOnUser can ONLY be used either for a logged-on user (token obtained from process or SCM event) OR for a user for which I have the plaintext password to call WinLogon and obtain a token - TRUE / FALSE ? In other words although I have maximum permissions as LocalSystem and am able to change the user's password or even delete the user's account, if the user is not logged-on, it is totally impossible to create a new token to impersonate the user without having the the password?
Apparently, there is some risk of damaging a user's profile if it is already loaded by another process when the user logs in. In that case, the system will try to create a new subdirectory for the user.