Kerberos and SPN problems

I get hundreds of Event ID: 4 Source: Kerberos on my SCCM server. This server is a Windows Server 2003 R2 (SP2).
The event error is:
The kerberos client received a KRB_AP_ERR_MODIFIED error from the
server (ComputerName)$.  The target name used was RPCSS/(ComputerName2.ACT.LCM). 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 (ACT.LCM), and the client realm.  
Please contact your system administrator.

Every error has a different server name ending with a $ sign. The RPCSS/Computer name is also never the same computer, and it's killing me!

How do I fix all these errors? Please help!

I have had a look at the SPN sites from Microsoft, but I'm not getting and concrete help or indication what's causing this.
The SPN query site helped a bit, but this is for one error at a time:

Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Did you registered the SPN of the service account for SCCM/SQL2005?

Method 1: The Right way
1. Install the Windows 2003 support tools somewhere on a machine in the domain
2. Login as a Domain Admin
3. Run  setspn -A MSSQLSvc/<FQDN> <SQL_Service_Account> Note YOU MUST USE THE FQDN
4. Run  setspn -A MSSQLSvc/<FQDN>:<Port> <SQL_Service_Account>  Note YOU MUST USE THE FQDN, and the most common port is 1443
5. Run setspn -L <SQL_Service_Account> validate that servicePrincipalName: has been set like you expect
6. Restart the SQL server after AD replication has completed
7. Run the following query on the SQL server; this MUST return KERBEROS:
select auth_scheme from sys.dm_exec_connections where session_id=@@spid

Method 2: The easy way
In adsiedit grant the service account the ability to write the servicePrincipalName to SELF
Taken from:
1. Click Start, click Run, type Adsiedit.msc, and then click OK.
- Note The ADSIEdit tool is included in the Windows Support Tools. To obtain the Windows Support Tools, visit the following Microsoft Web site: 
2. In the ADSI Edit snap-in, expand Domain [DomainName], expand DC= RootDomainName, expand CN=Users, right-click CN= AccountName , and then click Properties.
- DomainName is a placeholder for the name of the domain.  
- RootDomainName is a placeholder for the name of the root domain.  
- AccountName is a placeholder for the account that you specify to start the SQL Server service.  
- If you specify the Local System account to start the SQL Server service, AccountName is a placeholder for the account that you use to log on to Microsoft Windows.  
- If you specify a domain user account to start the SQL Server service, AccountName is a placeholder for the domain user account.  
3. In the CN= AccountName Properties dialog box, click the Security tab.
4. On the Security tab, click Advanced.  
5. In the Advanced Security Settings dialog box, make sure that SELF is listed under Permission entries.
- If SELF is not listed, click Add, and then add SELF.
6. Under Permission entries, click SELF, and then click Edit.
7. In the Permission Entry dialog box, click the Properties tab.  
8. On the Properties tab, click This object only in the Apply onto list, and then click to select the check boxes for the following permissions under Permissions:
- Read servicePrincipalName  
- Write servicePrincipalName
9. Click OK two times.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
AmpletrixAuthor Commented:

Thanks sprengy for the comments, but that did not work for me. I read some other articles on the web that pointed me into some DNS issues.
I found that we added another two subnets to our local network, without added them to our reverse lookups.
After adding these two subnets to our DNS servers, all the error messages went away.

Thanks for your help anyway.

AmpletrixAuthor Commented:
I found something that might be of use to somebody else.
Adding a subnet to the netowrk without adding it into the reverse lookups on DNS will cause all these errors on your servers. This might be useful.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft Server OS

From novice to tech pro — start learning today.