You will also have difficulty if you attempt to backup permissions of any site that has a document library, or probably any securable object, that has a forward slash in the path.  The backup will proceed normally until it hits the errent object.  It will then ask you for authentication and finally give up the ghost with the error:

“[-2146233088] Exception of type ‘ScriptLogic.Common.SharePointAccess.Node
+AuthenticationException’ was thrown.”

 So, if you use the Quest product for permissions management, don’t create document libraries that contain a forward slash “/” with names like “My Docs/Under Review.”  

I’m going to open a tickect with Quest / ScriptLogic later this week.  I’ll post any additional info I receive from them.

UPDATE:

Apparently Quest is aware of this issue and they have created a tech note in their support database.  Their workaround is to remove all forward slashes from document libraries and lists.  However, if you really want to use the forward slash in your system, it is possible to continue to use the forward slash in your navigation links.

1. Create your document library using a forward slash.
2. Navigate to your document library and open your library’s settings page.
3. Select “Title, Description and Navigation.” 
4. Remove the forward slash from the “Name” field and save. 
5. Open your “Site Settings” page and select “Navigation” under the “Look and Feel” section.
6. Find your site link and add the slash back into the “Title” field.
7. Click “OK” and close the “Navigation” page.

Your document library link will now contain the forward slash as  before and Security Explorer will be able to parse the object properly. 

While you can always use the page viewer web part to accomplish the same thing, this method will allow you to mix SharePoint documents and file server documents in the same library.

This method does require that you edit one of your layout files in the ”…\12\TEMPLATE\LAYOUTS” directory, so make sure you back it up before you begin. 

1) Add the content type “Link to a Document” to your document library. If the content type doesn’t exist, simply create it with Document as the parent.

2) Navigate to your “layouts” folder and edit the newlink.aspx. Add the following at the end of the script section near the top of the page:

function HasValidUrlPrefix_Override(url)
{
var urlLower=url.toLowerCase();
if (-1==urlLower.search(“^http://”) &&
-1==urlLower.search(“^https://”) && -1==urlLower.search(“^file://”))
return false;
return true;
}

3) Find each occurance of the function HasValidUrlPrefix and replace it with HasValidUrlPrefix_Override.  It’s in there twice.

4) Save and restart IIS.

Now not only can you add a link to an http:// or https:// page, the override function allows you to link to docs on a file share. Use a syntax of:  file://\\fileserver\filename.doc.

If you’d rather have it open a folder instead, create a shortcut to the folder in question and create your link like this:  file://\\fileserver\shortcutname.lnk

If you really want to get fancy, you can edit the wss.resx file at:  c:\Inetpub\wwwroot\wss\VirtualDirectories\<app name>\App_GlobalResources

Find the section named ‘<data name=”newlink_badurl”>’ and change the value to read:  <value>Enter a valid document name and URL.  Valid URLs must begin with ‘http:’,  ’https:’,  or ‘file:’</value>

Remember to backup your layouts folder and wss.resx file before messing around in there!

Anyone interested in a free copy of SharePoint Designer can get it here:

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=baa3ad86-bfc1-4bd4-9812-d9e710d44f42

I’m running the site using a least priviledged model which requires me to add the contacts manually to AD.  Everything seems to work properly as long as I include some text.

I’m not sure if this is a SharePoint deficiency or an Outlook issue.  I will post a followup if I figure this out.

Event Type: Error
Event Source: Kerberos
Event Category: None
Event ID: 4
Date: 01/01/2008
Time: 12:59:00 PM
User: N/A
Computer: XXX
Description:
The kerberos client received a KRB_AP_ERR_MODIFIED error from the server XXX$. The target name used was ldap/xxx.company.com. This indicates that the password used to encrypt the kerberos service ticket is different than that on the target server. Commonly, this is due to identically named machine accounts in the target realm (COMPANY.COM), and the client realm. Please contact your system administrator.

Using Kerbtray, I determined the user was receiving a valid Kerberos ticket from the front-end server and that ticket contained the proper service principal name (SPN). It appeared all DNS, forward and reverse, all delegations and all SPNs were correctly configured. The server was simply rejecting the user’s valid credentials. Following the clues from the event description, I began looking for duplicate or conflicting SPNs. I was unable to find any.

As other farms in our environment use the same basic configuration, I started to think this might be an issue with the secure channel, or domain account of the server. Since this was a new install, rebuilding the server wasn’t a big issue. Unfortunately the rebuild didn’t help. As soon as anyone tried to authenticate using Kerberos, they received the endless logon prompts. I was completely stumped until it occurred to me that what may be going on is exactly what the event indicated, but with a bit of a twist.

The theory I came up with was that the issue was not duplicate machine accounts, but duplicate keys. As the web application is an IIS virtual server and has a DNS name that is different from the server’s NETBIOS name, it was possible the server was sending the client the public key for the web application as configured in the SPN, but attempting to decrypt the packet using the private key associated with the server’s NETBIOS name.

To test the “multiple key” theory, I assigned two additional IP addresses to the server through the TCP/IP network settings. I then used the IIS manager to change the IP address for the SharePoint web application from “All Unassigned” to one of the newly added IPs. I repeated the process with the other new IP for the Central Administration site. All other web applications were left at the default “All Unassigned.”

After making the server changes and updating the DNS to reflect the directly assigned IP address, I rebooted the server. Once the server was back up, Kerberos authentication worked perfectly.

I’m not sure why it was necessary to statically assign an IP address to the web application as we have other farms that use the shared IP without issue. Perhaps it’s a hotfix, a .NET issue, or some obscure DNS anomaly. Whatever the case may be, we have reassigned all front-end servers with static IPs as a best practice and haven’t had a Kerberos issue since. If I ever find out the exact cause of this, I’ll post an update.

SharePoint relies heavily on DCOM and as such, requires additional access rights to several DCOM objects. Microsoft makes no assumptions about your SharePoint security model and only provides default access to DCOM objects for administrators, system, and a few select user and group accounts. The SharePoint install will add the farm account to some of the DCOM objects, but unless you’ve used that account for all your SharePoint services and made that account a server administrator, SharePoint will not have the necessary permissions to operate properly.

If you didn’t follow best practice and used a single account for all SharePoint services, you could easily eliminate all these errors by making your SharePoint account a local administrator. That, however, would be considered a most privileged model installation which is not advisable for several reasons, the primary being security. If you run your web server under an account with administrator privileges and your IIS server is compromised, any malware that a hacker could get onto your machine would run under the security context of the account running the web application pool. This is especially bad if the account running IIS is also the farm account. The hacker could now potentially gain access not only to your server, but to your SQL databases as well. It’s easy to see why running your MOSS install under non-privileged accounts is a good idea.

To complete your install and eliminate DCOM errors, you will need to make several security changes to two DCOM objects and two permission changes in your shared service provider. As I stated before, simply making the accounts in question local administrators will solve the issue, but as you now know, that’s not a good idea. We want to grant the minimum object permissions possible and still have a functioning system.

If you are experiencing Event ID: 10016 and Event ID: 7888 DCOM errors you will see these entries in your event logs:

Event Type:      Error
Event Source:     DCOM
Event Category: None
Event ID:     10016
User:          NT AUTHORITY\NETWORK SERVICE
Description:
The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID{61738644-F196-11D0-9953-00C04FD919C1} to the user NT AUTHORITY\NETWORK SERVICE SID (S-1-5-20).  This security permission can be modified using the Component Services administrative tool.

Event Type:     Error
Event Source:     Office SharePoint Server
Event Category: Office Server General
Event ID:     7888
User:          N/A
Description:
A runtime exception was detected. Details follow.
Message: Retrieving the COM class factory for component with CLSID {61738644-F196-11D0-9953-00C04FD919C1} failed due to the following error: 80070005.

These errors occur when the application pool accounts do not have sufficient privileges to the IIS WAMREG admin service. To correct the errors, add local launch and local activation permissions for all application pools to the IIS WAMREG object.

You may also receive this error for:
CSLID {3D42CCB1-4665-4620-92A3-478F47389230} which is the OSearch object that is discussed below.

To permission the IIS WAMREG object, open “Start/Settings/Control Panel/Admin Tools” and double-click on “Component Services.” Navigate to “DCOM Config” under “My Computer” and right-click on the “IIS WAMREG admin Service” object and select “Properties.”

Next, select the security tab and edit “Launch and Activation Permissions.” Make sure that your farm account (account that accesses your SQL database) and all your application pool accounts are granted both local launch and local activation rights. Select “OK” then “OK” again when finished.

If you are experiencing Event ID: 6398 and Event ID: 6482 errors you will see these entries in your event logs:

Event Type: Error
Event Source: Windows SharePoint Services 3
Event Category: Timer
Event ID: 6398
Date: 01/01/2008
Time: 00:00:00
User: N/A
Computer: XXX
Description:
The Execute method of job definition Microsoft.Office.Server.Search.Administration.IndexingScheduleJobDefinition (ID d2784cd2-20cf-466f-b5f0-365e65cdf542) threw an exception. More information is included below. Retrieving the COM class factory for component with CLSID {3D42CCB1-4665-4620-92A3-478F47389230} failed due to the following error: 8007000e.

Event Type: Error
Event Source: Office SharePoint Server
Event Category: Office Server Shared Services
Event ID: 6482
Date: 01/01/2008
Time: 00:00:00
User: N/A
Computer: XXX
Description:
Application Server Administration job failed for service instance Microsoft.Office.Server.Search.Administration.SearchServiceInstance (3ede7ca8-f6f6-432a-bd4b-cd8478ab6810).

These errors occur when your default content access account (account used for search and indexing) and your shared service provider service account do not have sufficient launch, activation and configuration permissions to the OSearch DCOM object. Referring back to the images above, locate the OSearch object and apply the following permissions:

1. Grant local launch and activation rights to your farm, default content access and shared service provider service accounts.
2. Grant full control to the configuration permissions to your farm and default content access accounts.

Finally, there is one other issue related to profile imports that some installations experience. This issue is solved through SharePoint permissioning in the SSP.

If you are experiencing Event ID: 7888 runtime exception errors you will see these entries in your event logs:

Event Type:    Error
Event Source:    Office SharePoint Server
Event Category: Office Server General
Event ID:    7888
Date:        01/01/2008
Time:        00:00:00 AM
User:        N/A
Computer:    XXX
Description:
A runtime exception was detected. Details follow.
Message: Access Denied! Only site admin can access Data Source object from user profile DB.
Techinal Details:
System.UnauthorizedAccessException: Access Denied! Only site admin can access Data Source object from user profile DB.

This error is caused by insufficient SharePoint permissions for your default content access account. This problem is corrected in Central Administration under your shared service providers “Personalization Service Permissions.” Open your Central Administration site and navigate to: “Shared Services Administration: Primary SSP > Manage Permissions.”  (Note: your SSP may be named differently)

Give your default content access account and your search service account “Manage User Profiles” rights. In my case, I use the same account for the search service as well as the default content access account. If you use different accounts, add permissions for both.

This concludes the basic permission granting tasks required for DCOM objects under a least privileged MOSS install. Depending on the particulars of your install, you may be required to troubleshoot additional DCOM issues. The basic troubleshooting methods include identifying the object in question and identifying the actual error. Keep in mind, the event ID is not the error; it’s the event the error triggered. For our IIS WAMREG and OSearch issues above, the actual error was “80070005.” This is an access denied error and one of the most common DCOM issues. If you are seeing 8007005 errors listed in your events, you can be sure it’s permissions related. Unfortunately, Microsoft doesn’t tell you right off what object is causing the trouble. Instead you are given a CSLID identifier and it’s up to you to figure out what it is.

Luckily, the human readable names of CSLIDs are easy to identify. Simply select the CSLID, including the {}’s, open the registry editor and search for it. If you carefully poke around, you will eventually be able to associate the CSLID with the name of the DCOM object.

If you have any additional questions about this article or about the least privileged model in general, please leave a comment or post to our forum. I will attempt to answer your questions as soon as possible.

I needed a method that wouldn’t require additional hardware or third party tools so I decided to try a simple export / import with stsadm. The procedure was much easier than I expected and after several test runs, I was ready to clone the site. The entire process took less than an hour (1GB data) and except for a few minor issues, I was able to create an exact replica of the production environment with a new application name.

Although this is a good method for renaming or cloning applications, I want to stress this is not a good method for building a development environment. Since all the web parts, databases and hardware are still shared with the production system, any changes to the base SharePoint environment of the clone will affect the original. A development or test environment should always remain isolated in its own farm on different hardware.

Procedure to create a duplicate MOSS instance in the same farm

1. Verify you have a proper backup of your source application.
   
2. Create a new target web application using a different name. For example; if the source application is http://sourceapp/, then create an application named http://targetapp/.
3. Create a site collection at the root of your new target application using the same template that was used to create the source application.
   1. Note: If you are using custom templates, this template must be the same version as the source site’s template.
4. Export the source site content and structure.
   1. stsadm –o export –url http://sourceapp/ –includeusersecurity –haltonwarning –filename c:\filename.cab
   2. You must export each sub-site separately. I.e. http://sourceapp/, then http://sourceapp/site1, etc.
5. Deploy and activate all solutions and web parts on the newly created target web app.
6. Take target server’s database offline at “Central Administration > Application Management > Content Databases > Manage Content Database Settings.”
   
7. Import each exported cab file into the new web application.
   1. stsadm –o import –url http://targetapp/ -includeusersecurity –haltonwarning –filename c:\filename.cab
   2. Repeat for each sub-site.
8. Put database back online.
9. Pay particular attention to Issue #2 outlined below.

Issues you may encounter

1. Due to small template inconsistencies, some sites may display the following page:

   

   This problem can be fixed by copying the “Default.aspx” page from a working site (in the same web app) to the root of the non-working site. This is accomplished through the “Manage Content and Structure” page of the web app. You must first delete the corrupted “Default.aspx” page before copying in the “good” page.

2. Please be aware that any links in the source app that are entered with the FQDN, will retain that FQDN when the site is exported/imported. This could allow the accidental editing of the source application’s data from the target application. The user will click the link thinking they are accessing the page on the duplicate server when they are actually redirected to the source server.

   To correct this issue, the source server should be carefully edited to replace all FQDN links with relative URLs prior to export. Go to the navigation page of the effected site and remove the leading host header. For example: change “http://targetapp.mydomain.com/site1/Default.aspx” to “/site1/Default.aspx.” This ensures the link is directed to the local site and not the original site. This issue is primarily of concern to user created links. SharePoint created links are always relative URLs.

3. Custom header icons at the root of the sites may not be active even though they are imported into the web app. Correct this from the “Title Description and Icon” page of each effected site. Simply remove the reference to the default SharePoint icon and save.

]]> http://www.os.com/blog/cloning-or-renaming-a-moss-web-application/feed/ 1 http://www.os.com/blog/microsoft-sharepoint-updates-released/ http://www.os.com/blog/microsoft-sharepoint-updates-released/#comments Wed, 16 Jul 2008 14:16:53 +0000 Craig Shrimpton http://www.os.com/?p=15 Microsoft has just released updates to both Sharepoint 2007 and Windows Sharepoint Services 3.0.  The update addresses several performance and scalability issues as well as adding new search features such as federated search and a unified search admin dashboard.

Microsoft recommends applying these fixes as soon as possible.

You can find the patches at:

32 bit

Infrastructure Update for Microsoft Office Servers (KB951297)

Infrastructure Update for Windows SharePoint Services 3.0 (KB951695)

64 bit

Infrastructure Update for Microsoft Office Servers (KB951297)

Infrastructure Update for Windows SharePoint Services 3.0 (KB951695)

Recently we experienced a rash of authentication issues when some users accessed a custom SharePoint web part that retrieves data from a MOSS farm hosted at a remote site. Although the target farm is in the same Active Directory (AD) domain as the source farm, this type of credential passing between IIS servers will introduce the “double-hop“ issue if the default Windows authentication method is set to NTLM. When a user accesses an IIS server in farm “A” and that server needs to pass the users credentials to an IIS server in farm “B,” authentication will fail unless the mechanism used is Kerberos. It doesn’t matter that both farms are in the same AD domain, only Kerberos will successfully avoid the “double-hop” issue.

In order for Kerberos to successfully pass credentials between IIS servers in different farms, both farms must be configured for negotiated authentication and have direct access to the same key distribution server (KDC). This means, both farms must either be in the same domain, or have a trust between domains. Kerberos doesn’t operate across un-trusted domains.

Knowing these requirements, we configured each MOSS farm for negotiated authentication and after solving several issues configuring Service Principal Names (SPNs) that I will discuss in a future post, we finally got our new custom web part working. After a couple of weeks, however, the help desk began to receive reports from several users that the web part was failing with authentication errors. Not finding anything wrong with the user’s profile or server permissions, the help desk issued its standard “reboot and try again” remedy when encountering unknown gremlins. This always seemed to fix the problem, at least temporarily. Unfortunately, after about a week, the support calls returned and it was usually the same users. That’s when I was put on the case.

Knowing this was an authentication issue and the authentication method was Kerberos, I grabbed my trusty kerbtray.exe and headed over to the user’s PC. It didn’t take long to figure out what was going on. Just looking at the Kerbtray icon in the system tray told me all I needed to know, “Kerberos – no credentials.”

“Do you logoff your PC when you leave the office?” I asked. “No” came the reply. “Do you ever logoff your PC?” I followed. “Well, only when it locks up or crashes” answered the now puzzled user. Finally, sounding somewhat like an irritated cop, I quipped “Well, there’s your problem, you’ve let all your Kerberos tickets expire.”

In some environments where applications are configured solely for Kerberos authentication, this may be a common problem. Contrary to what the Windows dialog box indicates when you issue the Ctl+Alt+Del, Windows doesn’t really have a log on / log off routine in the classic sense like say, a Unix shell. Instead you are granted access to resources until you either invalidate that access, or in the case of Kerberos, your tickets expire. This is what was happening to our users who were perpetually “logged in.”

With Kerberos authentication, when a user requests data from a remote server, that user’s PC will send a request for a session key to the local domain’s key distribution center (KDC). The KDC prepares two copies of the session key that both client and server will use for the authentication process. The client’s session key is encrypted with the client’s long-term key and the server’s session key is encrypted with the server’s long-term key. The long term key is derived from the user’s password.

The KDC then encrypts the client’s session key with the key it shares with the KDC. It also encrypts the server’s copy of the session key, along with the authentication data for the client with the key the KDC shares with the server. This packet then becomes the session ticket. Both the client’s session key and the server’s session ticket are then forwarded to the client PC.

When the client is ready to communicate with the server, the client decrypts its copy of the session key and uses it to encrypt an authenticator packet. The authenticator, along with the session ticket is forwarded to the target server. The authenticator and the session ticket now become the client’s credentials for access to the server. The server decrypts the session ticket, extracts its session key and decrypts the authenticator. If the authenticator decryption is successful, the server will allow access to the requested resource. If mutual authentication is required, the server will use the session key to encrypt a timestamp which it returns to the client. If the client is able to decrypt the timestamp and the time is within the configured limits, the client will know it is communicating with the proper server. For a more detailed explanation of the workings of Kerberos, see: http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/distrib/dscd_aun_yfet.mspx?mfr=true

Why did this problem only manifest itself with the custom SharePoint web part? Because all the other applications the user was using, such as Exchange, SharePoint, Windows file and print services, all fell back to the default NTLM authentication, which doesn’t expire until the user logs off the session. Only the application, which in this case was a web part, would fail when the Kerberos ticket expired. Interestingly, this NTLM fallback will occur even when the initial authentication was Kerberos.

In our environment, the tickets are valid for 10 hours and will automatically renew for 7 days. If the user doesn’t re-authenticate within the 7 day period, the tickets will no longer automatically renew and will expire and access to the Kerberos enabled service will fail.

The moral of the story is when depending on Kerberos for an application that has no NTLM fallback, make sure your users logout and login at least once per week. Actually, they should logout or lock their PCs whenever they leave them unattended. That’s just good security practice.

Kerberos, while somewhat tricky to configure, will solve the double hop issue as it allows for impersonation and delgation. In addition, it can authenticate both the client and the server. Authenticating both parties of the transaction ensures the requests are directed only to those servers and services the end user trusts. However, this feature is not active by default. You must allow the service accounts running on the web server to use impersonation by activating the trust for delegation settings for both the service account and server in “Active Directory Users and Computers.” A full tutorial on implementing Kerberos in a SharePoint environment is in an upcoming post.