Windows 7 I'm looking for a simple, intelligent way to transfer ownership / permissions to a new account

jjo

Honorable Member
Joined
Apr 6, 2010
Messages
6
My Windows 7 computer is part of an IT-administered domain. I have a user account on the domain (let's call that user 'UserD0') that has Admin privileges on my computer, but ordinarily I log in under a local user account (let's call that user 'UserL') with lesser privileges.

At some point, I need to move away from the local user account entirely. Assume another domain account has been created for me (let's call it 'UserD1') with the same level of privileges on my computer that 'UserL' has.

Is there a way (by which I mean a command or script, not a manual file-by-file method) to replace 'UserL' with 'UserD1', wherever 'UserL' appears as an owner or in the permissions list, on all the files and folders saved on my hard disc?

Let me emphasize this: I don't want to make either 'UserD0' or 'UserD1' the owner or have 'UserL's permissions on all the files. I only want the system to behave as if 'UserL' had been completely replaced by 'UserD1'.

Bonus questions:

Will this mess up group permissions? Will this mess up the permissions that CYGWIN thinks the files and folders have?

Thanks

jjo
 


Solution
The short answer is no. The main reason is the local account is managed locally and the domain is centrally managed in the AD "database". The local account has a locally generated SID and the domain user SID will be based part by the domain SID + a RID generated by AD. You can impersonate an account local or domain, but you would need to hold shift and right click an application and enter that accounts credentials every time. If your main concern is the data, the easiest way is to simply move the data from the local account to the domain user account with the admin account. The user profiles C:\Users\<username> have inherited permissions so dumping the data should give it the correct permissions for the domain user account.

You...
The short answer is no. The main reason is the local account is managed locally and the domain is centrally managed in the AD "database". The local account has a locally generated SID and the domain user SID will be based part by the domain SID + a RID generated by AD. You can impersonate an account local or domain, but you would need to hold shift and right click an application and enter that accounts credentials every time. If your main concern is the data, the easiest way is to simply move the data from the local account to the domain user account with the admin account. The user profiles C:\Users\<username> have inherited permissions so dumping the data should give it the correct permissions for the domain user account.

You could in theory sudo replace the user profile. You would need to at least mirror the permissions of the local user with that of the domain user on the local users profile. Then edit a registry key called ProfileList key (SID) of the domain user to point to that of the local user. This would cause the domain user to use the local users profile.

Bonus question...
Even if you could replace the local account, it would not mess up permissions, nor will you have different permissions on the domain user vs the local standard user. They should both be in the local built-in group "users" thus having the same local permissions.
 


Solution
I tend to agree with neemo on the basic answer. But, my reasons would be a little different. Depending on which server software is being used, say Windows Server 2008 R2 or newer, there could be some differences in accessing folders on your local hard drive in the new domain account and accessing the shared network folders on the domain server if you have shortcuts to mapped drives there. Also, many applications (I'm not familiar with CYGWIN), will work differently when logged into by a domain user account than from a local account. The difficulty here is that if there is drive mapping being done on a folder stored on your local hard drive a database such as Oracle or SAP say, and that folder was being used for storage by a Thin Client (used to log in to the database from your local account "UserL"), your new domain user account (UserD0) may not recognize that folder on your hard drive previously used by your local account "UserL". Even if it recognizes it, the server database may not have write or modify permissions to that folder on your drive. In that case, your new domain account can't write into that folder and then login and authentication to the server database would most likely fail.

At that point, you might need to enlist the help of your IT department which administers that domain you are logging into that contains the CYGWIN app. They might need to have you run a 1-time script as you suspected which will remap all or selected folders on your local hard drive to refresh your folder list and re-authenticate that list of folders into the server database for domain user login. If this is done correctly, each of the files inside of this list of your folders (previously setup to access the server app with your local account permissions) should be changed due to flow-down of inherited permissions, and the Thin Client folder used for login to the server database should then work--theoretically. It's possible you are not the only one to move from the Local Account login to the Domain User login, my guess this is due to the increased security and possibly an upgrade to ERP style software on the domain. If this is the case, your IT guys may be able to use a generic deployment script by just inputting your old local account login and your new domain user login into the script and have it run remotely on your machine and all will work. If not, one of the guys could write a custom script for you if you are the first person in your company to make this transition. That may take them a few attempts, so they and you should make sure that machine is protected by multiple layers of backups. Also, there are additional tools your IT guys may have if they have the MSDN subscription and toolkit which help with this type of transition. The toolkits have scripts for this sort of thing and can aid programmers into converting local users into domain users; this is often done with use of Roaming Profiles and Image backups on standardized hardware in companies where I've worked with similar setups. The issue for you will be is if you are NOT using a hardware platform that was tested by your IT departments deployment setup and have templates in place for their hardware. So, if you are attempting to use a personal desktop PC or laptop that you own at home to do so, this will not be an easy chore so you will most likely get hit by internal charges to your department if you are non-IT as it sounds in your description. This would be what we call a "one-off"; they would be programming a custom login on untested hardware for you and you alone. If this is the case, and you are an executive in the company it will be relatively easy as they will have a list of charges to bill to your P&L for this sort of thing. And it could take weeks or months or longer to get it done.

If that last scenario is the case, you might consider getting a company-issued machine and copy your folders onto that machine and then having the IT department deploy you a new Roaming Profile onto that machine that will take care of fixing all your folder permissions. That's still a big maybe. :andwhat: Since we don't know the structure or size of your company there are other variables to take into consideration, but if you are on company-owned and issued computers, it will be significantly easier than for them to include your personal computers at home into their Domain environment.;)

<<<BIGBEARJEDI>>>
 


ODBCs are stored in registry, if they are user DSNs they would care over provided the local profile is taken over, drive mapping would also care over since they are also in registry. It could get messy though since if they are mapped to shares on the domain they will typically require AD credentials to access. There are plenty of other caveats when working with domain users and devices.
 


Thank you Neemobeer and Bigbeardjedi for your thoughtful responses.

Let me add some clarifications.

I work at a small company (~500 people) and, although our IT department has ultimate control over my PC (which is owned by the company, not me), I think they are also interested in making this account transition work for me. In other words, if they can do something to help (within reason), they will. Additional cost is not a factor.

I have been assuming that if I had a complete record of the ownership and permission status of all my files and folders at present, it would be tedious but straightforward for me, as UserD0 (who has local admin privileges on my PC), to make UserD1 the owner of all the files/folders presently owned by UserL as well as to give UserD1 all the same permissions that UserL had. I can see how to do this one folder or one file at a time, but not all at once for all files/folders with the right selectivity. I would be happy to find a command or script or an example of a script from which I can devise my own custom script.

Let me add I don't see any harm in keeping UserL's permissions intact as long as UserD1 has the same permissions. They just won't get used any more since the UserL account will be defunct. By contrast, the ownership change is necessary.

In response to some specific questions:

1) I am concerned with more than just the data. I also have some apps installed as UserL that I would like UserD1 to take over. So it's some of both.

2) AFAIK, I'm not running any apps from the domain and I don't regularly access any domain databases. The binaries for every app I run has been installed locally. I can access files on other network resources connected via the domain on the rare occasions that I need to.

3) I installed CYGWIN locally on my PC. Ownership of the files related to CYGWIN is a mix of UserD0 and UserL.

4) I'm pretty sure I'm the only one at my company who is facing this issue. Everyone else thought it was fine to run everything at the Admin level all the time. I saw that as a big security risk so I didn't. Now the company is coming around to my point of view and will be requiring users to 1) always run from a domain account (their way of enforcing two factor authentication) with User privileges and 2) ask for Admin-level credentials when needed to perform a specific and temporary task. My system is basically there except for the fact that my User account is local rather than on the domain. That's all I'm trying to fix.

5) If IT already had the right script or knew how to accommodate my issue they would. If anyone knows of something specific that would reliably and easily solve this problem, please let me know and I can probably find a way to make that work.

jjo
 


  1. Programs are not really owned by any user , they are installed with an admin account and inherit permissions from the "Program Files" folder such that all users can access them, at most you may need to add a shortcut to execute them
  2. Nothing really to mention for this
  3. As long as you can run cygwin with either admin account without invoking an UAC prompt the regular domain account can run it just fine. Even logged in as an admin account, they still run as regular users. The UAC prompt is what created a second elevated user token which allows for admin functionality
  4. Yes running everything as an admin all the time is a really bad practice
To take ownership and assign permissions could be done in two commands
(From an elevated command prompt as an administrator)
takeown /U <domain\userD1> /P <UserD1sPassword> /F C:\Users\UserL0 /R /SKIPSL
cacls C:\Users\UserL0 /T /E /G domain\userD1:F

  • The last steps would be to login with UserD1, then logout and back in with an admin account
  • Open regedit and navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList
  • Click each SID and look at the ProfileImagePath, locate the one that has UserD1 in it and change it to point to C:\Users\UserL1
  • Logout and back in with UserD1 and it should load the local profile
 


Last edited:
Thanks for getting back to us with additional details on your domain situation. Having managed a domain network just a bit larger than yours (680 PCs), I'm very aware of the challenges you are facing. Hoping that neemo's commands can be used in a script or batch file that would work with your computer. You have some challenges, and so does your IT department. Here's a short list:

1.) From the Business Continuity standpoint (what we used to call Disaster Recovery), how will your system be affected by electronic or mechanical failures such as a failed Hard Drive in your company-owned PC? If they repair it, how will they replace the disk image that's currently working once you apply neemo's commands to a script or batch file to your computer and you get it all working? If they don't have a disk imaging software that they've tested and in place or a roaming profile deployment setup as I previously mentioned, how are they going to put Humpty-Dumpty back together again? I'm talking about your Computer which is likely to be a "one-off" PC in your Company, since you are going to be the guinea pig for this new domain user configuration. Sounds like you are an app developer for Windows or a programmer of some sort based on the Cygwin Redhat-Posix software.
2.) If you and your IT department do have a backup plan in place using either enterprise image backup software or the use of the SDK and roaming profile deployment to re-image your machine, the question is it will need to be tested on your machine, or a nearly identical one to the one you have now. If they (IT dept.) decides to use this for other developers in your domain network, they'll have to run the script file and image restore on more domain user PCs or test the Roaming Profile's ability to restore operational login for other users on the domain besides you and test the security as you mention. The issue will be here, that if those other users are on other subnets at your Company's HQ location (where your Domain servers live), there will be changes that need to be made to the routers in those other subnets that let that kind of traffic through from the domain server to those User's PCs. This is only part of it, as if you have remote offices, say you are based in Chicago, but you have offices throughout the US; and you or other users are located in satellite offices; again network changes will need to be applied to the routers in those other physical locates via reprogramming of those routers as well. In most cases, that can be done remotely; but it's still time consuming. Other issues will be let's say you have a User in the Portland OR office, and he get's transferred to the LA office. When he moves the routers in the LA office have to be reprogrammed to accommodate the network permissions that were in place in the Portland office router over to LA. As you can imagine this has lots of repercussions from the network management standpoint. Such as who in IT will do this, how long will it take to do etc.? In larger companies, they use a Ticket for a Move/Add/Change (MAC) request to get this done. If often involves signing off on cost-centers between departments as I said earlier; but you're company hasn't implemented that yet.
You personally may not be responsible for handling these types of situations, but surely someone in your IT department will be, or the IT Directory or CIO ultimately if you have one. They are responsible for assigning Manpower to a project such as this, and someone has to pay for that, and it's unlikely that your IT management has carte blanche on hours, manpower, or resources.

My point is that this could turn in to a much larger project than you think it is, if it does get replicated to other Users on your company network. This takes time, money, and manpower. Having been a Project Manager in IT I'm aware of these challenges even if you or your IT department is not. If you turn out to be the only one who ever uses this custom configuration in your company due to the difficulty of incorporating support for your PC, they can probably live with it. If it needs to get duplicated to 3, 10, 50, 100 or more users, across multiple subnets, in multiple time-zones, then it becomes much more difficult and expensive. And if your company has multiple domain servers that are being logged into that further complicates things too. Most companies, especially if they are involved in a merger/acquisition by a larger company or a smaller company face integrating multiple domains into one global domain server. If that's not the case and you only have 1 domain server currently that makes the task less challenging than otherwise.

Just some thoughts to let you know the can of worms you may have opened up. Your goal of increased security is worthy, but unless you have physical locations outside the HQ office where the domain server(s) live, I don't believe this whole thing will fly in terms of getting deployed to other users in your network. That's just my opinion from having done it of course.

Let us know how it goes.
<<<BBJ>>>
 


Back
Top