Replace The Default SharePoint People Picker With A Custom People Picker

At a recent customer of mine the question came up as to how we could replace the default people picker with a custom one that was tailored to some very particular AD queries to supplement the SharePoint calls. I read a few posts about replacing it across the board, notably this one:

which for the most part is accurate. But this looked like a lot of work.

Reflecting on how a majority of the security assignment stuff happens, the AvlInc.aspx page out of the Layouts directory is the primary workhorse. While modifying such pages out of the 12 hive isn’t technically the best route in terms of surviving updates and service packs, proper noting of the customization to re-integrate back was fine for my requirement.

That being said, after you get a custom picker working ala using inheritance for requisite SimpleQueryControl, PickerDialog, EntityEditorWithPicker classes to override the abstract inherited members with your own behavior, even if you replace the default picker on the page it will not work since the page is querying for a picker with id userPicker. You won’t be able to simply change your custom control to this id and expect it to work because the base type casting will not be supported, thus will throw a nasty error.

The easiest way around it is to toggle the visibility of the primary, OOB picker on the page to not visible, and then create your own code behind page for the AclInv.aspx. This will allow you to interrogate the accounts in the custom picker, copy them to the OOB picker, and then submit the changes (as a note, I am only concerned with one account being in the picker at a time). Once this is done change the page to look at your custom page for it’s code behind. In order to copy the accounts, you have to override the default Validate logic since you are trying to catch the account changes on the button click. To get the control on the page, you are not going to be able to use the orthodox FindControl method, but rather have to recursively search for the control using the Page root as a starting container.

public class test : Microsoft.SharePoint.ApplicationPages.AclInv
public override void Validate()
var control = (CustomEditorType) FindControlRecursive(Page, “userPicker1”);
foreach (string account in control.Accounts)
userPicker.CommaSeparatedAccounts = account;

public static Control FindControlRecursive(Control container, string name)
if ((container.ID != null) && (container.ID.Equals(name)))
return container;
return (container.Controls.Cast().Select(
ctrl => FindControlRecursive(ctrl, name))).FirstOrDefault(
foundCtrl => foundCtrl != null);


Not saying this is 100% great, but as a proof of concept is accuratish.


SharePoint 2010 Business Connectivity Services Security Best Practices – Introduction

The security architecture of Microsoft Business Connectivity Services server & client supports a secure environment. They allow for the connection of external content types to the system. There are various options for authorization that are stored. The techniques allow for the security of Microsoft Business Connectivity Services to be cultivated. Part of the security for Microsoft Business Connectivity Services includes the process for authentication of users before they can access external systems. This also requires configurations of permission for the data from an external system. You will find that Microsoft Business Connectivity Service is very flexible. As a result it is able to offer a full range of security methods from the Microsoft Office 2010 as well as the web browser.

It is recommended that you use Secure Sockets Layer (SSL) on all of the channels between computers and end servers. You should be using SSL between servers and external systems anyways.

It is possible to use a web browser to successfully access external data. There are three systems involved in this process:

  • The computer a client is logged into
  • The web server farm
  • The external system

The web browser is going to interact with the external data through the use of a series web parts. The server runtime for front end servers use that data to connect and execute the various operations with external systems. The secure store service stores the credential sets for external systems. Those credentials are used to identify certain individuals or groups. The security token service responds when a request for authentication occurs. They are issued by the security tokens that are part of identity claims based on account information. With Microsoft Business Connectivity Services, there are credentials that have to be passed to claims based authentication aware sub-systems.

External data may be accessed from an office client application. This requires both an external system being used and the client being logged into a client computer. The external data can be retrieved through, for example, the use of either Microsoft Word 2010 or Microsoft SharePoint Workspace. With Outlook 2010, users will be able to access external data including tasks or contacts. With SharePoint Workspace 2010 they can use external lists and use them offline. Microsoft Word 2010 users have the ability to insert the external data into Word documents. With office integration, the runtime is the connection between Microsoft Business Connectivity Services that operate on the client and the supported office applications. When the external data is configured to be used with claims based authentication, the client will interact with the security token service at SharePoint in order for a claims token to be retrieved. On client computers, BDC client runtime will use the data from the Business Data Connectivity Service in order to make the connection. This will also be the method for executing the operations for client access on external systems. The cache will store information from the Business Data Connectivity Service. That is necessary for the secure connection to be made to the external data. When cache is refreshed from the SharePoint farm, the information is updated. The Secure Store Service makes it possible for users to configure security credentials. Microsoft Business Connectivity Services has the ability to pass credentials to a database as well as services that are aware of claims.

The configuration of Microsoft Business Connectivity Services can be configured so that it can pass requests for authentication to external systems. This can be done through either credentials or claims.

  • Credentials This is in a format that asks for a name and password. There are external systems that may ask for additional information to validate such credentials such as a PIN.
  • Claims External data is passed to claims aware services through Security Assertion Markup Language (SAML) tickets.

In the next BCS post, we will be discussing these details more in depth. In the meantime, since we are talking about authentication, please see the following posts on the site if you need more authentication info (or the SharePoint security category).


SharePoint Security And Authentication Part 1 – Understanding Authentication In SharePoint 2010

There are numerous authentication methods that are supported by SharePoint Server 2010. Through authentication the identity of a user can be validated. Once that occurs the process of authorization will also determine which sites, what types of content, and which of the features available a given user has authority to access. SharePoint Server 2010 can be considered a type of distributed application. There are three tiers that it is divided into which are all important to consider when determining your authentication strategy:

  • Application server
  • Back end database
  • Front end web server

Each of these tiers offers a sub-system and corresponding authentication. A user has to be authorized before they can go from one tier to the next. The provider has control over what levels of access each user has. Those providers offer various software elements that are used to support a specific method of authentication. With SharePoint 2010 you can use a classic mode of authentication or a claims based method. If you are upgrading from Microsoft Office SharePoint Server 2007 Microsoft documentation will recommended you use the classic mode, personally I think it's advisable to just go claims since you can use the identity generation service to generate Windows identities. If you plan to use a forms based authentication or one that is SAML token based you should use the claims based method. This is because the classic mode authentication will only support Windows authentication.

There are several methods of authentication that can be supported by SharePoint Server 2010. As you explore the basics of them you can decide what will work best for your organization. There are three:


This is the standard method of authentication. There are many methods that fall into this particular category. They include:

  • Anonymous This allows users to find and access resources from public areas of websites. They don’t have to provide any credentials for authentication to do so.
  • Basic This requires a user to have account credentials that have been assigned ala Windows. There is a web browser that is enabled to provide such credentials when someone makes a request. The credentials of users aren’t encrypted but sent across the network as clear-text. Therefore it isn’t recommended for the use of basic authentication to be used on any connection that isn’t secure. Always use SSL encrypting for additional security.
  • Digest This type of authentication is very similar in function to basic authentication. However, it offers a much higher level of security with it. The credentials are encrypted as they are sent across a network. The username and password can’t be deciphered along the way. Valid credentials must be given by a user that belong to the secret password string.
  • Certificates This offers an exchange of the public key certifications. The use of SSL encryption is used. These certificates are issued by a Certificate Authority. They have to fit the Public Key Infrastructure. This can be done by selecting Windows authentication in the Central Administration area. Once SSL is enabled then the configured certification can be obtained from Certificate Authority.
  • NTLM This is a requirement for any network that receives requests for authentication from client computers which don’t support Kerberos authentication. NTLM is secure and it allows for credentials of users to be encrypted before they are transmitted. Windows NT Server, Windows 2003 Server WorkGroup, and Active Directory use NTLM authentication. It may be the default and need to be disabled if you don’t want to use it.
  • Negotiate With negotiate authentication for either NTLM or Kerberos, they client has to choose one of them. The default is Kerberos. The client application has to provide a Service Principal Name and a User Principal Name for the account. When such information can’t be offered then NTLM has to be used for authentication.

Forms Based

This type of authentication offers support for management systems that need to make identifications. They aren’t based on Windows because they make it possible to work with identity management systems. These use the MembershipProvider interface. This includes:

  • Custom membership providers
  • Lightweight Directory Access Protocol
  • SQL Database

This based on ASP.NET as well as role provider authentication. With SharePoint 2010 it is only able to be used when claims based authentication is used. Forms Based Authentication can be used to be able to authenticate other user accounts too when connected to Microsoft SQL Server database. You need to register the membership provider in the Web.config file in order to use this type of authentication.

SAML Token Based

This type of authentication is claims based. It is created to support a Windows Identity Foundation. This is a set of .NET framework entities used for the implementation of claims based identity. They include:

  • 3rd Party identity providers
  • Active Directory Federation Services 2.0
  • Windows Live ID

Next, we are going to be talking about user management in this SharePoint security series.