1. Module 5 Configuring Authentication

2. Module Overview Lesson 1: Understanding Classic SharePoint Authentication Providers Lesson 2: Understanding Federated Authentication

3. Lesson 1: Understanding Classic SharePoint Authentication Providers Identity and Authentication in SharePoint Configure Classic-Mode Authentication Integrated Windows Authentication Configure Kerberos Authentication Additional Windows Authentication Methods Secure Store Service

4. Identity and Authentication in SharePoint SharePoint is a three-tier, distributed application  Front-end Web server  Application server  Back-end database server Authentication can be (and by default, is) required at each tier Authentication types, providers, and methods TypesProviderMethods ClassicWindowsAnonymous, Basic, Digest, Certificates, NTLM, Negotiate (Kerberos or NTLM) Claims-basedWindowsAnonymous, Basic, Digest, Certificates, NTLM, Negotiate (Kerberos or NTLM) FBALDAP, SQL database, Other DB, Custom SAMLADFS 2.0, Windows Live ID, Third Party

5. Configure Classic-Mode Authentication Create a New Web Application Edit Authentication  From the Web Applications Management page  From the Authentication Providers page

6. Create a New Web Application

7. Edit Authentication

8. Integrated Windows Authentication NTLM  Out of box default.  Cannot authenticate user to other tiers and services. Kerberos  More secure.  More scalable.  Supports delegation.  Improves authentication performance.  Can authenticate user to other tiers and services.  Extra steps to configure. Negotiate (Kerberos or NTLM)  Client selects authentication method.  Kerberos is used unless it is not supported. Fallback to NTFS.

9. Authentication Processes NTLM  Server request requires authentication Server challenges client Client responds Server passes through the response to a DC DC validates response Session established Kerberos  Authentication (one time) Client authenticates with domain controller DC issues TGT  Server request Server requests Kerberos ticket Client presents TGT to DC and gets session ticket Client gives session ticket to server Session established

10. Configure Kerberos Authentication Configure service principal names (SPNs)  Represent the service class, name, and port of a service or web application  A property of the computer or user account in Active Directory  Must exist so that client can obtain a Kerberos session ticketKerberos session ticket Needed for every service and Web application using Kerberos Configure by using ADSI Edit or SetSPN.exe Service or App PoolAccountSPN http://intranet.contoso.comSP_ServiceHTTP/intranet.contoso.com HTTP/intranet http://sp2010-wfe1:9999SP_FarmHTTP/sp2010-wfe1.contoso.com:9999 HTTP/sp2010-wfe1:9999 SQL ServerSVC_SQLMSSQLSvc/sqlserver01.contoso.com:1433 MSSQLSvc/sqlserver01:1433

11. Kerberos Session Tickets Client request to server  I need http://intranet.contoso.com Service (in security context of app pool for intranet)  You need a session ticket for HTTP/intranet.contoso.com Client to domain controller  Here’s my TGT. I need a session ticket for HTTP/intranet.contoso.com. Domain controller  Knows client is authenticated already based on TGT  HTTP/intranet.contoso.com is a SPN of app pool user account  Create session key encrypted with app pool account password  Give session key to client Client returns to service with session key Service (app pool) decrypts the session key with its password Session established

12. Additional Windows Authentication Methods Anonymous access  Enables anonymous authentication but not permissions  Grant anonymous access permissions at site, list, library Basic  Plaintext password  Use SSL Digest  Configure in IIS Client certificates  Configure in IIS

13. Secure Store Service Replacement to Microsoft Single Sign On Simply stores username and passwords  NOT a Windows\Web Single Sign On Solution Several Service Applications support it  Business Connectivity Services  Excel Services  Performance Point Maps users to credentials for named applications Seamless integration with Security Token Service  Application ID Value in the authentication request forces lookup in Secure Store Service

14. Lesson 2: Understanding Federated Authentication Overview of Federated Identity Active Directory Federated Services (ADFS) Claims Authentication Process and Normalization Forms-Based Authentication Changes Claims to Windows Token Service

15. Overview of Federated Identity Federated Identity is the hosting of credentials somewhere else (claims providers)  LiveID  OpenID  Facebook Integration with one or many accomplished easily with Federation Gateways  ADFS  Azure ACS

16. Active Directory Federated Services (ADFS) ADFS is a service that allows for the creation of federated relationships between organizations for Web application authentication  Use their username and password AD; don’t create a new one!  Password resets and maintenance are responsibility of foreign system Allows you to trust other authentication mechanisms and retrieve “claims” about the users in those systems Implemented using WS-* standards You can define authorization rules based on the claims provided by external authentication systems

17. Claims Authentication Process and Normalization Identity validation process Federated sign-in process SharePoint identity normalization

18. Forms-Based Authentication Changes Forms-based authentication used to:  Create an ASP.NET Generic Identity It now creates:  Claims Identity Done through an STS provider  SecurityToken.svc Implements  SPSecurityTokenServiceHostFactory Multi-mode authentication  No longer requires you to “Extend” your Web applications. You can have multiple authentication types for a single Web application

19. Claims to Windows Token Service Since SharePoint is using Claims Identities, you need something to translate to Windows Identities  Claims to Windows Token Service (C2WTS)  When making a request for Windows authenticated resource, your claim is turned into a Windows Token Example  User through Web Part wants to access BCS data which connects to Windows authenticated Web service  The Claim Identity won’t work here!

20. Lab A: Configuring Custom Authentication Exercise 1: Creating and Configuring an ASP.NET Membership Database Exercise 2: Creating a Web Application that Uses Claims- Based Authentication Logon information Estimated time: 30 minutes

21. Scenario Your organizational IT policy states that only employees shall have an Active Directory account. Because of this policy, custom authentication databases must be used to authenticate outside vendors. IT has set up an ASP.NET membership database to authenticate all outside vendors. You have been tasked with setting up SharePoint to use this database for authentication.

22. Lab Review Why must you remove the elements from the Web.config file? If you are familiar with the configuration of forms-based authentication on Microsoft Office SharePoint Server 2007, what is different about the number and type of Web applications required to support forms-based authentication in SharePoint Server 2010 in the client extranet scenario presented in this lab?

23. Lab B: Configuring Secure Store Exercise 1: Creating User Accounts for Access to External Data Exercise 2: Configuring Secure Store Services Exercise 3: Configuring Secure Store Unattended Accounts Logon information Estimated time: 20 minutes

24. Scenario Organizational IT policy states that under no circumstances should credentials be stored in an unencrypted manner in applications. However, information workers have started using the new intranet portal site and would also like to start using SharePoint Designer 2010 to add Business Connectivity Services applications to pages. Because of the policy, they will not be allowed to embed the credentials in the ASP.NET pages. You have been tasked with configuring Secure Store to facilitate the authentication for these information workers.

25. Module Review and Takeaways Review Questions