Need Repros, UAC breaks Domain GPO or Logon scripts.

  • Thread starter Thread starter John [MS]
  • Start date Start date
J

John [MS]

I've been tracking an issue regarding UAC breaking logon scripts and I
need Repro's/scripts/examples. From what I've seen if you have your script
in the User/Logon GPO it pops UAC on some operations such as installing
antivirus or executing remote monitoring clients, cancelling on the UAC
prevents the domain policy from being fulfiled.

In some cases I have seen that moving these scripts to the Computer/Startup
GPO fixes the problem. Anybody had issues with similar cases? Have a bug
that was closed By Design, Not Repro relating to this type of issue, chime
in. Windows 2003 SBS connection issues welcome too.

Thanks,

John
Microsoft Windows Beta Team
(e-mail address removed)
 
John said:
I've been tracking an issue regarding UAC breaking logon scripts
and I need Repro's/scripts/examples. From what I've seen if you have
your script in the User/Logon GPO it pops UAC on some operations such
as installing antivirus or executing remote monitoring clients,
cancelling on the UAC prevents the domain policy from being fulfiled.

In some cases I have seen that moving these scripts to the
Computer/Startup GPO fixes the problem. Anybody had issues with
similar cases? Have a bug that was closed By Design, Not Repro
relating to this type of issue, chime in. Windows 2003 SBS connection
issues welcome too.
Thanks,

John
Microsoft Windows Beta Team
(e-mail address removed)
Click to expand...

Connecting to my SBS 2003 server as a domain user who is not a member of the
local administrator group (standard Vista user) pops up a uac prompt. If you
then specify a local administrator account that is not a domain account
(default first account from Vista install) you are then prompted again for
network credentials. If you specify a domain user that is in the local
administrators group then there is no second prompt for domain credentials.
It would be nice if SBS domain users did not need to be members of the local
administrators group. This happens with builds 5384 and 5472.

With 5384 I also had problems with group policies intermittently not being
applied with the same SBS domain. With 5472 this seems to be fixed. The SBS
group policies have not been modified from the default SBS install.

The media used for the SBS install was Microsoft Windows Small Business
Server 2003 Standard Edition with Service Pack 1. On the COA on the outside
of the box it is called WIN SBS STD 2003 W/SP1 ENGLISH CD/D.
 
Kerry said:
Connecting to my SBS 2003 server as a domain user who is not a member
of the local administrator group (standard Vista user) pops up a uac
prompt. If you then specify a local administrator account that is not
a domain account (default first account from Vista install) you are
then prompted again for network credentials. If you specify a domain
user that is in the local administrators group then there is no
second prompt for domain credentials. It would be nice if SBS domain
users did not need to be members of the local administrators group.
This happens with builds 5384 and 5472.
With 5384 I also had problems with group policies intermittently not
being applied with the same SBS domain. With 5472 this seems to be
fixed. The SBS group policies have not been modified from the default
SBS install.
The media used for the SBS install was Microsoft Windows Small
Business Server 2003 Standard Edition with Service Pack 1. On the COA
on the outside of the box it is called WIN SBS STD 2003 W/SP1 ENGLISH
CD/D.
Click to expand...

I forgot to mention. I have not been able to get the SBS
https://sbs-server-name/connectcomputer/ wizard to work in Vista. I have to
manually join the computer to the domain.
 
Kerry said:
Connecting to my SBS 2003 server as a domain user who is not a member of
the local administrator group (standard Vista user) pops up a uac prompt.
If you then specify a local administrator account that is not a domain
account (default first account from Vista install) you are then prompted
again for network credentials. If you specify a domain user that is in the
local administrators group then there is no second prompt for domain
credentials. It would be nice if SBS domain users did not need to be
members of the local administrators group. This happens with builds 5384
and 5472.
Click to expand...

That would be because the standard SBS login script invokes the SBS client
setup utility, which requires local administrative privileges.

On XP clients, this utility simply fails for non-administrative users.
It's only because of UAC/LUA/etc on Vista that there's an opportunity to
enter administrative credentials and have the utility do its' thing (which
is to install Outlook if necessary, configure IE, create entries in
Network Places, etc.)
 
Steve said:
That would be because the standard SBS login script invokes the SBS
client setup utility, which requires local administrative privileges.

On XP clients, this utility simply fails for non-administrative users.
It's only because of UAC/LUA/etc on Vista that there's an opportunity
to enter administrative credentials and have the utility do its'
thing (which is to install Outlook if necessary, configure IE, create
entries in Network Places, etc.)
Click to expand...

I know that's the reason why. I still feel it's a bug. I don't like the way
it works with XP and it's worse with Vista. It is a big security flaw
forcing everyone to be a local administrator and goes against the grain of
the new security model in Vista. It will be a major problem when deploying
Vista workstations in a SBS environment if you don't want everyone to be
local administrators. There will be no end of the users complaining about
the UAC prompt, asking what they should do, what's the password, etc. At
least with XP you could work around it. The SBS group rather than the Vista
group will have to fix it. If I complain about it every chance I get
hopefully sooner or later it will get through to the right people.
 
Thats exacly my thoughts on the matter and the issue Im trying to prevent.
Can you email me your logon script from that 2k3 server?

Thanks

John
Microsoft Windows Beta Team
(e-mail address removed)


Kerry Brown said:
Steve said:
Kerry said:
John [MS] wrote:
I've been tracking an issue regarding UAC breaking logon scripts
and I need Repro's/scripts/examples. From what I've seen if you have
your script in the User/Logon GPO it pops UAC on some operations
such as installing antivirus or executing remote monitoring
clients, cancelling on the UAC prevents the domain policy from
being fulfiled. In some cases I have seen that moving these scripts to
the
Computer/Startup GPO fixes the problem. Anybody had issues with
similar cases? Have a bug that was closed By Design, Not Repro
relating to this type of issue, chime in. Windows 2003 SBS
connection issues welcome too.
Thanks,

John
Microsoft Windows Beta Team
(e-mail address removed)

Connecting to my SBS 2003 server as a domain user who is not a
member of the local administrator group (standard Vista user) pops
up a uac prompt. If you then specify a local administrator account
that is not a domain account (default first account from Vista
install) you are then prompted again for network credentials. If you
specify a domain user that is in the local administrators group then
there is no second prompt for domain credentials. It would be nice
if SBS domain users did not need to be members of the local
administrators group. This happens with builds 5384 and 5472.
Click to expand...

That would be because the standard SBS login script invokes the SBS
client setup utility, which requires local administrative privileges.

On XP clients, this utility simply fails for non-administrative users.
It's only because of UAC/LUA/etc on Vista that there's an opportunity
to enter administrative credentials and have the utility do its'
thing (which is to install Outlook if necessary, configure IE, create
entries in Network Places, etc.)
Click to expand...

I know that's the reason why. I still feel it's a bug. I don't like the
way it works with XP and it's worse with Vista. It is a big security flaw
forcing everyone to be a local administrator and goes against the grain of
the new security model in Vista. It will be a major problem when deploying
Vista workstations in a SBS environment if you don't want everyone to be
local administrators. There will be no end of the users complaining about
the UAC prompt, asking what they should do, what's the password, etc. At
least with XP you could work around it. The SBS group rather than the
Vista group will have to fix it. If I complain about it every chance I get
hopefully sooner or later it will get through to the right people.
Click to expand...
 
Kerry Brown wrote:

I know that's the reason why. I still feel it's a bug. I don't like the
way it works with XP and it's worse with Vista. It is a big security flaw
forcing everyone to be a local administrator and goes against the grain of
the new security model in Vista. It will be a major problem when deploying
Vista workstations in a SBS environment if you don't want everyone to be
local administrators. There will be no end of the users complaining about
the UAC prompt, asking what they should do, what's the password, etc. At
least with XP you could work around it. The SBS group rather than the
Vista group will have to fix it. If I complain about it every chance I get
hopefully sooner or later it will get through to the right people.
Click to expand...

I disagree with the idea that ordinary users should be granted
administrative privileges on the workstation they use - so I don't do so.

It's trivial to eliminate the problem:

* rename the standard SBS logon script, and put an empty script in its'
place (keeps the wizards happy), or
* comment out the invocation of the client setup utlity, or
* change it like this (use your favourite user account with local
administrative privileges):

if not "%username%"=="Installer" goto exit
\\<server>\clients\setup\setup.exe /s <server>
:exit


That's three ways to fix it off the top of my head.
 
John said:
Thats exacly my thoughts on the matter and the issue Im trying to
prevent. Can you email me your logon script from that 2k3 server?

Thanks

John
Microsoft Windows Beta Team
(e-mail address removed)
Click to expand...

It's the standard SBS 2003 logon script. It only has one line which is the
following:

\\SBS-SERVER\Clients\Setup\setup.exe /s SBS-SERVER
 
I forgot to mention. I have not been able to get the SBS
https://sbs-server-name/connectcomputer/ wizard to work in Vista. I
have to manually join the computer to the domain.
Click to expand...

I just installed build 5536 and the connectcomputer wizard works sort of if
you run IE using Run as administrator. The computer was joined to the domain
proerly. I could pick which name from the list of available names. I could
not pick any local profiles to migrate to a domain profile. The drop down
list was blank. I had added one user besides the default one added during
the Vista install.
 
Steve said:
Kerry Brown wrote:



I disagree with the idea that ordinary users should be granted
administrative privileges on the workstation they use - so I don't do
so.
Click to expand...

I don't think we disagree here. I wholeheartedly agree that standard users
shouldn't have administrator privileges or access to a password that grants
this.
It's trivial to eliminate the problem:

* rename the standard SBS logon script, and put an empty script in
its' place (keeps the wizards happy), or
* comment out the invocation of the client setup utlity, or
* change it like this (use your favourite user account with local
administrative privileges):

if not "%username%"=="Installer" goto exit



That's three ways to fix it off the top of my head.
Click to expand...

I also agree it's pretty easy to get around the problem. My point is it
shouldn't be a problem in the first place. In a properly designed
client/server network once the client is joined to the network there
shouldn't be any need for users to ever have local administrator privileges.
Programs should be able to install for the user with user privileges.
Updates should be able to be pushed out by the server without any
interaction from the users. I know this is a ways off with Windows based
networks and SBS in particular but if we all complain loud enough the wait
for it to happen will be shorter :-)

This exists in 'nix and Netware environments. It needs to happen in Windows
as well or we will be forever chasing malware problems. Vista is a step in
the right direction but it needs to be made easy enough to use the built in
Vista security or users will find ways to turn it off. The SBS market is one
place where there are many installs administered by people who have grown up
in Windows environments and really don't understand how security should
work. These will be the people that will simply disable the security so the
warnings and problems go away.
 
Kerry said:
I don't think we disagree here. I wholeheartedly agree that standard users
shouldn't have administrator privileges or access to a password that
grants this.
Click to expand...

You're right, I wasn't disagreeing with you. Users as local administrators
without good reason is not a sensible thing to do. Heck, even Microsoft
I also agree it's pretty easy to get around the problem. My point is it
shouldn't be a problem in the first place. In a properly designed
client/server network once the client is joined to the network there
shouldn't be any need for users to ever have local administrator
privileges. Programs should be able to install for the user with user
privileges. Updates should be able to be pushed out by the server without
any interaction from the users. I know this is a ways off with Windows
based networks and SBS in particular but if we all complain loud enough
the wait for it to happen will be shorter :-)
Click to expand...

It's going to happen - but it'll be a while - as it takes new releases or
major service packs for Microsoft to roll out significant changes to
applications.
 
John said:
This is also fixed if the logon script is executed from a Computer/startup
GPO instead.
Click to expand...

Hmmm, not sure that's entirely safe.

* the client setup utility can be configured to allow interaction with the
user
* it applies some settings to the users' profile

I suspect neither of those aspects would work under the solution you're
suggesting (mind you, we'd lose the user-specific bits with an installer
account too).
 
John,

I am an SBS 2003 SP1 user and am also testing Vista RC1. I, too, could not
connect using the connectcomputer facility through IE7 until I enabled the
Administrator account, logged in as Administrator and re-ran connectcomputer.
That worked, but then I noticed the default SBS logon script would hang
awaiting UAC approval. So, I disabled UAC.

I know that circumvents most of the new security in Vista, but the hassle of
having to approve the logon script at each logon is too much.

I am also a consultant to the local county school district. We use logon
scripts - the good old fashioned kind - in each school. We have a few that
run as part of a GPO. If these won't run without the user having to
"approve" each one when logging into the network, UAC will disappear
immediately, I'm certain.
 
B. Getreu said:
John,

I am an SBS 2003 SP1 user and am also testing Vista RC1. I, too, could not
connect using the connectcomputer facility through IE7 until I enabled the
Administrator account, logged in as Administrator and re-ran
connectcomputer.
That worked, but then I noticed the default SBS logon script would hang
awaiting UAC approval. So, I disabled UAC.

I know that circumvents most of the new security in Vista, but the hassle
of
having to approve the logon script at each logon is too much.

I am also a consultant to the local county school district. We use logon
scripts - the good old fashioned kind - in each school. We have a few that
run as part of a GPO. If these won't run without the user having to
"approve" each one when logging into the network, UAC will disappear
immediately, I'm certain.
Click to expand...

They will run, that's not an issue.

But if they attempt to do anything that requires administrative
privileges, UAC will kick in.

This is why the default SBS logon script generates a UAC warning - it
invokes an executable that requires administrative privileges to do its'
work.
 
Back
Top