BTW - it's common to have shares with permissions of Everyone (or Domain Users, or Authenticated Users) with Full Control, then separately administer the NTFS permissions underneath the share, as that makes administration much easier.
It can become very confusing, for instance, if the Share permissions are Everyone (or some other group) with Read-Only, that controls access to the file system underneath, and nobody (including Domain Admins, etc.) can write/modify the files or directories, when accessing them through the network share - even though the NTFS permissions would otherwise are set to Modify or Full Control. Kurt On Mon, Jun 13, 2011 at 15:03, Tammy Stewart <[email protected]> wrote: > Thanks Kurt, > > Makes sense. They likely logged onto the infected workstation as domain > admin. I can't recall now but will find out. Not sure if they let users have > full control on the shares. > > Thanks, > > Tammy > > -----Original Message----- > From: Kurt Buff [mailto:[email protected]] > Sent: Monday, June 13, 2011 5:05 PM > To: NT System Admin Issues > Subject: Re: User accounts for shared folders > > I see. > > What you're saying implies that the infected workstation talked with > the machine hosting the shares. That's standard - and if the malware > is running in the context of a user that has the Full Control > permissions for the shares, it can strip out or add permissions at > will, without being resident on the machine hosting the shares. > > I have found that all too often folks are given Full Control > permissions, instead of Modify, which is all most people should have - > the only difference between them is that Full Control grants the > ability to modify permissions. > > Kurt > > On Mon, Jun 13, 2011 at 13:05, Tammy Stewart > <[email protected]> wrote: >> Hi Kurt, >> >> It is the NTFS permissions on the shares. (right click folder> properties> >> security) (not who on the network have access) >> Oddly enough other folders that are not shared have all the usual accounts >> listed. >> >> It is a file infecting virus (chir.b) from a few machines hitting the > shares >> -- however the server that had the shares hit did not have the OS hit. > Just >> shares so it did not get to memory or make registry modifications. >> >> Thanks, >> >> Tammy >> >> >> -----Original Message----- >> From: Kurt Buff [mailto:[email protected]] >> Sent: Monday, June 13, 2011 3:42 PM >> To: NT System Admin Issues >> Subject: Re: User accounts for shared folders >> >> On Mon, Jun 13, 2011 at 10:57, Tammy Stewart >> <[email protected]> wrote: >>> Ran into something interesting today t-shooting a virus issue on a >> network. >>> >>> On every share there is no system account listed. Only Domain admins & >>> domain users. >>> >>> My google kung-fu seems to be lacking today but is there anything/reason >> why >>> the system account would not show up? >>> >>> System account does exist on the machine - non shared directories have > it. >>> Just the shares that seem affected. >>> >>> Windows 2003 domain (if that makes any difference) >>> >>> Not just the system with infected files on the shares - all the servers >> are >>> like this including clean ones (that have not been touched by the virus >> yet) >>> >>> Anyone have any kb articles or something I can look at that would explain >>> this? (and hopefully put them back to normal) >>> >>> Thanks! >>> >>> Tammy >> >> When you say that the share doesn't list the System account - do you >> mean the Share permissions, or the NTFS permissions? >> >> Shares never list System for permissions, AFAIK. >> >> If the NTFS permissions for System have been deleted on the >> directories that are shared, that's either a conscious action by >> someone with Full Control permissions listed in an ACE on the >> directory, or else it's something that the malware did. If a person at >> the firm did that, I'd say it's a big mistake - well, unless they are >> doing something unusual, like setting up an FTP server. >> >> Kurt >> >> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ >> ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ >> >> --- >> To manage subscriptions click here: >> http://lyris.sunbelt-software.com/read/my_forums/ >> or send an email to [email protected] >> with the body: unsubscribe ntsysadmin >> >> >> >> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ >> ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ >> >> --- >> To manage subscriptions click here: > http://lyris.sunbelt-software.com/read/my_forums/ >> or send an email to [email protected] >> with the body: unsubscribe ntsysadmin >> > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > --- > To manage subscriptions click here: > http://lyris.sunbelt-software.com/read/my_forums/ > or send an email to [email protected] > with the body: unsubscribe ntsysadmin > > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > --- > To manage subscriptions click here: > http://lyris.sunbelt-software.com/read/my_forums/ > or send an email to [email protected] > with the body: unsubscribe ntsysadmin > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected] with the body: unsubscribe ntsysadmin
