Hi, In SP 2010, the default zone required to have Windows authentication enabled for the search crawl to work, even if we have Claims authentication on that web application. In SP 2013, it has been told that Windows authentication is not available as a default option at all and that the web application will use Claims auth by default. Does this mean that the search crawl would work even without Windows auth?Rgds, N.T.GOPALAKRISHNAN

Claims Based Authentication with SharePoint 2010 Architecture Overview The claims-based identity model for Microsoft SharePoint Foundation 2010 and Microsoft SharePoint Server 2010 is built upon Windows Identity Foundation (WIF), formerly code-named "Geneva" Framework Beta. Claims-based identity is an identity model in SharePoint Foundation 2010 and SharePoint Server 2010 that includes features such as authentication across users of Windows-based systems and systems that are not Windows-based, multiple authentication types, stronger real-time authentication, a wider set of principal types, and delegation of user identity between applications. When you build claims-aware applications, the user presents an identity to your application as a set of claims. One claim could be the users name, another might be an e-mail address. The idea is that an external identity system is configured to give your application all the information it needs about the user with each request, along with cryptographic assurance that the identity data you receive comes from a trusted source. Under this model, single sign-on is much easier to achieve. Figure 1: Issuers, security tokens, and applications Figure 2: ADFS functions Steps Create a local server instance with W2K8 R2, Sql Server and set it up as a domain controllerInstall ADFS 2.0 RCOpen the command prompt and browse to the ADFS installation folder cd "%programfiles%\Active Directory Federation Services 2.0"Configure ADFS with your database instance (instead of the default internal database). From the command prompt, type the following and fill in your details: FsConfigWizard.exe -sqlhost: -sqlinstance: -servacct: -servpass: [-dropdb] Parameter Description -sqlhost Sets the <SqlHostName> value. <SqlHostName> Specifies the name of the computer that is running an instance of SQL Server for use with AD FS 2.0. For example, if the local computer is to be specified, type localhost here. -sqlinstance Sets the <SqlInstName> value. <SqlInstName> Specifies the name of the SQL Server database instance to be used as the database. For example, to specify that a default Structured Query Language (SQL) instance that AD FS 2.0 Setup creates is to be used, type SQLEXPRESS here. -servacct Sets the <SvcAcctName> value. <SvcAcctName> Specifies the name of the Active Directory service account to use for running the AD FS 2.0 service. For example, to specify that the Network Service account for the Contoso domain be used, type CONTOSO\NetworkService here. -servpass Sets the <SvcAcctPwd> value. <SvcAcctPwd> Specifies the password text for the account set using the -servacct parameter. -dropdb (Optional.) If this parameter is specified, it deletes or overwrites any existing database if one is found to exist. If this parameter is omitted, and an existing AD FS 2.0 database is located it will be used. If no parameter is specified and no existing database is located, the database will be created as needed. To create the database, AD FS 2.0 uses the hosted SQL Server instance that is set using the -sqlhost and -sqlinstance parameters. 5. Create a claims-enabled SharePoint web application. Click Create new Web Application in Central Administration and select the Claims Based Authentication radio-button in the Authentication section. Create the base site collection after this. 6. (Optional) Create and deploy the claims checker webpart. You can download the WSP from here. You can download the sourcecode from here. 7. Launch ADFS 2 and validate the certificate, which should be the same certificate bound to the default web site. Make any changes necessary to ensure the Service Communications certificate and SSL binding in IIS is fully operational. 8. As a test, you should be able to browse to https://<servername>/FederationMetadata/2007-06/federationmetadata.xml 9. Now, export your Token-Signing Certificate to the c:\ drive. The quickest way to do this is to right-click the certificate in the ADFS 2.0 Management Console and select View Certificate. Then, navigate to the Details tab and click the button labeled Copy to File This will launch the Certificate Export Wizard. Follow the wizard to export the certificate as a DER encoded binary X.509 (.CER) file. For simplicity, I recommend saving the certificate to the C:\ drive. You will need this file in the following PowerShell script. 10. Add ADFS 2.0 as a Federated Identity Provider in SharePoint $cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("c:\[YOUR_STS_SIGNING_CERT].cer") $map1 = New-SPClaimTypeMapping "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "EmailAddress" -SameAsIncoming $realm = "urn:" + $env:ComputerName + ":adfs" $signinurl = "https://[YOUR_SERVER_NAME]/adfs/ls/" $ap = New-SPTrustedIdentityTokenIssuer -Name "ADFS20Server" -Description "ADFS 2.0 Federated Server" -Realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map1 -SignInUrl $signinurl -IdentifierClaim $map1.InputClaimType Configure Role Powershell Script $cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("c:\[YOUR_STS_SIGNING_CERT].cer") $map1 = New-SPClaimTypeMapping "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "EmailAddress" -SameAsIncoming $realm = "urn:" + $env:ComputerName + ":adfs" $signinurl = "https://[YOUR_SERVER_NAME]/adfs/ls/" $ap = New-SPTrustedIdentityTokenIssuer -Name "ADFS20Server" -Description "ADFS 2.0 Federated Server" -Realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map1 -SignInUrl $signinurl -IdentifierClaim $map1.InputClaimType HINT: You can copy and paste the above PowerShell commands into a text file. Save the text file with the .ps1 extension and you will be able to execute the file from within PowerShell. Be sure to launch SharePoint 2010 Management Shell as this will load all the SharePoint related extensions. 11. You should now be able add the Federated Identity Provider in Central Administration. Navigate to Web Applications Management, highlight the web application, and click the Authentication Providers button in the ribbon. You should now see your new provider in the Federated Identity Provider section of the Edit Authentication window 12. At this point, if you browse to your claims-enabled SharePoint site youll find a new screen where you need to specify what Identity Provider to use for access. This happens because we have both our Federated Identity Provider and Windows Authentication enabled for this zone. It should be noted that this screen can be customized with logic to automatically determine the correct provider based on the client IP address (for example). For now, we need to stick with Windows Authentication because ADFS 2.0 isnt configured yet to work with SharePoint. 13. There appear to be issues getting claims-enabled web applications that have both a custom Federated Identity Provider and standard Windows Authentication provider enabled. Therefore delete and create the web application again. Ahsan Kabir Please remember to click Mark as Answer and Vote as Helpful on posts that help you. This can be beneficial to other community members reading the thread. http://www.aktechforum.blogspot.com/

Claims Based Authentication with SharePoint 2010 Architecture Overview The claims-based identity model for Microsoft SharePoint Foundation 2010 and Microsoft SharePoint Server 2010 is built upon Windows Identity Foundation (WIF), formerly code-named "Geneva" Framework Beta. Claims-based identity is an identity model in SharePoint Foundation 2010 and SharePoint Server 2010 that includes features such as authentication across users of Windows-based systems and systems that are not Windows-based, multiple authentication types, stronger real-time authentication, a wider set of principal types, and delegation of user identity between applications. When you build claims-aware applications, the user presents an identity to your application as a set of claims. One claim could be the users name, another might be an e-mail address. The idea is that an external identity system is configured to give your application all the information it needs about the user with each request, along with cryptographic assurance that the identity data you receive comes from a trusted source. Under this model, single sign-on is much easier to achieve. Figure 1: Issuers, security tokens, and applications Figure 2: ADFS functions Steps Create a local server instance with W2K8 R2, Sql Server and set it up as a domain controllerInstall ADFS 2.0 RCOpen the command prompt and browse to the ADFS installation folder cd "%programfiles%\Active Directory Federation Services 2.0"Configure ADFS with your database instance (instead of the default internal database). From the command prompt, type the following and fill in your details: FsConfigWizard.exe -sqlhost: -sqlinstance: -servacct: -servpass: [-dropdb] Parameter Description -sqlhost Sets the <SqlHostName> value. <SqlHostName> Specifies the name of the computer that is running an instance of SQL Server for use with AD FS 2.0. For example, if the local computer is to be specified, type localhost here. -sqlinstance Sets the <SqlInstName> value. <SqlInstName> Specifies the name of the SQL Server database instance to be used as the database. For example, to specify that a default Structured Query Language (SQL) instance that AD FS 2.0 Setup creates is to be used, type SQLEXPRESS here. -servacct Sets the <SvcAcctName> value. <SvcAcctName> Specifies the name of the Active Directory service account to use for running the AD FS 2.0 service. For example, to specify that the Network Service account for the Contoso domain be used, type CONTOSO\NetworkService here. -servpass Sets the <SvcAcctPwd> value. <SvcAcctPwd> Specifies the password text for the account set using the -servacct parameter. -dropdb (Optional.) If this parameter is specified, it deletes or overwrites any existing database if one is found to exist. If this parameter is omitted, and an existing AD FS 2.0 database is located it will be used. If no parameter is specified and no existing database is located, the database will be created as needed. To create the database, AD FS 2.0 uses the hosted SQL Server instance that is set using the -sqlhost and -sqlinstance parameters. 5. Create a claims-enabled SharePoint web application. Click Create new Web Application in Central Administration and select the Claims Based Authentication radio-button in the Authentication section. Create the base site collection after this. 6. (Optional) Create and deploy the claims checker webpart. You can download the WSP from here. You can download the sourcecode from here. 7. Launch ADFS 2 and validate the certificate, which should be the same certificate bound to the default web site. Make any changes necessary to ensure the Service Communications certificate and SSL binding in IIS is fully operational. 8. As a test, you should be able to browse to https://<servername>/FederationMetadata/2007-06/federationmetadata.xml 9. Now, export your Token-Signing Certificate to the c:\ drive. The quickest way to do this is to right-click the certificate in the ADFS 2.0 Management Console and select View Certificate. Then, navigate to the Details tab and click the button labeled Copy to File This will launch the Certificate Export Wizard. Follow the wizard to export the certificate as a DER encoded binary X.509 (.CER) file. For simplicity, I recommend saving the certificate to the C:\ drive. You will need this file in the following PowerShell script. 10. Add ADFS 2.0 as a Federated Identity Provider in SharePoint $cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("c:\[YOUR_STS_SIGNING_CERT].cer") $map1 = New-SPClaimTypeMapping "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "EmailAddress" -SameAsIncoming $realm = "urn:" + $env:ComputerName + ":adfs" $signinurl = "https://[YOUR_SERVER_NAME]/adfs/ls/" $ap = New-SPTrustedIdentityTokenIssuer -Name "ADFS20Server" -Description "ADFS 2.0 Federated Server" -Realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map1 -SignInUrl $signinurl -IdentifierClaim $map1.InputClaimType Configure Role Powershell Script $cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("c:\[YOUR_STS_SIGNING_CERT].cer") $map1 = New-SPClaimTypeMapping "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "EmailAddress" -SameAsIncoming $realm = "urn:" + $env:ComputerName + ":adfs" $signinurl = "https://[YOUR_SERVER_NAME]/adfs/ls/" $ap = New-SPTrustedIdentityTokenIssuer -Name "ADFS20Server" -Description "ADFS 2.0 Federated Server" -Realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map1 -SignInUrl $signinurl -IdentifierClaim $map1.InputClaimType HINT: You can copy and paste the above PowerShell commands into a text file. Save the text file with the .ps1 extension and you will be able to execute the file from within PowerShell. Be sure to launch SharePoint 2010 Management Shell as this will load all the SharePoint related extensions. 11. You should now be able add the Federated Identity Provider in Central Administration. Navigate to Web Applications Management, highlight the web application, and click the Authentication Providers button in the ribbon. You should now see your new provider in the Federated Identity Provider section of the Edit Authentication window 12. At this point, if you browse to your claims-enabled SharePoint site youll find a new screen where you need to specify what Identity Provider to use for access. This happens because we have both our Federated Identity Provider and Windows Authentication enabled for this zone. It should be noted that this screen can be customized with logic to automatically determine the correct provider based on the client IP address (for example). For now, we need to stick with Windows Authentication because ADFS 2.0 isnt configured yet to work with SharePoint. 13. There appear to be issues getting claims-enabled web applications that have both a custom Federated Identity Provider and standard Windows Authentication provider enabled. Therefore delete and create the web application again. Ahsan Kabir Please remember to click Mark as Answer and Vote as Helpful on posts that help you. This can be beneficial to other community members reading the thread. http://www.aktechforum.blogspot.com/

Claims Based Authentication with SharePoint 2010 Architecture Overview The claims-based identity model for Microsoft SharePoint Foundation 2010 and Microsoft SharePoint Server 2010 is built upon Windows Identity Foundation (WIF), formerly code-named "Geneva" Framework Beta. Claims-based identity is an identity model in SharePoint Foundation 2010 and SharePoint Server 2010 that includes features such as authentication across users of Windows-based systems and systems that are not Windows-based, multiple authentication types, stronger real-time authentication, a wider set of principal types, and delegation of user identity between applications. When you build claims-aware applications, the user presents an identity to your application as a set of claims. One claim could be the users name, another might be an e-mail address. The idea is that an external identity system is configured to give your application all the information it needs about the user with each request, along with cryptographic assurance that the identity data you receive comes from a trusted source. Under this model, single sign-on is much easier to achieve. Figure 1: Issuers, security tokens, and applications Figure 2: ADFS functions Steps Create a local server instance with W2K8 R2, Sql Server and set it up as a domain controllerInstall ADFS 2.0 RCOpen the command prompt and browse to the ADFS installation folder cd "%programfiles%\Active Directory Federation Services 2.0"Configure ADFS with your database instance (instead of the default internal database). From the command prompt, type the following and fill in your details: FsConfigWizard.exe -sqlhost: -sqlinstance: -servacct: -servpass: [-dropdb] Parameter Description -sqlhost Sets the <SqlHostName> value. <SqlHostName> Specifies the name of the computer that is running an instance of SQL Server for use with AD FS 2.0. For example, if the local computer is to be specified, type localhost here. -sqlinstance Sets the <SqlInstName> value. <SqlInstName> Specifies the name of the SQL Server database instance to be used as the database. For example, to specify that a default Structured Query Language (SQL) instance that AD FS 2.0 Setup creates is to be used, type SQLEXPRESS here. -servacct Sets the <SvcAcctName> value. <SvcAcctName> Specifies the name of the Active Directory service account to use for running the AD FS 2.0 service. For example, to specify that the Network Service account for the Contoso domain be used, type CONTOSO\NetworkService here. -servpass Sets the <SvcAcctPwd> value. <SvcAcctPwd> Specifies the password text for the account set using the -servacct parameter. -dropdb (Optional.) If this parameter is specified, it deletes or overwrites any existing database if one is found to exist. If this parameter is omitted, and an existing AD FS 2.0 database is located it will be used. If no parameter is specified and no existing database is located, the database will be created as needed. To create the database, AD FS 2.0 uses the hosted SQL Server instance that is set using the -sqlhost and -sqlinstance parameters. 5. Create a claims-enabled SharePoint web application. Click Create new Web Application in Central Administration and select the Claims Based Authentication radio-button in the Authentication section. Create the base site collection after this. 6. (Optional) Create and deploy the claims checker webpart. You can download the WSP from here. You can download the sourcecode from here. 7. Launch ADFS 2 and validate the certificate, which should be the same certificate bound to the default web site. Make any changes necessary to ensure the Service Communications certificate and SSL binding in IIS is fully operational. 8. As a test, you should be able to browse to https://<servername>/FederationMetadata/2007-06/federationmetadata.xml 9. Now, export your Token-Signing Certificate to the c:\ drive. The quickest way to do this is to right-click the certificate in the ADFS 2.0 Management Console and select View Certificate. Then, navigate to the Details tab and click the button labeled Copy to File This will launch the Certificate Export Wizard. Follow the wizard to export the certificate as a DER encoded binary X.509 (.CER) file. For simplicity, I recommend saving the certificate to the C:\ drive. You will need this file in the following PowerShell script. 10. Add ADFS 2.0 as a Federated Identity Provider in SharePoint $cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("c:\[YOUR_STS_SIGNING_CERT].cer") $map1 = New-SPClaimTypeMapping "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "EmailAddress" -SameAsIncoming $realm = "urn:" + $env:ComputerName + ":adfs" $signinurl = "https://[YOUR_SERVER_NAME]/adfs/ls/" $ap = New-SPTrustedIdentityTokenIssuer -Name "ADFS20Server" -Description "ADFS 2.0 Federated Server" -Realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map1 -SignInUrl $signinurl -IdentifierClaim $map1.InputClaimType Configure Role Powershell Script $cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("c:\[YOUR_STS_SIGNING_CERT].cer") $map1 = New-SPClaimTypeMapping "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "EmailAddress" -SameAsIncoming $realm = "urn:" + $env:ComputerName + ":adfs" $signinurl = "https://[YOUR_SERVER_NAME]/adfs/ls/" $ap = New-SPTrustedIdentityTokenIssuer -Name "ADFS20Server" -Description "ADFS 2.0 Federated Server" -Realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map1 -SignInUrl $signinurl -IdentifierClaim $map1.InputClaimType HINT: You can copy and paste the above PowerShell commands into a text file. Save the text file with the .ps1 extension and you will be able to execute the file from within PowerShell. Be sure to launch SharePoint 2010 Management Shell as this will load all the SharePoint related extensions. 11. You should now be able add the Federated Identity Provider in Central Administration. Navigate to Web Applications Management, highlight the web application, and click the Authentication Providers button in the ribbon. You should now see your new provider in the Federated Identity Provider section of the Edit Authentication window 12. At this point, if you browse to your claims-enabled SharePoint site youll find a new screen where you need to specify what Identity Provider to use for access. This happens because we have both our Federated Identity Provider and Windows Authentication enabled for this zone. It should be noted that this screen can be customized with logic to automatically determine the correct provider based on the client IP address (for example). For now, we need to stick with Windows Authentication because ADFS 2.0 isnt configured yet to work with SharePoint. 13. There appear to be issues getting claims-enabled web applications that have both a custom Federated Identity Provider and standard Windows Authentication provider enabled. Therefore delete and create the web application again. Ahsan Kabir Please remember to click Mark as Answer and Vote as Helpful on posts that help you. This can be beneficial to other community members reading the thread. http://www.aktechforum.blogspot.com/

In SharePoint Server 2013, your default zone will not need to use Classic Authentication in order for Search to function. I have validated this with my lab environment (all web applications use only claims on all zones, and Search functions as intended). My lab at this time is a pretty simple configuration, however I don't see any reason you would need classic authentication on your SharePoint 2013 web applications.Roger Cormier Microsoft Premier Field Engineer, SharePoint Blog: http://blogs.msdn.com/b/rcormier/ Twitter: LinkedIn: Note: My posts are provided AS IS without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

In SharePoint Server 2013, your default zone will not need to use Classic Authentication in order for Search to function. I have validated this with my lab environment (all web applications use only claims on all zones, and Search functions as intended). My lab at this time is a pretty simple configuration, however I don't see any reason you would need classic authentication on your SharePoint 2013 web applications.Roger Cormier Microsoft Premier Field Engineer, SharePoint Blog: http://blogs.msdn.com/b/rcormier/ Twitter: LinkedIn: Note: My posts are provided AS IS without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

In SharePoint Server 2013, your default zone will not need to use Classic Authentication in order for Search to function. I have validated this with my lab environment (all web applications use only claims on all zones, and Search functions as intended). My lab at this time is a pretty simple configuration, however I don't see any reason you would need classic authentication on your SharePoint 2013 web applications.Roger Cormier Microsoft Premier Field Engineer, SharePoint Blog: http://blogs.msdn.com/b/rcormier/ Twitter: LinkedIn: Note: My posts are provided AS IS without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.