teeceecee
asked on
Windows 2000 server Auditing problem with existing directories/shares
Ok stay with me on this one :)
I am running windows 2000 server. I've turned on file/folder auditing for the domain policy (active
directory), I turned it on after creating my directories/shares from what I can recall. Service pack
2 is applied, all critical updates are applied. the problem is when I want to turn on auditing on my
current shared objects (folder, files), nothing shows up in the security log. Now if it would be only
that I'd say I missed a step, I've checked and doublechecked every options, everything is fine exept
it won't show up.
Now the funny thing is I tried creating a new directory and share. I put the same settings, and this
time it audits everything like it should. If I delete the shared directory, remove all the files, reboot,
recreate it and reapply permissions, it won't work if it's the same name as before. This is really
weird since it works on anything new I create.
One strange thing I've noticed though is that when I recreated the directory (which was deleted and
I've rebooted since then) and go in security->advanced->audit,
and active. Is this a bug or me doing something really nasty? Normally when you delete something,
it's supposed to be erm.. deleted. no?
Like I said, the auditing works fine when creating new directories... so it's really on the existing
items that I am having a hard time and I don't want to create new names, I want to solve this problem.
200 points for this one if I get a solution that fix the problem, not work around it.
Thanks for anyone's input.
I am running windows 2000 server. I've turned on file/folder auditing for the domain policy (active
directory), I turned it on after creating my directories/shares from what I can recall. Service pack
2 is applied, all critical updates are applied. the problem is when I want to turn on auditing on my
current shared objects (folder, files), nothing shows up in the security log. Now if it would be only
that I'd say I missed a step, I've checked and doublechecked every options, everything is fine exept
it won't show up.
Now the funny thing is I tried creating a new directory and share. I put the same settings, and this
time it audits everything like it should. If I delete the shared directory, remove all the files, reboot,
recreate it and reapply permissions, it won't work if it's the same name as before. This is really
weird since it works on anything new I create.
One strange thing I've noticed though is that when I recreated the directory (which was deleted and
I've rebooted since then) and go in security->advanced->audit,
and active. Is this a bug or me doing something really nasty? Normally when you delete something,
it's supposed to be erm.. deleted. no?
Like I said, the auditing works fine when creating new directories... so it's really on the existing
items that I am having a hard time and I don't want to create new names, I want to solve this problem.
200 points for this one if I get a solution that fix the problem, not work around it.
Thanks for anyone's input.
Well, I'm not sure this is the answer, but since you didn't mention doing it, I'll ask:
Did you grant the "Generate Security Audits" right to the "Administrators" local group on the domain policy?
(Can be found in the Domain Policy under: Computer Configuration/Windows Settings/Security Settings/Local Policies/User Rights Assignment)
I'm not sure (would need to look it up), but I believe you need to make that change under the Domain Controller policy as well if your server is a domain controller.
Because you're getting auditing of new directories, I'm not sure this is the issue -- but I'd check it. Hope this helps!
Did you grant the "Generate Security Audits" right to the "Administrators" local group on the domain policy?
(Can be found in the Domain Policy under: Computer Configuration/Windows Settings/Security Settings/Local Policies/User Rights Assignment)
I'm not sure (would need to look it up), but I believe you need to make that change under the Domain Controller policy as well if your server is a domain controller.
Because you're getting auditing of new directories, I'm not sure this is the issue -- but I'd check it. Hope this helps!
ASKER
I did all this, I did add the extra auditing on the file/directory that I wanted to audit (even the older that aren't working, I went thru them one by one, and besides my logging needs aren't the same for let's say /finance than they are for /public so I had to go thru them to change it anyways). I even explicitly told it to log my account on anything happening on the directory (read, access, etc) and like I said, if I do it on a newer dir, put the same values, it works just like it should.
As for the "generate security audits" it had nothing in it, I added administrator and administrator@xyz but it's still not working...
As for the "generate security audits" it had nothing in it, I added administrator and administrator@xyz but it's still not working...
Did you run
"secedit /refreshpolicy machine_policy /enforce" from the command line to make sure the policy took effect immediately? Is "audit object access" enabled in the policy?
On a different note: is it possible this machine is running NTFS 4 or earlier on the volume in question? It would be if it were originally formatted under NT 4 or earlier (if the server was upgraded from NT 4, for example).
If those don't pan out, try checking out this Microsoft knowledge base article (line may be wrapped):
http://support.microsoft.com/support/kb/articles/q300/5/49.asp
"secedit /refreshpolicy machine_policy /enforce" from the command line to make sure the policy took effect immediately? Is "audit object access" enabled in the policy?
On a different note: is it possible this machine is running NTFS 4 or earlier on the volume in question? It would be if it were originally formatted under NT 4 or earlier (if the server was upgraded from NT 4, for example).
If those don't pan out, try checking out this Microsoft knowledge base article (line may be wrapped):
http://support.microsoft.com/support/kb/articles/q300/5/49.asp
ASKER
I am not familiar with secedit, I'll read about it and try stuff around it, but I did try to see if anything changed from day to day to see if anything could have been screwed with the policy activation (and rebooted after changing something too, I could afford the downtime to fix that stupid issue), I think it usually takes 45 minutes for the domain policies to replicate among servers, in my case it's a single domain controller, and every time I did a mofification on anything it worked like it should, it's not upgraded from NT4, it's a pure win2000 server clean install.
No comment has been added lately, so it's time to clean up this TA.
I will leave a recommendation in the Cleanup topic area that this question is:
[paq refund]
Please leave any comments here within the next seven days.
PLEASE DO NOT ACCEPT THIS COMMENT AS AN ANSWER!
[ewtaylor]
EE Cleanup Volunteer
I will leave a recommendation in the Cleanup topic area that this question is:
[paq refund]
Please leave any comments here within the next seven days.
PLEASE DO NOT ACCEPT THIS COMMENT AS AN ANSWER!
[ewtaylor]
EE Cleanup Volunteer
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
To apply security settings throughout your domain, you can define ACLs to be applied/replaced on files in the GPO.