 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Windows Forum / Windows XP / Security and Administration / June 2006Bizzare security behaviour
I have a folder on our network fileserver that is exhibiting extremely bizzare behavior. Specifically, if I log on to a Windows NT 4.0 Workstation machine, when I try to open this folder from Windows Explorer I get "Access Denied". However, if I log on to a machine running Windows XP Professional, I can open the folder without difficulty. What the hell...?! I thought the entire POINT of security permissions being on the server is that the SERVER decides whether you can or can't access stuff, not the client. Why would using a different client OS make the slightest bit of difference? I find this really quite frightening. The fileserver is Windows 2000 Server. User accounts are Active Domain. My user account has the following permissions to the folder: Traverse Folder / Execute File: No List Folder / Read Data: Yes Read Attributes Yes Read Extended Attributes Yes Create Files / Write Data Yes Create Folders / Append Data Yes Write Attributes Yes Write Extended Attributes Yes Delete Subfolders and Files No Delete No Read Permissions Yes Change Permissions No Take Ownership No No other permissions are being inherited by this folder. No other security groups to which I belong are mentioned in the permissions. I realise that this is a pretty bizzare combination of permissions. I have no idea why it's set that way. (We have an in-house application that automatically fiddles with file permissions. I believe in this case it has set them wrong - but the application authors won't believe me because "it works in XP". <sigh>) Somebody suggested it might be something to do with the "Bypass traverse checking" - but this option is Enabled for the group Everyone on both test machines, and yet one gives me access and the other does not. Any help here?? Is this brand new behavior and does it apply to all users that logon to any NT4.0 workstation and all users that logon to any XP Pro workstation?? Check the security log on the server with the share to see if any logon failures are recorded that may help explain why access is denied. Refer to the KB article below that explains problems that can arise with incompatible security settings among access from different operating systems. Incompatible lan manager authentication levels and digitally sign communications [SMB signing] are usual suspects. Also have the user from the NT4.0 computer try accessing the share via the IP address of the server instead of name as in \\xxx.xxx.xxx.xxx\sharename to see if that makes a difference. Verify that your wins is set up correctly in that the all domain controllers, servers, and workstations also need to be wins clients since NT4.0 is being used in the domain. The NT4.0 computers should be able to ping the file share server and domain controller by name and IP dress. --- Steve http://support.microsoft.com/default.aspx?scid=kb;en-us;823659 >I have a folder on our network fileserver that is exhibiting extremely >bizzare behavior. Specifically, if I log on to a Windows NT 4.0 Workstation [quoted text clipped - 38 lines] > > Any help here?? > Is this brand new behavior Don't know. Nobody has ever tried to use such an unusual combination of security permissions before. (Usually things are set to no access, read-only, or full access. That simple.) But these folders are managed by our new wizzy in-house project management system [which is actually almost useless], and it has set these strange permissions. Nobody can tell me why exactly. Even so, you'd expect it to work the same way on NT and XP clients... > does it apply to all users that logon to any > NT4.0 workstation and all users that logon to any XP Pro workstation?? As far as I *know* it applies to anybody trying to access a folder to which they have been given List but not Traverse permission. (The problem originally showed up with a project folder, but I was able to create some random test folders myself and set myself to have the same permissions combination on them, which gives the same behaviour.) > Check > the security log on the server with the share to see if any logon failures > are recorded that may help explain why access is denied. Checked the logs on both the file server and the domain controller. Nothing of interest. <invert comment about security log entries being drastically too cryptic> > Refer to the KB > article below that explains problems that can arise with incompatible > security settings among access from different operating systems. > Incompatible lan manager authentication levels and digitally sign > communications [SMB signing] are usual suspects. Actually, we did have an issue with this very server where people would stop being able to access anything after a while. We eventually tracked it down to SMB signing - and that has been set as "optional" ever since. This server is now our main fileserver. People access files on it all day every day, and have been doing for about 7 months now without issue. The issues only showed up when we got this new software with it's strange permission settings. (I have no idea what List but not Traverse is actually supposed to mean... As far as I can tell, on both WinNT and WinXP, by default Bypass Traverse Checking is turned on anyway, so not quite sure why the software is denying this permission given that it's no-op anyway.) > Also have the user from the > NT4.0 computer try accessing the share via the IP address of the server > instead of name as in \\xxx.xxx.xxx.xxx\sharename to see if that makes a > difference. I'll give it a go... I don't imagine it will make any difference. > Verify that your wins is set up correctly in that the all domain > controllers, servers, and workstations also need to be wins clients since > NT4.0 is being used in the domain. The NT4.0 computers should be able to > ping the file share server and domain controller by name and IP > dress. Yep. That all checks out. > http://support.microsoft.com/default.aspx?scid=kb;en-us;823659 Well, it's a place to start from... OK. Maybe I misread some of your post. So you are saying that users can access other shares on this server from NT4.0 and XP Pro but it is this particular folder only that you are having problems with?? I would try documenting current permissions for the folder and then give everyone read/list/execute/write permissions temporarily in the main security page and check the special permissions to make sure there are no deny entries for any group/user for NTFS and also check share permissions to make sure there are no deny permissions entries to see what happens. The other thing you could try is enable auditing of object access on the server temporarily for failure only. Then audit the folder where access is being denied for full control permissions [all boxes checked] for failure for everyone. Then after access is denied again check the security log for any object access failures and you may get a clue as to what access is denied. --- Steve >> Is this brand new behavior > [quoted text clipped - 58 lines] > > Well, it's a place to start from... > OK. Maybe I misread some of your post. So you are saying that users can > access other shares on this server from NT4.0 and XP Pro but it is this > particular folder only that you are having problems with?? Indeed. Only the project folders managed by our project manager software are causing problems due to the odd permissions combinations it likes to give things. > The other thing you > could try is enable auditing of object access on the server temporarily for > failure only. Then audit the folder where access is being denied for full > control permissions [all boxes checked] for failure for everyone. Then after > access is denied again check the security log for any object access failures > and you may get a clue as to what access is denied. --- Steve Ah... I hadn't thought of that. Could tell me something useful... Sorry about that. NT4.0 relies on anonymous access for a lot of things and this may be shooting in the dark but I would also check that the user right for bypass traverse checking includes everyone on the server with the are. --- Steve >> OK. Maybe I misread some of your post. So you are saying that users can >> access other shares on this server from NT4.0 and XP Pro but it is this [quoted text clipped - 12 lines] > > Ah... I hadn't thought of that. Could tell me something useful... |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.