Windows Authorization

[tshad]

I am trying to set up an intranet at work that will use our Active directory
to authorize our users. We also want them to access the site from the
outside (such as at home) and also be authenticated by our Active Directory.

We don't want to set up a separate Sql setup.

I tried to set up my Web.config file like so:

**********************************************************
<?xml version="1.0" encoding="utf-8" ?>
<configuration>

<!-- DYNAMIC DEBUG COMPILATION
Set compilation debug="true" to insert debugging symbols (.pdb
information)
into the compiled page. Because this creates a larger file that
executes
more slowly, you should set this value to true only when debugging
and to
false at all other times. For more information, refer to the
documentation about
debugging ASP.NET files.
-->
<compilation defaultLanguage="vb" debug="true" />

<!-- CUSTOM ERROR MESSAGES
Set customErrors mode="On" or "RemoteOnly" to enable custom error
messages, "Off" to disable.
Add <error> tags for each of the errors you want to handle.
-->
<customErrors mode="Off" />

<!-- AUTHENTICATION
This section sets the authentication policies of the application.
Possible modes are "Windows",
"Forms", "Passport" and "None"
-->
<authentication mode="Windows"/>


<!-- AUTHORIZATION
This section sets the authorization policies of the application.
You can allow or deny access
to application resources by user or role. Wildcards: "*" mean
everyone, "?" means anonymous
(unauthenticated) users.
-->
<authorization>
allow users="*" />
</authorization>

<!-- APPLICATION-LEVEL TRACE LOGGING
Application-level tracing enables trace log output for every page
within an application.
Set trace enabled="true" to enable application trace logging. If
pageOutput="true", the
trace information will be displayed at the bottom of each page.
Otherwise, you can view the
application trace log by browsing the "trace.axd" page from your
web application
root.
-->
<trace enabled="false" requestLimit="10" pageOutput="false"
traceMode="SortByTime" localOnly="true" />


<!-- SESSION STATE SETTINGS
By default ASP.NET uses cookies to identify which requests belong
to a particular session.
If cookies are not available, a session can be tracked by adding a
session identifier to the URL.
To disable cookies, set sessionState cookieless="true".
-->
<sessionState
mode="InProc"
stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString="data source=127.0.0.1;user id=sa;password="
cookieless="false"
timeout="20"
/>

<!-- GLOBALIZATION
This section sets the globalization settings of the application.
-->
<globalization requestEncoding="utf-8" responseEncoding="utf-8" />

</system.web>

</configuration>
***********************************************************

I also set the Web Application to Integrated Windows security.

But when I try to access first page, it lets me without asking my
credentials.

What else do I need to do to get this to work?

Thanks,

Tom

 

[Riki]

<authorization>
allow users="*" />
</authorization>

This means: access to all users.

Change it to:

<authorization>
allow users="*" />
deny users="?" />
</authorization>

Riki

 

[Erik Funkenbusch]

<authorization>
allow users="*" />
</authorization>

This means: access to all users.

Change it to:

<authorization>
allow users="*" />
deny users="?" />
</authorization>
Riki

Actually, the deny should be first. The way ASP.NET does things is that it
only processes rules until it reaches one that succeeds. Since you list
allow users="*", which means allow everybody, that rule will be evaluated
first, and since this will succeed, it will not evaluate the second rule to
deny unauthenticated users.

 

[tshad]

Actually, the deny should be first. The way ASP.NET does things is that it
only processes rules until it reaches one that succeeds. Since you list
allow users="*", which means allow everybody, that rule will be evaluated
first, and since this will succeed, it will not evaluate the second rule to
deny unauthenticated users.

I did make the change (there was a small error where is was missing the left
angle bracket) but I am still able to get to the home page with out any
logon screen from windows.

Is there something else I need to do?

Remember, I am at home and trying to log on, so it should be asking be for a
logon.

Thanks,

Tom

 

[Erik Funkenbusch]

I did make the change (there was a small error where is was missing the left
angle bracket) but I am still able to get to the home page with out any
logon screen from windows.

Is there something else I need to do?

Remember, I am at home and trying to log on, so it should be asking be for a
logon.

Your web.config you posted is not valid. For example, you have a closing
</system.web> but no opening one.

It's hard to say what your problems are with incomplete information.

 

[Riki]

How are you testing, with IIS or with the Cassini webserver from VS2005?
The latter will use the credentials of the logged on user for running
ASP.NET.

 

[tshad]

How are you testing, with IIS or with the Cassini webserver from VS2005?
The latter will use the credentials of the logged on user for running
ASP.NET.

I am running from IIS on the Windows 2003 Web Server Edition.

Tom

 

[Erik Funkenbusch]

I am running from IIS on the Windows 2003 Web Server Edition.

Is the web server a member of the domain?

 

[tshad]

Your web.config you posted is not valid. For example, you have a closing
</system.web> but no opening one.

It's hard to say what your problems are with incomplete information.

You're right.

Not sure why I missed that.

It now asks for authentication outside and inside. But there are a couple
of anomalies.

One is that it doesn't ask for the logon on the home page, but it does for
all the other pages. They are all in the same root folder. The home page
is index.htm and not index.aspx - is this the reason?

On the inside (at work) we are already logged onto the network, but it still
asks us to log on.

The other problem is that I and a couple others only have to put in our
logon names and others have to put in the Domain/logon.

Not sure why that is. I can log in outside and inside without the Domain.

Also, for those that try to login and cannot, they get back the website name
as the Domain (which I assume is why their logon fails -
intranet.ft.com/jfranks). But if they put in the actual domain
(ft0/jfranks), it works fine.

Thanks,

Tom

 

[tshad]

Is the web server a member of the domain?

Yes.

As I mentioned in my other post a couple of minutes ago, I was missing the
<system.web>, which fixed that problem.

It is part of the Domain. And some can connect without putting in the
domain name and some people have to put the domain name in.

The Domain is (either ft0 or ft.com) and both allow users to logon. But if
a person is not able to logon, it redisplays as intranet.ft.com\jfranks
(which is intranet domain\logon). They then need to put in ft.com\jfranks
or ft0\jfranks to log on.

Tom

 

[Erik Funkenbusch]

One is that it doesn't ask for the logon on the home page, but it does for
all the other pages. They are all in the same root folder. The home page
is index.htm and not index.aspx - is this the reason?

Yes. The ASP.NET security system only works with resources that are mapped
throught the asp.net isapi module. htm files are handled natively by IIS
unless you map them specifically.

It's best to probably just rename your htm file as aspx (even though it
doesn't contain any aspx).

On the inside (at work) we are already logged onto the network, but it still
asks us to log on.

You want to enable Windows Integrated Authentication in the IIS web site.
Open IIS Manager, right click on the wewbsite, and choose properties. Then
go to the Directory Security tab and edit the access control. You might
also need to enable digest (don't recall off hand)

The other problem is that I and a couple others only have to put in our
logon names and others have to put in the Domain/logon.

That's not an easy problem to solve. The only way I was able to
effectively solve it is to not use integrated authentication and instead
use forms authentication and deal with it myself. I don't know if you're
using ASP.NET 2.0 or 1.x, if 2.0 then you can use the
ActiveDirectoryMembershipProvider to authenticate against AD both an and
out. But it will take more work to have it auto-authenticate from inside.

 

[tshad]

Yes. The ASP.NET security system only works with resources that are
mapped
throught the asp.net isapi module. htm files are handled natively by IIS
unless you map them specifically.

It's best to probably just rename your htm file as aspx (even though it
doesn't contain any aspx).

Thought so.

As you suggested, changing to aspx and adding it into the default document
list solved the problem.

You want to enable Windows Integrated Authentication in the IIS web site.
Open IIS Manager, right click on the wewbsite, and choose properties.
Then
go to the Directory Security tab and edit the access control. You might
also need to enable digest (don't recall off hand)

The site was already set as Windows Integrated Authentication, but didn't
have the Digest selected. I tried selecting that, but it didn't solve the
problem. We still have to log on.

I assume it is because it is trying to use the wrong domain for some users.
It seems to be using the Web Site Name as the Domain instead of the Server
Domain (intranet.ft.com instead of ft.com). This is what comes up when it
fails (intranet.ft.com/jfranks instead of ft.com/jfranks).

That's not an easy problem to solve. The only way I was able to
effectively solve it is to not use integrated authentication and instead
use forms authentication and deal with it myself. I don't know if you're
using ASP.NET 2.0 or 1.x, if 2.0 then you can use the
ActiveDirectoryMembershipProvider to authenticate against AD both an and
out. But it will take more work to have it auto-authenticate from inside.

I am using ASP.Net 1.1 (haven't converted to 2.0 yet).

I don't want to use Forms Authentication as it would mean having to deal
with 2 sets of logons (one in AD and the other in Sql) which is a problem as
people change passwords, leave the company or are hired.

Thanks,

Tom

 

[Erik Funkenbusch]

The site was already set as Windows Integrated Authentication, but didn't
have the Digest selected. I tried selecting that, but it didn't solve the
problem. We still have to log on.

You may have to add the site to the trusted or local intranet zone.

I assume it is because it is trying to use the wrong domain for some users.
It seems to be using the Web Site Name as the Domain instead of the Server
Domain (intranet.ft.com instead of ft.com). This is what comes up when it
fails (intranet.ft.com/jfranks instead of ft.com/jfranks).

No, that's just the "realm", which is largely ignored.

I am using ASP.Net 1.1 (haven't converted to 2.0 yet).

I don't want to use Forms Authentication as it would mean having to deal
with 2 sets of logons (one in AD and the other in Sql) which is a problem as
people change passwords, leave the company or are hired.

No, it doesn't mean that at all. Forms authentication does not require
SQL.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/SecNetHT02.asp

 

[tshad]

You may have to add the site to the trusted or local intranet zone.

Did that and that solved the problem.

Is there a way to globally change it on all Browsers without having to go
into each browser and make the change?

No, that's just the "realm", which is largely ignored.

Sounds like some sort of Medieval lands or something.

 

[Erik Funkenbusch]

Did that and that solved the problem.

Is there a way to globally change it on all Browsers without having to go
into each browser and make the change?

That's what group policy is for. If you don't know what that is, then ask
your network administrator to add the site to the trusted or local intranet
zones in the group policy or domain security policy file.