[MOSS2007] Cross domain Manager property

In an Active Directory, it is possible to configure a manager for a specific user. SharePoint is able to use this information and show you a hierarchy on a users MySite. Unfortunately this functionality has a limitation caused by Active Directory.

Active Directory issue
Within Active Directory It is only possible to select users (or contacts) that are in the same forest or domain as manager. So if you have (like at a customer of mine) a multi forest, multi domain environment, with Forest Trusts between all forests, you cannot select a user from domain 1 in forest 1 as the manager of a user in domain 2 in forest 2.

Customer situation
At the customer, they are using two tools to manage the data in AD:
1.) A replication engine to replicate users in one domain as a contact in the other domain. These contact are used for Exchange in that domain.
2.) A self service portal where users can configure their own data, including manager. When a user changes his/her manager, this is changed in the domain that has been marked as master domain. If the manager does not exist in that domain as a user, the contact in that domain is selected.

SharePoint behavior
This situation causes SharePoint to "generate" two different kind of hierarchy trees. One for domain1 and the other for domain2. Because contacts are not treated as users in SharePoint (as it shouldn't), when browsing through the hierarchy you never end up with the real manager account.

Then how to solve this issue
In order to work around the issue, we have modified the replication engine in such a way that the replication engine performs the following steps:

1. Check the manager property and retrieve the master account in the other domain
2. Configure the master account name in a separate AD property, which is not used
3. Configure SharePoint to import that AD property as the manager, with the format <domain>\<userid> (configurable in property mapping settings)

This mechanism now works like a charm: Managers are imported correctly and more important, the hierarchy tree is displayed correctly!!

[MOSS2007] Import connections only shows a few domain controllers

[ISSUE]
At my current project we experienced the the issue that only one domain controller was listed when trying to configure SharePoint to use a specific domain controller (Shared Services /ssp/admin/_layouts/EditDSServer.aspx?dn=<domain name>).

[EXTRA INFORMATION]
The specific domain has about 75+ domain controllers world wide, so the fact that SharePoint lists only one is something strange. Because the listed domain controller isn't the closed one, SharePoint will always generate WAN traffic and imports will be slower.

[CAUSE]
After a long period of troubleshooting we discovered that the Active Directory guys had deleted all _ldap and _kerberos DNS entries (except for the one domain controller) in _tcp.dc._msdcs.. They have done this to make sure that computers that log on from an unmanaged site (which IP address is not configured in the AD subnets) always use the central AD server instead of randomly choose one and generating unnecessary WAN traffic. As soon as we added some extra _ldap DNS keys, these popped up in the list.

[SOLUTION]
We added the _ldap and _kerberos DNS entries for all domain controller in our 2nd datacenter. We are now able to select the closest domain controller.

[MOSS2007/WSSv3] Kerberos, CNAMEs and SharePoint

When trying to configure Kerberos on the environment, I ran into the following issue:

[ISSUE]
When opening the SharePoint site from another machine, Internet Explorer logs on with NTLM anyway. When opening the site from the server, a logon prompt appears which won't accept any credentials. After three times, an Unauthorized message is shown.

[TROUBLESHOOTING]
I had all Service Principal Names configured as described in Configure Kerberos authentication (Office SharePoint Server). To get more information I enabled Kerberos logging (How to enable Kerberos event logging), which resulted in a lot of events in the System log:

Source: Kerberos
Type: Error
Event: 3
Message: "A Kerberos Error Message was received:
on logon session <user>
Client Time:
Server Time: 12:5:19.0000 10/30/2008 Z
Error Code: 0x34 KRB_ERR_RESPONSE_TOO_BIG
Extended Error:
Client Realm:
Client Name:
Server Realm: <domain>
Server Name: krbtgt/<domain>
Target Name: krbtgt/<domain>@<domain>
Error Text:
File: e
Line: 6c0
Error Data is in record data.

[SOLUTION]
After using Network Monitor v3.2, I found that the Kerberos traffic from the server was requesting a different Service Principal Name than the url of the SharePoint site. The error which was also listed in the eventlog was returned by AD. The SPN that was send, contained the CNAME value instead of the original URL. Using Google, I found the following article:
The Problem with Kerberos Delegation (Section: "Confused Yet?")

This article states the following:

• Computer running IIS: ws.identitychaos.com (WS)
• Service Account hosting the Central Admin app pool: idchaos\svc.wss.farm
• Host Header for Central Admin: spca.identitychaos.com
• SPN's registered to idchaos\svc.wss.farm
• HTTP/spca
• HTTP/spca.identitychaos.com

Using a CNAME, when IE requests the SPN, spca.identitychaos.com resolves to ws.identitychaos.com (the alias resolves to the host) so IE asks AD, "tell me which account has an SPN registration of HTTP/ws.identitychaos.com" and it gets the WS computer account, not the service account. How do you fix it? You use A records instead of CNAME's.

After changing our CNAME records to A records, all Kerberos issues were resolved.

In other words:
Do not use CNAMEs when using Kerberos authentication!!!

[MOSS2007] Issues with web part toolbars and audiences/Active Directory groups

Over the past few days I ran into some small but very annoying issues with SharePoint 2007:

The first is with a document library web part. After placing a document library web part on a page and configuring it with a “Full Toolbar”, I wanted to change some fields which are shown in the web part. I opened the “Modify This Web part” menu, clicked “Edit current view”, made some changes and clicked Ok. When the web part page was shown, the Full Toolbar had switched back to the Summary Toolbar. Also the “Modify This Web part” sidebar was closed. It meant I had to open the sidebar again and configure the Full Toolbar again. Very annoying behavior!

The second issue is when you are using Active Directory groups in audiences. In SharePoint 2003, using audiences meant creating special audiences which are compiled according to predefined rules. As of SharePoint 2007 it is possible to use AD groups directly as an audience. When a user is a member of that group, the item or web part is shown to the user.
On a page I had several web part configured with AD group audiences. In the AD I moved the groups to a different OU and after a profile import my web parts weren’t shown to anyone any more. Some troubleshooting revealed that the groups were in the profile list twice, one for the old OU and one for the new OU. Because they had exactly the same name, I could not determine which group was the correct one. I added both groups to the web part audience to get it working again.
Looks like SharePoint is looking at the absolute DN when using AD groups in audiences. Now I am hoping the “old” groups will disappear automatically……not really sure.