How to deny access to domain shares from a workgroup computer

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

Hello swb,

A local user account on a workgroup computer not belonging to a domain can
have access to a domain share when the share/NTFS permissions on the domain
will allow this, for example both are set to Everyone Full control. Everyone
group doesn't have the need for a domain SID, it's really everyone.

A local configured username on the workgroup computer will not sync a password
with a domain user account even it has the same name, there is no sync running,
don't know where you read/find this explanation, or maybe i understand you
wrong.

Best regards

Meinolf Weber
Disclaimer: This posting is provided "AS IS" with no warranties, and confers
no rights.
** Please do NOT email, only reply to Newsgroups
** HELP us help YOU!!! http://www.blakjak.demon.co.uk/mul_crss.htm


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

This does not involve the everyone group permission.

When I say "Synched" . . I mean an account manually setup on a workgroup
computer with the same username and password as a domain account.

If the account on the domain is a domain admin, and the NTFS permission only
permit the domain admin group, I have access to those shares with the
workgroup account of the same name.

I also have access to the C$ D$ admin shares with the workgroup account.
This is true on all Microsoft network that I have seen, but I don't know
why.



"Meinolf Weber [MVP-DS]" <meiweb(nospam)@gmx.de> wrote in message
news: .com...
> Hello swb,
>
> A local user account on a workgroup computer not belonging to a domain can
> have access to a domain share when the share/NTFS permissions on the
> domain will allow this, for example both are set to Everyone Full control.
> Everyone group doesn't have the need for a domain SID, it's really
> everyone.
>
> A local configured username on the workgroup computer will not sync a
> password with a domain user account even it has the same name, there is no
> sync running, don't know where you read/find this explanation, or maybe i
> understand you wrong.
>
> Best regards
>
> Meinolf Weber
> Disclaimer: This posting is provided "AS IS" with no warranties, and
> confers no rights.
> ** Please do NOT email, only reply to Newsgroups
> ** HELP us help YOU!!! http://www.blakjak.demon.co.uk/mul_crss.htm
>
>> ( 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 ?
>>
>
>

I have not seen any documentation of this, but what I have observed is that
if I create a local account on a machine not connected to the domain but on
the same LAN and I synchronize the user name and password with a domain
account, I am granted the same access as that domain account.

On Windows XP, it is not automatic. The way this manifests itself in Windows
Explorer, for example, is that there is an authentication prompt the first
time you connect to the share, even if you are logged in with the
synchronized credentials. You simply provide the same credentials again to
proceed.

On Windows 98, it seems to be automatic. You log on to Windows with
synchronized credentials (of course Windows 9x will let you log on with
whatever credentials you wish) and you can proceed without any further
prompts.

It would seem to be some sort of backwards compatibility hack that I would
think is thrown into question in the current security landscape.

I asked the same thing in a slightly different way a while ago and noone was
able to answer my qusestion. If you doubt this, we could try to reproduce it
with current OSes under controlled conditions. I suppose it's always
possible that swb, myself and our IT manager are having a mass
hallucination. Or that it was fixed relatively recently. It would be nice to
see Microsoft documentation of this.

Paul

"Meinolf Weber [MVP-DS]" <meiweb(nospam)@gmx.de> wrote in message
news: .com...
> Hello swb,
>
> A local user account on a workgroup computer not belonging to a domain can
> have access to a domain share when the share/NTFS permissions on the
> domain will allow this, for example both are set to Everyone Full control.
> Everyone group doesn't have the need for a domain SID, it's really
> everyone.
>
> A local configured username on the workgroup computer will not sync a
> password with a domain user account even it has the same name, there is no
> sync running, don't know where you read/find this explanation, or maybe i
> understand you wrong.
>
> Best regards
>
> Meinolf Weber
> Disclaimer: This posting is provided "AS IS" with no warranties, and
> confers no rights.
> ** Please do NOT email, only reply to Newsgroups
> ** HELP us help YOU!!! http://www.blakjak.demon.co.uk/mul_crss.htm
>
>> ( 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 ?
>>
>
>

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" <> wrote in message
news:O3H#...
> ( 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 ?
>
>
>

Hello Paul Baker [MVP, Windows Desktop Experience],

I have never seen this before. Will do some test when i am back in my office
next week. Which kind of authentication format is used in the domain, Kerberos
or is Kerberos complete disabled and NTLM is used? If NTLM which version?

Best regards

Meinolf Weber
Disclaimer: This posting is provided "AS IS" with no warranties, and confers
no rights.
** Please do NOT email, only reply to Newsgroups
** HELP us help YOU!!! http://www.blakjak.demon.co.uk/mul_crss.htm


> I have not seen any documentation of this, but what I have observed is
> that if I create a local account on a machine not connected to the
> domain but on the same LAN and I synchronize the user name and
> password with a domain account, I am granted the same access as that
> domain account.
>
> On Windows XP, it is not automatic. The way this manifests itself in
> Windows Explorer, for example, is that there is an authentication
> prompt the first time you connect to the share, even if you are logged
> in with the synchronized credentials. You simply provide the same
> credentials again to proceed.
>
> On Windows 98, it seems to be automatic. You log on to Windows with
> synchronized credentials (of course Windows 9x will let you log on
> with whatever credentials you wish) and you can proceed without any
> further prompts.
>
> It would seem to be some sort of backwards compatibility hack that I
> would think is thrown into question in the current security landscape.
>
> I asked the same thing in a slightly different way a while ago and
> noone was able to answer my qusestion. If you doubt this, we could try
> to reproduce it with current OSes under controlled conditions. I
> suppose it's always possible that swb, myself and our IT manager are
> having a mass hallucination. Or that it was fixed relatively recently.
> It would be nice to see Microsoft documentation of this.
>
> Paul
>
> "Meinolf Weber [MVP-DS]" <meiweb(nospam)@gmx.de> wrote in message
> news: .com...
>
>> Hello swb,
>>
>> A local user account on a workgroup computer not belonging to a
>> domain can have access to a domain share when the share/NTFS
>> permissions on the domain will allow this, for example both are set
>> to Everyone Full control. Everyone group doesn't have the need for a
>> domain SID, it's really everyone.
>>
>> A local configured username on the workgroup computer will not sync a
>> password with a domain user account even it has the same name, there
>> is no sync running, don't know where you read/find this explanation,
>> or maybe i understand you wrong.
>>
>> Best regards
>>
>> Meinolf Weber
>> Disclaimer: This posting is provided "AS IS" with no warranties, and
>> confers no rights.
>> ** Please do NOT email, only reply to Newsgroups
>> ** HELP us help YOU!!! http://www.blakjak.demon.co.uk/mul_crss.htm
>>> ( 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 ?
>>>

I'm afraid I don't know which authentication protocol it is using, nor do I
know much about how to find out. Besides, it would be the historical
information you need, which is even harder to get. Unless I repeat the
tests, which I do not have time to do.

A couple of things I do *not* recall clearly are:
- Whether the behaviour really was any different depending on whether or not
the "synchronized" account was added. Maybe it allows it even without that
account. But then there is some kind of trust between the domain and a
non-joined computer, which seems wrong.
- Whether it makes a difference using the DOMAIN\ prefix when attempting to
gain access and prompted in Windows Explorer. It was Windows XP I used, so
it doesn't have the nice helpful text Vista has explaining what domain it
will be using. It is possible I was really using the domain account but then
again, the domain is trusting a non-joined computer.

So, yes, I think it best that an expert such as yourself repeat some tests
with the knowledge that you have, and that I do not, to guide you.

Paul

"Meinolf Weber [MVP-DS]" <meiweb(nospam)@gmx.de> wrote in message
news: .com...
> Hello Paul Baker [MVP, Windows Desktop Experience],
>
> I have never seen this before. Will do some test when i am back in my
> office next week. Which kind of authentication format is used in the
> domain, Kerberos or is Kerberos complete disabled and NTLM is used? If
> NTLM which version?
>
> Best regards
>
> Meinolf Weber
> Disclaimer: This posting is provided "AS IS" with no warranties, and
> confers no rights.
> ** Please do NOT email, only reply to Newsgroups
> ** HELP us help YOU!!! http://www.blakjak.demon.co.uk/mul_crss.htm
>
>> I have not seen any documentation of this, but what I have observed is
>> that if I create a local account on a machine not connected to the
>> domain but on the same LAN and I synchronize the user name and
>> password with a domain account, I am granted the same access as that
>> domain account.
>>
>> On Windows XP, it is not automatic. The way this manifests itself in
>> Windows Explorer, for example, is that there is an authentication
>> prompt the first time you connect to the share, even if you are logged
>> in with the synchronized credentials. You simply provide the same
>> credentials again to proceed.
>>
>> On Windows 98, it seems to be automatic. You log on to Windows with
>> synchronized credentials (of course Windows 9x will let you log on
>> with whatever credentials you wish) and you can proceed without any
>> further prompts.
>>
>> It would seem to be some sort of backwards compatibility hack that I
>> would think is thrown into question in the current security landscape.
>>
>> I asked the same thing in a slightly different way a while ago and
>> noone was able to answer my qusestion. If you doubt this, we could try
>> to reproduce it with current OSes under controlled conditions. I
>> suppose it's always possible that swb, myself and our IT manager are
>> having a mass hallucination. Or that it was fixed relatively recently.
>> It would be nice to see Microsoft documentation of this.
>>
>> Paul
>>
>> "Meinolf Weber [MVP-DS]" <meiweb(nospam)@gmx.de> wrote in message
>> news: .com...
>>
>>> Hello swb,
>>>
>>> A local user account on a workgroup computer not belonging to a
>>> domain can have access to a domain share when the share/NTFS
>>> permissions on the domain will allow this, for example both are set
>>> to Everyone Full control. Everyone group doesn't have the need for a
>>> domain SID, it's really everyone.
>>>
>>> A local configured username on the workgroup computer will not sync a
>>> password with a domain user account even it has the same name, there
>>> is no sync running, don't know where you read/find this explanation,
>>> or maybe i understand you wrong.
>>>
>>> Best regards
>>>
>>> Meinolf Weber
>>> Disclaimer: This posting is provided "AS IS" with no warranties, and
>>> confers no rights.
>>> ** Please do NOT email, only reply to Newsgroups
>>> ** HELP us help YOU!!! http://www.blakjak.demon.co.uk/mul_crss.htm
>>>> ( 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 ?
>>>>
>
>

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]" <> wrote in message
news:32943829-9687-4588-9FDA-...
>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" <> wrote in message
> news:O3H#...
>> ( 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 ?
>>
>>
>>

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]"
<> wrote in message
news:...
> 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]" <> wrote in message
> news:32943829-9687-4588-9FDA-...
>>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" <> wrote in message
>> news:O3H#...
>>> ( 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 ?
>>>
>>>
>>>
>
>

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]" <> wrote in message
news:FA93C883-1405-4C2B-9D7F-...
> 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]"
> <> wrote in message
> news:...
>> 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]" <> wrote in message
>> news:32943829-9687-4588-9FDA-...
>>>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" <> wrote in message
>>> news:O3H#...
>>>> ( 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 ?
>>>>
>>>>
>>>>
>>
>>