A Happy New Year to all!

I built a corporate intranet site (ASP.NET, IIS 6.0, W2K3) that (until now)
was only used by domain users. The authentication mode was set to Integrated
Windows authentication, so clients could be easily identified
(Page.User.Identity / System.Security.Principal.WindowsIdentity ...).
Authentication btw is not the problem, but identification is, because every
user has its own personal profile stored in a database.

Now additional corporate users want to use the site, that do not have a
domain account. This new class of users can not be identified by their IP
addresses and the administration of individual server-local user accounts is
not wanted.

So I have to turn on "Anonymous" access. The problem is, if anonymous is
turned on, no NTLM handshake is done and therefore no "identity" is aquired
from the client - even if IWA is also checked.

How can it be achieved, that all existing and future domain users can use
the site as usual and only non-domain users must identify themselfs at a
custom page (without dismissing the browsers logon window and via a replaced
401 page because it is confusing)?

Clearly spoken, I want IIS to do IWA and if that fails, it should accept the
client as anonymous user instead of returning the 401 error that leads to the
browser logon process on the client.

Is there an "administrative" solution or do I have to write an ISAPI filter?
Is there any such ISAPI sample out there?

Thanks in advance!

On Jan 8, 1:51 am, Karsten <Kars***@discussions.microsoft.com> wrote:
Show quoteHide quoteThere is no such "fallback authentication protocol defined in a public/
free specification for IIS to implement/support, so what you want does
not exist as any easy switch.

When you check IWA and Anonymous in IIS, it means that IIS is allowed
to accept either IWA or Anonymous. It does not mean "try one and if it
fails, try the other" nor "try IWA before Anonymous" because no
authentication protocol works like that. By RFC specification, IIS can
only tell the web browser "I support Anonymous and IWA -- pick one and
talk with me".

The reason anonymous authentication happens even when IWA is checked
is this -- since the authentication options mean "choose one amongst
these choices" and anonymous authentication happens when nothing is
chosen, and most browsers send no authentication unless forced by the
server, whenever you allow Anonymous, it will supercede any other
authentication selected on the server.

Before you even jump to ISAPI Filter or asking for sample code, you
will have to figure out your authentication protocol itself. There are
many problems with your proposed 'fallback authentication protocol",
starting with the fact that no browser and server work like that.
Also, the protocol would have problems distinguishing between a user
punching in a wrong username/password and a user who is not in the
domain and should be anonymous.

In general, I think it is easier for you to get legitimate accounts to
those "other corporate users" so that you can leverage your existing
authentication process. It is certainly less technically challenging
solution than crafting a "fallback authentication protocol" using a
technology like ISAPI Filter with zero sample code and support code.

Yes, many people have asked for many variations of "fallback/
fallforward authentication protocol", usually trying to expose their
Intranet app to the Internet or other non-domain-associated groups of
people. The solution in those cases is to create two websites pointing
to the same application, one for Intranet access with one
authentication protocol, and the other for Internet access with
another authentication protocol. If intranet user goes to the Internet
website, they are treated as external.


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

Many thanks to you David!

Sure, you are right and we discussed that already:
...but the customer did not want that.

I think the 2-website-solution is most pragmatic, the more so as it would be
ready to use immediately. Thank you.

Karsten

On Jan 8, 3:58 am, Karsten <Kars***@discussions.microsoft.com> wrote:
Show quoteHide quoteWell, then feel free to charge the customer a lot of money for trying
to figure out a fallback authentication protocol because it is not
going to be easy. Maybe that will convince the customer...

If the customer does not believe you and thinks that such a design is
easy... then he/she should feel free to do it themself and see the
truth!


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

Managing IP restrictions in IIS 6.0 - nightmare!
Multiple website in single IP, host header and SSL problem
configure host name? localhost to localhost/(dir)
IIS Always asking for credentials
Delegation: IIS Server setup in typical 3-tier scenario.
IIS authentication (kerberos and Integrated security)
ISAPI filter with Basic Authentication and Asp.net impersonation
Extranet Authentication
The minimum right to be granted at user to manage IIS
Re: Authentication prompts with wrong domain