Users can create alerts to notify them of changes to list items (item-level alerts), documents, lists (list-level alerts), or document libraries.

At times we would see the Alerts coming in with various DisplayName of the sender . I would like to explain the logic being this behavior .

Here are how you would get various alert emails . Notice the Changes in Display name of the sender.

Example 1 : Subscription to a SharePoint Group
---------------------------------------------------------------

Example 2 : Subscription to a SharePoint Group
-----------------------------------------------------------------

Example 3: Subscription Alert for a document library / Discussion board etc
---------------------------------------------------------------------------------------------------

Example 4: Subscription Alert for a document library / Discussion board etc
-----------------------------------------------------------------------------------------------------

Note : The From address in the Outgoing Mail settings on the Central admin & Web application outgoing Email settings page is : MossAdmin@BA.com

The Logic behind this behavior

1. When we subscribe to a SharePoint alert for a list , Discussion Board , Document library etc  share point would Append the Title of the site as the Display name of the Sender & send the SMTP message accordingly  . See example 3 , here " Contoso Collabration Portal " is the title of the site .  You may alternatively see the DisplayName as Senders Name ( Example 4)  as seen in active directory .

2. In case of addition made to a group etc , SharePoint does append the title hence DisplayName would either be the Sender's address ( Example 1)  or Senders Name  as seen in active directory ( Example 2)  .

Finally the DisplayName of the sender as seen by the recipient of the message depends upon how mail is sent to exchange server & its  configuration .
It should be noted that all versions of exchange do not try to resolve the sender of the message when message is sent anonymously while the recipient is always resolved as we have to deliver email to him . But if the message is sent to exchange server using authentication , exchange would try to resolve the sender against an object in AD & if found would change the DiaplayName as it exists on the object .

How to Fix it

If we  need to Resolve the DisplayName of the sender of the alert to the object in AD ( Example 2 & 4)  , we need to ensure message is received by exchange is forcefully resolved .

For Exchange 2000/2003 :
---------------------------------

1. Go the Exchange System Manager

2. Expand Servers Container & go the Exchange server in question.

3. Expand Protocols & SMTP

4. Go to properties of Virtual Server , Access tab

5. Click on Authentication Tab & Ensure that " Resolve anonymous e-mail" checkbox is checked .

For Exchange 2007 :
--------------------------

To achieve this in exchange 2007 requires that mail be received by exchange via a Externally secured Connector , mails received via this connector are resolved for Sender of the message .  This  is very explained here

Allowing application servers to relay off Exchange Server 2007

Review & evaluate your current AD infrastructure to determine the existing trust relationships as this information would be critical to determine the behavior of People Picker & configuration required . If you need assistance to figure out the type of Trust or Transitivity , please refer to TechNet articles in References section

Querying Additional Forest or Domains

Scenario 1 : The SharePoint server belongs to a forest and/or domain that has 2-way trusts established with other forests or domain

The accounts of the users accessing SharePoint therefore belong to those trusted domains and since the trust is 2 way, the identity of the IIS application pool is also capable of authenticating against those trusted domains. Hence all domains and forests with a two-way trust relationship are available without any additional configuration steps as People Picker searches all two-way trusted forests and all two-way trusted domains by default .

Note : If there is a Forest wide Trust between two forests & users and/or resources belong to Child domains , still no configuration is required at the SharePoint level as Forest Trust creates a transitive trust relationship between every domain in both forests.

Scenario 2 : The SharePoint server belongs to a forest and/or domain that has 1-way trusts established with other forests or domain

In order to instruct SharePoint to query those trusted domain or forests we need to configure access to them by using the Stsadm command-line tool and selecting an account to use when accessing each forest or domain. Those credentials must be from the forest/domain to be queried or from a trusted domain, as long as it is allowed to authenticate and is not denied to logon remotely.

You can use a different account for each target domain or forest, or the same account for all domains and forests.

1. On every front-end Web server on a farm, at a command prompt, type the following command, and then press ENTER:

STSADM.exe -o setapppassword -password key

Note: The account and password used to access each domain or forest is stored on each front-end Web server in the farm . This key is an encryption string that is used to encrypt the password for the account that is used to access the forest or domain . This encryption string must be the same for all servers in the farm, and unique for each server farm in a deployment with multiple farms.

2. On a front-end Web server, at a command prompt, type the following command, and then press ENTER,

STSADM.exe -o setproperty-propertyname peoplepicker-searchadforests -propertyvalue <Valid list of forests or domains> -url <URL of the Web application>

Note : You have to provide a valid list of forest/domains to be queried as well as the credentials to do so, this can be specified as below .

forest:DnsName,LoginName,Password

domain:DnsName,LoginName,Password

You can add multiple forests and or domains by listing multiple domains or forests in the format Forest/Domain:DnsName,LoginName,Password separated by semicolons. For e.g.

STSADM.exe -o setproperty-propertyname peoplepicker-searchadforests -propertyvalue“forest:Contoso.com,Contoso\User1,PasswordofUser1; domain:Fabrikam.com,Fabrikam\User2,PasswordofUser2” -url http://webapp

Note : You can omit the username and password if the application pool identity already has access to Target domain or forest, this would be the case where application pool identity is from the Trusted forest or domain itself .

Special Case : If the application pool identity is from the Target forest or Domain you would be able to resolve all users from target domain & forest but unable to resolve users from local SharePoint domain using the Browse option ( Checkname will still work **) & would require to specify the local Domain or Forest via the STSADM Command ,although without a username & password .

Key Observations & Considerations :

1. In the above example notice how each block is separated by semi-colons and each element in a block is separated by comma.
2. There is no space between peoplepicker and -searchadforests .
3. Ensure that you have valid credentials for each forest/domain & passwords do not contain commas.
4. If you need to query a forest the “forest” argument is specified, a forest-trust must be in place and/or if you need to query a domain the "domain" argument is specified , an external trust will suffice .
5. If you configure a forest to be queried, it is not necessary to declare all or some child domains separately, they will be queried anyway .
6. If “forest” is specified, the Global Catalog Service will be used to perform the query, if “Domain” is specified, the LDAP service will be used instead.
7. The DC Locator process used as discussed in Default configuration is still applicable BUT is extended beyond the local forest boundaries. This means that the SharePoint servers must be able to resolve names of remote forests/domains domain controllers (SRV records and A records) , hence DNS must be correctly configured .
8. Once you have configured peoplepicker for a web app & If you still wish to query the forest/domain SharePoint belongs to, you’ll have to add it as part of the parameter too.
9. If you use “Selective authentication” or “SID Filtering” in order to restrict authentication through trusts, you must make sure that the IIS application pool identity is allowed to authenticate against the remote forest/domain it queries.
10. If you add a cross Forest /Domain user to SharePoint Site there is an entry for the same in the Userinfo table for that web application . If later the trust is removed , you my still be able to Checkname that user as it already exists in SQL but cannot add it to the site & assign permissions etc .

To Remove the People Picker entry for a web Application , Run the STSADM command with blank property value i.e. Start & End double quotes with no space .

STSADM.exe -o setproperty-propertyname peoplepicker-searchadforests -propertyvalue“” -url http://webapp

Here is flow Chart which depicts the process flow of configuring People Picker for cross forest scenarios .

**Note: The people picker settings added by Stsadm peoplepicker-searchadforests command are honored by Browse feature while the checkname still would query all domains local & trusted & would be able to enumerate users provided the application pool identity has access to it . Once you add the People picker entry the ability to query local share point Domain /Forest is lost & that too needs to be added in the list of peoplepicker-searchadforests command.

Refrences:

TRUST TYPES

FOREST TRUSTS

Peoplepicker-searchadforests: Stsadm property

Select users from multiple forest domains

How to configure Active Directory to allow anonymous queries

Coming in Subsequent blogs other Peoplepicker configuration commands & troubleshooting Peoplepicker issues . Hang On!

The people-picker is a SharePoint interface responsible for querying repositories for identities or groups in order to grant them permission in the SharePoint application. Site administrators and other users use the People Picker Web control to select people and groups when assigning permissions. There are two possible ways to add users, via the checkname or via the browse feature.

The checkname is the icon with a messenger guy and a checkmark :

The browse feature is the book icon:

Let's get's into the internals of what happens when you  go add a user /Group & say Checkname or Browse

Default Configuration , How this works

1. Site administrator or other users submit a query to the people-picker web control.
2. The WFE performs a DNS query in order to locate a domain controller hosting the Global Catalog Service.
3. Once located it tries to connect to it . This first connection, which is anonymous, will report to the SharePoint server extra information over the DC it contacted. It will include various LDAP information, the its exact capabilities as well as the authentication mechanism it supports. This entry point is known as the “Root” or “RootDSE” .
4. If the AD requires authentication, which is by default the case, SharePoint will authenticate using the context of the IIS application pool the SharePoint web application runs under. It can be Local system or Network Service or a specified domain user .
5. The WFE sends an LDAP Global Catalog Search Request to the DC asking for any match in the whole subtree for user or group objects with attributes that contain the search string (a wildcard search version of the User display name) in one of the following attributes:

# User objects: 'name', 'displayName', 'cn', 'sn', 'SamAccountName', 'mail', SMTP or sip 'proxyAddresses' attributes.

# Group objects: 'name', 'displayName', 'cn', or 'SamAccountName' attributes.

Here is how the frame looks like a Network capture ( filtered for LDAP traffic ) , searching for a string " Teds" which is for a user name Ted Simpson . Check out list of attributes requested to be returned for each record & server Controls Specified .  The Browse feature will use the LDAP filter to search for a user .

The Check name option will try to connect to one of the dc’s in its domain & tries to do a SID lookup using the windows API LsarLookupNames4 .The LsarLookupNames4 method translates a batch of security principal names to their SID form. This traffic is encrypted and the Web server and domain controller talks via RPC.  If unsuccessful  it falls back to LDAP query as used by Browse ( The  LDAP Query Filter used is the same as described below but without the wildcard expression ‘ * ’ ).

LDAP Query Filter

(&(objectCategory=person)(objectClass=user)(!(userAccountControl:1.2.840.113556.1.4.803:=2))(|(name={teds}*)(displayName={teds}*)(cn={teds}*)(mail={teds}*)(sn={teds}*)(SamAccountName={1}*)(proxyAddresses=SMTP:{teds})(proxyAddresses=sip:{teds}){2}))", "(&(objectCategory=person)(objectClass=user)(!(userAccountControl:1.2.840.113556.1.4.803:=2))(|(name={teds})(displayName={teds})(cn={teds})(mail={teds})(samAccountName={teds})(proxyAddresses=SMTP:{teds})(proxyAddresses=sip:{teds})))", "(&(objectCategory=person)(objectClass=user)(!(userAccountControl:1.2.840.113556.1.4.803:=2))(|(mail={teds})(proxyAddresses=SMTP:{teds})))"), new SearchParameter("(&(objectCategory=group)(|(name={teds}*)(displayname={teds}*)(cn={teds}*)(SamAccountName={1}*)(mail={teds}*)(proxyAddresses=SMTP:{teds}){2}))", "(&(objectCategory=group)(|(name={teds})(displayname={teds})(SamAccountName={teds})(mail={teds})(proxyAddresses=SMTP:{teds})))", "(&(objectCategory=group)(|(mail={teds})(cn={teds})(proxyAddresses=SMTP:{teds})))"), new SearchParameter("(&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=2147483648)(|(name={teds}*)(displayname={teds}*)(cn={teds}*)(SamAccountName={1}*){2}))", "(&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=2147483648)(|(name={teds})(displayName={teds})(cn={teds})(samAccountName={teds})))

 

The query conditions as seen in the above LDAP query Filter are :

1. We are searching for a  user or a group
2. If it is user, it must not be disabled &  at least one of the following attribute must begin with the input the user provided: name, displayName, cn, mail, sn, SamAccountName, proxyAddresses etc
3. If it is a group, at least of  the following attribute must begin with the input the user provided: name, displayname, cn, SamAccountName
4. if it is a group, it must be a security group (domain local, global or universal), not a distribution group

6.  The DC responds with an LDAP Global Catalog Search Response containing both user and group objects that match the search string & results are displayed . Check out the responses to the list of attributes request in the search query

After the Successful LDAP response in either case ( Browse or Checkname )  we go & verify the user based on the SID value ( Value of Object Sid ) obtained as a result of the query using the Windows API LsarLookupSids3 . The LsarLookupSids3 method translates a batch of security principal SIDs to their name forms.  Once this is successful we move forward in the query process else fail to display names.

After the the LDAP response is received & successful verification of the user via ObjectSid  , a lot more is done  before the result is displayed in the PeoplePicker UI . For details on what is the actual process flow & stuff happening in the SQL server in terms of Stored procedures being executed in the background etc,  please refer to the following links from Microsoft TechNet .

Active Directory: People Picker Check Name UI

Active Directory: People Picker Browse Display UI

References :

LsarLookupSids3

LsarLookupNames4

How to query Active Directory by using a bitwise filter

Searching for Groups by Scope or Type in a Domain

I will be covering how to configure PeoplePicker to query Additional forest or Domains in the next post & Troubleshooting People Picker Issues in the subsequent ones . So keep watching for this Space

All you want to know about People Picker in SharePoint ( Functionality | Configuration | Troubleshooting ) Part-2