Bizzare security behaviour

[Invisible]

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??

 

[Steven L Umbach]

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

 

[Invisible]

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...

 

[Steven L Umbach]

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

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...

 

[Invisible]

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...

 

[Steven L Umbach]

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
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...