NTFS Security - Quick Question

First off, if your not MCSA or higher, dont attempt to answer this question ^_^ im sure i would have already tried all your stupid answers ^_^
on the other hand, i have a file server im implementing into a 2k3 network infrastructure running windows server 2003 r2 enterprise.
i have a share named File Library and it is setup acordingly with the correct NTFS permissions (im 100% positive this is correct) ive been working with ntfs permissions for over 5 years and can do them in my sleep.
for the tough part, when mapped to the share, under a standard user with modify permissions to a given server full UNC;
\\ukcph-fsv01\file library\netusers\john
the user john has all permissions but change permission and take ownership.
when trying to upload a file while logged on oh john, i get access denied. (im sure ya thinkin its security and nope its not, the user effectively has the correct permissions to the dir), no acl icd is denied period nor is the ntfs acls inherited. The only way i can place a file in the dir period is with admin rights. The server uses the new File Magement that applys soft/hard quota's. each dir is given 2GB space hard quota.
has any one had this problem yet? is their any setting in security conf that would prevent any users other then admins to store files on shares? (i dont recall a setting like this) but if its somthing new in R2 then i'd love to be enlightened. its driving me nuts.
if no one can give me an answer that works, then ill contact ms ^_^
on the other hand, i have a file server im implementing into a 2k3 network infrastructure running windows server 2003 r2 enterprise.
i have a share named File Library and it is setup acordingly with the correct NTFS permissions (im 100% positive this is correct) ive been working with ntfs permissions for over 5 years and can do them in my sleep.
for the tough part, when mapped to the share, under a standard user with modify permissions to a given server full UNC;
\\ukcph-fsv01\file library\netusers\john
the user john has all permissions but change permission and take ownership.
when trying to upload a file while logged on oh john, i get access denied. (im sure ya thinkin its security and nope its not, the user effectively has the correct permissions to the dir), no acl icd is denied period nor is the ntfs acls inherited. The only way i can place a file in the dir period is with admin rights. The server uses the new File Magement that applys soft/hard quota's. each dir is given 2GB space hard quota.
has any one had this problem yet? is their any setting in security conf that would prevent any users other then admins to store files on shares? (i dont recall a setting like this) but if its somthing new in R2 then i'd love to be enlightened. its driving me nuts.
if no one can give me an answer that works, then ill contact ms ^_^
There is no place like 127.0.0.1
Comments
Well your arrogance is keeping me from answering your question. I know more people without ANY certs that are Admins, engineers, etc than i do with them.
So my stupid answer is probably the solution but i probably shouldnt attempt something this hard yet....i dont have MCSA or MCSE next to my name.
I hate people like you.
You should, it must be a problem with their software.
I've talked to a few other MCSE's with years experince in a 50,000+ node enterprise enviroment and they have no ideal either >.< I was wondering if any one had the same issue with r2.
Well here a MCSA 2003, in messaging and security. Hope that's fine with you. Regarding your post: cool down... As you say, it might me a MS bug.
Now... Without seeing your NTFS or Share ACLs, if your admin user can write to the share, and knowing that you have disk quotas enabled, there are two possible problems:
1.- Incorrect ACL somewhere. To create files you need Write perms
2.- Your user John is over quota... remember that Admin files are not enforced, explaining why you can write as admin.
Again, this is just a shot in the dark... Giveme more info and I'll help you out... or at least confirm its a MS bug. Give me share ACL and NTFS ACL on the folder (advanced view). Also give me the quota settings on the user. Maybe with this we can work it out.
PS: I haven't tried R2...
the NTFS security on johns folder is pretty simple, server name is UKCPH-FSV01 so this will help you understand AD Naming convention we use also, this is being done at the university of kentucky (where i work)
our server admins are members of UKCPH_SrvAdmins set by this group being a member group of local admin group on the server.
The NTFS ACL on the Folder is;
UKCPH-FSV01\Administrators - Full Control (Inherited)
MC.UKY.EDU\UKCPH_SrvAdmins - Full Controll (Inherited)
MC.UKY.EDU\JWS - Modify, Adv/del sub dir&files
Thats all thats on the NTFS ACL's, setup simple and sweet. Also they are alotted 2GB per a user (Hard Quota)
I dont know if you realized it or not but this isnt the first time we both responded to his amazing MCSE knowledge.
Just the other day he was the guy with this quote:
"I don’t believe Techexams.net would support the discussion of WEP Cracking, considering it is in violation of several US Laws, and can be considered a Class B Felony in some states.
I suggest a forum mod lock this thread for example."
Apparently he is just another idiot that wants respect over the internet for certs that he probably doesnt have, or worse braindumped to get.
What was the solution?
Pound sand.
Sure, you probably had a wrong permission assignment somewhere and had to cover your tracks.
If you can, please post the solution, since it's quite interesting... your ACLs are fine.
Hope I could be more helpful next time!
Cheers!
I wouldn't expect to see this kind of content on the 290 any time soon, unless they decide to update it to include R2.
Apparently the issue i had was with FSRM, when i orginally created a share and quota's and what not, i deleted the shared folder and recreated it, security and so on, i never bothered to check with FSRM first, and apparently it was making it seem like the whole share was full and giving me access denied, full or write protected.
A guy i work with where i teach apparently had an issue simular, he just told me to reinstall fsrm, delete and recreate share, security etc... after i did, all worked as planned. i dunno if this is a bug or if its suppose to do this or what not. dont care now, i feel better now, this file server deployment deadline is this friday, i was about to freak out.
I will check out R2 once I finish my exams... thanks for the suggestion!
^_^ ^_^ ^_^ ^_^ ^_^ ^_^
On the other hand, saying ^_^ has nothing to do with the professionalism of my question.
I'm done posting on this thread. If I insulted you, go tell your mommy, or be a man and get over it.
Oh well, at least I can go back and read his rude comments over and over again...
I hate to be nit-picky and kick a guy when he's down, but mgeorge27 is just ripe for the kickin'! He said that he teaches somewhere, hopefully it is nothing to do with networking (or english...how hard is it to know the difference between "your" and "you're"?)
But, he's gone now and will never seek the advice of lowly non-MCSAs or higher, but his quote was something like this: "On a persoanl note, reason im cocky a bout certs is because if your smart enough to pass the exam, then dont be lazy, take it and get the cert. Me and lazyness dont get along to well and i have my reasons why. "
(English teachers all over the country are jumping off of buildings after reading that one!) And I know this is not an English forum, but if you expect to be taken seriously, then look intelligent...there is a spell-checker right below where you are typing...USE IT!
Whew, I feel better now...
Now go tell your mommy I called you dumb. And arrogant. Oh, and don't forget you also mentioned cocky yourself.
See, you get stupid replies even when you try and avoid them with comments like
Of course let's not even bring up that MS recommends granting Full Control on Share permissions to everyone and then tightening down via NTFS. That's a completely different discussion.
Usually the way I try an isolate a share permission problem versus an NTFS permission problem is eliminate the share as a problem by temporarily allowing the user account to log on locally, log on locally as the user, then see if you can get to the folder and do the required tasks. If not, it isn't the share, or the share is not the only problem.
Checking event logs might shed some light if it was an OS problem unrelated to ACL security. Enabling security audits could check if there was an ACL security problem.
Denies hidden by a group membership can also be troublesome to spot.