We had a request from client to allow to pick up users in a people picker on a site from particular domain

Let me elaborate the SharePoint environment involved here

The SharePoint farm is on a domain say Contoso.  The client has another domain say Talespin.  There is 2 way trust relationship between Contoso and Talespin.

The SharePoint farm and machine is joined to Contoso.  Now for a particular site the client wants to be able to search and pick users from Talespin and not Contoso.

It took a long time for us to finally nail it.  Some of the commands available on net were working with resolving users but not with search on people picker.

Here are the commands that worked

$wa = Get-SPWebApplication -Identity https://webapp

#List the Domains 
 $wa.PeoplePickerSettings.SearchActiveDirectoryDomains 

#Below script will add domain to Search of people picker
 $wa = Get-SPWebApplication -Identity https://webapp
$ad = New-Object Microsoft.SharePoint.Administration.SPPeoplePickerSearchActiveDirectoryDomain 
$ad.DomainName = "Talespin.local" 
$ad.IsForest = $true 
$wa.PeoplePickerSettings.SearchActiveDirectoryDomains.Add($ad) 
$wa.Update() 

stsadm -o setproperty -url https://webapp -pn peoplepicker-distributionlistsearchdomains -pv Talespin.local

#This will restrict people picker to resolve and search only from Talespin
stsadm -o setproperty -pn peoplepicker-searchadcustomfilter -pv "(&(userPrincipalName=*Talespin.local)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))" -url https://siteurl

In my last post Sync FBA user profiles I discussed how to synchronize Form based authentication users with SharePoint.

One of the steps is to create a new synchronization connection for FBA.  Now I received couple of comments mentioning that they faced an issue where while creating new connection they got several errors like Value is not valid or drpClaimId is not a valid value. 

If you look closely you will see one of the drop downs have “No trusted providers found” as shown in below screen shot

Now the Authentication Provider type should be Forms Based Authentication and still if you see No trusted providers were found there is a problem.

Lets take a step back and see how to configure a web application for FBA (assuming you already have a solution which would do the actual authentication)

There are 2 main steps to do this.

1. Configure the membership provider and membership role in web config files

2. Change the authentication provider setting in central admin for that web application.

Step 1 – Changing web config.

The web.config files need to be changed for web application, central admin and Security Token Service

Web application web.config should have below changes.  Add the key under app settings.

<appSettings>

<add key="LDAPPath" value=LDAP://CN=Users,DC=Talespin,DC=local />

</appSettings>

Add providers under <membership><providers> and rolemanager tag under <rolemanager><providers>.  Highlighted in Green shows the custom additions

<membership defaultProvider="i">
     <providers>
       <add name="LdapMember" type="Microsoft.Office.Server.Security.LdapMembershipProvider,&#xD;&#xA; Microsoft.Office.Server, Version=15.0.0.0, Culture=neutral,&#xD;&#xA; PublicKeyToken=71e9bce111e9429c" server="sk-dc.sickkids.local" port="389" useSSL="false" userDNAttribute="distinguishedName" userNameAttribute="sAMAccountName" userContainer="OU=SPUsers,DC=Talespin,DC=LOCAL" userObjectClass="person" userFilter="(ObjectClass=person)" scope="Subtree" otherRequiredUserAttributes="sn,givenname,cn" />
       <add name="i" type="Microsoft.SharePoint.Administration.Claims.SPClaimsAuthMembershipProvider, Microsoft.SharePoint, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
     </providers>
   </membership>
   <roleManager defaultProvider="c" enabled="true" cacheRolesInCookie="false">
     <providers>
       <add name="LdapRole" type="Microsoft.Office.Server.Security.LdapRoleProvider, &#xD;&#xA;Microsoft.Office.Server, Version=15.0.0.0, Culture=neutral, &#xD;&#xA;PublicKeyToken=71e9bce111e9429c" server="sk-dc.sickkids.local" port="389" useSSL="false" groupContainer="OU=SPUsers,DC=Talespin,DC=LOCAL" groupNameAttribute="cn" groupNameAlternateSearchAttribute="samAccountName" groupMemberAttribute="member" userNameAttribute="sAMAccountName" dnAttribute="distinguishedName" groupFilter="(ObjectClass=group)" userFilter="(ObjectClass=person)" scope="Subtree" />
       <add name="c" type="Microsoft.SharePoint.Administration.Claims.SPClaimsAuthRoleProvider, Microsoft.SharePoint, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
     </providers>
   </roleManager>

Central Admin web config should have below additions

    <membership>
   <providers>
      <add name="LdapMember"
         type="Microsoft.Office.Server.Security.LdapMembershipProvider,
Microsoft.Office.Server, Version=15.0.0.0, Culture=neutral,
PublicKeyToken=71e9bce111e9429c"
         server="sk-dc.sickkids.local"
         port="389"
         useSSL="false"
         userDNAttribute="distinguishedName"
         userNameAttribute="sAMAccountName"
         userContainer="OU=SPUsers,DC=SICKKIDS,DC=LOCAL"
         userObjectClass="person"
         userFilter="(ObjectClass=person)"
         scope="Subtree"
         otherRequiredUserAttributes="sn,givenname,cn" />
   </providers>
</membership>
    <roleManager enabled="true" defaultProvider="AspNetWindowsTokenRoleProvider" >
   <providers>
      <add name="LdapRole"
         type="Microsoft.Office.Server.Security.LdapRoleProvider,
Microsoft.Office.Server, Version=15.0.0.0, Culture=neutral,
PublicKeyToken=71e9bce111e9429c"
         server="sk-dc.sickkids.local"
         port="389"
         useSSL="false"
         groupContainer="OU=SPUsers,DC=SICKKIDS,DC=LOCAL"
         groupNameAttribute="cn"
         groupNameAlternateSearchAttribute="samAccountName"
         groupMemberAttribute="member"
         userNameAttribute="sAMAccountName"
         dnAttribute="distinguishedName"
         groupFilter="(ObjectClass=group)"
         userFilter="(ObjectClass=person)"
         scope="Subtree" />
   </providers>
</roleManager>

Web config of STS is as below additions.

<system.web>
     <membership>
   <providers>
      <add name="LdapMember"
         type="Microsoft.Office.Server.Security.LdapMembershipProvider,
Microsoft.Office.Server, Version=15.0.0.0, Culture=neutral,
PublicKeyToken=71e9bce111e9429c"
         server="sk-dc.sickkids.local"
         port="389"
         useSSL="false"
         userDNAttribute="distinguishedName"
         userNameAttribute="sAMAccountName"
         userContainer="OU=SPUsers,DC=SICKKIDS,DC=LOCAL"
         userObjectClass="person"
         userFilter="(ObjectClass=person)"
         scope="Subtree"
         otherRequiredUserAttributes="sn,givenname,cn" />
   </providers>
</membership>

<roleManager enabled="true">
   <providers>
      <add name="LdapRole"
         type="Microsoft.Office.Server.Security.LdapRoleProvider,
Microsoft.Office.Server, Version=15.0.0.0, Culture=neutral,
PublicKeyToken=71e9bce111e9429c"
         server="sk-dc.sickkids.local"
         port="389"
         useSSL="false"
         groupContainer="OU=SPUsers,DC=SICKKIDS,DC=LOCAL"
         groupNameAttribute="cn"
         groupNameAlternateSearchAttribute="samAccountName"
         groupMemberAttribute="member"
         userNameAttribute="sAMAccountName"
         dnAttribute="distinguishedName"
         groupFilter="(ObjectClass=group)"
         userFilter="(ObjectClass=person)"
         scope="Subtree" />
   </providers>
</roleManager>
  </system.web>

2nd steps is to change configuration of application.  To do so navigate to central admin go to application management.  Select web application and click Authentication Providers. 

Click on default or if you have some other zone.  Enable FormBased Authentication by checking the check box for FBA.

Next is to provide the membershipprovider name.  This name is what you added in the web.config file above.  This name should match the string in web.config

Note that this is case sensitive also .  If this name or case does not match it gives the “No trusted provider” in the drop down when you try to add the connection.

This is a common problem.  The first thing you might want to inspect is the database size.

Navigate to C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\DATA

Check the size of SharePoint_Config database.  If this database is taking more disk space you are at the right page.

Run the following commands and you should be good.

alter database sharepoint_config set recovery simple
dbcc shrinkfile(sharepoint_config_log,50)
alter database sharepoint_config set recovery full

Had this issue for a while.   Some said restart IIS, Powershell etc

I closed Visual Studio restarted IIS that was open and it worked.

Posting it here just in case some one else facing it.

A fellow colleague was trying to do something in web part that required more privileges

So as all of us would do he wrapped the code round SPSecurity.RunWithElevatedPrivileges.

It is then he started receiving errors on access denied each time he tried to add the web part.

Below was his code

SPSecurity.RunWithElevatedPrivileges(delegate()

{

         SPSite site = SPContext.Current.Site;

         SPWeb web = SPContext.Current.Web;

         SPWebCollection webs = web.Webs;

...  

});//Close "SPSecurity.RunWithElevatedPrivileges" block

This code is not correct because of the lines below

SPSite site = SPContext.Current.Site;

SPWeb web = SPContext.Current.Web;

SPContext is something that exists and is not created from within RunWithElevatedPrivileges.  Hence only object created with ElevatedPriviliges give the user the elevated privileges.

Hence the below code should work fine.

SPSecurity.RunWithElevatedPrivileges(delegate()

{

         SPSite site = SPContext.Current.Site;

         SPWeb web = SPContext.Current.Web;

         string url = SPContext.Current.Web.Url;

         using (SPSite localSiteObj = newSPSite(url))

              {

            using (SPWeb localWebObj = localSiteObj.OpenWeb())

                   {       SPWebCollection webs = localWebObj.Webs;            }

              }

});//Close "SPSecurity.RunWithElevatedPrivileges" block

If you notice localSiteObj and localWebObj are created within elevatedPrivileges and hence would work fine.  You can use SPContext also within elevatedPrivileges but only to do stuff which does not need extra privileges.

Hope it clarifies

Normally we would like to provide a confirmation dialog to the user before deleting something and initiate an AJAX request if user says yes to delete. Standard way looks like this:

<asp:Button ID="Button1" runat="server" OnClientClick="return confirm('Are you sure you want to delete?');" />

To work with AJAX when the button is AJAX-enabled or inside update panel or added to AJAX setting to AjaxManager it needs to be changed a bit.

<asp:Button ID="Button1" runat="server" OnClientClick="if (!confirm('Are you sure?')) return false;" />

So basically with ajax requests, return from javascript cancels the post back it does not matter whether it returns true or false.  So the work around is return only when you want to cancel the post back.

In my earlier post Getting Updates to User profile in SharePoint, I wrote about AD updates not rolling out to site for defafult AD user i.e. Windows authentication.  This post talks about the same problem but for Forms Authentication.

For simplicity I am using an example where I created LDAP Connection with users in AD.

This article will not cover how to create ldap connection but it is about trouble shooting if the properties of the ldap users are not shown and reflected in SharePoint site.

So there are 2 things here.  First the ldap users properties should be seen and reflected in User profile and second in the site collection.

So for ldap users’ properties to sync with SharePoint below are the steps that needs to be done

Check the properties are not synced.  From Central Admin –> Navigate to Manage Service Applications –> Click on User Profile Service Application.

Click Manage User Profiles

Put a user name and click Find.

Now if you find the user’s profile, click Edit profile and see the properties like Name, Department etc.  It should sync with the source.  If it is then User Profile sync is happening.  If not or even if the profile is not there the sync is not working.

Navigate back to Manager User Profile Service Application page and click on Configure Synchronization Connections.

Click on Create new connection.

Select Forms Authentication in Authentication Provider Type.  Authentication Provider Instance is populated in drop down based on the settings configured for authentication in web config.  Provide with Account name and Password.

This account should have replicate directory permission.   Be careful with this as if the account does not have sufficient priveliges there is no error thrown, just when the profile sync is run it does not import profiles from the source.  So it is not evident that the problem is insufficient priveleges

Click Populate Containers.  Select whatever you need to sync.  In my case it is just SPUsers OU.

Again careful here as the account specified is used to populate the containers.  If the account has AD read permissions, it will populate the containers but will not import profiles silently without any error if it does not have replicate directory permissions.

Once done click ok. 

Click on Manage User Properties.  Search for Claim User Identifier

Click Edit and on the next page you need to add mapping.

So basically in claims-based Web applications, SharePoint Server uses the Claim User Identifier property (SPS-ClaimID) to match an authenticated user to the correct user profile. If the SPS-ClaimID is not mapped to the directory service attribute that you want to use as the user identifier, when a user is authenticated, he or she is not matched to the correct user profile and will not see the imported user profile data.

To resolve this issue, map the SPS-ClaimID property to the directory service attribute that uniquely identifies the user in my case here it is samAccountName.

Once done and Start the profile synchronization.

When the profile sync starts you would see Synchronizing and Stop links.  Click on Synchronizing link to see the status.  Check the status once in a while.

Once done click on Manager User Profile and search for the user you searched in step 1.  Check the user profile properties should be updated.  

Next task is to go to a site collection and verify if the properties got propagated to site.

Navigate to web application, try to login with one of the ldap users and see the name that appears in the right corner.  If it is the updated name, the properties are updated, if not it means the user updates are not propagated to site.

This is a small issue that I noticed that after a ldap user logs in the site, the profile is pushed to the site and sometimes you need to run Profile synchronization to push the updates to the profile.  So if you cannot see the updates on the site but can see on user profile manage users profile page, try logging in the site with that user or add that user to some group (so that user’s profile is added to the site, later you can remove the user if you don't want him to be in any groups) and run the profile sync.

Hope it helps.

Whenever user properties are updated in Active Directory, following needs to be done to have them reflected in SharePoint

1. Run User Profile Synchronization

Go to Central Admin –> Navigate to Manage Applications Service –> Find User Profile Synchronisation and run full sync

Click Start Full Synchronization

Notice the status of synchronization in the Manage Profile Service screen

Once done to verify user values have changed in profile click on Manage User Profile on the same screen

Find the user and click the Account name to check the profile

Notice the changes are reflected here.  I changed the display name, first name and last name and they have changed.  Do not update anything here, this is to just see if changes are reflected from AD

Now if you navigate to the site collection and search for the user I do not see the reflected name yet.

This is because the user is not synchronizing correctly to a Site Collection.

To do this, note what permission the user has.

Navigate to Site Setting of the site collection in question

Click on Site Permissions

Click on Check Permissions

Give user name here and note the groups and permissions of the user.

So navigate to this page <Site URL>/_layouts/people.aspx?MembershipGroupId=0

Delete the user from this list.

Important If you remove the user from the All People group, all the user's permissions to this Site Collection are removed. Before you remove the user's permissions and re-add them, note the user's permissions. To do this, on the Site Actions menu, click Site Permissions, and then click Check Permissions.
The All People group is hidden in SharePoint 2010. However, to access this group, you can modify the following URL in the browser:

< Site URL>/_layouts/people.aspx?MembershipGroupId=0

Having done this re-add the users to the groups it belonged to and give it the permission it had.

Once done the user’s properties are now synced with site collection and update properties started getting reflected.

In my earlier post Provisioning webparts through feature, we saw how can custom or out of the box web parts be provisioned on a page through visual studio feature.

Note that sometimes using this approach you might stumble on this error “Cannot recognize the XML namespace”

Notice that when ou download the configured web part you would see 2 kinds of namspaces. https://schemas.microsoft.com/WebPart/v2 and https://schemas.microsoft.com/WebPart/v3.  In SharePoint you have two types of webparts, v2 and v3. Both have slightly different syntax

The elements.xml file for v2 would look something like below

and with v3:

v3 had extra <webparts> tag and v2 has extra attributes in WebPart tag.