NTFS problem

[FunkyGibbon]

Here's the problem. 11.30 yesterday all our internet servers appeared to stop working. Turns out that the reason for this is the services no longer had NTFS file access to the data (accessed as a network share). The user permissions had simply disappeared, or rather been replaced with "Unknown User". Note the user account was not corrupt as it had access to other shares on the system.

I know how to manually add the permissions back, but this is taking ages (over 200,000 files !).

My question is how the did the user permissions get corrputed without human intervention?

TIA

[annodomini2]

if you've to apply it to each file then the information must be stored in the hard drive file table or the file header, an executable/dll (i.e. virus) could change those status bits to change the access rights.

[rich-uk]

Was the account deleted and re-created? The permissions work on the SID (Sercurity Identifier) of the account, not the name, so if you delete the account and create one of the same name, it's not the 'same' account as it'll have a new SID (That's what that long string instead of the name is)

You can cascade permissions thorough a whole folder/drive, saves you doing it to each file. Change the security properites on the highest level folder you can, click 'Advanced' and tick 'Replace permission enteries on all child objects with entries shown here that apply to chils objects'

[onedsla]

rick-uk is dead right - it sounds like the SID of the account has been lost somehow - hey it's microsoft so random stuff can & will happen!

It's loads quicker to run the permissions locally on the server rather than doing it from a remote mapping - shouldn't take more than a couple of minutes to have the permissions cascaded to all sub-folders.
Dave

[FunkyGibbon]

cheers folks.

we've re-applied the permissions from the root and cascaded down, took about 3 hours (and that was on the local machine )

Just need to find out how/why the SID was corrupted.

[wagon-555]

I put this to the IT collective on ScoobyNet

Corrupted SIDs seem to have it.

Mark

[danielson]

What type of domain are you running, NT or W2K?

I had something similar to one of my servers earlier this morning, and it turned out to be WINS related. WINS had detected a duplicate IP entry of the server so stopped it talking via RPC to the rest of the domain. So even though i could happily ping/VNC to the server, its local permissions/shares where shot to pieces as it couldnt see the Domain permissions.

Perhaps a trawl through your IE server event viewer will help you figure out the cause..

[pdV6]

Maybe somebody deleted the user account, then thought "oops - needed that" & re-created with the same name. I've seen that happen b4.

[_DJ_]

'Unknown account' means that SID stored in the security descriptor could not be resolved by the server. If the user account can still access the same resources on other servers as previously, chances are that the account has not been deleted/recreated. If you have auditing enabled, check the security log on the PDC (or DC's if using 2000)
One possible explanation is that the server cannot locate a domain controller for the domain in which the accounts exists to lookup the SAMAccountName. This is likely to be due to one of the following:

1) The machine in question has lost its secure connection with the domain

2) If the account is in a domain other than the domain in which the computer is a member, the trust could have failed

3) The server cannot locate a domain controller (network issue or name resolution).

If the server is in the same domain as the user account, try NET USER <username> /DOMAIN at a command line, and see what it makes of it.

I don't subscribe to the 'corrupted SID' theory. Each security principle is assigned a SID (composed of a domain identifier and a RID) when it's created. I cannot see any logical reason why that value would ever change unless there was:

1) a bug in the OS. I've used NT since v3.5 and have never seen this.

2) a disk failure. Again, I doubt that a single SID would have been corrupted, a block would be corrupted, not a 32bit section of disk!

DJ


>> Edited by _DJ_ on Tuesday 14th October 22:09

[sjg]

FunkyGibbon said:

we've re-applied the permissions from the root and cascaded down, took about 3 hours (and that was on the local machine )

Aaaah, NT. Why take 2 seconds to do something simple like a permissions change, when you could spend 3 hours at full load applying those permissions to every individual item underneath it?

[_DJ_]

Yawn. Windows 2000/3, NTFS 5.0, inherit permissions etc? .There's obviously a trade off no matter how you do it (other distributed computing OS's aren't much better). Let me guess, you're a Netware admin? Keep up the good work (and go down with the (much more seaworthy) ship!)

>> Edited by _DJ_ on Tuesday 14th October 23:46