RSOP.MSC gotcha

[Leo Vasiliou]

Hello:

I just want to make you aware of an unfortunate side-effect with the rsop
snap-in. It probably won't be that big of a deal for most of the admins,
but for those of us it affects, it will be.

When you run rsop.msc, the parameters of any startup/shutdown scripts
supplied by the gpo are passed to the rsop. In my case, in one of my
scripts, I was passing an administrator password in the parameters field (as
recommended by the Windows & .NET periodical, 'Security Administrator' insta
doc 27330).

For example, my startup script contained the following:

net user administrator %1 (where %1 is the local admin password I was
passing to the parameter input on the script)

Yes, the security is set appropriately and the account I am logged on with
has only user permissions in the domain.

-leo

 

[David Fisher [MSFT]]

Hello Leo.

Anyone with read access to the startup script can open it and see the
administrator's password. It is generally not recommended to have an
administrator password located in a script. Running RSOP is simply
reporting the Group Policy configuration of the client--thereby showing the
script contents.

A more secure means to change the password of a client machine would be to
run script from a centralized location to connect to each system remotely
and reset the local administrator's password. This will prevent the need to
pass the password to the "net user" command.

I agree that administrators need to be aware of the security ramifications
of implementing the article you referenced.

Here is a more secure to perform this action:
272530 How to Use the Cusrmgr.exe Tool to Change Administrator Account
Password
http://support.microsoft.com/?id=272530

David Fisher
Enterprise Platform Support

 

[Leo Vasiliou]

Hello David:

"It is generally not recommended to have an
administrator password located in a script."

We are almost on the same page. I wasn't locating an administrator password
in the script. Rather, I was feeding the password to the script through the
use of the script parameters field.

According to the article, passing the password in the parameter field is
acceptable so long as you remove the default permission of 'authenticated
users' from read and apply group policy and instead grant permissions of
read and apply group policy only to the computer accounts the script will
run on.

"Anyone with read access to the startup script can open it and see the
administrator's password."

Agreed. But what I'm trying to point out is that, even after removing the
'authenticated users' group permissions of read and apply group policy and
only allowing the specific computer accounts read and apply group policy,
people can still get the passed parameter by running rsop.msc from any
client that specific gpo applies to.

On an aside, cusrmgr is nowhere near as valuable as the startup/shutdown
script solution. Cusrmgr is good only if:

-) the computer is powered on at the time the script runs. In an
ever-increasing mobile workforce, this problem only grows. With the startup
script, we're guaranteed the local admin password to change when the
computer boots.

-) you assume that an end user won't go behind your back and change the
password after it has been changed by cusrmgr.

-) you have a current list of every computer account you want to change the
password on. In a helpdesk environment; I wouldn't wish this task on my
worst enemy.

-leo