I am using an ISAPI Filter in IIS 5.1 to remove all but 'Basic' 
WWW-Authenticate headers when windows login fails.

I am using the 3rd consecutive 401 response to indicate a failure. Is there 
a better way to catch a login failure? I'm doing it for 
SF_NOTIFY_SEND_RESPONSE notification.

The reason I am doing this is to set up Basic authentication and use local 
validation if there is no valid windows account on my server.

Using this method windows accounts can log in , but non windows accounts get 
prompted for windows login and not my local login. Is removing the 
WWW-Authenticate headers and adding a Basic one going to work?

Also when a windows user does login I want to run my isapi dll as the 
anonymous user; do you impersonate the anonymous user to do this?

Many Thanks

-- 
regards Dave

Hi Dave,

Can you please give some more detail about what you are trying to do?

Basic is one of several different ways that IIS can do authentication, but
all users that IIS authenticates are Windows users.  If you want to strip
all www-authenticate headers except basic, the best way to do this is to
just turn off all authentication except basic.  That way, IIS won't ever put
one there that's not for basic.

Thank you,
-Wade A. Hilmo,
-Microsoft

"dareag"  wrote in message
news:A47F16AF-64F9-47BA-BE48-6767842B878F@microsoft.com...
> I am using an ISAPI Filter in IIS 5.1 to remove all but 'Basic'
> WWW-Authenticate headers when windows login fails.
>
> I am using the 3rd consecutive 401 response to indicate a failure. Is
there
> a better way to catch a login failure? I'm doing it for
> SF_NOTIFY_SEND_RESPONSE notification.
>
> The reason I am doing this is to set up Basic authentication and use local
> validation if there is no valid windows account on my server.
>
> Using this method windows accounts can log in , but non windows accounts
get
> prompted for windows login and not my local login. Is removing the
> WWW-Authenticate headers and adding a Basic one going to work?
>
> Also when a windows user does login I want to run my isapi dll as the
> anonymous user; do you impersonate the anonymous user to do this?
>
> Many Thanks
>
> -- 
> regards Dave

Hi Wade

What I want to do is first try the windows credentials of the user who is 
currently logged on to the machine. If that fails it will not be a windows 
account that will access my application, it will be a local account that my 
application stores in a database.

So after the initial logon failure from windows I want to display my local 
login dialog box, and not a windows logon dialog.

What I did have working was to tell IIS to do anonymous authentication and 
my dll would display my logon dialog; but if its a valid windows account that 
is accessing my application then I want windows to authenticate them.

Hope this makes it clearer. The user accessing my application may have 
windows credentials or they may have my application credentials.

The other point I was trying to ask was that if they were using windows 
credentials I still want the dll to run as the anonymous user.

Thanks
-- 
regards Dave 


"Wade A. Hilmo [MS]" wrote:

> Hi Dave,
> 
> Can you please give some more detail about what you are trying to do?
> 
> Basic is one of several different ways that IIS can do authentication, but
> all users that IIS authenticates are Windows users.  If you want to strip
> all www-authenticate headers except basic, the best way to do this is to
> just turn off all authentication except basic.  That way, IIS won't ever put
> one there that's not for basic.
> 
> Thank you,
> -Wade A. Hilmo,
> -Microsoft
> 
> "dareag"  wrote in message
> news:A47F16AF-64F9-47BA-BE48-6767842B878F@microsoft.com...
> > I am using an ISAPI Filter in IIS 5.1 to remove all but 'Basic'
> > WWW-Authenticate headers when windows login fails.
> >
> > I am using the 3rd consecutive 401 response to indicate a failure. Is
> there
> > a better way to catch a login failure? I'm doing it for
> > SF_NOTIFY_SEND_RESPONSE notification.
> >
> > The reason I am doing this is to set up Basic authentication and use local
> > validation if there is no valid windows account on my server.
> >
> > Using this method windows accounts can log in , but non windows accounts
> get
> > prompted for windows login and not my local login. Is removing the
> > WWW-Authenticate headers and adding a Basic one going to work?
> >
> > Also when a windows user does login I want to run my isapi dll as the
> > anonymous user; do you impersonate the anonymous user to do this?
> >
> > Many Thanks
> >
> > -- 
> > regards Dave
> 
> 
>

Hi Dave,

Each request to IIS gets one shot at authentication.  There is no concept of
trying other types if the first one fails.

You might be able to approximate this in a filter, but only if you are using
Basic authentication.  It would work like this:

Filter on SF_NOTIFY_PREPROC_HEADERS and look for an authorization header.
If there is no authorization header, the request is anonymous.  If you want
to allow anonymous access to the requested URL, then just return
SF_STATUS_REQ_NEXT_NOTIFICATION.  If you don't want to allow anonymous
authentication, then base64 decode the credentials from the authorization
header and test them for validity by calling LogonUser or LogonUserEx.  If
the credentials are not valid, then redirect the request to your login page.
If the credentials are valid, and you want to allow them, then you need to
set a flag that can be accessed through pFC->pFilterContext.  Finally, have
your filter listen on SF_NOTIFY_AUTHENTICATION and check for the flag.  If
you see the flag, then set the pszUser and pszPassword members of the passed
structure to empty strings.  This will cause the request to run as
anonymous.

Note that this mechanism cannot work with NTLM because NTML is a multi-leg
authentication scheme.  So to complete an NTLM handshake, there are multiple
requests where some 401 responses are by design, and some may indicate an
authorization failure.  Also, NTLM authentication is not exposes to the
SF_NOTIFY_AUTHENTICATION notification.

A few other notes:

Your requirement to redirect to a login page is what forces the need to use
PREPROC_HEADERS.  You could test the user provided credentials from the
AUTHENTICATION notification, but you could not do the redirection there.

If you care about server variables like REMOTE_USER, you should know that
they are populated from the credentials in the Authorization header, and not
from the credentials that you set in the AUTHENTICATION notification.  Using
basic authentication allows you control of their contents by creating the
base64 encoded credential string and setting it into the Authorization
header in PREPROC_HEADERS.

There are probably a bunch of other implementation details that you will run
into if you decided to do this.  This post is mainly just background
information to let you know what you are dealing with.

Thank you,
-Wade A. Hilmo,
-Microsoft
"dareag"  wrote in message
news:B64F20F6-7972-4F01-8B2F-5A321BCE28EE@microsoft.com...
> Hi Wade
>
> What I want to do is first try the windows credentials of the user who is
> currently logged on to the machine. If that fails it will not be a windows
> account that will access my application, it will be a local account that
my
> application stores in a database.
>
> So after the initial logon failure from windows I want to display my local
> login dialog box, and not a windows logon dialog.
>
> What I did have working was to tell IIS to do anonymous authentication and
> my dll would display my logon dialog; but if its a valid windows account
that
> is accessing my application then I want windows to authenticate them.
>
> Hope this makes it clearer. The user accessing my application may have
> windows credentials or they may have my application credentials.
>
> The other point I was trying to ask was that if they were using windows
> credentials I still want the dll to run as the anonymous user.
>
> Thanks
> -- 
> regards Dave
>
>
> "Wade A. Hilmo [MS]" wrote:
>
> > Hi Dave,
> >
> > Can you please give some more detail about what you are trying to do?
> >
> > Basic is one of several different ways that IIS can do authentication,
but
> > all users that IIS authenticates are Windows users.  If you want to
strip
> > all www-authenticate headers except basic, the best way to do this is to
> > just turn off all authentication except basic.  That way, IIS won't ever
put
> > one there that's not for basic.
> >
> > Thank you,
> > -Wade A. Hilmo,
> > -Microsoft
> >
> > "dareag"  wrote in message
> > news:A47F16AF-64F9-47BA-BE48-6767842B878F@microsoft.com...
> > > I am using an ISAPI Filter in IIS 5.1 to remove all but 'Basic'
> > > WWW-Authenticate headers when windows login fails.
> > >
> > > I am using the 3rd consecutive 401 response to indicate a failure. Is
> > there
> > > a better way to catch a login failure? I'm doing it for
> > > SF_NOTIFY_SEND_RESPONSE notification.
> > >
> > > The reason I am doing this is to set up Basic authentication and use
local
> > > validation if there is no valid windows account on my server.
> > >
> > > Using this method windows accounts can log in , but non windows
accounts
> > get
> > > prompted for windows login and not my local login. Is removing the
> > > WWW-Authenticate headers and adding a Basic one going to work?
> > >
> > > Also when a windows user does login I want to run my isapi dll as the
> > > anonymous user; do you impersonate the anonymous user to do this?
> > >
> > > Many Thanks
> > >
> > > -- 
> > > regards Dave
> >
> >
> >

Hi Wade
Thanks for the information!
Trying to implement this I use the function call
pfc->GetServerVariable(pfc,"HTTP_AUTHORIZATION",szAUTHORIZATION, &buffSize); 
to get the authorization header. Only problem is, it is either empty or it 
gives me the credentials of the last attempted login from the browser and not 
the logged in user credentials.

I tried using getheader with "Authorizatio" as a parameter, but this never 
got populated with credentials.

Any ideas.
Thanks
-- 
regards Dave 


"Wade A. Hilmo [MS]" wrote:

> Hi Dave,
> 
> Each request to IIS gets one shot at authentication.  There is no concept of
> trying other types if the first one fails.
> 
> You might be able to approximate this in a filter, but only if you are using
> Basic authentication.  It would work like this:
> 
> Filter on SF_NOTIFY_PREPROC_HEADERS and look for an authorization header.
> If there is no authorization header, the request is anonymous.  If you want
> to allow anonymous access to the requested URL, then just return
> SF_STATUS_REQ_NEXT_NOTIFICATION.  If you don't want to allow anonymous
> authentication, then base64 decode the credentials from the authorization
> header and test them for validity by calling LogonUser or LogonUserEx.  If
> the credentials are not valid, then redirect the request to your login page.
> If the credentials are valid, and you want to allow them, then you need to
> set a flag that can be accessed through pFC->pFilterContext.  Finally, have
> your filter listen on SF_NOTIFY_AUTHENTICATION and check for the flag.  If
> you see the flag, then set the pszUser and pszPassword members of the passed
> structure to empty strings.  This will cause the request to run as
> anonymous.
> 
> Note that this mechanism cannot work with NTLM because NTML is a multi-leg
> authentication scheme.  So to complete an NTLM handshake, there are multiple
> requests where some 401 responses are by design, and some may indicate an
> authorization failure.  Also, NTLM authentication is not exposes to the
> SF_NOTIFY_AUTHENTICATION notification.
> 
> A few other notes:
> 
> Your requirement to redirect to a login page is what forces the need to use
> PREPROC_HEADERS.  You could test the user provided credentials from the
> AUTHENTICATION notification, but you could not do the redirection there.
> 
> If you care about server variables like REMOTE_USER, you should know that
> they are populated from the credentials in the Authorization header, and not
> from the credentials that you set in the AUTHENTICATION notification.  Using
> basic authentication allows you control of their contents by creating the
> base64 encoded credential string and setting it into the Authorization
> header in PREPROC_HEADERS.
> 
> There are probably a bunch of other implementation details that you will run
> into if you decided to do this.  This post is mainly just background
> information to let you know what you are dealing with.
> 
> Thank you,
> -Wade A. Hilmo,
> -Microsoft
> "dareag"  wrote in message
> news:B64F20F6-7972-4F01-8B2F-5A321BCE28EE@microsoft.com...
> > Hi Wade
> >
> > What I want to do is first try the windows credentials of the user who is
> > currently logged on to the machine. If that fails it will not be a windows
> > account that will access my application, it will be a local account that
> my
> > application stores in a database.
> >
> > So after the initial logon failure from windows I want to display my local
> > login dialog box, and not a windows logon dialog.
> >
> > What I did have working was to tell IIS to do anonymous authentication and
> > my dll would display my logon dialog; but if its a valid windows account
> that
> > is accessing my application then I want windows to authenticate them.
> >
> > Hope this makes it clearer. The user accessing my application may have
> > windows credentials or they may have my application credentials.
> >
> > The other point I was trying to ask was that if they were using windows
> > credentials I still want the dll to run as the anonymous user.
> >
> > Thanks
> > -- 
> > regards Dave
> >
> >
> > "Wade A. Hilmo [MS]" wrote:
> >
> > > Hi Dave,
> > >
> > > Can you please give some more detail about what you are trying to do?
> > >
> > > Basic is one of several different ways that IIS can do authentication,
> but
> > > all users that IIS authenticates are Windows users.  If you want to
> strip
> > > all www-authenticate headers except basic, the best way to do this is to
> > > just turn off all authentication except basic.  That way, IIS won't ever
> put
> > > one there that's not for basic.
> > >
> > > Thank you,
> > > -Wade A. Hilmo,
> > > -Microsoft
> > >
> > > "dareag"  wrote in message
> > > news:A47F16AF-64F9-47BA-BE48-6767842B878F@microsoft.com...
> > > > I am using an ISAPI Filter in IIS 5.1 to remove all but 'Basic'
> > > > WWW-Authenticate headers when windows login fails.
> > > >
> > > > I am using the 3rd consecutive 401 response to indicate a failure. Is
> > > there
> > > > a better way to catch a login failure? I'm doing it for
> > > > SF_NOTIFY_SEND_RESPONSE notification.
> > > >
> > > > The reason I am doing this is to set up Basic authentication and use
> local
> > > > validation if there is no valid windows account on my server.
> > > >
> > > > Using this method windows accounts can log in , but non windows
> accounts
> > > get
> > > > prompted for windows login and not my local login. Is removing the
> > > > WWW-Authenticate headers and adding a Basic one going to work?
> > > >
> > > > Also when a windows user does login I want to run my isapi dll as the
> > > > anonymous user; do you impersonate the anonymous user to do this?
> > > >
> > > > Many Thanks
> > > >
> > > > -- 
> > > > regards Dave
> > >
> > >
> > >
> 
> 
>

Hi Dave,

The function call below just retrieves the raw Authorization header sent by
the client.  Also, the result of the call may vary based on when you call
it.  If, for example, the Authorization header is incompatible with the
enabled authentication types, IIS will remove it during authentication.  Any
attempts to retrieve it after that will return an empty string.

If you are trying to get the credentials that the client is sending for the
current request in PREPROC_HEADERS, the best way to do it is to use the
GetHeader function and pass in "authorization:" as the header name.  Note
that interpreting the actual client credentials will vary based on the
authentication type.  For Basic authentication, you should base64 decode the
value after the auth specification, which will yield the username and
password, separated by a colon.

I hope that this helps,
-Wade A. Hilmo,
-Microsoft

"dareag"  wrote in message
news:5364937A-C7B5-4A68-B5E2-B910DDC798A0@microsoft.com...
> Hi Wade
> Thanks for the information!
> Trying to implement this I use the function call
> pfc->GetServerVariable(pfc,"HTTP_AUTHORIZATION",szAUTHORIZATION,
&buffSize);
> to get the authorization header. Only problem is, it is either empty or it
> gives me the credentials of the last attempted login from the browser and
not
> the logged in user credentials.
>
> I tried using getheader with "Authorizatio" as a parameter, but this never
> got populated with credentials.
>
> Any ideas.
> Thanks
> -- 
> regards Dave
>
>
> "Wade A. Hilmo [MS]" wrote:
>
> > Hi Dave,
> >
> > Each request to IIS gets one shot at authentication.  There is no
concept of
> > trying other types if the first one fails.
> >
> > You might be able to approximate this in a filter, but only if you are
using
> > Basic authentication.  It would work like this:
> >
> > Filter on SF_NOTIFY_PREPROC_HEADERS and look for an authorization
header.
> > If there is no authorization header, the request is anonymous.  If you
want
> > to allow anonymous access to the requested URL, then just return
> > SF_STATUS_REQ_NEXT_NOTIFICATION.  If you don't want to allow anonymous
> > authentication, then base64 decode the credentials from the
authorization
> > header and test them for validity by calling LogonUser or LogonUserEx.
If
> > the credentials are not valid, then redirect the request to your login
page.
> > If the credentials are valid, and you want to allow them, then you need
to
> > set a flag that can be accessed through pFC->pFilterContext.  Finally,
have
> > your filter listen on SF_NOTIFY_AUTHENTICATION and check for the flag.
If
> > you see the flag, then set the pszUser and pszPassword members of the
passed
> > structure to empty strings.  This will cause the request to run as
> > anonymous.
> >
> > Note that this mechanism cannot work with NTLM because NTML is a
multi-leg
> > authentication scheme.  So to complete an NTLM handshake, there are
multiple
> > requests where some 401 responses are by design, and some may indicate
an
> > authorization failure.  Also, NTLM authentication is not exposes to the
> > SF_NOTIFY_AUTHENTICATION notification.
> >
> > A few other notes:
> >
> > Your requirement to redirect to a login page is what forces the need to
use
> > PREPROC_HEADERS.  You could test the user provided credentials from the
> > AUTHENTICATION notification, but you could not do the redirection there.
> >
> > If you care about server variables like REMOTE_USER, you should know
that
> > they are populated from the credentials in the Authorization header, and
not
> > from the credentials that you set in the AUTHENTICATION notification.
Using
> > basic authentication allows you control of their contents by creating
the
> > base64 encoded credential string and setting it into the Authorization
> > header in PREPROC_HEADERS.
> >
> > There are probably a bunch of other implementation details that you will
run
> > into if you decided to do this.  This post is mainly just background
> > information to let you know what you are dealing with.
> >
> > Thank you,
> > -Wade A. Hilmo,
> > -Microsoft
> > "dareag"  wrote in message
> > news:B64F20F6-7972-4F01-8B2F-5A321BCE28EE@microsoft.com...
> > > Hi Wade
> > >
> > > What I want to do is first try the windows credentials of the user who
is
> > > currently logged on to the machine. If that fails it will not be a
windows
> > > account that will access my application, it will be a local account
that
> > my
> > > application stores in a database.
> > >
> > > So after the initial logon failure from windows I want to display my
local
> > > login dialog box, and not a windows logon dialog.
> > >
> > > What I did have working was to tell IIS to do anonymous authentication
and
> > > my dll would display my logon dialog; but if its a valid windows
account
> > that
> > > is accessing my application then I want windows to authenticate them.
> > >
> > > Hope this makes it clearer. The user accessing my application may have
> > > windows credentials or they may have my application credentials.
> > >
> > > The other point I was trying to ask was that if they were using
windows
> > > credentials I still want the dll to run as the anonymous user.
> > >
> > > Thanks
> > > -- 
> > > regards Dave
> > >
> > >
> > > "Wade A. Hilmo [MS]" wrote:
> > >
> > > > Hi Dave,
> > > >
> > > > Can you please give some more detail about what you are trying to
do?
> > > >
> > > > Basic is one of several different ways that IIS can do
authentication,
> > but
> > > > all users that IIS authenticates are Windows users.  If you want to
> > strip
> > > > all www-authenticate headers except basic, the best way to do this
is to
> > > > just turn off all authentication except basic.  That way, IIS won't
ever
> > put
> > > > one there that's not for basic.
> > > >
> > > > Thank you,
> > > > -Wade A. Hilmo,
> > > > -Microsoft
> > > >
> > > > "dareag"  wrote in message
> > > > news:A47F16AF-64F9-47BA-BE48-6767842B878F@microsoft.com...
> > > > > I am using an ISAPI Filter in IIS 5.1 to remove all but 'Basic'
> > > > > WWW-Authenticate headers when windows login fails.
> > > > >
> > > > > I am using the 3rd consecutive 401 response to indicate a failure.
Is
> > > > there
> > > > > a better way to catch a login failure? I'm doing it for
> > > > > SF_NOTIFY_SEND_RESPONSE notification.
> > > > >
> > > > > The reason I am doing this is to set up Basic authentication and
use
> > local
> > > > > validation if there is no valid windows account on my server.
> > > > >
> > > > > Using this method windows accounts can log in , but non windows
> > accounts
> > > > get
> > > > > prompted for windows login and not my local login. Is removing the
> > > > > WWW-Authenticate headers and adding a Basic one going to work?
> > > > >
> > > > > Also when a windows user does login I want to run my isapi dll as
the
> > > > > anonymous user; do you impersonate the anonymous user to do this?
> > > > >
> > > > > Many Thanks
> > > > >
> > > > > -- 
> > > > > regards Dave
> > > >
> > > >
> > > >
> >
> >
> >

In your "fall-back" authentication scheme, how do you plan to
distinguish between the expected 401s of the NTLM authentication
protocol and the unexpected 401s of non-existing Windows user?

And are you sure that your browser agent is able to break out of NTLM
authentication handshake to perform Basic authentication?

These are but some of the details that you must consider when you want
to fabricate a custom authentication protocol by stitching together
existing ones. In addition to knowing the existing protocols backwards
and forwards. And the details of what headers/values get sent and when
it is available. While ISAPI Filter can retrieve all those values,
unfortunately you have to know when to do everything.

Also, it is not possible for an ISAPI Filter to change the
impersonated user token of an NTLM-authenticated request. So you
cannot run your DLL as anonymous when the remote user has a Windows
account.

It sounds like what you are trying to do is:
1. Perform custom authentication protocol which involves trying NTLM
and if the remote user does not have Windows account, try Basic.
2. And after authentication completes, run the request as anonymous
user on the web server to handle the request
3. And re-use as much of the built-in code of IIS as possible in this
new sequence.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//




On Mar 9, 5:01 am, dareag  wrote:
> Hi Wade
> Thanks for the information!
> Trying to implement this I use the function call
> pfc->GetServerVariable(pfc,"HTTP_AUTHORIZATION",szAUTHORIZATION, &buffSize);
> to get the authorization header. Only problem is, it is either empty or it
> gives me the credentials of the last attempted login from the browser and not
> the logged in user credentials.
>
> I tried using getheader with "Authorizatio" as a parameter, but this never
> got populated with credentials.
>
> Any ideas.
> Thanks
> --
> regards Dave
>
> "Wade A. Hilmo [MS]" wrote:
>
>
>
> > Hi Dave,
>
> > Each request to IIS gets one shot at authentication.  There is no concept of
> > trying other types if the first one fails.
>
> > You might be able to approximate this in a filter, but only if you are using
> > Basic authentication.  It would work like this:
>
> > Filter on SF_NOTIFY_PREPROC_HEADERS and look for an authorization header.
> > If there is no authorization header, the request is anonymous.  If you want
> > to allow anonymous access to the requested URL, then just return
> > SF_STATUS_REQ_NEXT_NOTIFICATION.  If you don't want to allow anonymous
> > authentication, then base64 decode the credentials from the authorization
> > header and test them for validity by calling LogonUser or LogonUserEx.  If
> > the credentials are not valid, then redirect the request to your login page.
> > If the credentials are valid, and you want to allow them, then you need to
> > set a flag that can be accessed through pFC->pFilterContext.  Finally, have
> > your filter listen on SF_NOTIFY_AUTHENTICATION and check for the flag.  If
> > you see the flag, then set the pszUser and pszPassword members of the passed
> > structure to empty strings.  This will cause the request to run as
> > anonymous.
>
> > Note that this mechanism cannot work with NTLM because NTML is a multi-leg
> > authentication scheme.  So to complete an NTLM handshake, there are multiple
> > requests where some 401 responses are by design, and some may indicate an
> > authorization failure.  Also, NTLM authentication is not exposes to the
> > SF_NOTIFY_AUTHENTICATION notification.
>
> > A few other notes:
>
> > Your requirement to redirect to a login page is what forces the need to use
> > PREPROC_HEADERS.  You could test the user provided credentials from the
> > AUTHENTICATION notification, but you could not do the redirection there.
>
> > If you care about server variables like REMOTE_USER, you should know that
> > they are populated from the credentials in the Authorization header, and not
> > from the credentials that you set in the AUTHENTICATION notification.  Using
> > basic authentication allows you control of their contents by creating the
> > base64 encoded credential string and setting it into the Authorization
> > header in PREPROC_HEADERS.
>
> > There are probably a bunch of other implementation details that you will run
> > into if you decided to do this.  This post is mainly just background
> > information to let you know what you are dealing with.
>
> > Thank you,
> > -Wade A. Hilmo,
> > -Microsoft
> > "dareag"  wrote in message
> >news:B64F20F6-7972-4F01-8B2F-5A321BCE28EE@microsoft.com...
> > > Hi Wade
>
> > > What I want to do is first try the windows credentials of the user who is
> > > currently logged on to the machine. If that fails it will not be a windows
> > > account that will access my application, it will be a local account that
> > my
> > > application stores in a database.
>
> > > So after the initial logon failure from windows I want to display my local
> > > login dialog box, and not a windows logon dialog.
>
> > > What I did have working was to tell IIS to do anonymous authentication and
> > > my dll would display my logon dialog; but if its a valid windows account
> > that
> > > is accessing my application then I want windows to authenticate them.
>
> > > Hope this makes it clearer. The user accessing my application may have
> > > windows credentials or they may have my application credentials.
>
> > > The other point I was trying to ask was that if they were using windows
> > > credentials I still want the dll to run as the anonymous user.
>
> > > Thanks
> > > --
> > > regards Dave
>
> > > "Wade A. Hilmo [MS]" wrote:
>
> > > > Hi Dave,
>
> > > > Can you please give some more detail about what you are trying to do?
>
> > > > Basic is one of several different ways that IIS can do authentication,
> > but
> > > > all users that IIS authenticates are Windows users.  If you want to
> > strip
> > > > all www-authenticate headers except basic, the best way to do this is to
> > > > just turn off all authentication except basic.  That way, IIS won't ever
> > put
> > > > one there that's not for basic.
>
> > > > Thank you,
> > > > -Wade A. Hilmo,
> > > > -Microsoft
>
> > > > "dareag"  wrote in message
> > > >news:A47F16AF-64F9-47BA-BE48-6767842B878F@microsoft.com...
> > > > > I am using an ISAPI Filter in IIS 5.1 to remove all but 'Basic'
> > > > > WWW-Authenticate headers when windows login fails.
>
> > > > > I am using the 3rd consecutive 401 response to indicate a failure. Is
> > > > there
> > > > > a better way to catch a login failure? I'm doing it for
> > > > > SF_NOTIFY_SEND_RESPONSE notification.
>
> > > > > The reason I am doing this is to set up Basic authentication and use
> > local
> > > > > validation if there is no valid windows account on my server.
>
> > > > > Using this method windows accounts can log in , but non windows
> > accounts
> > > > get
> > > > > prompted for windows login and not my local login. Is removing the
> > > > > WWW-Authenticate headers and adding a Basic one going to work?
>
> > > > > Also when a windows user does login I want to run my isapi dll as the
> > > > > anonymous user; do you impersonate the anonymous user to do this?
>
> > > > > Many Thanks
>
> > > > > --
> > > > > regards Dave- Hide quoted text -
>
> - Show quoted text -

"I have seen that the browser does not break out of NTLM; I am now using 
"Basic", and if there are no valid windows credentials redirect to a local 
login.

In PREPROC_HEADERS I still do not get any user credentials with GetHeader 
using "authorization:", the user has to enter credentials at the login prompt 
before any credentials are received. I really need to check credentials 
before any login prompt is displayed.

Is it only NTLM that will offer this functionallity?
-- 
regards Dave 


"David Wang" wrote:

> In your "fall-back" authentication scheme, how do you plan to
> distinguish between the expected 401s of the NTLM authentication
> protocol and the unexpected 401s of non-existing Windows user?
> 
> And are you sure that your browser agent is able to break out of NTLM
> authentication handshake to perform Basic authentication?
> 
> These are but some of the details that you must consider when you want
> to fabricate a custom authentication protocol by stitching together
> existing ones. In addition to knowing the existing protocols backwards
> and forwards. And the details of what headers/values get sent and when
> it is available. While ISAPI Filter can retrieve all those values,
> unfortunately you have to know when to do everything.
> 
> Also, it is not possible for an ISAPI Filter to change the
> impersonated user token of an NTLM-authenticated request. So you
> cannot run your DLL as anonymous when the remote user has a Windows
> account.
> 
> It sounds like what you are trying to do is:
> 1. Perform custom authentication protocol which involves trying NTLM
> and if the remote user does not have Windows account, try Basic.
> 2. And after authentication completes, run the request as anonymous
> user on the web server to handle the request
> 3. And re-use as much of the built-in code of IIS as possible in this
> new sequence.
> 
> 
> //David
> http://w3-4u.blogspot.com
> http://blogs.msdn.com/David.Wang
> //
> 
> 
> 
> 
> On Mar 9, 5:01 am, dareag  wrote:
> > Hi Wade
> > Thanks for the information!
> > Trying to implement this I use the function call
> > pfc->GetServerVariable(pfc,"HTTP_AUTHORIZATION",szAUTHORIZATION, &buffSize);
> > to get the authorization header. Only problem is, it is either empty or it
> > gives me the credentials of the last attempted login from the browser and not
> > the logged in user credentials.
> >
> > I tried using getheader with "Authorizatio" as a parameter, but this never
> > got populated with credentials.
> >
> > Any ideas.
> > Thanks
> > --
> > regards Dave
> >
> > "Wade A. Hilmo [MS]" wrote:
> >
> >
> >
> > > Hi Dave,
> >
> > > Each request to IIS gets one shot at authentication.  There is no concept of
> > > trying other types if the first one fails.
> >
> > > You might be able to approximate this in a filter, but only if you are using
> > > Basic authentication.  It would work like this:
> >
> > > Filter on SF_NOTIFY_PREPROC_HEADERS and look for an authorization header.
> > > If there is no authorization header, the request is anonymous.  If you want
> > > to allow anonymous access to the requested URL, then just return
> > > SF_STATUS_REQ_NEXT_NOTIFICATION.  If you don't want to allow anonymous
> > > authentication, then base64 decode the credentials from the authorization
> > > header and test them for validity by calling LogonUser or LogonUserEx.  If
> > > the credentials are not valid, then redirect the request to your login page.
> > > If the credentials are valid, and you want to allow them, then you need to
> > > set a flag that can be accessed through pFC->pFilterContext.  Finally, have
> > > your filter listen on SF_NOTIFY_AUTHENTICATION and check for the flag.  If
> > > you see the flag, then set the pszUser and pszPassword members of the passed
> > > structure to empty strings.  This will cause the request to run as
> > > anonymous.
> >
> > > Note that this mechanism cannot work with NTLM because NTML is a multi-leg
> > > authentication scheme.  So to complete an NTLM handshake, there are multiple
> > > requests where some 401 responses are by design, and some may indicate an
> > > authorization failure.  Also, NTLM authentication is not exposes to the
> > > SF_NOTIFY_AUTHENTICATION notification.
> >
> > > A few other notes:
> >
> > > Your requirement to redirect to a login page is what forces the need to use
> > > PREPROC_HEADERS.  You could test the user provided credentials from the
> > > AUTHENTICATION notification, but you could not do the redirection there.
> >
> > > If you care about server variables like REMOTE_USER, you should know that
> > > they are populated from the credentials in the Authorization header, and not
> > > from the credentials that you set in the AUTHENTICATION notification.  Using
> > > basic authentication allows you control of their contents by creating the
> > > base64 encoded credential string and setting it into the Authorization
> > > header in PREPROC_HEADERS.
> >
> > > There are probably a bunch of other implementation details that you will run
> > > into if you decided to do this.  This post is mainly just background
> > > information to let you know what you are dealing with.
> >
> > > Thank you,
> > > -Wade A. Hilmo,
> > > -Microsoft
> > > "dareag"  wrote in message
> > >news:B64F20F6-7972-4F01-8B2F-5A321BCE28EE@microsoft.com...
> > > > Hi Wade
> >
> > > > What I want to do is first try the windows credentials of the user who is
> > > > currently logged on to the machine. If that fails it will not be a windows
> > > > account that will access my application, it will be a local account that
> > > my
> > > > application stores in a database.
> >
> > > > So after the initial logon failure from windows I want to display my local
> > > > login dialog box, and not a windows logon dialog.
> >
> > > > What I did have working was to tell IIS to do anonymous authentication and
> > > > my dll would display my logon dialog; but if its a valid windows account
> > > that
> > > > is accessing my application then I want windows to authenticate them.
> >
> > > > Hope this makes it clearer. The user accessing my application may have
> > > > windows credentials or they may have my application credentials.
> >
> > > > The other point I was trying to ask was that if they were using windows
> > > > credentials I still want the dll to run as the anonymous user.
> >
> > > > Thanks
> > > > --
> > > > regards Dave
> >
> > > > "Wade A. Hilmo [MS]" wrote:
> >
> > > > > Hi Dave,
> >
> > > > > Can you please give some more detail about what you are trying to do?
> >
> > > > > Basic is one of several different ways that IIS can do authentication,
> > > but
> > > > > all users that IIS authenticates are Windows users.  If you want to
> > > strip
> > > > > all www-authenticate headers except basic, the best way to do this is to
> > > > > just turn off all authentication except basic.  That way, IIS won't ever
> > > put
> > > > > one there that's not for basic.
> >
> > > > > Thank you,
> > > > > -Wade A. Hilmo,
> > > > > -Microsoft
> >
> > > > > "dareag"  wrote in message
> > > > >news:A47F16AF-64F9-47BA-BE48-6767842B878F@microsoft.com...
> > > > > > I am using an ISAPI Filter in IIS 5.1 to remove all but 'Basic'
> > > > > > WWW-Authenticate headers when windows login fails.
> >
> > > > > > I am using the 3rd consecutive 401 response to indicate a failure. Is
> > > > > there
> > > > > > a better way to catch a login failure? I'm doing it for
> > > > > > SF_NOTIFY_SEND_RESPONSE notification.
> >
> > > > > > The reason I am doing this is to set up Basic authentication and use
> > > local
> > > > > > validation if there is no valid windows account on my server.
> >
> > > > > > Using this method windows accounts can log in , but non windows
> > > accounts
> > > > > get
> > > > > > prompted for windows login and not my local login. Is removing the
> > > > > > WWW-Authenticate headers and adding a Basic one going to work?
> >
> > > > > > Also when a windows user does login I want to run my isapi dll as the
> > > > > > anonymous user; do you impersonate the anonymous user to do this?
> >
> > > > > > Many Thanks
> >
> > > > > > --
> > > > > > regards Dave- Hide quoted text -
> >
> > - Show quoted text -
> 
> 
>

Hi Dave,

With Basic authentication, the user will have to enter credentials at some
point.  Once the user has done this once, the browers will probably be smart
about remembering them for future requests to the same server (with some
consideration to the URL) until the browser is restarted.

Basic authentication cannot avoid this login on the client side because it
is not possible for it to get the actual credentials from Windows (this
would be a pretty big security hole if some application could just get your
password from the OS.)  The Windows Integrated protocols never actually use
the raw credentials from the client.  When the client does it's part with
NTLM or Kerberos, it's actually passing through most of the work to the OS,
which has built-in knowledge of how to handle them.  That is why Windows
Integrated can skip asking the user for credentials.  Unfortunately, all of
the Windows Integrated protocols are incompatible with ISAPI authentication
filters (largely because IIS doesn't know how to do NTLM or Kerberos.  Like
the client, it delegates this work to the OS.)

Thank you,
-Wade A. Hilmo,
-Microsoft

"dareag"  wrote in message
news:6851B793-0B5B-4112-94A6-0206326808C6@microsoft.com...
> "I have seen that the browser does not break out of NTLM; I am now using
> "Basic", and if there are no valid windows credentials redirect to a local
> login.
>
> In PREPROC_HEADERS I still do not get any user credentials with GetHeader
> using "authorization:", the user has to enter credentials at the login
prompt
> before any credentials are received. I really need to check credentials
> before any login prompt is displayed.
>
> Is it only NTLM that will offer this functionallity?
> -- 
> regards Dave
>
>
> "David Wang" wrote:
>
> > In your "fall-back" authentication scheme, how do you plan to
> > distinguish between the expected 401s of the NTLM authentication
> > protocol and the unexpected 401s of non-existing Windows user?
> >
> > And are you sure that your browser agent is able to break out of NTLM
> > authentication handshake to perform Basic authentication?
> >
> > These are but some of the details that you must consider when you want
> > to fabricate a custom authentication protocol by stitching together
> > existing ones. In addition to knowing the existing protocols backwards
> > and forwards. And the details of what headers/values get sent and when
> > it is available. While ISAPI Filter can retrieve all those values,
> > unfortunately you have to know when to do everything.
> >
> > Also, it is not possible for an ISAPI Filter to change the
> > impersonated user token of an NTLM-authenticated request. So you
> > cannot run your DLL as anonymous when the remote user has a Windows
> > account.
> >
> > It sounds like what you are trying to do is:
> > 1. Perform custom authentication protocol which involves trying NTLM
> > and if the remote user does not have Windows account, try Basic.
> > 2. And after authentication completes, run the request as anonymous
> > user on the web server to handle the request
> > 3. And re-use as much of the built-in code of IIS as possible in this
> > new sequence.
> >
> >
> > //David
> > http://w3-4u.blogspot.com
> > http://blogs.msdn.com/David.Wang
> > //
> >
> >
> >
> >
> > On Mar 9, 5:01 am, dareag  wrote:
> > > Hi Wade
> > > Thanks for the information!
> > > Trying to implement this I use the function call
> > > pfc->GetServerVariable(pfc,"HTTP_AUTHORIZATION",szAUTHORIZATION,
&buffSize);
> > > to get the authorization header. Only problem is, it is either empty
or it
> > > gives me the credentials of the last attempted login from the browser
and not
> > > the logged in user credentials.
> > >
> > > I tried using getheader with "Authorizatio" as a parameter, but this
never
> > > got populated with credentials.
> > >
> > > Any ideas.
> > > Thanks
> > > --
> > > regards Dave
> > >
> > > "Wade A. Hilmo [MS]" wrote:
> > >
> > >
> > >
> > > > Hi Dave,
> > >
> > > > Each request to IIS gets one shot at authentication.  There is no
concept of
> > > > trying other types if the first one fails.
> > >
> > > > You might be able to approximate this in a filter, but only if you
are using
> > > > Basic authentication.  It would work like this:
> > >
> > > > Filter on SF_NOTIFY_PREPROC_HEADERS and look for an authorization
header.
> > > > If there is no authorization header, the request is anonymous.  If
you want
> > > > to allow anonymous access to the requested URL, then just return
> > > > SF_STATUS_REQ_NEXT_NOTIFICATION.  If you don't want to allow
anonymous
> > > > authentication, then base64 decode the credentials from the
authorization
> > > > header and test them for validity by calling LogonUser or
LogonUserEx.  If
> > > > the credentials are not valid, then redirect the request to your
login page.
> > > > If the credentials are valid, and you want to allow them, then you
need to
> > > > set a flag that can be accessed through pFC->pFilterContext.
Finally, have
> > > > your filter listen on SF_NOTIFY_AUTHENTICATION and check for the
flag.  If
> > > > you see the flag, then set the pszUser and pszPassword members of
the passed
> > > > structure to empty strings.  This will cause the request to run as
> > > > anonymous.
> > >
> > > > Note that this mechanism cannot work with NTLM because NTML is a
multi-leg
> > > > authentication scheme.  So to complete an NTLM handshake, there are
multiple
> > > > requests where some 401 responses are by design, and some may
indicate an
> > > > authorization failure.  Also, NTLM authentication is not exposes to
the
> > > > SF_NOTIFY_AUTHENTICATION notification.
> > >
> > > > A few other notes:
> > >
> > > > Your requirement to redirect to a login page is what forces the need
to use
> > > > PREPROC_HEADERS.  You could test the user provided credentials from
the
> > > > AUTHENTICATION notification, but you could not do the redirection
there.
> > >
> > > > If you care about server variables like REMOTE_USER, you should know
that
> > > > they are populated from the credentials in the Authorization header,
and not
> > > > from the credentials that you set in the AUTHENTICATION
notification.  Using
> > > > basic authentication allows you control of their contents by
creating the
> > > > base64 encoded credential string and setting it into the
Authorization
> > > > header in PREPROC_HEADERS.
> > >
> > > > There are probably a bunch of other implementation details that you
will run
> > > > into if you decided to do this.  This post is mainly just background
> > > > information to let you know what you are dealing with.
> > >
> > > > Thank you,
> > > > -Wade A. Hilmo,
> > > > -Microsoft
> > > > "dareag"  wrote in message
> > > >news:B64F20F6-7972-4F01-8B2F-5A321BCE28EE@microsoft.com...
> > > > > Hi Wade
> > >
> > > > > What I want to do is first try the windows credentials of the user
who is
> > > > > currently logged on to the machine. If that fails it will not be a
windows
> > > > > account that will access my application, it will be a local
account that
> > > > my
> > > > > application stores in a database.
> > >
> > > > > So after the initial logon failure from windows I want to display
my local
> > > > > login dialog box, and not a windows logon dialog.
> > >
> > > > > What I did have working was to tell IIS to do anonymous
authentication and
> > > > > my dll would display my logon dialog; but if its a valid windows
account
> > > > that
> > > > > is accessing my application then I want windows to authenticate
them.
> > >
> > > > > Hope this makes it clearer. The user accessing my application may
have
> > > > > windows credentials or they may have my application credentials.
> > >
> > > > > The other point I was trying to ask was that if they were using
windows
> > > > > credentials I still want the dll to run as the anonymous user.
> > >
> > > > > Thanks
> > > > > --
> > > > > regards Dave
> > >
> > > > > "Wade A. Hilmo [MS]" wrote:
> > >
> > > > > > Hi Dave,
> > >
> > > > > > Can you please give some more detail about what you are trying
to do?
> > >
> > > > > > Basic is one of several different ways that IIS can do
authentication,
> > > > but
> > > > > > all users that IIS authenticates are Windows users.  If you want
to
> > > > strip
> > > > > > all www-authenticate headers except basic, the best way to do
this is to
> > > > > > just turn off all authentication except basic.  That way, IIS
won't ever
> > > > put
> > > > > > one there that's not for basic.
> > >
> > > > > > Thank you,
> > > > > > -Wade A. Hilmo,
> > > > > > -Microsoft
> > >
> > > > > > "dareag"  wrote in message
> > > > > >news:A47F16AF-64F9-47BA-BE48-6767842B878F@microsoft.com...
> > > > > > > I am using an ISAPI Filter in IIS 5.1 to remove all but
'Basic'
> > > > > > > WWW-Authenticate headers when windows login fails.
> > >
> > > > > > > I am using the 3rd consecutive 401 response to indicate a
failure. Is
> > > > > > there
> > > > > > > a better way to catch a login failure? I'm doing it for
> > > > > > > SF_NOTIFY_SEND_RESPONSE notification.
> > >
> > > > > > > The reason I am doing this is to set up Basic authentication
and use
> > > > local
> > > > > > > validation if there is no valid windows account on my server.
> > >
> > > > > > > Using this method windows accounts can log in , but non
windows
> > > > accounts
> > > > > > get
> > > > > > > prompted for windows login and not my local login. Is removing
the
> > > > > > > WWW-Authenticate headers and adding a Basic one going to work?
> > >
> > > > > > > Also when a windows user does login I want to run my isapi dll
as the
> > > > > > > anonymous user; do you impersonate the anonymous user to do
this?
> > >
> > > > > > > Many Thanks
> > >
> > > > > > > --
> > > > > > > regards Dave- Hide quoted text -
> > >
> > > - Show quoted text -
> >
> >
> >

In addition to what Wade says -- it is not possible to "check
credentials before any login prompt is displayed" because you are
asking to know the user's identity before authenticating to determine
the user's identity -- and that is clearly an impossible catch-22.

NTLM does not side-step any of this. No authentication protocol
sidesteps this. How browsers avoid the login prompt is to
automatically "pre-authenticate" to the server.

Basic authentication does not pre-authenticate because that is a
security vulnerability. Do you expect the browser to automatically
pass your username/password to every single webserver that it talks
to, just to possibly avoid the login prompt?

So, you cannot use Basic Authentication to get the username without
the user seeing a login prompt from the browser. And you cannot get
the username from NTLM until it successfully authenticates a Windows
user identity.

Secure authentication protocols simply do not give you access to the
username until authentication is complete. I understand that what you
want to do *seems* easy, but like most things with security, the
devil's in the details.

Most people imagine authentication as the browser remembering the
user's name/password, then automatically sending over the username/
password to the server, and then the server "looks up" the username to
determine if it is a Windows user or not, and then determine what
authentication protocol to use. However, that is simply not a standard
protocol understood by any browser or server. Nor is the protocol safe
nor secure, even if you make it over SSL.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//





On Mar 12, 3:01 am, dareag  wrote:
> "I have seen that the browser does not break out of NTLM; I am now using
> "Basic", and if there are no valid windows credentials redirect to a local
> login.
>
> In PREPROC_HEADERS I still do not get any user credentials with GetHeader
> using "authorization:", the user has to enter credentials at the login prompt
> before any credentials are received. I really need to check credentials
> before any login prompt is displayed.
>
> Is it only NTLM that will offer this functionallity?
> --
> regards Dave
>
>
>
> "David Wang" wrote:
> > In your "fall-back" authentication scheme, how do you plan to
> > distinguish between the expected 401s of the NTLM authentication
> > protocol and the unexpected 401s of non-existing Windows user?
>
> > And are you sure that your browser agent is able to break out of NTLM
> > authentication handshake to perform Basic authentication?
>
> > These are but some of the details that you must consider when you want
> > to fabricate a custom authentication protocol by stitching together
> > existing ones. In addition to knowing the existing protocols backwards
> > and forwards. And the details of what headers/values get sent and when
> > it is available. While ISAPI Filter can retrieve all those values,
> > unfortunately you have to know when to do everything.
>
> > Also, it is not possible for an ISAPI Filter to change the
> > impersonated user token of an NTLM-authenticated request. So you
> > cannot run your DLL as anonymous when the remote user has a Windows
> > account.
>
> > It sounds like what you are trying to do is:
> > 1. Perform custom authentication protocol which involves trying NTLM
> > and if the remote user does not have Windows account, try Basic.
> > 2. And after authentication completes, run the request as anonymous
> > user on the web server to handle the request
> > 3. And re-use as much of the built-in code of IIS as possible in this
> > new sequence.
>
> > //David
> >http://w3-4u.blogspot.com
> >http://blogs.msdn.com/David.Wang
> > //
>
> > On Mar 9, 5:01 am, dareag  wrote:
> > > Hi Wade
> > > Thanks for the information!
> > > Trying to implement this I use the function call
> > > pfc->GetServerVariable(pfc,"HTTP_AUTHORIZATION",szAUTHORIZATION, &buffSize);
> > > to get the authorization header. Only problem is, it is either empty or it
> > > gives me the credentials of the last attempted login from the browser and not
> > > the logged in user credentials.
>
> > > I tried using getheader with "Authorizatio" as a parameter, but this never
> > > got populated with credentials.
>
> > > Any ideas.
> > > Thanks
> > > --
> > > regards Dave
>
> > > "Wade A. Hilmo [MS]" wrote:
>
> > > > Hi Dave,
>
> > > > Each request to IIS gets one shot at authentication.  There is no concept of
> > > > trying other types if the first one fails.
>
> > > > You might be able to approximate this in a filter, but only if you are using
> > > > Basic authentication.  It would work like this:
>
> > > > Filter on SF_NOTIFY_PREPROC_HEADERS and look for an authorization header.
> > > > If there is no authorization header, the request is anonymous.  If you want
> > > > to allow anonymous access to the requested URL, then just return
> > > > SF_STATUS_REQ_NEXT_NOTIFICATION.  If you don't want to allow anonymous
> > > > authentication, then base64 decode the credentials from the authorization
> > > > header and test them for validity by calling LogonUser or LogonUserEx.  If
> > > > the credentials are not valid, then redirect the request to your login page.
> > > > If the credentials are valid, and you want to allow them, then you need to
> > > > set a flag that can be accessed through pFC->pFilterContext.  Finally, have
> > > > your filter listen on SF_NOTIFY_AUTHENTICATION and check for the flag.  If
> > > > you see the flag, then set the pszUser and pszPassword members of the passed
> > > > structure to empty strings.  This will cause the request to run as
> > > > anonymous.
>
> > > > Note that this mechanism cannot work with NTLM because NTML is a multi-leg
> > > > authentication scheme.  So to complete an NTLM handshake, there are multiple
> > > > requests where some 401 responses are by design, and some may indicate an
> > > > authorization failure.  Also, NTLM authentication is not exposes to the
> > > > SF_NOTIFY_AUTHENTICATION notification.
>
> > > > A few other notes:
>
> > > > Your requirement to redirect to a login page is what forces the need to use
> > > > PREPROC_HEADERS.  You could test the user provided credentials from the
> > > > AUTHENTICATION notification, but you could not do the redirection there.
>
> > > > If you care about server variables like REMOTE_USER, you should know that
> > > > they are populated from the credentials in the Authorization header, and not
> > > > from the credentials that you set in the AUTHENTICATION notification.  Using
> > > > basic authentication allows you control of their contents by creating the
> > > > base64 encoded credential string and setting it into the Authorization
> > > > header in PREPROC_HEADERS.
>
> > > > There are probably a bunch of other implementation details that you will run
> > > > into if you decided to do this.  This post is mainly just background
> > > > information to let you know what you are dealing with.
>
> > > > Thank you,
> > > > -Wade A. Hilmo,
> > > > -Microsoft
> > > > "dareag"  wrote in message
> > > >news:B64F20F6-7972-4F01-8B2F-5A321BCE28EE@microsoft.com...
> > > > > Hi Wade
>
> > > > > What I want to do is first try the windows credentials of the user who is
> > > > > currently logged on to the machine. If that fails it will not be a windows
> > > > > account that will access my application, it will be a local account that
> > > > my
> > > > > application stores in a database.
>
> > > > > So after the initial logon failure from windows I want to display my local
> > > > > login dialog box, and not a windows logon dialog.
>
> > > > > What I did have working was to tell IIS to do anonymous authentication and
> > > > > my dll would display my logon dialog; but if its a valid windows account
> > > > that
> > > > > is accessing my application then I want windows to authenticate them.
>
> > > > > Hope this makes it clearer. The user accessing my application may have
> > > > > windows credentials or they may have my application credentials.
>
> > > > > The other point I was trying to ask was that if they were using windows
> > > > > credentials I still want the dll to run as the anonymous user.
>
> > > > > Thanks
> > > > > --
> > > > > regards Dave
>
> > > > > "Wade A. Hilmo [MS]" wrote:
>
> > > > > > Hi Dave,
>
> > > > > > Can you please give some more detail about what you are trying to do?
>
> > > > > > Basic is one of several different ways that IIS can do authentication,
> > > > but
> > > > > > all users that IIS authenticates are Windows users.  If you want to
> > > > strip
> > > > > > all www-authenticate headers except basic, the best way to do this is to
> > > > > > just turn off all authentication except basic.  That way, IIS won't ever
> > > > put
> > > > > > one there that's not for basic.
>
> > > > > > Thank you,
> > > > > > -Wade A. Hilmo,
> > > > > > -Microsoft
>
> > > > > > "dareag"  wrote in message
> > > > > >news:A47F16AF-64F9-47BA-BE48-6767842B878F@microsoft.com...
> > > > > > > I am using an ISAPI Filter in IIS 5.1 to remove all but 'Basic'
> > > > > > > WWW-Authenticate headers when windows login fails.
>
> > > > > > > I am using the 3rd consecutive 401 response to indicate a failure. Is
> > > > > > there
> > > > > > > a better way to catch a login failure? I'm doing it for
> > > > > > > SF_NOTIFY_SEND_RESPONSE notification.
>
> > > > > > > The reason I am doing this is to set up Basic authentication and use
> > > > local
> > > > > > > validation if there is no valid windows account on my server.
>
> > > > > > > Using this method windows accounts can log in , but non windows
> > > > accounts
> > > > > > get
> > > > > > > prompted for windows login and not my local login. Is removing the
> > > > > > > WWW-Authenticate headers and adding a Basic one going to work?
>
> > > > > > > Also when a windows user does login I want to run my isapi dll as the
> > > > > > > anonymous user; do you impersonate the anonymous user to do this?
>
> > > > > > > Many Thanks
>
> > > > > > > --
> > > > > > > regards Dave- Hide quoted text -
>
> > > - Show quoted text -- Hide quoted text -
>
> - Show quoted text -

Thanks for the response.
What if I had 2 virtual directories both pointing to the same dll; one using 
Integrated Authentication, and the other using Anonymous access. Would it be 
possible to redirect to the second virtual directory after detecting the 
first login failure?
 
That way the user is not authenticated on the first virtual directory, but 
is redirected and authenticated on the second virtual directory. (unless they 
have a valid windows account, and they're in).

Do you think this would be feasible?

I was thinking of monitoring the 401 responses in SF_NOTIFY_SEND_RESPONSE; 
if there are 2 consecutive 401 responses then there is a login failure, when 
that occurs somehow redirect to the other virtual directory and get that to 
display my local login prompt.

Would I be able to redirect from here? or do you have to be in 
PREPROC_HEADERS or AUTH_COMPLETE?
-- 
regards Dave 


"David Wang" wrote:

> In addition to what Wade says -- it is not possible to "check
> credentials before any login prompt is displayed" because you are
> asking to know the user's identity before authenticating to determine
> the user's identity -- and that is clearly an impossible catch-22.
> 
> NTLM does not side-step any of this. No authentication protocol
> sidesteps this. How browsers avoid the login prompt is to
> automatically "pre-authenticate" to the server.
> 
> Basic authentication does not pre-authenticate because that is a
> security vulnerability. Do you expect the browser to automatically
> pass your username/password to every single webserver that it talks
> to, just to possibly avoid the login prompt?
> 
> So, you cannot use Basic Authentication to get the username without
> the user seeing a login prompt from the browser. And you cannot get
> the username from NTLM until it successfully authenticates a Windows
> user identity.
> 
> Secure authentication protocols simply do not give you access to the
> username until authentication is complete. I understand that what you
> want to do *seems* easy, but like most things with security, the
> devil's in the details.
> 
> Most people imagine authentication as the browser remembering the
> user's name/password, then automatically sending over the username/
> password to the server, and then the server "looks up" the username to
> determine if it is a Windows user or not, and then determine what
> authentication protocol to use. However, that is simply not a standard
> protocol understood by any browser or server. Nor is the protocol safe
> nor secure, even if you make it over SSL.
> 
> 
> //David
> http://w3-4u.blogspot.com
> http://blogs.msdn.com/David.Wang
> //
> 
> 
> 
> 
> 
> On Mar 12, 3:01 am, dareag  wrote:
> > "I have seen that the browser does not break out of NTLM; I am now using
> > "Basic", and if there are no valid windows credentials redirect to a local
> > login.
> >
> > In PREPROC_HEADERS I still do not get any user credentials with GetHeader
> > using "authorization:", the user has to enter credentials at the login prompt
> > before any credentials are received. I really need to check credentials
> > before any login prompt is displayed.
> >
> > Is it only NTLM that will offer this functionallity?
> > --
> > regards Dave
> >
> >
> >
> > "David Wang" wrote:
> > > In your "fall-back" authentication scheme, how do you plan to
> > > distinguish between the expected 401s of the NTLM authentication
> > > protocol and the unexpected 401s of non-existing Windows user?
> >
> > > And are you sure that your browser agent is able to break out of NTLM
> > > authentication handshake to perform Basic authentication?
> >
> > > These are but some of the details that you must consider when you want
> > > to fabricate a custom authentication protocol by stitching together
> > > existing ones. In addition to knowing the existing protocols backwards
> > > and forwards. And the details of what headers/values get sent and when
> > > it is available. While ISAPI Filter can retrieve all those values,
> > > unfortunately you have to know when to do everything.
> >
> > > Also, it is not possible for an ISAPI Filter to change the
> > > impersonated user token of an NTLM-authenticated request. So you
> > > cannot run your DLL as anonymous when the remote user has a Windows
> > > account.
> >
> > > It sounds like what you are trying to do is:
> > > 1. Perform custom authentication protocol which involves trying NTLM
> > > and if the remote user does not have Windows account, try Basic.
> > > 2. And after authentication completes, run the request as anonymous
> > > user on the web server to handle the request
> > > 3. And re-use as much of the built-in code of IIS as possible in this
> > > new sequence.
> >
> > > //David
> > >http://w3-4u.blogspot.com
> > >http://blogs.msdn.com/David.Wang
> > > //
> >
> > > On Mar 9, 5:01 am, dareag  wrote:
> > > > Hi Wade
> > > > Thanks for the information!
> > > > Trying to implement this I use the function call
> > > > pfc->GetServerVariable(pfc,"HTTP_AUTHORIZATION",szAUTHORIZATION, &buffSize);
> > > > to get the authorization header. Only problem is, it is either empty or it
> > > > gives me the credentials of the last attempted login from the browser and not
> > > > the logged in user credentials.
> >
> > > > I tried using getheader with "Authorizatio" as a parameter, but this never
> > > > got populated with credentials.
> >
> > > > Any ideas.
> > > > Thanks
> > > > --
> > > > regards Dave
> >
> > > > "Wade A. Hilmo [MS]" wrote:
> >
> > > > > Hi Dave,
> >
> > > > > Each request to IIS gets one shot at authentication.  There is no concept of
> > > > > trying other types if the first one fails.
> >
> > > > > You might be able to approximate this in a filter, but only if you are using
> > > > > Basic authentication.  It would work like this:
> >
> > > > > Filter on SF_NOTIFY_PREPROC_HEADERS and look for an authorization header.
> > > > > If there is no authorization header, the request is anonymous.  If you want
> > > > > to allow anonymous access to the requested URL, then just return
> > > > > SF_STATUS_REQ_NEXT_NOTIFICATION.  If you don't want to allow anonymous
> > > > > authentication, then base64 decode the credentials from the authorization
> > > > > header and test them for validity by calling LogonUser or LogonUserEx.  If
> > > > > the credentials are not valid, then redirect the request to your login page.
> > > > > If the credentials are valid, and you want to allow them, then you need to
> > > > > set a flag that can be accessed through pFC->pFilterContext.  Finally, have
> > > > > your filter listen on SF_NOTIFY_AUTHENTICATION and check for the flag.  If
> > > > > you see the flag, then set the pszUser and pszPassword members of the passed
> > > > > structure to empty strings.  This will cause the request to run as
> > > > > anonymous.
> >
> > > > > Note that this mechanism cannot work with NTLM because NTML is a multi-leg
> > > > > authentication scheme.  So to complete an NTLM handshake, there are multiple
> > > > > requests where some 401 responses are by design, and some may indicate an
> > > > > authorization failure.  Also, NTLM authentication is not exposes to the
> > > > > SF_NOTIFY_AUTHENTICATION notification.
> >
> > > > > A few other notes:
> >
> > > > > Your requirement to redirect to a login page is what forces the need to use
> > > > > PREPROC_HEADERS.  You could test the user provided credentials from the
> > > > > AUTHENTICATION notification, but you could not do the redirection there.
> >
> > > > > If you care about server variables like REMOTE_USER, you should know that
> > > > > they are populated from the credentials in the Authorization header, and not
> > > > > from the credentials that you set in the AUTHENTICATION notification.  Using
> > > > > basic authentication allows you control of their contents by creating the
> > > > > base64 encoded credential string and setting it into the Authorization
> > > > > header in PREPROC_HEADERS.
> >
> > > > > There are probably a bunch of other implementation details that you will run
> > > > > into if you decided to do this.  This post is mainly just background
> > > > > information to let you know what you are dealing with.
> >
> > > > > Thank you,
> > > > > -Wade A. Hilmo,
> > > > > -Microsoft
> > > > > "dareag"  wrote in message
> > > > >news:B64F20F6-7972-4F01-8B2F-5A321BCE28EE@microsoft.com...
> > > > > > Hi Wade
> >
> > > > > > What I want to do is first try the windows credentials of the user who is
> > > > > > currently logged on to the machine. If that fails it will not be a windows
> > > > > > account that will access my application, it will be a local account that
> > > > > my
> > > > > > application stores in a database.
> >
> > > > > > So after the initial logon failure from windows I want to display my local
> > > > > > login dialog box, and not a windows logon dialog.
> >
> > > > > > What I did have working was to tell IIS to do anonymous authentication and
> > > > > > my dll would display my logon dialog; but if its a valid windows account
> > > > > that
> > > > > > is accessing my application then I want windows to authenticate them.
> >
> > > > > > Hope this makes it clearer. The user accessing my application may have
> > > > > > windows credentials or they may have my application credentials.
> >
> > > > > > The other point I was trying to ask was that if they were using windows
> > > > > > credentials I still want the dll to run as the anonymous user.
> >
> > > > > > Thanks
> > > > > > --
> > > > > > regards Dave
> >
> > > > > > "Wade A. Hilmo [MS]" wrote:
> >
> > > > > > > Hi Dave,
> >
> > > > > > > Can you please give some more detail about what you are trying to do?
> >
> > > > > > > Basic is one of several different ways that IIS can do authentication,
> > > > > but
> > > > > > > all users that IIS authenticates are Windows users.  If you want to
> > > > > strip
> > > > > > > all www-authenticate headers except basic, the best way to do this is to
> > > > > > > just turn off all authentication except basic.  That way, IIS won't ever
> > > > > put
> > > > > > > one there that's not for basic.
> >
> > > > > > > Thank you,
> > > > > > > -Wade A. Hilmo,
> > > > > > > -Microsoft
> >
> > > > > > > "dareag"  wrote in message
> > > > > > >news:A47F16AF-64F9-47BA-BE48-6767842B878F@microsoft.com...
> > > > > > > > I am using an ISAPI Filter in IIS 5.1 to remove all but 'Basic'
> > > > > > > > WWW-Authenticate headers when windows login fails.
> >
> > > > > > > > I am using the 3rd consecutive 401 response to indicate a failure. Is
> > > > > > > there
> > > > > > > > a better way to catch a login failure? I'm doing it for
> > > > > > > > SF_NOTIFY_SEND_RESPONSE notification.
> >
> > > > > > > > The reason I am doing this is to set up Basic authentication and use
> > > > > local
> > > > > > > > validation if there is no valid windows account on my server.
> >
> > > > > > > > Using this method windows accounts can log in , but non windows
> > > > > accounts
> > > > > > > get
> > > > > > > > prompted for windows login and not my local login. Is removing the
> > > > > > > > WWW-Authenticate headers and adding a Basic one going to work?
> >
> > > > > > > > Also when a windows user does login I want to run my isapi dll as the
> > > > > > > > anonymous user; do you impersonate the anonymous user to do this?
> >
> > > > > > > > Many Thanks
> >
> > > > > > > > --
> > > > > > > > regards Dave- Hide quoted text -
> >
> > > > - Show quoted text -- Hide quoted text -
> >
> > - Show quoted text -
> 
> 
>

NTLM Protocol without PreAuthentication can have two consecutive 401s
as a part of successful user login

Also, browsers tend to pop up the user login dialog box when it
encounters an unexpected 401 response.

Basic Protocol can have 401s if user enters wrong username/password
but succeed on subsequent retry.

How does your protocol distinguish between these use cases?

I caution against jumping into implementation without first crafting
the algorithm. Simply knowing the events will not help with
implementing your necessary algorithm.

Redirection is simply the browser auto-responding to the Location:
header of a 30X response. All Filter events up through
SF_NOTIFY_SEND_RAW_DATA can modify the perceived response by the
client in different ways - hence they can all redirect.

Of course, you want to redirect as soon as you have the necessary
information, but you have not determined what nor when you have that
information. So, asking about filter events is like the tail wagging
the dog...


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//






On Mar 13, 7:29 am, dareag  wrote:
> Thanks for the response.
> What if I had 2 virtual directories both pointing to the same dll; one using
> Integrated Authentication, and the other using Anonymous access. Would it be
> possible to redirect to the second virtual directory after detecting the
> first login failure?
>
> That way the user is not authenticated on the first virtual directory, but
> is redirected and authenticated on the second virtual directory. (unless they
> have a valid windows account, and they're in).
>
> Do you think this would be feasible?
>
> I was thinking of monitoring the 401 responses in SF_NOTIFY_SEND_RESPONSE;
> if there are 2 consecutive 401 responses then there is a login failure, when
> that occurs somehow redirect to the other virtual directory and get that to
> display my local login prompt.
>
> Would I be able to redirect from here? or do you have to be in
> PREPROC_HEADERS or AUTH_COMPLETE?
> --
> regards Dave
>
>
>
> "David Wang" wrote:
> > In addition to what Wade says -- it is not possible to "check
> > credentials before any login prompt is displayed" because you are
> > asking to know the user's identity before authenticating to determine
> > the user's identity -- and that is clearly an impossible catch-22.
>
> > NTLM does not side-step any of this. No authentication protocol
> > sidesteps this. How browsers avoid the login prompt is to
> > automatically "pre-authenticate" to the server.
>
> > Basic authentication does not pre-authenticate because that is a
> > security vulnerability. Do you expect the browser to automatically
> > pass your username/password to every single webserver that it talks
> > to, just to possibly avoid the login prompt?
>
> > So, you cannot use Basic Authentication to get the username without
> > the user seeing a login prompt from the browser. And you cannot get
> > the username from NTLM until it successfully authenticates a Windows
> > user identity.
>
> > Secure authentication protocols simply do not give you access to the
> > username until authentication is complete. I understand that what you
> > want to do *seems* easy, but like most things with security, the
> > devil's in the details.
>
> > Most people imagine authentication as the browser remembering the
> > user's name/password, then automatically sending over the username/
> > password to the server, and then the server "looks up" the username to
> > determine if it is a Windows user or not, and then determine what
> > authentication protocol to use. However, that is simply not a standard
> > protocol understood by any browser or server. Nor is the protocol safe
> > nor secure, even if you make it over SSL.
>
> > //David
> >http://w3-4u.blogspot.com
> >http://blogs.msdn.com/David.Wang
> > //
>
> > On Mar 12, 3:01 am, dareag  wrote:
> > > "I have seen that the browser does not break out of NTLM; I am now using
> > > "Basic", and if there are no valid windows credentials redirect to a local
> > > login.
>
> > > In PREPROC_HEADERS I still do not get any user credentials with GetHeader
> > > using "authorization:", the user has to enter credentials at the login prompt
> > > before any credentials are received. I really need to check credentials
> > > before any login prompt is displayed.
>
> > > Is it only NTLM that will offer this functionallity?
> > > --
> > > regards Dave
>
> > > "David Wang" wrote:
> > > > In your "fall-back" authentication scheme, how do you plan to
> > > > distinguish between the expected 401s of the NTLM authentication
> > > > protocol and the unexpected 401s of non-existing Windows user?
>
> > > > And are you sure that your browser agent is able to break out of NTLM
> > > > authentication handshake to perform Basic authentication?
>
> > > > These are but some of the details that you must consider when you want
> > > > to fabricate a custom authentication protocol by stitching together
> > > > existing ones. In addition to knowing the existing protocols backwards
> > > > and forwards. And the details of what headers/values get sent and when
> > > > it is available. While ISAPI Filter can retrieve all those values,
> > > > unfortunately you have to know when to do everything.
>
> > > > Also, it is not possible for an ISAPI Filter to change the
> > > > impersonated user token of an NTLM-authenticated request. So you
> > > > cannot run your DLL as anonymous when the remote user has a Windows
> > > > account.
>
> > > > It sounds like what you are trying to do is:
> > > > 1. Perform custom authentication protocol which involves trying NTLM
> > > > and if the remote user does not have Windows account, try Basic.
> > > > 2. And after authentication completes, run the request as anonymous
> > > > user on the web server to handle the request
> > > > 3. And re-use as much of the built-in code of IIS as possible in this
> > > > new sequence.
>
> > > > //David
> > > >http://w3-4u.blogspot.com
> > > >http://blogs.msdn.com/David.Wang
> > > > //
>
> > > > On Mar 9, 5:01 am, dareag  wrote:
> > > > > Hi Wade
> > > > > Thanks for the information!
> > > > > Trying to implement this I use the function call
> > > > > pfc->GetServerVariable(pfc,"HTTP_AUTHORIZATION",szAUTHORIZATION, &buffSize);
> > > > > to get the authorization header. Only problem is, it is either empty or it
> > > > > gives me the credentials of the last attempted login from the browser and not
> > > > > the logged in user credentials.
>
> > > > > I tried using getheader with "Authorizatio" as a parameter, but this never
> > > > > got populated with credentials.
>
> > > > > Any ideas.
> > > > > Thanks
> > > > > --
> > > > > regards Dave
>
> > > > > "Wade A. Hilmo [MS]" wrote:
>
> > > > > > Hi Dave,
>
> > > > > > Each request to IIS gets one shot at authentication.  There is no concept of
> > > > > > trying other types if the first one fails.
>
> > > > > > You might be able to approximate this in a filter, but only if you are using
> > > > > > Basic authentication.  It would work like this:
>
> > > > > > Filter on SF_NOTIFY_PREPROC_HEADERS and look for an authorization header.
> > > > > > If there is no authorization header, the request is anonymous.  If you want
> > > > > > to allow anonymous access to the requested URL, then just return
> > > > > > SF_STATUS_REQ_NEXT_NOTIFICATION.  If you don't want to allow anonymous
> > > > > > authentication, then base64 decode the credentials from the authorization
> > > > > > header and test them for validity by calling LogonUser or LogonUserEx.  If
> > > > > > the credentials are not valid, then redirect the request to your login page.
> > > > > > If the credentials are valid, and you want to allow them, then you need to
> > > > > > set a flag that can be accessed through pFC->pFilterContext.  Finally, have
> > > > > > your filter listen on SF_NOTIFY_AUTHENTICATION and check for the flag.  If
> > > > > > you see the flag, then set the pszUser and pszPassword members of the passed
> > > > > > structure to empty strings.  This will cause the request to run as
> > > > > > anonymous.
>
> > > > > > Note that this mechanism cannot work with NTLM because NTML is a multi-leg
> > > > > > authentication scheme.  So to complete an NTLM handshake, there are multiple
> > > > > > requests where some 401 responses are by design, and some may indicate an
> > > > > > authorization failure.  Also, NTLM authentication is not exposes to the
> > > > > > SF_NOTIFY_AUTHENTICATION notification.
>
> > > > > > A few other notes:
>
> > > > > > Your requirement to redirect to a login page is what forces the need to use
> > > > > > PREPROC_HEADERS.  You could test the user provided credentials from the
> > > > > > AUTHENTICATION notification, but you could not do the redirection there.
>
> > > > > > If you care about server variables like REMOTE_USER, you should know that
> > > > > > they are populated from the credentials in the Authorization header, and not
> > > > > > from the credentials that you set in the AUTHENTICATION notification.  Using
> > > > > > basic authentication allows you control of their contents by creating the
> > > > > > base64 encoded credential string and setting it into the Authorization
> > > > > > header in PREPROC_HEADERS.
>
> > > > > > There are probably a bunch of other implementation details that you will run
> > > > > > into if you decided to do this.  This post is mainly just background
> > > > > > information to let you know what you are dealing with.
>
> > > > > > Thank you,
> > > > > > -Wade A. Hilmo,
> > > > > > -Microsoft
> > > > > > "dareag"  wrote in message
> > > > > >news:B64F20F6-7972-4F01-8B2F-5A321BCE28EE@microsoft.com...
> > > > > > > Hi Wade
>
> > > > > > > What I want to do is first try the windows credentials of the user who is
> > > > > > > currently logged on to the machine. If that fails it will not be a windows
> > > > > > > account that will access my application, it will be a local account that
> > > > > > my
> > > > > > > application stores in a database.
>
> > > > > > > So after the initial logon failure from windows I want to display my local
> > > > > > > login dialog box, and not a windows logon dialog.
>
> > > > > > > What I did have working was to tell IIS to do anonymous authentication and
> > > > > > > my dll would display my logon dialog; but if its a valid windows account
> > > > > > that
> > > > > > > is accessing my application then I want windows to authenticate them.
>
> > > > > > > Hope this makes it clearer. The user accessing my application may have
> > > > > > > windows credentials or they may have my application credentials.
>
> > > > > > > The other point I was trying to ask was that if they were using windows
> > > > > > > credentials I still want the dll to run as the anonymous user.
>
> > > > > > > Thanks
> > > > > > > --
> > > > > > > regards Dave
>
> > > > > > > "Wade A. Hilmo [MS]" wrote:
>
> > > > > > > > Hi Dave,
>
> > > > > > > > Can you please give some more detail about what you are trying to do?
>
> > > > > > > > Basic is one of several different ways that IIS can do authentication,
> > > > > > but
> > > > > > > > all users that IIS authenticates are Windows users.  If you want to
> > > > > > strip
> > > > > > > > all www-authenticate headers except basic, the best way to do this is to
> > > > > > > > just turn off all authentication except basic.  That way, IIS won't ever
> > > > > > put
> > > > > > > > one there that's not for basic.
>
> > > > > > > > Thank you,
> > > > > > > > -Wade A. Hilmo,
> > > > > > > > -Microsoft
>
> > > > > > > > "dareag"  wrote in message
> > > > > > > >news:A47F16AF-64F9-47BA-BE48-6767842B878F@microsoft.com...
> > > > > > > > > I am using an ISAPI Filter in IIS 5.1 to remove all but 'Basic'
> > > > > > > > > WWW-Authenticate headers when windows login fails.
>
> > > > > > > > > I am using the 3rd consecutive 401 response to indicate a failure. Is
> > > > > > > > there
> > > > > > > > > a better way to catch a login failure? I'm doing it for
> > > > > > > > > SF_NOTIFY_SEND_RESPONSE notification.
>
> > > > > > > > > The reason I am doing this is to set up Basic authentication and use
> > > > > > local
> > > > > > > > > validation if there is no valid windows account on my server.
>
> > > > > > > > > Using this method windows accounts can log in , but non windows
> > > > > > accounts
> > > > > > > > get
> > > > > > > > > prompted for windows login and not my local login. Is removing the
> > > > > > > > > WWW-Authenticate headers and adding a Basic one going to work?
>
> > > > > > > > > Also when a windows user does login I want to run my isapi dll as the
> > > > > > > > > anonymous user; do you impersonate the anonymous user to do this?
>
> > > > > > > > > Many Thanks
>
> > > > > > > > > --
> > > > > > > > > regards Dave- Hide quoted text -
>
> > > > > - Show quoted text -- Hide quoted text -
>
> > > - Show quoted text -- Hide quoted text -
>
> - Show quoted text -

The NTLM authenticated link is completely extraneous here because
unauthorized people would step right around your security by going to your
anonymous link.  You would be better off just setting up the anonymous one.

Thank you,
-Wade A. Hilmo,
-Microsoft

"dareag"  wrote in message
news:6687023B-F7D2-45DA-9DC3-4D25309705FA@microsoft.com...
> Thanks for the response.
> What if I had 2 virtual directories both pointing to the same dll; one
using
> Integrated Authentication, and the other using Anonymous access. Would it
be
> possible to redirect to the second virtual directory after detecting the
> first login failure?
>
> That way the user is not authenticated on the first virtual directory, but
> is redirected and authenticated on the second virtual directory. (unless
they
> have a valid windows account, and they're in).
>
> Do you think this would be feasible?
>
> I was thinking of monitoring the 401 responses in SF_NOTIFY_SEND_RESPONSE;
> if there are 2 consecutive 401 responses then there is a login failure,
when
> that occurs somehow redirect to the other virtual directory and get that
to
> display my local login prompt.
>
> Would I be able to redirect from here? or do you have to be in
> PREPROC_HEADERS or AUTH_COMPLETE?
> -- 
> regards Dave
>
>
> "David Wang" wrote:
>
> > In addition to what Wade says -- it is not possible to "check
> > credentials before any login prompt is displayed" because you are
> > asking to know the user's identity before authenticating to determine
> > the user's identity -- and that is clearly an impossible catch-22.
> >
> > NTLM does not side-step any of this. No authentication protocol
> > sidesteps this. How browsers avoid the login prompt is to
> > automatically "pre-authenticate" to the server.
> >
> > Basic authentication does not pre-authenticate because that is a
> > security vulnerability. Do you expect the browser to automatically
> > pass your username/password to every single webserver that it talks
> > to, just to possibly avoid the login prompt?
> >
> > So, you cannot use Basic Authentication to get the username without
> > the user seeing a login prompt from the browser. And you cannot get
> > the username from NTLM until it successfully authenticates a Windows
> > user identity.
> >
> > Secure authentication protocols simply do not give you access to the
> > username until authentication is complete. I understand that what you
> > want to do *seems* easy, but like most things with security, the
> > devil's in the details.
> >
> > Most people imagine authentication as the browser remembering the
> > user's name/password, then automatically sending over the username/
> > password to the server, and then the server "looks up" the username to
> > determine if it is a Windows user or not, and then determine what
> > authentication protocol to use. However, that is simply not a standard
> > protocol understood by any browser or server. Nor is the protocol safe
> > nor secure, even if you make it over SSL.
> >
> >
> > //David
> > http://w3-4u.blogspot.com
> > http://blogs.msdn.com/David.Wang
> > //
> >
> >
> >
> >
> >
> > On Mar 12, 3:01 am, dareag  wrote:
> > > "I have seen that the browser does not break out of NTLM; I am now
using
> > > "Basic", and if there are no valid windows credentials redirect to a
local
> > > login.
> > >
> > > In PREPROC_HEADERS I still do not get any user credentials with
GetHeader
> > > using "authorization:", the user has to enter credentials at the login
prompt
> > > before any credentials are received. I really need to check
credentials
> > > before any login prompt is displayed.
> > >
> > > Is it only NTLM that will offer this functionallity?
> > > --
> > > regards Dave
> > >
> > >
> > >
> > > "David Wang" wrote:
> > > > In your "fall-back" authentication scheme, how do you plan to
> > > > distinguish between the expected 401s of the NTLM authentication
> > > > protocol and the unexpected 401s of non-existing Windows user?
> > >
> > > > And are you sure that your browser agent is able to break out of
NTLM
> > > > authentication handshake to perform Basic authentication?
> > >
> > > > These are but some of the details that you must consider when you
want
> > > > to fabricate a custom authentication protocol by stitching together
> > > > existing ones. In addition to knowing the existing protocols
backwards
> > > > and forwards. And the details of what headers/values get sent and
when
> > > > it is available. While ISAPI Filter can retrieve all those values,
> > > > unfortunately you have to know when to do everything.
> > >
> > > > Also, it is not possible for an ISAPI Filter to change the
> > > > impersonated user token of an NTLM-authenticated request. So you
> > > > cannot run your DLL as anonymous when the remote user has a Windows
> > > > account.
> > >
> > > > It sounds like what you are trying to do is:
> > > > 1. Perform custom authentication protocol which involves trying NTLM
> > > > and if the remote user does not have Windows account, try Basic.
> > > > 2. And after authentication completes, run the request as anonymous
> > > > user on the web server to handle the request
> > > > 3. And re-use as much of the built-in code of IIS as possible in
this
> > > > new sequence.
> > >
> > > > //David
> > > >http://w3-4u.blogspot.com
> > > >http://blogs.msdn.com/David.Wang
> > > > //
> > >
> > > > On Mar 9, 5:01 am, dareag  wrote:
> > > > > Hi Wade
> > > > > Thanks for the information!
> > > > > Trying to implement this I use the function call
> > > > > pfc->GetServerVariable(pfc,"HTTP_AUTHORIZATION",szAUTHORIZATION,
&buffSize);
> > > > > to get the authorization header. Only problem is, it is either
empty or it
> > > > > gives me the credentials of the last attempted login from the
browser and not
> > > > > the logged in user credentials.
> > >
> > > > > I tried using getheader with "Authorizatio" as a parameter, but
this never
> > > > > got populated with credentials.
> > >
> > > > > Any ideas.
> > > > > Thanks
> > > > > --
> > > > > regards Dave
> > >
> > > > > "Wade A. Hilmo [MS]" wrote:
> > >
> > > > > > Hi Dave,
> > >
> > > > > > Each request to IIS gets one shot at authentication.  There is
no concept of
> > > > > > trying other types if the first one fails.
> > >
> > > > > > You might be able to approximate this in a filter, but only if
you are using
> > > > > > Basic authentication.  It would work like this:
> > >
> > > > > > Filter on SF_NOTIFY_PREPROC_HEADERS and look for an
authorization header.
> > > > > > If there is no authorization header, the request is anonymous.
If you want
> > > > > > to allow anonymous access to the requested URL, then just return
> > > > > > SF_STATUS_REQ_NEXT_NOTIFICATION.  If you don't want to allow
anonymous
> > > > > > authentication, then base64 decode the credentials from the
authorization
> > > > > > header and test them for validity by calling LogonUser or
LogonUserEx.  If
> > > > > > the credentials are not valid, then redirect the request to your
login page.
> > > > > > If the credentials are valid, and you want to allow them, then
you need to
> > > > > > set a flag that can be accessed through pFC->pFilterContext.
Finally, have
> > > > > > your filter listen on SF_NOTIFY_AUTHENTICATION and check for the
flag.  If
> > > > > > you see the flag, then set the pszUser and pszPassword members
of the passed
> > > > > > structure to empty strings.  This will cause the request to run
as
> > > > > > anonymous.
> > >
> > > > > > Note that this mechanism cannot work with NTLM because NTML is a
multi-leg
> > > > > > authentication scheme.  So to complete an NTLM handshake, there
are multiple
> > > > > > requests where some 401 responses are by design, and some may
indicate an
> > > > > > authorization failure.  Also, NTLM authentication is not exposes
to the
> > > > > > SF_NOTIFY_AUTHENTICATION notification.
> > >
> > > > > > A few other notes:
> > >
> > > > > > Your requirement to redirect to a login page is what forces the
need to use
> > > > > > PREPROC_HEADERS.  You could test the user provided credentials
from the
> > > > > > AUTHENTICATION notification, but you could not do the
redirection there.
> > >
> > > > > > If you care about server variables like REMOTE_USER, you should
know that
> > > > > > they are populated from the credentials in the Authorization
header, and not
> > > > > > from the credentials that you set in the AUTHENTICATION
notification.  Using
> > > > > > basic authentication allows you control of their contents by
creating the
> > > > > > base64 encoded credential string and setting it into the
Authorization
> > > > > > header in PREPROC_HEADERS.
> > >
> > > > > > There are probably a bunch of other implementation details that
you will run
> > > > > > into if you decided to do this.  This post is mainly just
background
> > > > > > information to let you know what you are dealing with.
> > >
> > > > > > Thank you,
> > > > > > -Wade A. Hilmo,
> > > > > > -Microsoft
> > > > > > "dareag"  wrote in message
> > > > > >news:B64F20F6-7972-4F01-8B2F-5A321BCE28EE@microsoft.com...
> > > > > > > Hi Wade
> > >
> > > > > > > What I want to do is first try the windows credentials of the
user who is
> > > > > > > currently logge