I’m (still) running Win-7 Home Premium. I understand the risks and, for a number of reasons, still DO NOT want to upgrade to Win-10 or to rebuild my win-7 installation to correct this problem. The system was built 8 years ago and, over the years, I have created and deleted numerous user accounts. I currently have three user accounts:
Administrator (SID 500)
AdminUser (SID 1003)
NormalUser (SID 1007)
Somewhere along the way, I deleted the original user account that Windows created during its original install which I believe was assigned SID 1000.
On the current system, things generally work as desired. But I occasionally encounter strange behavior and failures. During troubleshooting, I discovered that many folders retain ACL entries that refer to the now-orphaned SID 1000. For example, the command
icacls c:\ProgramData /save output.txt
produces the following
ProgramData
D:PAI(A;OICI;FA;;;SY)(A;OICI;FA;;;BA)(A;OICI;FA;;;S-1-5-21-xxx-yyy-zzz-1000)
The above indicates that NT AUTHORITY\SYSTEM and BUILTIN\Administrators have Full Control permissions. It also lists the full SID for the now-orphaned 1000 user account. I'd like to remove these references to the bogus SID, but the command:
icacls C:\ProgramData /remove S-1-5-21-xxx-yyy-zzz-1000
does nothing when run from an elevated command prompt, reporting Successfully processed 0 files. When using File Manager, the Remove button is grayed-out on the Advanced Security Settings dialog of the Security tab of the Folder’s Properties. So I cannot remove the permission that way either.
How do I remove the reference to this orphaned SID? Or change it to refer to a legitimate SID?
Alternatively, how do I change the SID associated with the existing 1003 user to 1000 so that references to SID 1000 get properly resolved to an active user account?
Any suggestions would be appreciated.
No sooner did I post my question, than I found an answer:
Right-click a File Explorer shortcut pinned to my TaskBar
Select Run as Administrator
Browse to the desired Folder, right-click and select Properties
Select the Security Tab
Remove the undesired User
Not sure why I didn't think to use an elevated File Explorer earlier. But it successfully updated the ACLs and now the references to the bogus SID are gone. :-)
There was a tool subinacl.exe that was provided by Microsoft until 2004. It is a bit hard to find now (see https://answers.microsoft.com/en-us/windows/forum/all/i-wanted-to-download-subinacl-but-i-cant-find-it/a8bf4c50-1d43-4f03-b6f9-f62deab010fb ).
With this tool you can remove all invalid SIDs from a folder and subfolders.
subinacl /subdirectories "C:\folder\*.*" /cleandeletedsidsfrom=<domain>
It was helpful for me, but the output seems to be corrupt. So I bypassed the output to a file by >logfile.txt
Related
Apologies if this is a really simple question...
We have a .NET application that is installed by an administrator, and then run by multiple staff on the same computer with their own login credentials (normal user - non-admin).
Application uses MSI installer and is installed to Program Files folder.
The application needs to have some settings about attached devices to the computer saved as preferences so when a user opens the app these settings are set and the user is not asked for preferences each time. These preferences should not be set per user, rather per computer.
However if user A changes one of these settings on the computer, then when user B logs in they should see the changed setting from user A.
Hence the settings need to be per computer, not per user.
Where in windows 7,8,10 etc. can an application save data that is computer specific not user specific, yet allow users without admin rights to change that data?
We have looked at system temp folder but the computers have GPO policy to regularly remove temp folder content.
Any other ideas?
It takes administrator rights to change the permissions on a registry key inside HKLM, but once that's done, anyone in the group given permission can make modifications.
Obviously don't change permissions on any of the standard keys (e.g. HKLM\Software or HKLM\Classes) but in your own application area (HKLM\Software\YouCorp\YouApp\Attached Devices) it's perfectly fine to adjust permissions the way you like.
You'll just have to include "grant write permission on HKLM\Software\YouCorp\YouApp\Attached Devices to the group Users" as one of the actions of your installer.
If you are allergic to the registry, you can do the same with a subdirectory of your application install (e.g. %ProgramFiles%\YouCorp\YouApp\Device Settings)
Given you are using a .Net application, you could store the information in the app.config file associated with the application.
I have a VB6 application which links to several POS terminals from a Windows 7 32-bit machine. The POS terminals are mapped to the Windows 7 machine and I can access the POS terminals from the Windows 7 machine from Explorer or via the cmdline/shell.
The application has been updated to ADO 2.8 and all other controls and components I no longer had source code for have been re-written. After a few annoying hiccups, I got the application to recompile on the Windows 7 computer without errors.
Now come the problems. The VB6 application cannot see or navigate to any mapped drives! I have tried twiddling UAC settings; I have set the app to run in Windows XP SP3 mode; I have tried running as Administrator. None of these things (and many permutations of these) work.
Any suggestions on how to make this work?
Adding this registry setting solved the problem for me: http://technet.microsoft.com/en-us/library/ee844140%28v=ws.10%29.aspx.
To work around this problem, configure the EnableLinkedConnections
registry value. This value enables Windows Vista and Windows 7 to
share network connections between the filtered access token and the
full administrator access token for a member of the Administrators
group. After you configure this registry value, LSA checks whether
there is another access token that is associated with the current user
session if a network resource is mapped to an access token. If LSA
determines that there is a linked access token, it adds the network
share to the linked location. To configure the EnableLinkedConnections
registry value
Click Start, type regedit in the Start programs and files box, and
then press ENTER.
Locate and then right-click the registry subkey HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System.
Point to New, and then click DWORD Value.
Type EnableLinkedConnections, and then press ENTER.
Right-click EnableLinkedConnections, and then click Modify.
In the Value data box, type 1, and then click OK.
Exit Registry Editor, and then restart the computer.
I believe you are having trouble because casual drive mapping is per-user, and on a UAC system Administrators group users have two separate contexts (one for each token: SU & elevated).
There is such a thing as a system level drive mapping, which is one done under the System user (NT Authority\System). When you map a drive under this account, and map it persistently, all users can see and use the mapping (subject to the usual access rights for files there).
The normal way you do this is via Domain-level GPOs (Group Policy Objects), which means bribing your local box jockeys if in a corporate managed LAN environment.
One way to do this in a Workgroup machine is to map the letter as System via the AT command, from an elevated command prompt:
at 8:53 am "net use m: \\MediaShare\MyLibrary
ThePW /user:MediaShare\TheUser /persistent:yes > nul"
There the remote server is MediaShare, user TheUser, password ThePW, and 8:53 AM is a minute or two in the future to avoid accidentally scheduling this for tomorrow.
But this fails on Vista and later due to Session 0 Isolation!
So... use the 3rd alternative at Run CMD.exe as Local System Account which is the same thing mentioned by ForcePush's reply to How to map a network drive to be used by a service.
I believe that's what you are after here.
don't know if you ever figured this one out but for me it was the ChDir command (even with the registry fix above).
I had in my code
ChDir "P:\Temp\VidCap\Cam1\" 'I almost never use ChDir
Open "list.txt" For Output As #1
and all the VB6 inbuilt file commands looked straight though any operations, no errors, no nothing. I solved it by explicitly having the path, (in my code it was in a string but you could have it explicitly):
dd = "P:\Temp\VidCap\Cam1\"
Open dd & "list.txt" For Output As #1
works as expected.
hope this helps
H
Try this:
Open command prompt as administrator, and type this in:
net use Z: \\IP Address\share /user:you passwd /persistent:Yes
Change "IP Address", the "share" name, and your username and password as needed.
The author of this is howtogeek (source).
I had same problem. VB6 kept crashing when trying to access USB and mapped drives using the Commondialog method, even though the drives and files were all accessible OK via Explorer. Problem is the drives were not set as shared.
Solved by selecting the connected USB drive in explorer and then right click to
select Properties.
Select Sharing Tab
Select Advanced Sharing
Set the sharing and user rights as needed. May need to have local admin rights.
I have an addin program that works with MS Word (version 2007). It is located in the C:\Program Files location. I installed Windows 7 and then went to make a routine change to my files in this location and it would only bring up a read only file. How can I grant myself permission to write to my own program? I cannot change this location or use any other workaround. I have this product out to 25 different companies and I can't change the programming to work from any other location. Thanks
You could also embed a manifest in your EXE that makes your program require adminrights on Windows 7 / Vista.
On Windows Vista, UAC means that users run without admin rights and don't have write access to the program files directories.
The correct solution is to write to a folder for which standard users do have write permissions.
The solution you are looking for is to make your app's folder within program files writeable to all users. You can do this by adding a DACL when installing. It is extremely bad practice to allow standard users to write inside the program files directory and I urge you instead to re-code your app so that it does not need to write there.
Assuming you're doing this as part of modifying the config (and not when your application is running for regular users)...
Your user account probably doesn't have the correct permissions to write/modify the file. Assuming your account is an administrator account, right-click the file, select "Properties". Click the "Security" tab. Click edit and give your user account Full Control.
If you can't do this, it's probably because the ownership of the file doesn't allow you. If this is the case, click on "Advanced", go to the "Owner" tab, and click "Edit".
However, if it needs these permissions when it's running, you should instead be using the %AppData% folder.
I installed my application in Windows 7 and as part of the installation, it installs some text files. Now, if I open the text file in notepad and try to save it, I get an "Access denied" error. I'm logged in as administrator on the machine and the file is not marked read only and security permissions seem to be fine.
However, I could delete or rename the file without any problem and I could create a new file with the same name/location using notepad and the save works fine.
I understand it has something to do with UAC. I'm wondering what UAC does in order to block access to the file. Our application is not installed in Program files folder as I believe UAC restrict any changes to files in Program Files folder
Can anyone throw light on what is going on.
regards
G
With UAC, just because you're logged in as a user with administrator privileges does not mean a program actually runs with them. The program has to either request privilege elevation (which gives the "Do you want to allow this program to _____" UAC pop-up) or explicitly be run as administrator (right-click on the program/shortcut and choose Run as Administrator).
By default most areas of the drive outside of the standard "user files" (a.k.a. My Documents & co.) are restricted to administrator-only access, but the folder permissions can be changed to add access for a particular user if desired.
You will find that saving files almost anywhere except the "my documents" area for the user will be restricted, this includes saving to other drives on the system etc.
If you check the permissions for the directory you are trying to write to, all you have to do is expressely give the user permission. Otherwise only the admins have permission, which requires UAC approval from the user to get the admin token.
You normally get "Access Denied" error when the file is in use. UAC could not be an issue here. Check out if the file is in use by anyother process.
You can use tools like Process Explorer from sysinternals to do that.
You have to right click the file and select properties. THen open the security tab and you can see different accounts with differet privelages. Click USERS and it should highlight. The box under it should have a bunch of check marks that indicate what this user can do. Click Full Control. Apply and Okay. Then you can save!!!
I want to known who is locking a file on a network share.
Here is the problem : the network share is on a NAS, so I can't log on. I need a tool to find out remotely who is locking the file. It is not practical to reboot the NAS every time, because there are several users.
Handle.exe, Process Explorer and PsFile seems to be limited to files on the local machine, so they don't work for me.
Just in case someone looking for a solution to this for a Windows based system or NAS:
There is a built-in function in Windows that shows you what files on the local computer are open/locked by remote computer (which has the file open through a file share):
Select "Manage Computer" (Open "Computer Management")
click "Shared Folders"
choose "Open Files"
There you can even close the file forcefully.
On Windows 2008 R2 servers you have two means of viewing what files are open and closing those connections.
Via Share and Storage Management
Server Manager > Roles > File Services > Share and Storage Management > right-click on SaSM > Manage Open File
Via OpenFiles
CMD > Openfiles.exe /query /s SERVERNAME
See http://technet.microsoft.com/en-us/library/bb490961.aspx.
PsFile does work on remote machines. If my login account already has access to the remote share, I can just enter:
psfile \\remote-share
(replace "remote-share" with the name of your file server) and it will list every opened document on that share, along with who has it open, and the file ID if I want to force the file closed. For me, this is a really long list, but it can be narrowed down by entering part of a path:
psfile \\remote-share I:\\Human_Resources
This is kind of tricky, since in my case this remote share is mounted as Z: on my local machine, but psfile identifies paths as they are defined on the remote file server, which in my case is I: (yours will be different). I just had to comb through the results of my first psfile run to see some of the paths it returned and then run it again with a partial path to narrow down the results.
Optionally, PsFile will let you specify credentials for the remote share if you need to supply them for access.
Lastly, a little known tip: if someone clicks on a file in Windows Explorer and cuts or copies the file with the intent to paste it somewhere else, that act also places a lock on the file.
If its simply a case of knowing/seeing who is in a file at any particular time (and if you're using windows) just select the file 'view' as 'details', i.e. rather than Thumbnails, tiles or icons etc. Once in 'details' view, by default you will be shown;
- File name
- Size
- Type, and
- Date modified
All you you need to do now is right click anywhere along said toolbar (file name, size, type etc...) and you will be given a list of other options that the toolbar can display.
Select 'Owner' and a new column will show the username of the person using the file or who originally created it if nobody else is using it.
This can be particularly useful when using a shared MS Access database.
The sessions are handled by the NAS device. What you are asking is dependant on the NAS device and nothing to do with windows. You would have to have a look into your NAS firmware to see to what it support. The only other way is sniff the packets and work it out yourself.
Partial answer: With Process Explorer, you can view handles on a network share opened from your machine.
Use the Menu "Find Handle" and then you can type a path like this
\Device\LanmanRedirector\server\share\
sounds like you have the same problem i tried to solve here. in my case, it's a Linux fileserver (running samba, of course), so i can log in and see what process is locking the file; unfortunately, i haven't found how to close it without killing the responsible session. AFAICT, the windows client 'thinks' it's closed; but didn't bother telling the fileserver.
Close the file e:\gestion\yourfile.dat, open by any user (/a *)
openfiles /disconnect /a * /op "e:\gestion\yourfile.dat"
more in:
http://dosprompt.info/commands/openfiles.asp