Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Or: "Is this a thing? And how would I check if it was?"

In an environment without a Domain Controller, when accessing a share on a Windows Server 2008 R2 box, from a remote computer without a matching user account on the server, (and connecting by typing \\SERVERNAME\ShareName from the Start menu) I currently observe the following behavior based on the "Password protected sharing" setting (Advanced sharing settings):

When "Password protected sharing" is turned on, all attempted connections fail after up to 30 seconds with:

Logon failure: the user has not been granted the requested logon type at this computer.

With "Password protected sharing" turned off, connections to anonymous-accessible shares are allowed, while permission-restricted shares fail with:

You do not have permission to access \SERVERNAME\ShareName. Contact your network administrator to request access.

This seems to be expected behavior. I need to have certain shares accessible by anonymous logons, so I had to change this setting from the default to off.

HOWEVER, there is a third case here. (whaaaaat?)

If you try to connect to a share without having modified this setting (that is, it is set to on but you've never clicked it), the connection behaves similar to the on case above in that it takes up to 30 seconds to show a response, but then it displays an authentication dialog:

Share Authentication Dialog

I had this hunch after beating my head against a wall for a few days, and just replicated this on a server with no existing shares: Create anon-read share, try to connect and get dialog, change the setting, connect successfully, change setting back, and get a different error message. (Tested all of these on fresh client systems so there was no risk of caching.)

To reiterate: I have controlled for the client systems. This appears to be entirely server-related.

So, it's clear to me that changing the "Password protected sharing" setting is changing more than one thing (registry key? I'm Mac-native) behind the scenes, and that the default settings the system ships with do NOT all match up with the setting reflected in the control panel (or the control panel itself is broken and should be changing more things).

So the question is: is this by design, or is it a bug? And in either case, what is the "hidden setting" that is being changed or left unchanged? How would one track that down? I'm running out of fresh servers to test on. :-(

share|improve this question
    
What is the ACL on the folder and what is the permission on the share? –  AWippler Jan 7 at 1:18
    
You can use a project called regshot to compare two snapshots of the registry (one when the system is initialized, one after the setting is set, and a third after the setting is unset). Also take a look at the "local domain/security policy" settings and check the "Access this Computer from the Network" setting (aka SeNetworkLogonRight)‌​. Here's some info on changes, and here's some info on settings. –  mbrownnyc Jan 7 at 14:03
    
@NReilingh: you posted the bounty, were you ever able to figure it out? –  charleswj81 Jan 12 at 17:35
    
@charleswj81 Your answer was exactly what I was looking for! Just had to find the time to sit down with it. What I'm noticing now is that the Guest Account listings in Manage Computer Accounts control panel and in Server Manager don't always appear to be in sync with regard to being enabled or not. So now I have three variables to test for in regard to anonymous and passworded connectivity: "Password Protected Sharing" on or off, the Guest account in Server Manager being enabled or disabled, and the Guest account in Control Panels being on or off. –  NReilingh Jan 13 at 0:02

3 Answers 3

up vote 10 down vote accepted
+100

This really piqued my interest. I was able to replicate your findings in my lab with the same pattern of results that you describe. I used Procmon to to try to see what changes are made and almost gave up until I saw the following:

procmon guest account modified

That shows lsass.exe (Local Security Authority) writing to the local SAM and making a change(s) to the built-in Guest account (well-known RID 501). Sure enough, when I retested your scenario while watching the Guest account's status, I see it enabled when "Password protected sharing" is disabled. However, when "Password protected sharing" is re-enabled, the guest account is not disabled again. Manually disable the guest account restores the original functionality: I am prompted for credentials (i.e. your third case).

I'm not sure why this behaves like this. TO be honest, I'd never even toggled the "Password protected sharing" setting before today (or even noticed it, for that matter). I hope this helps with your project. If someone else is interested in digging further, it would be interesting to know if this behavior is still present on Server 2012/2012 R2...

Oh and to your original questions (Is this by design or is it a bug?), I haven't the slightest idea...

share|improve this answer
    
I can confirm that this is correct. I had to install a W2K8 server fresh earlier today and could replicate this before I joined it to the domain. The Guest account has to be disabled manually. If that is done the behavior is what I would consider normal: After a timeout user is prompted to supply correct (from the servers perspective) credentials. (PS: I have never understood why that bloody timeout is so long. It is not as if the original credentials will magically become valid during the timeout period. So why bother waiting ?) –  Tonny Jan 10 at 21:10

If I've understood your question correctly, then the shares' credentials is saved in the Credential Manager under the control panel.

In order to prompt the authentication dialog box, simply delete the credential relating to that share under the credential Manager.

When you check the 'Remember my credentials', this is usually saved under the Credential Manager and if this password was wrong then you would see the logon failure error.

share|improve this answer
    
No so; I tested all three cases on a fresh client system with no cached credentials. (And in this case, any credential I entered would have granted access.) The only time I've ever seen this authentication dialog is when the "Password protected sharing" had not been touched. –  NReilingh Dec 22 '13 at 18:24
    
Had the opposite issue (here: serverfault.com/q/619027/175650) where I was getting the prompt but didn't want it. Turned out I had a bad credential saved, and your post pointed me in the right direction to delete it and solve my problem. Thanks! –  SenorAmor Aug 8 at 21:49

Might not help you but in case it does - I often have calls that my users can't access a share (their old password is cached by Windows) and I have them do this:

net use * /D

share|improve this answer
    
Like I said in the question, I controlled for the client. I used a fresh system for each test so there was no risk of caching credentials. –  NReilingh Dec 31 '13 at 6:47

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.