Registry Permissions issue 1

[wlfpackr]

I have some manufacturing engineers that have a test device that is supposed to go out on the floor. The problem is that they can't get it to work properly without a logon ID have local admin rights (which is a strict no-no here).

I've done some testing myself and it appears the problem lies with the following key in the registry: HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\SERIALCOMM. If I give the userID full rights to this key, everything works without issue. The problem is that after a reboot (on or off the network) these rights are removed so the software quits communicating with it's hardware.

I believe the rights are getting removed due to some group policy being pushed out by "the mothership" at corporate HQ, but preliminary responses from those guys sound like they are going to blame Windows XP for this happening. I'm not sure why the OS would allow you to grant permissions and then take them away on reboot? Anyone have any knowledge on this?

=================
There are 10 kinds of people in this world, those that understand binary and those that do not.

 

[Grenage]

No, you're right, it shouldn't happen. It does sound more like a policy, either that or the key removed and recreated by the software, but that's very unlikely.

If you give users access to the key, but remove the SYSTEM's rights, does the problem still occur?

"We can categorically state that we have not released man-eating badgers into the area" - Major Mike Shearer

 

[linney]

Can you use a Logon Script to run at Startup and reset the Key to your specification?

How to add, modify, or delete registry subkeys and values by using a registration entries (.reg) file

http://support.microsoft.com/kb/310516

Can you use something like SubInAcl and run that at Startup and make it applicable to the relevant Registry Key (path) and for the desired user group? Example and details in this link.

Not Getting a "Save As" dialog
thread779-962708

 

[wlfpackr]

Unfortunately, scripting is out of the question. We're part of a Fortune 50 company now and they don't let us do anything that might actually work.

No, you're right, it shouldn't happen. It does sound more like a policy, either that or the key removed and recreated by the software, but that's very unlikely.

If you give users access to the key, but remove the SYSTEM's rights, does the problem still occur?

I tried removing the SYSTEM's rights and it's still doing the same thing.


I tried this on a PC that was off the network and it's also doing the same thing. Even does it at the top level of HKEY_LOCAL_MACHINE. I'm starting to think that Windows' recreates this registry key on boot?




=================
There are 10 kinds of people in this world, those that understand binary and those that do not.

 

[wlfpackr]

I did find this in a Microsoft article:

DeviceMap Subkey Entries for Serial and Parallel Ports

Remember that the entries in HKEY_LOCAL_MACHINE\HARDWARE are recreated each time the system is started. The entries in these subkeys are described here for informational purposes only.

I'm wondering why it won't hold permissions though at the top level (HKLM) and then propagate down when the keys are recreated?

=================
There are 10 kinds of people in this world, those that understand binary and those that do not.

 

[cdogg]

wlfpackr,
Does the same thing happen on a reboot after giving the ID local admin rights to the entire workstation? If so, then either it's group policy thing (despite what HQ is telling you) or you're using a thin client workstation.

Thin clients (or "fat" clients) load from an image saved to a ROM-memory location and not a hard drive. When the OS boots up, many elements are running in local system RAM or if it's a true thin client, it is only a terminal that sends/receives data with a server. Nothing from your session is saved. When you reboot, the default image is loaded. A lot of manufacturing plants I supported at my old job had thin clients on the floor to make image control an easy thing to manage and help prevent downtime.

~cdogg
"Insanity: doing the same thing over and over again and expecting different results." - Einstein
[tab][navy]For posting policies, click [/navy]here.

 

[wlfpackr]

cdogg,

If the ID has LA rights (whether the ID is a domain ID or a local ID) it never has a problem b/c by default LAs have full permissions to that key.

(In our company, by default LA rights are removed on a reboot unless you've filed an exception and are on the exclusion list. I have the ability to manipulate this and exclude specific machines from the GPO that removes admin rights and this option has been tested.)

Also, we are not using thin clients.

=================
There are 10 kinds of people in this world, those that understand binary and those that do not.

 

[cdogg]

In our company, by default LA rights are removed on a reboot unless you've filed an exception and are on the exclusion list.

OK, well now it seems like you are more informed on your company's group policy than you were before. In your first post, you said: "[blue]I'm not sure why the OS would allow you to grant permissions and then take them away on reboot?[/blue]". Obviously, there was at least one GPO in place that removes admin rights. Why then does your earlier post seem surprised that this could be possible? Did you discover additional information since starting this thread?

My guess with this being a fortune 50 company, there are a lot of other GPO's that you aren't aware of as well including one that is apparently resetting permissions on the registry. I realize you excluded the PC from the GPO that resets local groups such as Administrators, but there could be others. Even if it's not a GPO, it could have something to do with the way Discretionary Access Control Lists (DACLs) are setup in your environment. If these are reset when group policy is applied at logon, then the changes you made to any registry keys are lost.

Have a look here for a program called Regperm.exe:

http://homepages.cae.wisc.edu/~micro/regperm/

~cdogg
"Insanity: doing the same thing over and over again and expecting different results." - Einstein
[tab][navy]For posting policies, click [/navy]here.

 

[wlfpackr]

OK, well now it seems like you are more informed on your company's group policy than you were before. In your first post, you said: "I'm not sure why the OS would allow you to grant permissions and then take them away on reboot?". Obviously, there was at least one GPO in place that removes admin rights. Why then does your earlier post seem surprised that this could be possible? Did you discover additional information since starting this thread?

Sorry for the confusion, I am the director for our particular facility and have been for quite some time. Unfortunately, I'm pretty in tune with what is going on with GPOs and restrictions.

My initial point was that either the OS by default was changing the permissions in the registry or that a GPO was changing the permissions. I automatically leaned to GPO b/c I could not think of a single reason as to why Windows would do something like that on it's own. According to Microsoft, though, it appears that in fact, it was the OS making the change and not a GPO.

=================
There are 10 kinds of people in this world, those that understand binary and those that do not.

 

[linney]

Perhaps the actual software will have to be amended to find an alternate way of changing the Permissions in the relevant key if your hands are tied?

What would happen if you had the Bios manage "Plug and Play" rather than the operating system? Would the Permissions in that key then change at each reboot?

This was a handy program to know about, it has been discontinued but can still be found on the Internet. It will allow an user to run a single program as an Administrator.

http://www.palmersoft.co.uk/runasuser.aspx

http://www.savefile.com/files/2115537

 

[BadBigBen]

Maybe this is of some help:


How to: Use a Script to Change Registry Permissions from the Command Line

http://support.microsoft.com/?kbid=245031

Ben
"If it works don't fix it! If it doesn't use a sledgehammer..."
How to ask a question, when posting them to a professional forum.
Only ask questions with yes/no answers if you want "yes" or "no"

 

[cdogg]

My initial point was that either the OS by default was changing the permissions in the registry or that a GPO was changing the permissions...According to Microsoft, though, it appears that in fact, it was the OS making the change and not a GPO.

In this situation dealing with HKEY_LOCAL_MACHINE\HARDWARE, the OS was indeed responsible. This hive contains session values that are reset after a reboot. I should have noticed that before. If you were talking about another hive such as HKEY_LOCAL_MACHINE\SOFTWARE, then we'd be back to looking at group policy or 3rd-party software as the culprit, because here you should be able to get registry permission changes to stick.

This little excerpt explains what I'm referring to:

Most Registry entries are permanent, although some are session dependent, transient, and never written to disk. An example of a transient key is the HKEY_LOCAL_MACHINE\Hardware as generated by automatic hardware detection by the Hardware Recognizer (ntdetect.com for Intel computers). The Hardware key is an example of a session value. Another transient value is the information written as part of a logon for a session, including security tokens.

[tab]-source:

http://www.measureup.com/testobjects/MS_NT4W/5a8e030.htm

As a workaround, you should be able to devise a script (using the information provided in Ben's link above) to adjust permissions for the HARDWARE hive. To be on the safe side, I would have it run at least a minute or two after logon.

~cdogg
"Insanity: doing the same thing over and over again and expecting different results." - Einstein
[tab][navy]For posting policies, click [/navy]here.

 

[perrrr]

I ran across this sometime ago. Look at the bottom for toolbox and select repair permissions. It sounds like a problem in the security part of the registry.

http://www.softpedia.com/progDownload/Dial-a-fix-Download-27328.html

 

[cdogg]

perrr,
Everything under HKLM\HARDWARE is recreated on each reboot. For example if you were to create a "test" key under an ID with admin rights and reboot, it will be gone at logon regardless of permissions. So when HKLM\HARDWARE is generated, the Users group is given read/execute rights only.

 

[Midiean]

download subacl.exe from microsoft and put it in the windows directory. then create a batch file with the following script:

subinacl /subkeyreg HKEY_LOCAL_MACHINE /grant=administrators=f
subinacl /subkeyreg HKEY_CURRENT_USER /grant=administrators=f
subinacl /subkeyreg HKEY_CLASSES_ROOT /grant=administrators=f
subinacl /subdirectories %SystemDrive% /grant=administrators=f

subinacl /subkeyreg HKEY_LOCAL_MACHINE /grant=system=f
subinacl /subkeyreg HKEY_CURRENT_USER /grant=system=f
subinacl /subkeyreg HKEY_CLASSES_ROOT /grant=system=f
subinacl /subdirectories %SystemDrive% /grant=system=f
pause

This scrip will reset all permissions through out the registry.

 

[wlfpackr]

Some good suggestions out there. They are currently running a 72hour stress test with this laptop right now. I simply gave them LA admin rights for the generic ID b/c I'm simply not going to hold up anything dealing with production.

I'll give some of these a try and report back.

=================
There are 10 kinds of people in this world, those that understand binary and those that do not.

 

[CaptainCommandLine]

I encountered this same issue with an application. Without making the faux pa of posting a URL to another forum, I'd recommend searching on Google for:

serialcomm permissions

This should give you an idea for a workaround.