Re: How to deny access to domain shares from a workgroup computer


"Paul Baker [MVP, Windows Desktop Experience]" <paulrichardbaker@xxxxxxxxxxxxxxxx> wrote in message news:Ox#DZ9HEKHA.1252@xxxxxxxxxxxxxxxxxxxxxxx
Anthony,

Thanks for clearing it up :)

It makes sense to me, now that you clearly state it, that there is no need to trust the machine where the authentication is coming from. It just seems odd that the user may have no idea what domain he is connected to but is easily able to become authenticated as a domain user.

If he truly knew nothing about the domain, it is somewhat unlikely for him to have a local account whose name matches that of a domain account, although this is possible. But it is as unlikely that he would coincidentally have the same password as the domain account on the domain he knows nothing about.

/Al

In a sense, he's not a domain anything! However, if you consider only user name and password sufficient credentials, then it's fine.

Odd is not a security issue, though. Or, as you already said, curious.

Paul

"Anthony [MVP]" <anthony@xxxxxxxxxxxx> wrote in message news:FA93C883-1405-4C2B-9D7F-81CDF44BD03F@xxxxxxxxxxxxxxxx
Paul,
There isn't really any level of trust involved.
If I take the example of Internet Explorer pass-through authentication:
- the authentication process is NTLM or Kerberos (required by the backend IIS server)
- the authentication process is identical whether I am prompted and enter credentials, or whether my logged in credentials are passed-through
- Internet Explorer passes through my credentials if the site is in my Intranet zone (at least by default) but that is to protect me from passing credentials to a bad site.
- there is no level of trust between the browser and the server. It is just an authentication based on username and password; and authentication protocol designed to make it hard to intercept or decipher the authentication in transit; and a convenience mechanism for passing through under certain circumstances without an explicit prompt.

There is no need to trust the machine where the authentication is coming from. After you authenticate with the right credentials, you only have the access of that user - which can not be denied, as you have the credentials. It is really you who is trusting the server, as you are passing it your credentials and it could steal them and use them on your machine.

I think what you are describing is some changes in Prompt behaviour. That's hard to pin down because:
- if a prompt is accepted, then it is cached and supplied in future for the same resource, until you log off
- if you have the same username but different password for the remote resource it can get in a tangle and give you a Denied rather than a prompt
- if both machines are in a domain rather than one in a workgroup you don't get a prompt.

I can't tell you for sure when you get prompted and when not, or when anything changed. I am just observing that I think it is purely a convenience problem and not a security problem for the server side. I think it is quite likely that changes have been made to prompt you rather than pass through, as automatic pass through has an element of risk of disclosure involved.

Anthony,
http://www.airdesk.com




"Paul Baker [MVP, Windows Desktop Experience]" <paulrichardbaker@xxxxxxxxxxxxxxxx> wrote in message news:u3iqPwFEKHA.1492@xxxxxxxxxxxxxxxxxxxxxxx
This makes sense, except that this means the domain is trusting a non-joined, therefore unknown, machine. It presumably cannot enforce domain policies and in general the machine may be out of the domain administrator's control. Is it not to be considered a rogue machine? So how can this be allowed?

Another issue:

According to this premise, if I am logged in with the right user name and password, I should not be prompted again. It should just "pass through". But when I use Windows Explorer on Windows XP, I am prompted and provide the same credentials I expected it to pass in the first place! I *think* in an older setup I was not prompted, but I wouldn't rely on that information.

Actually, I have an application of my own that shows a credentials dialog and impersonates. Something about it doesn't work and I wasn't able to figure out why in the time I alloted myself to do so. But I *think* the exact same code used to work in the days when a prompt was unecessary. It's like I'm prompting incorrectly but if I didn't have to prompt I would be good.

So I don't think the mystery of the logon dialog is solved. Unless Microsoft made a fix that required a prompt despite credentials that successfully "pass through" and my code is just wrong. And what would be the intent of such a change?

Paul

"Anthony [MVP]" <anthony@xxxxxxxxxxxx> wrote in message news:32943829-9687-4588-9FDA-C7AA291F8FBE@xxxxxxxxxxxxxxxx
I agree that it is curious at first sight, but I am not sure how else it could be.

Lets start from the premise that a user's password should be unknowable except to them. The user name part is a convenience and can add to the security by being obfuscated, but let's assume that it is fairly obvious.

So the chairman of the company has an obvious username and an unknowable password.

What difference does it make if, when asked for his password, he prefixes the domain name or not? The domain name is not secret. The workgroup or server name is not secret. By adding a prefix he is really saying "this version rather than that version of my account".

If the user's password is knowable, then a whole different set of problems arise. Two factor authentication is the solution to weak passwords.

What you are referring to is the convenience of pass-through authentication. When the logged in credentials are tried first. But this is just a convenience. You still have to have the right credentials. NTLM is a method of ensuring the password is not revealed, and Kerberos is a more sophisticated method of ensuring that even if the credentials could be cracked they would not be valid after the event.

So I think what you are describing is a convenience but not a security measure,

Anthony,
http://www.airdesk.com




"swb" <swb_mct@xxxxxxx> wrote in message news:O3H#3l5DKHA.2832@xxxxxxxxxxxxxxxxxxxxxxx
( I posted a version of the question the Small Business Server newsgroup - no response - I hope that doesn't violate a posting rule )

Can anyone explain why a local account on a workgroup computer has access to domain shares (sbs2008) if the local username and password are synchronized
with a domain username and password ?

The local workgroup account is allowed the same access as specified by NTFS file permissions assigned to the domain account of the same username/password.

I though the ACL on NTFS file shares on a Domain Controller required the users access token to include a domain SID for the user.

This seems to be true on all Microsoft networks . . . I audit banks. They give me a domain admin account for my visit. When I create a matching account username/password on my notebook, I have access to all shares on the Microsoft network, only using the domain account they created for me for terminal service logins.

Is there a Security Option in to disable access to domain shares using a synchronized local account on a workgroup computer.

Bigger Picture: What is all the Kerberos Trust path stuff about, if access to shares only requires a synched username/password from any workgroup ?










.

Relevant Pages

  • Re: How to deny access to domain shares from a workgroup computer
    ... If I take the example of Internet Explorer pass-through authentication: ... the authentication process is identical whether I am prompted and enter credentials, or whether my logged in credentials are passed-through ... It is just an authentication based on username and password; and authentication protocol designed to make it hard to intercept or decipher the authentication in transit; and a convenience mechanism for passing through under certain circumstances without an explicit prompt. ... By adding a prefix he is really saying "this version rather than that version of my account". ...
    (microsoft.public.windows.server.security)
  • Re: How to deny access to domain shares from a workgroup computer
    ... sufficient credentials, then it's fine. ... There isn't really any level of trust involved. ... If I take the example of Internet Explorer pass-through authentication: ... I think what you are describing is some changes in Prompt behaviour. ...
    (microsoft.public.windows.server.security)
  • Re: How to deny access to domain shares from a workgroup computer
    ... I have an application of my own that shows a credentials dialog ... exact same code used to work in the days when a prompt was unecessary. ... So the chairman of the company has an obvious username and an unknowable ... Can anyone explain why a local account on a workgroup computer has access ...
    (microsoft.public.windows.server.security)
  • Re: How to deny access to domain shares from a workgroup computer
    ... It makes sense to me, now that you clearly state it, that there is no need to trust the machine where the authentication is coming from. ... However, if you consider only user name and password sufficient credentials, then it's fine. ... It is just an authentication based on username and password; and authentication protocol designed to make it hard to intercept or decipher the authentication in transit; and a convenience mechanism for passing through under certain circumstances without an explicit prompt. ... By adding a prefix he is really saying "this version rather than that version of my account". ...
    (microsoft.public.windows.server.security)
  • Re: Remoting
    ... of authentication to provide appropriate credentials to the remote server. ... You need software on the remote machine that the remoting client can talk to ... > the process and thread account will be the interactive or logged on user ...
    (microsoft.public.dotnet.security)
Quantcast