Over the past few months we’ve seen a growing trend in our office.  Users are turning in their Blackberries for iPhones.  At first, this created a bit of concern for our helpdesk staff as we don’t officially support non-Blackberry devices for mobile email access.  However, with the growing demand for alternative mobile devices and the iPhone’s full support for ActiveSync, it’s starting to look like that’s about to change. 

In the past we’ve allowed ActiveSync for those enterprising users who were savvy enough to configure their own Windows Mobile devices with the understanding that if they were unable to get it to work, they’d need to switch back to the officially supported Blackberry.  However, we found that most users who had made the switch off Blackberry had relatively fewer issues than those users remaining with our Blackberry Enterprise Server (BES) environment. 

With BES, we’ve had occasional difficulties activating devices, or devices losing sync with RIM’s servers, the latter usually occurring after a mail box is moved between mail stores.  Naturally this always happens to senior management when they are sitting in an airport in the middle of nowhere.  This isn’t a problem with ActiveSync and Direct Push.  If the user has a connection with Internet access, the service always works. Even with all its minor issues, BES is still the standard for many companies worldwide and is basically a very good product.  However, with the user demand for alternative devices rising, it’s time to see if Microsoft’s ActiveSync and Direct Push technology is also up to the task.

Is the iPhone ready for the enterprise?

One of the main issues affecting adoption of the iPhone, iPad, Droid, or any other ActiveSync capable device is the question of remote management.  If the device is lost or stolen, can we remotely wipe the device?  What about password changes?  Will the help desk receive endless calls for password resets on locked accounts?

Surprisingly we have found many of these worries unfounded.  Even without a third party mobile device manager (MDM), managing ActiveSync devices from the Microsoft Exchange platform is relatively pain-free.

Beginning with Exchange 2003 SP2, Microsoft has continuously added a host of new ActiveSync features with each release.  With features such as password enforcement policies, remote device wipe and especially Direct Push technology, ActiveSync can now closely emulate RIM’s always connected mail service. 

Finally, with the release of Exchange 2010, ActiveSync can now replace all the functionality of BES save one very important capability which is the ability to access internally published web services through the BES.  We have found this feature indispensible for the publishing of dashboards and key performance metrics hosted on internal web servers.  While you can emulate this function with the use of a VPN connection, Blackberry’s transparent access is top notch. 

For those organizations requiring a more robust management solution, especially if they want to maintain a mix of ActiveSync and Blackberry devices, the deployment of a third party MDM is highly desirable.  MDMs such as BoxTone and MobileIron enable the enterpirse to manage all of their disparate mobile devices from a central server.  Some of the core features MDMs provide are:

• Over the air firmware updates
• Diagnostics and troubleshooting
• Remote provisioning and software installation
• Enforcement of security policies
• Backup/restore
• Mobile asset tracking and management
• Remote lock and device wipe

The ability to deploy Blackberry, Windows Mobile, Android, iPad and iPhone on a sihgle management platform makes a compelling business case. 

While many organizations will resist the growing demand for alternative Smartphones, it appears this trend is here to stay.  Users who are willing to spend their own hard-earned money on iPhones, iPads and Droids demonstrate the value derived from the feelings of empowerment and increased productivity.  For the highly mobile user, this is a worthwhile purchase and marks a trend that will only get stronger as mobile device technology advances.

One of the potential issues of data sprawl is the loss of data relevancy.  As the volume of historical data increases within the active data set, a smaller and smaller percentage of that data is relevant and timely.  When the active data set becomes a very small percentage of the total, finding and retrieving active documents becomes tedious and time consuming.  If data is difficult to find and retrieve, it ultimately leads to the unintentional duplication of the data when users are forced to create additional copies that are easily accessible for them.  This behavior best serves the data de-duplication and storage vendors.

Backup and recovery issues can also be a source of major frustration when historical and active data are mixed.  Each full backup will create a tape with duplicate content that must be cataloged and stored off site.  No doubt literally hundreds of copies of the same historical data are stored at offsite facilities, when a single backup copy would be sufficient.  Maintaining unnecessary backup archives adds to storage and management costs, but the real concern is how this puts the active and relevant data at greater risk.

The repeated backup of historical data often increases the window of time required to archive all the data to an unacceptable level.  The continual struggle with rapidly closing backup windows is a major complaint at IT shops around the world.  Unfortunately, backup technology has not kept pace with storage growth which is now estimated to average thirty percent annually.  This uncontrolled growth is forcing storage administrators to implement various stopgap solutions such as virtual tape libraries, which only consume more disk storage, and de-duplication schemes, which while reducing total storage requirements, do nothing to address data relevance.  If your organization is facing uncontrolled data growth, a coordinated solution to the sprawl is achievable through the implementation of a sound data lifecycle management program.

SearchStorage.com defines data life cycle management (DLM) as: “…a policy-based approach to managing the flow of an information system’s data throughout its life cycle: from creation and initial storage to the time when it becomes obsolete and is deleted.” DLM systems usually provide a mechanism to automate the organization of data into hierarchical storage tiers based on pre-defined policies and rules.  They usually include intelligence that enables the system to automatically migrate data between storage tiers based on access requirements.  Generally, data that is newer or more frequently accessed is stored on faster, but more expensive storage while older, less relevant data, is stored on less expensive and slower media.

The tiering of data allows the organization to better manage its active data set for relevancy and security.  Older data is transferred to locked stores and backed up once, thus greatly reducing the backup window for the active data set.  This strategy is especially useful for e-mail as smaller mailboxes mean better performance, better searching and better recovery.  With a sound data archiving methodology, data quotas can be increased, or even eliminated.

While data lifecycle management is not a product but a process, there are several solutions available to ease the management burden of implementing a DLM plan.  Over the past year, I been testing the Symantec Enterprise Vault product and I believe it would be a good fit in many environments.

Enterprise Vault (EV) is an archiving solution that helps businesses to organize data according to preset policies.  By offloading historical data to a secure storage platform, organizations can achieve compliance, performance and stability of their data environment.  In addition, compliance is enhanced as all data would be readily available and searchable if retrieval of historical e-mails or files is required.

Enterprise Vault is a highly configurable archiving solution that manages data for not only E-mail, but file servers, SharePoint and Livelink.  These are all systems within many environments that require careful storage management.  In addition to EV’s archiving components, version 8 also contains a data de-duplication algorithm that will integrate with third party de-duplication systems to further reduce the total storage required for both active and archived data.  It is estimated that of the thirty-percent data growth referenced above, nearly seventy-five percent of that is due to redundant data storage.  For organizations planning a migration to Exchange 2010, eliminating duplicate data is especially important as Microsoft has removed Exchange’s single instance storage feature.  A migration from Exchange 2007 to 2010 will significantly increase storage requirements for e-mail as each copy of any attached documents or e-mails sent to multiple users will now be copied to each mailbox individually.  With Exchange 2007, only a reference pointer to the original copy was required.

To be successful, a DLM program requires careful implementation and management buy-in.  It is important for everyone in the organization to understand why the process is necessary and the consequences of ignoring data sprawl.  The approach you use for your DLM program should not only focus on the issues from an operational standpoint, but from a legal standpoint as well. It is essential to address any potential compliance and data discovery impacts as the way data is stored, retrieved and archived is radically changed.

Part I – Background of SCADA and the Stuxnet trojan
Part II – Stuxnet and the demise of the digital certificate

On July 17^th, Siemens AG warned their customers of a sophisticated virus hence named Stuxnet,  targeting their Windows SCADA control software, Simatic WinCC.  SCADA, which stands for Supervisory Control and Data Acquisition, is a centralized system used to control and monitor complex production systems usually dispersed over a large area.  The systems SCADA manages are industrial, manufacturing, production and infrastructure applications such as refining and power generation.  

 While not commonly known to the general public, SCADA is ubiquitous in industries and organizations that must control extremely large integrated systems such as subways and water works.  SCADA accomplishes this using RTUs, or remote terminal systems that employ sensors which monitor process metrics and then forwards that information to the central supervisory unit.  It’s this unit, which in the case of Siemens’ SCADA system, is controlled by a Windows PC running the Simatic WinCC program, which provides the visualization, or human-machine interface (HMI).  I.E., this is the system operator’s primary interface with the SCADA system.

It’s easy to imagine the chaos a nefarious intruder could create if he were able to penetrate a SCADA system controlling a power plant or a subway system in a large city.  Luckily for you and me, SCADA systems are almost never connected to the Internet just for that reason.  Usually it requires direct access to the console, or a network connection over a secure LAN to operate the system. 

Unfortunately, many SCADA installations are so poorly managed and configured that the lack of a direct Internet connection may not matter all that much.  Often times the entire system is deployed using the default password and once installed are hardly ever patched and maintained in the most minimalist fashion.  To be fair to the SCADA operators, this is not due to negligence, but from a real fear of disrupting the process control, as SCADA systems are extremely complex and often, only the manufacturer has the level of knowledge required for upgrades, patches and general maintenance.  In fact, the systems are so sensitive, that Siemens instructed their customers to not change the default password as that is often used in multiple places and if you didn’t change them all, you could disable operational processes.

While in the long term, operators really need to clean up their SCADA act and properly secure and maintain their systems; for the short term, Siemens’ recommendation is most likely correct.  The risk of disabling a control system with an unplanned and possibly global password change is far greater than the risk of a Stuxnet infection.  This is because the exploit requires several specific actions and conditions for a successful payload launch.

In order for the Stuxnet exploit to succeed, not only does an operator need to insert an infected USB drive into the PC running the Simatic WinCC software, the system must also be running with the default manufacturer’s password.   Even if Stuxnet is unable to compromise WinCC, it still can infect the PC and propagate itself. 

Stuxnet is able to infect the target operating system in a very clever and unusual fashion through the exploitation of the vulnerability in the Windows shell component that controls how Windows processes lnk files.  The specific issue, known as “Vulnerability in Windows Shell Could Allow Remote Code Execution” is detailed in the Microsoft security advisory 2286198. This vulnerability enables Stuxnet to execute even when the normally requisite USB autorun.inf feature is absent.  Disabling AutoPlay will not protect the system, as the vulnerability is in the way lnk files are processed and not with the AutoPlay feature.

Microsoft has recommended two possible workarounds, both of which negatively affect the usability of the PC.  The workarounds essentially involve disabling the icon display for lnk files.  This leaves you with desktop full of generic white icons which are not very visually appealing or even useful.  Nevertheless, this is a small price to pay for protecting your systems until a patch is issued and installed.

While the major anti-virus software vendors were quick to issue definitions that can identify the Stuxnet trojan, this may not be much help as many SCADA systems are not regularly patched for virus definitions.  However, with all the press Stuxnet has received, operators are scrambling to protect their systems. 

If an operator is unfortunate enough to insert an infected USB drive into their Simatic WinCC system, Stuxnet will install two device drivers and attempt to login using the default password.  If unsuccessful, the trojan goes idle and takes no additional action. This is interesting as the author went through a great deal of trouble to create this trojan and it is unclear what its actual purpose may be.  Some believe this may be a proof of concept attack and if successful, more may follow.

This exploit targets a specific vendor’s SCADA HMI and does so in a way that the “run of the mill” malware programmer wouldn’t even think of.   Writing this exploit required specific in depth knowledge of how Siemens’ SCADA operates.  While presently unknown, the ultimate goal of Stuxnet and the other similar exploits certain to follow, may be for industrial, or even political espionage.  Compromise of a SCADA system could reveal process trade secrets and methodologies, causing the victim to lose their competitive advantage in the marketplace, or worse:  it could destroy a power plant or even derail a train.

While this exploit is of little direct concern to the average PC user, one aspect of Stuxnet’s design is somewhat more sinister.  When Stuxnet executes, it installs two drivers that are digitally signed with the code signing key of RealTek Semiconductor, a legitimate and well known corporation.   The key that signed the Stuxnet code appears legitimate in all aspects except one:  RealTek was not the one doing the signing.

Stay tuned for Part II – Was RealTek’s key stolen or forged?

Craig Shrimpton

A good passphrase consists of five to six words usually arranged as an easily remembered sentence.  For example “All good cats chase mice.” is an example of a good passphrase, especially if you add some punctuation.  In fact, an easily remembered passphrase of five or six words can be as strong as a random nine character password.

Not only are passphrases easier to remember, they are much more secure than any password the average user can remember.  It is said that humans have the ability to remember a block of characters no longer than seven, plus or minus two.  The reason we can remember phone numbers is because we break them down into smaller blocks.  It is much easier to remember 555-483-9576 than 5554839576.  Passphrases break down a complex password in much the same way.

Since it is so difficult to remember long complex passwords, most people use very short easily guessable passwords.  Unfortunately short and simple passwords of seven characters or less are easily cracked.  A simple password like “RedSox1” can be brute-forced, meaning all possible combinations of characters tested, in about fifteen days.  But that doesn’t tell the real story.  If the cracker has employed a more sophisticated application that uses predictive algorithms or a time-memory tradeoff mechanism like Rainbow Tables, a password like the one above would be cracked in less than one second. 

Simply adding an additional character or two will significantly increase the time required to discover the password. Working through all possible combinations of a random nine character password would take well over six-thousand years. But who can remember a nine character password?  Imagine sitting at your desktop and trying to type in “f@RVy&Tc7” every morning!  So if that’s too daunting a task, passphrases are your answer.

While some may find that creating good passwords or passphrases is a chore, remember, in addition to your responsibility to protect your company’s corporate assets, your own assets are also at risk when you use weak passwords.  It’s not your e-mail or Facebook login the crackers are after; it’s your bank account.  Since many users use their company’s PCs to do their banking, or pay the bills, getting that login password puts the hacker one step closer to your money.  So remember, when your computer prompts you it’s time to change your password, choose an easy to remember passphrase instead!

Note: All crack times derived from the Password Cracking Spreadsheet available from SANS.  Parameters supplied were one computer searching the entire key space at a testing rate 2.8 million keys per second

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.