Re: Client/server application and Windows Integrated Auth

From: Ken Schaefer (kenREMOVE_at_THISadopenstatic.com)
Date: 02/02/05 

Date: Wed, 2 Feb 2005 12:28:24 +1100

"Joubert" <Joubert@discussions.microsoft.com> wrote in message
news:8EBF2C3B-32EE-45F0-95E9-136F0C9D51ED@microsoft.com...
> Hi Ken,
>
>> "Joubert" <Joubert@discussions.microsoft.com> wrote in message
>> news:F6E36F51-8307-4B41-9C0C-05BBAFC22CEB@microsoft.com...
>> > Hi,
>> >
>> > We now want to support Windows Integrated auth so that the user does
>> > not
>> > have to enter a login name and password. One way to do this is to
>> > identify
>> > the user based on their domain\username. However, this can be spoofed,
>> > by
>> > setting up another computer so that the application is run under the
>> > same
>> > domain\username and then connecting to the datastore (since the user
>> > doesn't
>> > actually have to login to the domain in order to access the datastore,
>> > e.g.
>> > Access file on local drive or when connecting to SQL Server via
>> > TCP/IP).
>>
>> This can only be "spoofed" if the person setting up the application has
>> both
>> the username *and* the corresponding password. If you have users that
>> know
>
> No, you can spoof it without have the "real" password because you are not
> using the "real" Windows user account to identify yourself. Here's a
> sketch
> of the scenario:
>
> Setup
> =====
> Let's say the datastore is an MS Access database and is on a fileshare
> somewhere. In the authentication table the user George Smith is
> (literally)
> identified as STDOM\gsmith
> If George logs onto his network, Windows will return his domain\username
> as
> STDOM\gsmith (assuming he logged into that account). His Windows password
> is
> never stored in the application's datastore (the MS Access database).
> Remember we want the user not have to bother to enter their username /
> password - they've already done it in Windows.
>
> Naughty person
> ===========
> Now, let's say Jill Sander wants to impersonate George in order to get to
> information stored in the application datastore which only George can see
> because of his identity. She can setup a PC with the computer name "STDOM"
> (or on PC setup a Windows domain called "STDOM"). Further, she can create
> a
> user account called "gsmith" and choose whatever password she likes.
> She now simply logs into that account (Windows will now ID her as
> STDOM\gsmith) and launch the application. When she opens the datastore
> with
> the application it will do a match against the authentication table in the
> datastore and identify her has George Smith.
>
> Avoid the spoof
> ==========
> So, from the example above it appears as if simply using DOMAIN\username
> is
> not an adequate solution. And now we're back at my original e-mail.
> I am thinking of using the user's SID and store that in the authentication
> table in the datastore instead of teh DOMAIN\username. This should ensure
> it
> is in fact the SAME person and so avoid the possibility of impersonation.
>
> Is this assessment accurate?

No, it's not correct.

Jill Sanders sets up a PC called STDOM, and creates a user account gsmith
and assigns any password. She then attempts to connect to the webserver.
Webserver denies anonymous access, and requires the user/client to
authenticate.

The rogue user (Jill Sanders) sends the credentials STDOM\gsmith + arbitrary
password. The webserver then consults the STDOM domain controller and says
"are these credentials valid for STDOM\gsmith?". The Domain Controller will
say "no, that's not the real password for gsmith - require them to send a
different set of credentials"

This is assuming that you're using Basic, Digest, Integrated Windows Auth
(not anonymous access)

Cheers
Ken