|
Posted by =?Utf-8?B?QWx3aW4=?= on June 30, 2006, 11:51 am
If you were Registered and logged in, you could reply and use other advanced thread options
question and access was denied as expected. running gpresult reveals that the
computer account is part of a whole bunch of groups (that do not appear under
'member of' in AD, for the computer??) one of these groups is 'MyPc$' and
another is Builtin\Users. I have no idea where these memberships come from.
I'm not too worried about the fact that the computer can access the share,
the normal network security seems to control that even though the group
membership is questionable.
What I really don't get is why the service is accessing the share with the
'MyPc$' computer account when it is running as Local System. If a process
running as Local System uses some other set of credentials when accessing the
network then this would mean that the Lcoal System account can in fact access
the network (as long as it's computer account has the rights) - again, this
goes against all the info I have been able to find on the Local System
account?
BTW thanks for all your input here
"Steven L Umbach" wrote:
> When you see a $ after the username that means it is a computer account so
> apparently the computer account was able to authenticate and have access to
> the share. You said that the share has only read for domain users group
> which I believe would not normally contain domain computer accounts. I would
> double check the membership of the domain users group, check the membership
> of the computer account which you can do with the support tool gpresult, and
> double check the share permissions to make sure it does not include users,
> everyone, authenticate users, or any other group the computer is a member
> of. As a test I would also try changing the share permissions to be a
> specific domain user account or change the permissions to deny for domain
> users to see what happens. --- Steve
>
>
> > Thanks Steve, I enabled detailed logging on the server and redid the
> > excercise, these are the the only two entries from the event log:
> >
> > User Logoff:
> > User Name: PCNAME$
> > Domain: MYDOMAIN
> > Logon ID: (0x0,0xBA816)
> > Logon Type: 3
> >
> > and
> >
> >
> > Successful Network Logon:
> > User Name: PCNAME$
> > Domain: MYDOMAIN
> > Logon ID: (0x0,0xBA816)
> > Logon Type: 3
> > Logon Process: Kerberos
> > Authentication Package: Kerberos
> > Workstation Name:
> >
> > Looks like it's connecting with some kind of 'system' computer account?
> >
> > Just some background - I'm developing the service and the GUI that sends
> > the
> > commands to it. This seems to be more of a security issue than a
> > development
> > issue which is why I posted it here.
> > It's a real worry when programs work better than they are not supposed to
> > :-)
> >
> >
> > "Steven L Umbach" wrote:
> >
> >> Offhand I don't know exactly what is going on but what I would do is to
> >> check the security log on the server that has the administrator share to
> >> see
> >> the type 3 logon event generated when access is allowed to the share and
> >> the
> >> user name. The events in the log are time stamped so it should be easy to
> >> find. The info in the link below may also be helpful if you have not seen
> >> it
> >> yet on planning security for service accounts. --- Steve
> >>
> >>
http://www.microsoft.com/technet/security/topics/serversecurity/serviceaccount/sspgch03.mspx
> >> -- The Services and Service Accounts Security Planning Guide
> >>
> >>
> >> > Hi,
> >> >
> >> > I have a custom developed windows service running on XP - very simple ,
> >> > it
> >> > accepts commands via TCP/IP and executes them on the pc on which it is
> >> > installed.
> >> >
> >> > The service gets installed with 'Local System' account credentials
> >> > which
> >> > by
> >> > all accounts does not have access to network resources. I am however
> >> > able
> >> > to
> >> > send commands to the service instructing it to install software
> >> > packages
> >> > which reside on a network share (shared read-only for domain users) and
> >> > it
> >> > works just fine.
> >> >
> >> > I am concerned because all the documentation I have read indicates that
> >> > this
> >> > should not be possible, are there any special circumstances where the
> >> > System
> >> > account can access UNC share paths?
> >>
> >>
> >>
>
>
>
| 
XML site map