Prev: weird problem with session object
Next: working with values returned via SQL
From: <-> on 28 Apr 2008 15:35
Hello,

This is a very belated followup to the below issue, I am the original
poster. I recently was creating a new OU structure and new security policy
and during testing it was noticed that in fact happened on a server that has
a web-app that uses Windows integrated authentication, which was a surprise
to me.

Does this "Log on Locally" policy also affect web-apps using Windows
Integrated Authentication?

Thanks.


---------------------------------------------------------
Basic Auth requires that the authenticating user have "login locally"
privilege on the server.

The reason that your changes to IUSR/VUSR/Web Anonymous group have no effect
is because those users are NOT used for basic auth (they are accounts used
for Anonymous auth)


The actual user accounts authenticating under Basic auth needs to have
"login locally" privilege.


--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//


<-> wrote in message news:OLg0S3e7EHA.3236(a)TK2MSFTNGP15.phx.gbl...


Hello,

We have a server that has IIS lockdown and basic authentication for a
website and when the server team applied a policy that restricted logon only
to administrators, no one was able to log into the application. The
application users are not actually logging in locally, so I am thinking that
there is something in the IIS definition that requires that they have this
privilege. In addition, we took the IUSR and VUSR accounts and also Web
anonymous (all "Web" groups local to the machines) and added them, and still
no luck. We added the Everyone group, and this resolved the problem. Is
there any way to preserve non Single Sign-on authentication and not have to
have the Everyone group with the log on locally user right?


Thanks.



 | 
Pages: 1
Prev: weird problem with session object
Next: working with values returned via SQL