On Feb 23, 7:58 pm, dareag <dar...@discussions.microsoft.com> wrote:
> I have an ISAPI dll that uses basic authentication, validating users in a
> local database. I want to fist try and authenticate users using windows
> authentication; if this fails, (ie they do not have a windows account), I
> want to use the previous method of authenticating.
>
> How do I do this? Can I try NTLM and then revert to Basic. I tried using
> 'Integrated Windows Authentication', but I couldn't see how to force Basic
> afterwards. I also need the dll to run as the anonymous user, so that the
> user has the correct directory permissions.

>
> I guess the alternative is to let the user determine which account to
> authenticate against. If I did this would it still be anonymouse access?

<kirit.saelensmi...@gmail.com> wrote:
> On Feb 23, 7:58 pm, dareag <dar...@discussions.microsoft.com> wrote:
>
> > I have an ISAPI dll that uses basic authentication, validating users in=
a
> > local database. I want to fist try and authenticate users using windows
> > authentication; if this fails, (ie they do not have a windows account),=
I
> > want to use the previous method of authenticating.
>
> > How do I do this? Can I try NTLM and then revert to Basic. I tried using
> > 'Integrated Windows Authentication', but I couldn't see how to force Ba=
sic
> > afterwards. I also need the dll to run as the anonymous user, so that t=
he
> > user has the correct directory permissions.
>
> Our FOST.3 framework does this. Every user has credentials information
> stored in the database. If the user is registered as an Active
> Directory/local user then the framework returns its own 401 response
> triggering IIS to check the credentials against the users using basic
> authentication/NTLM or whatever other authentication protocols are set
> up for IIS.
>
> If the user is registered such that the password is in the database
> then this password is checked by the framework. For active directory/
> local users IIS informs you of the authenticated user in the server
> variables.
>
> In both cases a cookie set on the browser session (database users
> could have a longer cookie) to tell the framework how the user is
> authenticating.
>
> There are a number of details that need to be right to make it secure,
> but that's the gist of it.
>
>
>
> > I guess the alternative is to let the user determine which account to
> > authenticate against. If I did this would it still be anonymouse access?
>
> We also allow anonymous access to the site. If you're going to be
> using the normal log in process seen on most web sites then this will
> look to IIS like anonymous access and you have to check the user
> settings on each page request.
>
> It should also be possible to write an authentication plug-in to IIS,
> but it's not something we've really looked at. I suspect it'll be a
> lot more complex than the way we've done it.
>
> K

"DaveMo" wrote:

> On Feb 24, 12:28 am, "Kirit Sælensminde"
> <kirit.saelensmi...@gmail.com> wrote:
> > On Feb 23, 7:58 pm, dareag <dar...@discussions.microsoft.com> wrote:
> >
> > > I have an ISAPI dll that uses basic authentication, validating users in a
> > > local database. I want to fist try and authenticate users using windows
> > > authentication; if this fails, (ie they do not have a windows account), I
> > > want to use the previous method of authenticating.
> >
> > > How do I do this? Can I try NTLM and then revert to Basic. I tried using
> > > 'Integrated Windows Authentication', but I couldn't see how to force Basic
> > > afterwards. I also need the dll to run as the anonymous user, so that the
> > > user has the correct directory permissions.
> >
> > Our FOST.3 framework does this. Every user has credentials information
> > stored in the database. If the user is registered as an Active
> > Directory/local user then the framework returns its own 401 response
> > triggering IIS to check the credentials against the users using basic
> > authentication/NTLM or whatever other authentication protocols are set
> > up for IIS.
> >
> > If the user is registered such that the password is in the database
> > then this password is checked by the framework. For active directory/
> > local users IIS informs you of the authenticated user in the server
> > variables.
> >
> > In both cases a cookie set on the browser session (database users
> > could have a longer cookie) to tell the framework how the user is
> > authenticating.
> >
> > There are a number of details that need to be right to make it secure,
> > but that's the gist of it.
> >
> >
> >
> > > I guess the alternative is to let the user determine which account to
> > > authenticate against. If I did this would it still be anonymouse access?
> >
> > We also allow anonymous access to the site. If you're going to be
> > using the normal log in process seen on most web sites then this will
> > look to IIS like anonymous access and you have to check the user
> > settings on each page request.
> >
> > It should also be possible to write an authentication plug-in to IIS,
> > but it's not something we've really looked at. I suspect it'll be a
> > lot more complex than the way we've done it.
> >
> > K
>
> Hi Dave,
>
> Will your users that have a valid AD account be connecting through
> workstations that are joined to the domain? I'm trying to understand
> whether you would like to preserve the good user experience of
> intranet SSO that you normally get with AD credentials in this
> scenario.
>
> If so then you want to try NTLM first (anonymous not allowed). This
> allows IIS to challenge the browser session for default creds that
> might work. If the default creds don't work, i.e. the user's not
> logged on with his AD creds. Before IIS returns an error for
> unauthenticated access you'd want to trap that and instead initiate a
> Basic logon sequence via a redirect to another page. I think I would
> probably prefer forms-based authentication for the scenario, but
> that's up to you of course.
>
> I don't know if you have to do something like create two versions of
> the app in two different VDIRs in order to make this work. I've had
> that thought before when trying to figure out how to make IIS use two
> completely different forms of AuthN but have never gone through the
> process of trying to set it up to see how it works.
>
> HTH.
>
> Dave
>