احصائيات المدونة

Sunday, June 17, 2012

Enabling or Disabling Claims Based Authentication


Enabling or Disabling Claims Based Authentication

Author: Luis Kerr
Claims Based Authentication is becoming so popular these days and enabling a SharePoint site to authenticate users no matter what authentication system is involved just got easier. I will not digress on Claims Based Authentication, not the point of this article, but I will focus on how to enable or disable CBA using PowerShell since there is no GUI available for this trick.
First, make sure your site (web application) does not have the CBA enabled. Go to Central Administration >> Manage web applications and click on the site you’re planning to enable CBA. Under Web Applications tab click on the Authentication Providers icon and a small window will pop-up. Under Default you should see Windows.
Claims Based Authentication
Claims Based Authentication
Next, create a PowerShell (.ps1) file using Notepad and paste the following code into it:
$setcba = Get-SPWebApplication "http://YourSiteURL"
$setcba.UseClaimsAuthentication = 1;
$setcba.Update()
Give it a name, like SetCB.ps1 and save in under C: on your SharePoint 2010 server.
Claims Based Authentication
Open SharePoint 2010 Management Shell, make sure you’re under C: (use CD.. to move under C:)and type or Copy and right-click Paste this command./SetCB.ps1
Claims Based Authentication
Hit Enter and after few seconds your SharePoint site should have Claims Based Authentication enabled.
Repeat the previous steps to check if your site has CBA enabled, Central Administration >> Manage web applications and click on the site, click on the Authentication Providers icon and under Default you should see now Claims Based Authentication.
Claims Based Authentication
To revert back to Classic mode authentication (disabled Claims Based Authentication) just change the 1 to a 0:
$setcba = Get-SPWebApplication "http://YourSiteURL"
$setcba.UseClaimsAuthentication = 0;
$setcba.Update()

Wednesday, June 6, 2012

Search Issue in Claims Based Application

http://www.codeproject.com/Tips/95049/Search-Server-2010-and-Claims-Based-Authentication


Problem

If you install Search Server Express 2010 on a SharePoint farm that has a web application using claims based authentication, you will get access denied in Central Administration when trying to manage the search service application.

Solution

To work around this issue, the user logged in to Central Administration must be added with permissions directly on the claims based authenticated web application. This cannot be done in the central administration UI even if ntlm authentication is enabled on the web application. The claims based user is not perceived by SharePoint as the user logged on to the windows authenticated Central Administration, i.e. 'i: 0#.w|domain\user' is not the same as 'domain\user'.

Use the following powershell script to add the windows authenticated user to the web application:
[void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")
$site = new-Object Microsoft.SharePoint.SPSite("http://SitesCBA.domain.no")
$wa = $site.WebApplication
$user = "domain\user"
$policy = $wa.Policies.Add($user, $user)
$policy.PolicyRoleBindings.Add($wa.PolicyRoles.GetSpecialRole(
[Microsoft.SharePoint.Administration.SPPolicyRoleType]::FullControl))
$wa.Update() 
$site.Dispose() 


Disable mobile browsers in SharePoint


  • We too encountered this problem. After a few hours of research and diving into the SharePoint assemblies with reflector I have found a way to get it to work. As in, to display the normal website on all mobile devices. This was our goal, so I didn't research options to get the mobile view to work on a public facing site.
    For this, add within the web.config file of the WebApp in the section configuration/system.web:

     <browserCaps>
      <result type="System.Web.Mobile.MobileCapabilities, System.Web.Mobile, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>
      <filter>isMobileDevice=false</filter>
    </browserCaps>

    This method is officially deprecated since the .NET Framework 3.0, but works like a charm. Needless to say that one could easily wrap this in a feature event receiver to adjust the web.config files upon deployment.