Web Application Policies
Since we have lots of policies this wave, web app policies sometimes get overlooked or misunderstood. They are not the same as information policies which are more focused on data in lists and libraries. Web App policies are designed around rights to the web app as a whole. Here are a few examples... As you look through these imagine how much time it would take to change perms on every site collection on the web app.
You have an employee only portal you want to expose to the internet, but you only want employees to access it. You don't want anyone to accidentally allow "authenticated users" and allow contractors and vendors access or even partner access. So you create a web app policy to *deny* the security group which includes contractors, vendors, and partners.
Your legal team needs to do a search to ensure that a document was not leaked across your environment, but they can't tell you about it. You setup a web application policy to the elite legal security group to have *read only* access.
You have a temp who is going to be migrating a bunch of content across a number of site collections to a web app. You give him full control on the web app and the ones he's migrating to, but *deny* to all others.
You'll notice even the crawl account is a good use of a web app policy. With read access the crawl account can easily get at what it needs without exposing those permissions on each site collection at risk of it getting removed.
A user asked a question.... "I've noticed that if I apply a deny all policy for a web application, it effectively breaks any anonymous access specified on any site associated with that web application.
It doesn't grey out the anonymous access checkboxes, it just uncheck them and ignores (without error) any anonymous access I try to grant. Is this a bug?"
My thoughts.... Anonymous is an authentication mechanism. If you don't want to authenticate users (by using anonymous) Then how do you expect to deny specific users if you don't know who they are? So if you don't want to force users to log in for read access... how will you know who they are to deny them? Works for NTLM or basic, etc...
The alternative is to go into IIS MMC security and deny IPs, ranges or subnets. That's really one of the few things you can do if you don't know the account. The other alternative is machine accounts. That's even less likely to be known. Even your firewall won't know the account until you ask for it. Once they attempt to login, then the “deny” has an opportunity to work when combined with anonymous access.
