[gptalk] Re: Installing Applications Fails[Scanned]
- From: "Darren Mar-Elia" <darren@xxxxxxxxxx>
- To: <gptalk@xxxxxxxxxxxxx>
- Date: Thu, 15 Feb 2007 16:21:34 -0800
Thorbjorn-
Thanks for that. I had always assumed that LocalSystem was different than
the machine account but I just tested it and it does not appear to be. Or at
least, as localSystem I am able to access SYSVOL resources. I?ll have to go
back and look at the GP logs I?ve seen where impersonation is happening to
verify that it is indeed impersonating the computer. Perhaps not!
Have a good weekend.
Darren
From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On
Behalf Of Thorbjörn Sjövold
Sent: Thursday, February 15, 2007 2:49 PM
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Re: Installing Applications Fails[Scanned]
Darren,
are we talking about the same thing, I do not follow you? Unless something
is wrong with the ACLs of SYSVOL or the computer account you would be able
to do a DIR for example from a command prompt running with LocalSystem
credentials. Perhaps I misunderstood what you meant but since there seems to
be some general confusion about what happens when the LocalSystem accesses
the network, a short summary could be cool for those of you that are in the
mood for some weekend geek reading; yes I know it isn't weekend yet, but
here in Sweden we are at least getting very close to Friday :).
LocalSystem (or Network Service) is the machine account (or at least have
the NT AUTHORITY\SYSTEM SID in its token), and can access to the network
(unless we are talking NT4 where the SYSTEM credentials accessing the
network resulted in a Null Sessions, basically as no user at all), no need
for impersonfication, i.e. any process running as LocalSystem access the
network as <domain>\<computername>$. Although there are some strange stuff
going on under the hood for computer accounts, for instance is the
LocalSystem Kerberos Tickets not populated with the SIDs of the groups as a
normal user token is, add your computer to a some groups, reboot, start a
command prompt as LocalSystem (described at the start at this thread) and
run a WHOAMI /GROUPS and you'll see that the groups are not there. But in
the end this is not something one need to worry about, this is taken care of
during the network access, the important thing is that it is possible to
access the network as Local System without any extra effort, besides the
proper permissions of course on the network resources). I have done this
both from Services and Group Policy Client Side Extensions I've written, all
running as LocalSystem, so I am sure it works :)
Since GP is running inside the Winlogon process, prior to Vista, and
Winlogon is running as LocalSystem this is exactly the same scenario. If we
forget that Winlogon.exe/Userenv.dll handles all the profile stuff etc that
obviously requires impersonification if the user logging on, my guess is
that any impersonification calls being made during actual GP processing is
since Winlogon uses the users token when processing GP for users, but if it
really also impersonate during computer processing then my guess is that it
is because the GP team wanted the code to be identical for users and
computers, impersonating yourself is not forbidden (although the effect is
of course not very drastic since it is like going to a masquerade and dress
up as yourself ), and thus they get more readable code instead of doing some
stuff for the user and some for the computer. But since I do not have access
to the Windows source code :( it is only my qualified guess.
Best,
Thorbjörn Sjövold
Special Operations Software
www.specopssoft.com <http://www.specopssoft.com/>
thorbjorn.sjovold a t specopssoft.com
Download our free tool for remote Gpupdate with graphical reporting,
http://www.specopssoft.com/products/specopsgpupdate/
_____
From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On
Behalf Of Darren Mar-Elia
Sent: den 15 februari 2007 15:53
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Re: Installing Applications Fails[Scanned]
Thorbjorn-
I would think this would not work at all from the LocalSystem account
because in order for it to access network resources, it would need to
impersonate the machine account, which I didn?t think was an automatic thing
(i.e. during GP processing, there is an explicit call to ImpersonateUser).
Darren
From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On
Behalf Of Thorbjörn Sjövold
Sent: Thursday, February 15, 2007 5:14 AM
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Re: Installing Applications Fails[Scanned]
My suggestion was something like (If your AD domain DNS name is for example
"parkstone.local")
DIR \\parkstone.local\SYSYVOL\parkstone.local
<file:///\\parkstone.local\SYSYVOL\parkstone.local> (from a client where
you are experiencing the problem)
Thorbjörn Sjövold
Special Operations Software
www.specopssoft.com <http://www.specopssoft.com/>
thorbjorn.sjovold a t specopssoft.com
Download our free tool for remote Gpupdate with graphical reporting,
http://www.specopssoft.com/products/specopsgpupdate/
_____
From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On
Behalf Of Craig Judd
Sent: den 15 februari 2007 13:49
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Re: Installing Applications Fails[Scanned]
Thanks Thorbjörn
I have again run an interactive session and tried what you said, but cannot
seem to connect to the SYSVOL
When I run NET VIEW from the domain controller in question I can see all the
shares including NETLOGON AND SYSVOL but yet when I try to open them I
receive the following error.
?SYSTEM ERROR 123
The filename, Directory Name, or Volume label syntax is incorrect.?
When you suggested connecting to
<file:///\\%3cdomain.rootdomain\SYSVOL\%3cdomain.rootdomain>
\\<domain.rootdomain\SYSVOL\<domain.rootdomain what exact syntax should I
use for this.
Thanks
Craig
From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On
Behalf Of Thorbjörn Sjövold
Sent: 15 February 2007 10:00
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Re: Installing Applications Fails[Scanned]
You are running with the system credentials (system level) but you get
prompted for credentials because the Redirector (Workstation service)
figures out that to access the resources you request the current ones are
inadequate. On the network the mighty Local System account is just another
user, if you have security logging enabled on your share you would find the
computer name with a $ sign , e.g. "mycomputer$" sign after it as it it is
the computer SAM account name that is used when a computer is trying to
access something.
Your account obviously are still connected to the domain, since Group Policy
is processing fine. In the System command prompt I assume you can read from
SYSVOL. i.e. \\ <file:///\\%3cdomain.rootdomain\SYSVOL\%3cdomain.rootdomain>
<domain.rootdomain\SYSVOL\<domain.rootdomain ? Also do you have any problems
accessing the shares as an ordinary user and not as the computer?
HTH,
Thorbjörn Sjövold
Special Operations Software
www.specopssoft.com <http://www.specopssoft.com/>
thorbjorn.sjovold a t specopssoft.com
Download our free tool for remote Gpupdate with graphical reporting,
http://www.specopssoft.com/products/specopsgpupdate/
_____
From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On
Behalf Of Craig Judd
Sent: den 15 februari 2007 10:21
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Re: Installing Applications Fails[Scanned]
I did try this, it seems like an excellent way to determine access rights
from the system level. I obviously have a problem because I am trying to
connect to our shares
Net view \\10.1.1.10\[sharename <file:///\\10.1.1.10\%5bsharename> ] and I
get the error
?System error 5 Access is denied? ? this seems to be blanket across all
shares, even if I have ?everyone? read only and the ?domain computers? read
only on the shares and file level security.
If I Net Use * \\10.1.1.10\[sharename <file:///\\10.1.1.10\%5bsharename> ] I
get prompted for username and password. But I thought this was running at
the system level?
Any ideas?
Regards
Craig
From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On
Behalf Of Thorbjörn Sjövold
Sent: 14 February 2007 15:22
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Re: Installing Applications Fails[Scanned]
If this is a computer based deployment, here is a neat little trick to check
if this is permission problem:
1) Log on as an administrator on a computer where you have the problem.
2) Start a Command Prompt
3) Run the command "AT <A time close to now> /Interactive cmd.exe"
4) When the jobs runs a new command prompt will pop up where you are
actually running with the security credentials as the System, i.e. the
computer account.
5) Try to access the path where your files are located using for example DIR
from the new command prompt. If you get an Access Denied here then you know
it is a permission problem.
Observe that this will not work in Vista due to all services and the system
itself now have their Windows Stations in Session 0 and we mortals do not :)
HTH,
Thorbjörn Sjövold
Special Operations Software
www.specopssoft.com <http://www.specopssoft.com/>
thorbjorn.sjovold a t specopssoft.com
Download our free tool for remote Gpupdate with graphical reporting,
http://www.specopssoft.com/products/specopsgpupdate/
_____
From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On
Behalf Of Darren Mar-Elia
Sent: den 14 februari 2007 15:58
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Re: Installing Applications Fails
Craig-
This is a common problem I see and I?ll be darned if I can find a common
thread. But, some things to check. If you are deploying per-computer, try
granting the Domain Computers group explicit read access to these shares and
files. I know that it shouldn?t matter if you already have the Everyone
group but I have seen this help. 2nd thing?if the servers are 2003, SP1,
there may be some SMB signing going on that the clients can?t handle. Make
sure that your security settings on the servers don?t require SMB signing or
that your clients are set to respond to it.
Those are the two things that come to mind right away. Let us know if
neither helps.
Darren
From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On
Behalf Of Craig Judd
Sent: Wednesday, February 14, 2007 12:45 AM
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Installing Applications Fails
Hi
We have a medium sized Active Directory that has been in place for about 3
yrs, apart from the deployment of the Office Suite against the ?domain
policy? we have OU?s that represent each group of machines and in turn we
have associated applications for each department trying to install from
these OU?s. The office installation succeeds by the way.
However it has come to light that these other apps fail to be deployed
successfully, the LOG entry says that the ?source installation file is not
available?.
So we see that when we reboot a client workstation it says that it is
installing the required application, it all appears to go through ok, the
log in box finally appears, but yet the deployed application has not been
installed.
The source files are available at the share location, and all security and
rights are available to everyone as read only.
Any pointers as to why the apps are failing to deploy would be a huge help,
thanks in advance.
Craig Judd
ICT Network Manager
Parkstone Grammar School,
Sopers Lane,
Poole,
Dorset.
BH17 7EP
01202 605617
Other related posts:
