# Enable Windows Authentication on website, allow only some users

I am investigating this problem. I have a CGI application that I publish through a website published in IIS7.

EDIT: I changed the web.config to use url authorization. This is the web.config of a folder called secure and this is the web.config of that specific folder

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<security>
<authorization>
<remove users="*" roles="" verbs="" />
</authorization>
</security>
</system.webServer>
</configuration>


With that config it is not working but if I remove the Deny it is working again, maybe rule order?

I changed website configuration in order to use windows authentication and then deny to all users but one with the current web.config

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<directoryBrowse enabled="false" />
</system.webServer>
<system.web>
<authentication mode="Windows">
</authentication>
<authorization>
<allow users="MYDOMAIN\myname2"/>
<deny users="?"/>
<deny users="*"/>
<deny users="MYDOMAIN\myname"/>
</authorization>
</system.web>
</configuration>


Unfortunately I can access the application both with myname and myname2 (both the published cgi and the IIS welcome page).

Any hint on how to configure it? Thanks!

EDIT: I have found this post IIS7: How to block access with a web.config file? where it marks web.config as

>   <system.webServer>
>       <security>
>           <authorization>
>               <remove users="*" roles="" verbs="" />
>           </authorization>
>       </security>   </system.webServer>


but the cgi keeps on being executed

• Could you control access through NTFS permissions rather than the web.config file? – Lee Tickett Jan 17 '12 at 17:29

System.Web stuff applies to ASP.Net, and uses the .Net authorization model. Based on your use of CGI, I'm not sure that's entirely appropriate here.

The System.WebServer authorization stuff works with IIS' native URL Authorization module, and should apply to CGI.

That assumes it's installed, though - ensure it is first, and you should also have a GUI icon for configuring it, which might help nut out the problem.

Additionally, you can use Failed Request Tracing to work out why each item is working as it is - see this article for an example of tracing 200-399 status codes (eg, not-failed traces) using FREB.

More on URL Authorization here.

• I edit the question. Could you have a look? – Mauro Jan 20 '12 at 10:21
• Is DOMAIN\MyRole a group? Try making it the user= condition instead? Are you configuring it through the GUI? – TristanK Jan 20 '12 at 10:55
• No, apparently the deny clause for all ovverrides every rule!!! So if it is not allowed is denied by defualt. Makes it sense to you? – Mauro Jan 20 '12 at 11:06
• Interesting, that's not how I read the documentation. A Deny at a parent level definitely should, but at the same level, it should be done in the order listed, AFAIK. – TristanK Jan 20 '12 at 11:07