Setting permissions on HKCU\Control Panel\Current

[barabba]

Hi all,

don't ask me why, but I noticed that in our environment (W2K Server
domain, XP Pro SP1 clients) when a new Outlook profile is profiled,
the 1st time that the application loads it an error saying that group
policy are preventing....etc. etc. shows up. This, after a long
research, is due to the fact that users need access (read / set &
query value) to the key HKCU\Control Panel\Current key (but why ???).

Now, what I did is to implement a group policy (registry settings
node) to edit the permissions accordingly in order to hide this error.
However, this key only exists under the User portion and does not
exist in the HKLM node. So I used the Default User (because no users
exist at the start-up of the computer - I cannot set the GP at logon
because the users would not have the rights to perform this change).

The problem is that users do not apply this permissions so they still
get the message. I thought that the when users logon they would apply
the permissions granted to the default users but this does not happen.

I hope I made myself understood.
Does anybody have a workaround to this behaviour ? Anybody has
experienced a similar problem ?

Hope to get a feedback.
Thanks in advance.

Bar

 

[Buz [MSFT]]

Create a script
Put it in the Startup folder.
Have the script call the resource kit tool subinacls to make the permissions
change.
Use RUNAS in the script with an admin account.

Buz Brodin
MCSE NT4 / Win2K
Microsoft Enterprise Domain Support

Get Secure! - www.microsoft.com/security

This posting is provided "as is" with no warranties and confers no rights.

Please do not send e-mail directly to this alias. This alias is for
newsgroup purposes only.

 

[barabba]

Thank you for your reply. Unfortunately your hint is not viable as it
would pose a security risk. Even encrypting the script using
screnc.exe does not guarantee security.

Is there really not "clean" way to configure this setting ?

Thanx,
Bar

 

[Buz [MSFT]]

Well Hkey current user is going to be the users loaded NTUSER.dat from their
profile. You need this loaded to change the permissions via subinacls.

Buz Brodin
MCSE NT4 / Win2K
Microsoft Enterprise Domain Support

Get Secure! - www.microsoft.com/security

This posting is provided "as is" with no warranties and confers no rights.

Please do not send e-mail directly to this alias. This alias is for
newsgroup purposes only.

Thank you for your reply. Unfortunately your hint is not viable as it
would pose a security risk. Even encrypting the script using
screnc.exe does not guarantee security.

Is there really not "clean" way to configure this setting ?

Thanx,
Bar


"Buz [MSFT]" <[email protected]> wrote in message

Create a script
Put it in the Startup folder.
Have the script call the resource kit tool subinacls to make the permissions
change.
Use RUNAS in the script with an admin account.

Buz Brodin
MCSE NT4 / Win2K
Microsoft Enterprise Domain Support

Get Secure! - www.microsoft.com/security

This posting is provided "as is" with no warranties and confers no rights.

Please do not send e-mail directly to this alias. This alias is for
newsgroup purposes only.

 

[barabba]

Hi buz,

thank you for your reply. I am not sure I understood what you say
about the NTUSER.dat loading mechanism. Can you rearrange your answer
? I would appreciate it.

Thanks,
Bar

Well Hkey current user is going to be the users loaded NTUSER.dat from their
profile. You need this loaded to change the permissions via subinacls.

Buz Brodin
MCSE NT4 / Win2K
Microsoft Enterprise Domain Support

Get Secure! - www.microsoft.com/security

This posting is provided "as is" with no warranties and confers no rights.

Please do not send e-mail directly to this alias. This alias is for
newsgroup purposes only.

Thank you for your reply. Unfortunately your hint is not viable as it
would pose a security risk. Even encrypting the script using
screnc.exe does not guarantee security.

Is there really not "clean" way to configure this setting ?

Thanx,
Bar


"Buz [MSFT]" <[email protected]> wrote in message

Create a script
Put it in the Startup folder.
Have the script call the resource kit tool subinacls to make the permissions
change.
Use RUNAS in the script with an admin account.

Buz Brodin
MCSE NT4 / Win2K
Microsoft Enterprise Domain Support

Get Secure! - www.microsoft.com/security

This posting is provided "as is" with no warranties and confers no rights.

Please do not send e-mail directly to this alias. This alias is for
newsgroup purposes only.



Hi all,

don't ask me why, but I noticed that in our environment (W2K Server
domain, XP Pro SP1 clients) when a new Outlook profile is profiled,
the 1st time that the application loads it an error saying that group
policy are preventing....etc. etc. shows up. This, after a long
research, is due to the fact that users need access (read / set &
query value) to the key HKCU\Control Panel\Current key (but why ???).

Now, what I did is to implement a group policy (registry settings
node) to edit the permissions accordingly in order to hide this error.
However, this key only exists under the User portion and does not
exist in the HKLM node. So I used the Default User (because no users
exist at the start-up of the computer - I cannot set the GP at logon
because the users would not have the rights to perform this change).

The problem is that users do not apply this permissions so they still
get the message. I thought that the when users logon they would apply
the permissions granted to the default users but this does not happen.

I hope I made myself understood.
Does anybody have a workaround to this behaviour ? Anybody has
experienced a similar problem ?

Hope to get a feedback.
Thanks in advance.

Bar

 

[Buz [MSFT]]

When a user logs on the NTUSER.dat file is loaded from thier profile. To
easily determine the current profile path go to Start\Run and type in a
single period (.) and press ok. This will take you to the root of the
current profile. Here you will see a file called NTUSER.DAT this file is
loaded into the registry as the HKEY_CURRENT_USER key. When a user logs off
the HKEY_CURRENT_USER key is saved back to the NTUSER.DAT file.

Buz Brodin
MCSE NT4 / Win2K
Microsoft Enterprise Domain Support

Get Secure! - www.microsoft.com/security

This posting is provided "as is" with no warranties and confers no rights.

Please do not send e-mail directly to this alias. This alias is for
newsgroup purposes only.

Hi buz,

thank you for your reply. I am not sure I understood what you say
about the NTUSER.dat loading mechanism. Can you rearrange your answer
? I would appreciate it.

Thanks,
Bar

"Buz [MSFT]" <[email protected]> wrote in message

Well Hkey current user is going to be the users loaded NTUSER.dat from their
profile. You need this loaded to change the permissions via subinacls.

Buz Brodin
MCSE NT4 / Win2K
Microsoft Enterprise Domain Support

Get Secure! - www.microsoft.com/security

This posting is provided "as is" with no warranties and confers no rights.

Please do not send e-mail directly to this alias. This alias is for
newsgroup purposes only.

Thank you for your reply. Unfortunately your hint is not viable as it
would pose a security risk. Even encrypting the script using
screnc.exe does not guarantee security.

Is there really not "clean" way to configure this setting ?

Thanx,
Bar


"Buz [MSFT]" <[email protected]> wrote in message

Create a script
Put it in the Startup folder.
Have the script call the resource kit tool subinacls to make the permissions
change.
Use RUNAS in the script with an admin account.

Buz Brodin
MCSE NT4 / Win2K
Microsoft Enterprise Domain Support

Get Secure! - www.microsoft.com/security

This posting is provided "as is" with no warranties and confers no rights.

Please do not send e-mail directly to this alias. This alias is for
newsgroup purposes only.



Hi all,

don't ask me why, but I noticed that in our environment (W2K Server
domain, XP Pro SP1 clients) when a new Outlook profile is profiled,
the 1st time that the application loads it an error saying that group
policy are preventing....etc. etc. shows up. This, after a long
research, is due to the fact that users need access (read / set &
query value) to the key HKCU\Control Panel\Current key (but why ???).

Now, what I did is to implement a group policy (registry settings
node) to edit the permissions accordingly in order to hide this error.
However, this key only exists under the User portion and does not
exist in the HKLM node. So I used the Default User (because no users
exist at the start-up of the computer - I cannot set the GP at logon
because the users would not have the rights to perform this change).

The problem is that users do not apply this permissions so they still
get the message. I thought that the when users logon they would apply
the permissions granted to the default users but this does not happen.

I hope I made myself understood.
Does anybody have a workaround to this behaviour ? Anybody has
experienced a similar problem ?

Hope to get a feedback.
Thanks in advance.

Bar