I am writing a c# application.
As part of my application, I need to read the users' profiles.
In order to get all the users, I am using Registry.Users.GetSubKey().
The problem is that on Windows 8 the HKEY_USERS contains only logged in users! (when there is 2 users logged in I wiil see 2 users under HKEY_USERS, but if one of the users will sign out, then there will be only 1 user under HKEY_USERS)
As a result, I get the profiles only for logged in users.
I tried to search the entire registry to find where the data is saved, but I can't find this information anywhere.... it seems like the info is gone when the user logs out.
Is it by design, or a bug?
Where the data is saved - it must be in the registry, but I can't find it...
Could it be something in the permissions? Maybe the info is there but it's hidden when the user is not logged in? Is there a flag or something I can use to read the profile for non logged in users?
This may not work in all cases, but has suited my needs. Load Registry Hive
reg load HKU\Steven C:\Users\Steven\ntuser.dat
Read necessary data, then unload
reg unload HKU\Steven
As part of my application, I need to read the users' profiles.
Then you need to redesign your application. What you're asking for is not possible.
From Raymond Chen's blog post, "Beware of roaming user profiles":
[Y]ou cannot just cruise through the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList registry key expecting to find all the user profiles and possibly even modify them, because the copy of the user profile on the local computer might not be the authoritative one.
Anything you see on your local machine relating to other users' profiles -- whether under HKEY_USERS, or in their profile directories under C:\Users -- is just a local cache from the last time they logged in on that machine. The real data, the up-to-date data, is stored on a domain controller somewhere.
You can't rely on other users' locally-stored profile data for anything at all. You're better off pretending it's not even there.
Related
I have an Application that needs to store User Info such as their Username and there score and etc...
I have selected LocalApplicationData of the Environment.SpecialFolder Enumeration.
but I can access the directory for my application manually using file explorer and can edit or delete the file that can prove as a weak spot for the application and the users may be able to mess with my application.
So, Is there any directory that I can write to using code that the user will not be able to access it.
tnx
Is there any directory that I can write to using code that the user will not be able to access it.
No. An application run by a user account has the same privileges and permissions as that user. Therefore, there is no way that the application could do something the user couldn't do on his own.
If the data you need to store is intended to be browsed or modified by the user, it should go in Environment.SpecialFolder.Personal.
Otherwise, data should be stored in either Environment.SpecialFolder.ApplicationData (if it should roam with the user account) or Environment.SpecialFolder.LocalApplicationData (if it should not roam with the user, and instead should be limited to the local machine).
Yes, the user can get into these folders and destroy the data. By doing so, they run the risk of breaking your application. You can't secure yourself from yourself.
Develop a "repair" utility that can recover from the damage by recreating the necessary files on startup of your application if necessary.
As your application is running with your users privileges, there is no place your application can access that your user would not be able to access.
Your only option is to use encryption so your user cannot tamper with the file easily once it's written. But even then... what you did with the user's privileges can be undone by the user with the same privileges. You can only make it hard enough so he or she won't bother.
You can not prevent use open the file, but have some method to check if a file is being modified by user.
You can save it at Registry, or if your data is big, you can encrypt it before save to file. When you encrypt data, user can not know which infomartion it contains, and if user open the file and modify it, the data become invalid and you can know it is modified.
Typical case of making a simple application, boss likes it, sysadmin wants to be able to configure it.
I made a simple login helper application to assist my team members with logging into a pile of different websites/tools in the morning. You create a list of sites, enter your most used password, it logs you in (and prompts for a password for sites with a unique one). Gif here: http://i.imgur.com/0HIVbMw.gif
The sysadmin at my facility has requested that I store the list of websites in the registry and make it available for management via Group Policy (So that the list can be pushed to everyone, and limited in some way). I'm going to be honest, I know nothing about Group Policy. I have heard that storing data in teh registry is not always the best option.
How can I make my applications setting and/or data configurable through Group Policy? Do I need to store it all in the registry? What options do I have that can give our sysadmin the control he desires?
Edit: Can a config file be pushed to the profiles of all users that the application can use?
What is my purpose?
I would like to save user credentials at the first start of my application.
What is the starting situation?
At the first start I have a configuration dialog, which allows the support-employee of my company to configure the application firstly. At these dialog he can also set sundry credentials. I need these credentials for every user, who starts the app. (it is a network-based application)
May some solutions?
I know, there are 'user settings' in WPF. But these are not persistent. That means, I lose the credentials, if the application is closed and another user is starting the app. But I need these credentials persistent. And for every user.
Of course, there are also 'application settings'. But these settings I cant set dynamically at the first start of my app. So I need to set the credentials for every customer at the development and compile one executive per customer.
Furthermore I can also save these credentials in a special database. But to create a database, only for this purpose seems a little bit to huge for me.
Would be really nice, if somebody could help me. :-)
You could store it in a local SQLite database, it takes just a few lines of code and one table but either store the hashes or make sure credentials are encrypted.
Also, user settings are persisted and as long as the other user is using his or her own Windows logon their user setting will not overwrite user settings of other users. However these are stored in a plain text config file so if storing credentials you should at least encrypt the values...
I am trying to use active directory to tell if a user is logged in currently. Is this possible with active directory?
I can check what role the user has User.IsInRole(#"domain.com\TeamLead")
But I'm not seeing anything to see if they are currently logged in or not.
By strictly using Active Directory, you will not be able to get this information. Active Directory doesn't store this type of information. You can turn on Login Auditing through GPO and query individuals computers, but that could be messy.
An outside solution could be psloggedon:
http://technet.microsoft.com/en-us/sysinternals/bb897545.aspx
Though that is hardly ideal.
AFAIK there is no out of the box datastore that keeps track of which users are currently logged into a domain.
Another alternative could be to craft a logon/logoff script that writes to a particular file/database and you could monitor that file to see who is logged in.
I am building a C# app which will need to talk to a database - I have written a module which checks whether users are permissioned appropriately and then uses a shared username to run the query
This means that permissioning is done in C#.
I am now wondering whether this is a good idea and whether permissions should be applied a the database level ie each user set up with their own user name and account. The reason for NOT doing this is that we are not DBAs and getting users added
What are the benefits and problems of permissioning users at the database level rather then c# level?
I always use a database login/user set up for my application.
By doing this i can operate reasonably safely within a database that may be shared with other applications - my application can be granted just the permissions it needs on the objects it needs to access.
This decouples the users from the database - it means that user Jane Doe doesn't need to be given specific rights on the database to use my application, which DBAs love as because of that it also means she can't just start up SQL Management Studio and start looking through tables (because she has no rights).
Edit: note that it is not necessary to give each user a login in order to audit who made changes - my app can still be logged in as one (restricted) user and i can pass the machine/user name of the user in to whatever stored proc i am calling so that data changes can be logged.
You can certainly have a group set up on your database and allocate the correct permissions to this group, but that means you then have to add/remove users from that group as necessary, which can be an administrative annoyance.
How important is the data in your database? Is auditability (logging who changed the data, what they changed and when) important?
If all your C# program does is read the data and the data is public anyway, then what you are doing is fine. This is exactly what happens on a website where users do not need to login, all queries are run from the same user.
For a high security, mission critical application rolling your own security in the code is seldom a good idea, much better to utilize the security system built into the operating system.
Are your computers part of a domain and do you use Active Directory? If so, you might want to consider using Windows authentication and groups.