Microsoft Office Tutorials and References
In Depth Information
AMBIDEXTROUS
When you enable claims-based authentication for a web application, it is able to support several
authentication types simultaneously: forms-based authentication, which can simply use a SQL
database to contain usernames instead of Active Directory; trusted provider authentication, which
takes advantage of Active Directory Federated Services (ADFS) if you’re using it in your
environment; and Windows authentication, which uses NTLM, Kerberos, or Basic. This means for one
claims-based web application, you can use all of the authentication types. Not only that, but with
Windows authentication alone you can enable NTLM, Kerberos, and Basic authentication access for
one zone (try that with classic mode). Being able to support NTLM alongside the other authentication
types should assist Search in accessing the web application’s content and indexing it.
The Public URL section is interesting. Like many settings in SharePoint, this one has a
particular use if some other technology is configured elsewhere. The Public URL is the
address that users are supposed to use to access the site, is the address returned to the
browser of the users if they successfully access the site, and is the address that will be at
the beginning of all links contained in the web application. This setting is also used for
load balancing; it actually used to be called the Load Balanced URL in previous versions of
SharePoint. Microsoft didn’t change that capability of this setting, just its name. In other
words, when you have more than one SharePoint front-end server in the server farm, it
is assumed that some load-balancing technology will be employed to balance the load
of requests to the servers. The load balancer (be it hardware or software) will intercept
the traffic to the public URL and route it to the appropriate SharePoint server in the
loadbalanced cluster. Therefore, there must be one URL that each SharePoint server knows is
the primary one for that web application.
8. Needless to say, this setting is pretty useful to know about. By default it will use the
address specified above it (whether server name or host header) and then the port—in
our case, that’s the server name and port 80. This is fine to accept for right now, since we
are not load balancing just yet. If you are going to enable SSL, it’s the public URL that
must match the certificate address (depending on the certificate type). Watch out for that
appended port in that case. Again, that’s not our issue here, so leave the default.
The last section in this set is Application Pool. It’s here that you indicate whether you
want to use an existing pool (not really recommended) or create one specifically for this
web application’s use. In addition, you need to specify the account identity used by the
application pool.
9. We are, of course, going to create a unique application pool for this web application. The
default name is always the name you gave the Web Site, which works for me because it’s
not only convenient, but it’s logical and makes it easier to figure out which application
pool goes with which IIS Web Site. So, keep the default.
The application identity, or security account, is another thing altogether. The options are
to either use a local built-in account (bad idea, and it’s grayed out anyway) or use a “con-
igurable” account.
 
Search JabSto ::




Custom Search