chabge authentication protocol

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?
--
regards Dave

Re: chabge authentication protocol

On Feb 23, 7:58 pm, dareag 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

Re: chabge authentication protocol

On Feb 24, 12:28 am, "Kirit S=E6lensminde"
wrote:
> On Feb 23, 7:58 pm, dareag 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

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

Re: change authentication protocol

Thanks for the response.

Just to confirm, not all users will have an account in the AD domain. I
would like to acheive Single sign on, (SSO), where possible.

So I will allow NTLM first and then use Basic. I'm not sure about running 2
different VDIRs, I guess I'll need to try it. The other thought was to use a
filter to remove NTLM after the first 401 failure, and then get IIS to use
Basic so that I can validate against my local database.

Many Thanks

Dave
--
regards Dave


"DaveMo" wrote:

> On Feb 24, 12:28 am, "Kirit Sælensminde"
> wrote:
> > On Feb 23, 7:58 pm, dareag 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
>
>