1

I'm trying to secure an MVC.NET site on IIS7.5 with basic authentication. I'd rather not setup an entire windows account for this as I don't want the user to have that much privilege. I also don't want to implement a data driven authentication solution. I just want quick way to create a user that can only gain access to the website and nothing else.

Is there a way to do this by storing the credentials in the web.config file? Or use the IIS Managed users? The managed users seem like overkill as I don't want the user to actually be able to manage the site, just gain access to view it.

LaserJesus
  • 133
  • 2
  • 8

2 Answers2

2

If I remember correctly you can store the credentials for users directly in the web.config file but only when used in combination with the Forms Authentication Provider.

It really isn't recommended to store credentials like this, especially when you could easily setup the default ASP.NET Membership provider to use a local SQLCE instance.

<authentication mode="Forms"> 
    <forms name=".ASPNETAUTH"> 
        <credentials passwordFormat="Clear"> 
             <user name="test" password="test"/> 
        </credentials> 
    </forms> 
</authentication>
Brent Pabst
  • 6,069
  • 2
  • 24
  • 36
  • Doen't this answer mean that one is running forms-auth and there is not running basic-auth. / HTTP-auth.? Or can I use forms-auth provide HTTP-Auth.? Thought this won't work. – Marc Jun 13 '13 at 06:47
1

Most of the built-in IIS authentication methods use Windows accounts in some way or another, so if you don;t want to do any major work for this, you are going to have to use these -- you will want to create accounts that are reasonably locked down.

It is usually sufficient to:

  1. create a group (e.g. Web Users)
  2. add the individual accounts to that group
  3. remove the accounts from Users (which effectively gets rid of a lot of the default permissions)
  4. give the Web Users group read permissions to the web site folder (and selectively any modify permissions required -- e.g. upload directories)
  5. add the group to the relevant 'Deny...' entries in Local Security Policy / User Rights Assignment

Optionally, you might want to add recursive deny full control ACEs for that group to the disks, registry hives and any other DACL-driven resources -- SetACL should be able to do most of them (see http://helgeklein.com/).

If you really must use a custom list of users, then (as @BrentPabst said) Forms Authentication is the only real way (see http://msdn.microsoft.com/en-us/library/da0adyye.aspx), but you will need to create the ASP.NET login page.

I've not tried IIS Manager Authentication but, from what I can see, it only applies to FTP sites, not Web Sites.

J.

jimbobmcgee
  • 2,675
  • 4
  • 27
  • 43
  • I discovered this doesn't work very well because without users group, the user can't traverse C:\ and so can't get to C:\inetpub\wwwroot. – joshudson May 26 '20 at 21:33
  • @joshudson - this is typically controlled by the *[Bypass traverse checking](https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/bypass-traverse-checking)* user right. The default for this includes *Everyone*, which means group membership is usually not a problem for traversing C:\ to C:\inetpub\wwwroot (unless you use an anonymous user account explicitly excluded from *Everyone*). Permissions on wwwroot itself are more important (see point 4). – jimbobmcgee May 27 '20 at 19:22