Doru,

You are almost there!

The error message is saying that there were elements in the web.config in the sub directory that ASP.NET expects only in the root web.config of an application. Now, you don't want to create a new application in that sub directory because that would ruin the scope of the forms authentication cookies. So the alternative is to remove the web.config from the sub directory and add a location element to your root web.config.

Here is a sample of one of my root web.configs:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
	<location path="Admin">
		<system.web>
			<authorization>
				<allow users="someone@somewhere.com" />
				<allow roles="SuperAdmin" />
				<deny users="*" />
			</authorization>
		</system.web>
	</location>
	<location path="Developer">
		<system.web>
			<authorization>
				<allow users="someone@somewhere.com" />
				<allow roles="Developer" />
				<deny users="*" />
			</authorization>
		</system.web>
	</location>
	<location path="TimeAndBilling">
		<system.web>
			<authorization>
				<allow users="someone@somewhere.com" />
				<allow roles="SuperAdmin" />
				<deny users="*" />
			</authorization>
		</system.web>
	</location>
	<location path="UserAccount">
		<system.web>
			<authorization>
				<deny users="?" />
			</authorization>
		</system.web>
	</location>
	<location path="RealEstate">
		<system.web>
			<authorization>
				<allow users="someone@somewhere.com" />
				<allow roles="SuperAdmin, RealEstateAdmin" />
				<deny users="*" />
			</authorization>
		</system.web>
	</location>
	<system.web>
		<!-- <httpRuntime maxRequestLength="140000"/> -->
		<!--  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="RemoteOnly" defaultRedirect="http://tms-us.com/error/error.aspx">
			<error statusCode="500" redirect="http://tms-us.com/error/error500.aspx" />
			<error statusCode="404" redirect="http://tms-us.com/error/error404.aspx" />
		</customErrors>
		<!--  AUTHENTICATION 
          This section sets the authentication policies of the application. Possible modes are "Windows", 
          "Forms", "Passport" and "None"
    -->
		<authentication mode="Forms">
			<forms loginUrl="~/Login.aspx" name="TechnicalMarketingSolutionsAuth" protection="All"
				timeout="30" path="/" />
		</authentication>
		<!-- <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="*" />
			<!--  <allow     users="[comma separated list of users]"
                             roles="[comma separated list of roles]"/>
                  <deny      users="[comma separated list of users]"
                             roles="[comma separated list of roles]"/>
            -->
		</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 posted the entire file because I know that seeing only fragments can sometimes be disorienting. The key portion of the file is the location elements. These are the guys that protect the sub directories from unauthenticated and unauthorized users.

You'll notice that the root authorization element - the one that is not inside a location element - is wide open. This covers the root directory where the login.aspx is located. I don't want to exclude anyone from attempting to log in!

Normally, the root authorization element would cover all of the sub directories as well. But in this case, there are location elements, which override the root authorization element for the path specified in each one.

You'll also notice that I am using both an allow roles element and an allow users element in the authorization elements. This is a back-door in case my roles table in the database gets messed up. These are followed immediately by a deny users = * element, which would seem to override the allow elements and make the whole thing useless. But since all of the elements are on the same hierarchal level within the authorization element, none take precedence over the others.

But here's a final gotcha. ASP.NET, in its infinite wisdom, will ignore everything after a deny users = * inside the authorization element. Therefore, the deny users = * must appear last.

So, in conclusion, you're best bet is to get rid of the web.config file in the sub directory and use the location element in the root web.config.

>Hi Cathi,
>I had success with adding a sub directory to the project and a form in it, and I could navigate between the forms in the application root directory and the form in the subdirectory. However, as soon as I add a web.config file in the subdir I get an error when I try to navigate to the form:
>
>It is an error to use a section registered as allowDefinition='MachineToApplication' beyond application level. This error can be caused by a virtual directory not being configured as an application in IIS.
>Source Error:
>Line 52: lt authentication mode="Windows" /gt
>
>
>I looked at the location tag in web.config as Eugenio suggested - that seems to use one config for different settings in different directories.
>In all, I'm totally confused...
>I thought this should be the simplest thing:
>- the root dir containing forms accessible to all users (including login and registration forms)
>- the 'members' sub directory with forms that require authentication
>I notice you said 'forms authentication at the root directory' - that seems the oposite to what I thought, but in the end I stil won't know how to set it up...
>
>
>
>>Hi Doru,
>>
>>If I am understanding you correctly, you don't want to create two ASP.NET projects. When you do that you have two separate virual directories and you will not be able to treat them as one application. You set forms authentication at the root directory of the application then you can have different web.config files for each directory that have different rights associated with the files contained in them. One ASP.NET project can have multiple web.config files associated with it by placing them in the different subfolders.