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

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. 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
    ... 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. ... 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. ... user name and password sufficient credentials, ... 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. ...
    (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: How to deny access to domain shares from a workgroup computer
    ... name and password sufficient credentials, ... If I take the example of Internet Explorer pass-through authentication: ... I think what you are describing is some changes in Prompt behaviour. ... really saying "this version rather than that version of my account". ...
    (microsoft.public.windows.server.security)
  • Re: Authenticate on multi domain
    ... You obviously can only logon to one domain at a time via computer logon. ... connection using your credentials in the other domain such as [net use * ... A proper trust between domains must be enabled for all this to ...
    (microsoft.public.win2000.security)