Solution for: A security package specific error occurred

  • Article

For me the issue was happening with Powershell and Get-Winevent, but it could happen with any number of actions.  In my instance the problem occurs when we were using a cross-forest single sign-on account to manage multiple Active Directory forests. In this case if there are multiple computer accounts with the same name in play and one of those stale computer accounts resides in the same domain as your user account it can cause Kerberos to freak out:

PS C:\> get-winevent -ComputerName Server1 -LogName "Microsoft-Exch..."
Get-WinEvent : A security package specific error occurred
At line:1 char:13
+ get-winevent <<<< -ComputerName Server1 -LogName "Microsoft-Exch"
+ CategoryInfo : NotSpecified: (:) [Get-WinEvent], EventLogException
+ FullyQualifiedErrorId : System.Diagnostics.Eventing.Reader.EventLogException,Microsoft.PowerShell.Commands.GetWinEventCommand
<snip>

Log Name: System

Source: Microsoft-Windows-Security-Kerberos

Date: 3/2/2011 6:06:04 PM

Event ID: 4

Task Category: None

Level: Error

Keywords: Classic

User: N/A

Computer: ClientComputer1.capacity.contoso.com

Description:

The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server . The target name used was host/Server1. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using. Please ensure that the target SPN is registered on, and only registered on, the account used by the server. This error can also happen when the target service is using a different password for the target service account than what the Kerberos Key Distribution Center (KDC) has for the target service account. Please ensure that the service on the server and the KDC are both updated to use the current password. If the server name is not fully qualified, and the target domain () is different from the client domain (mgt.contoso.com), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server.

If we used the FQDN of the server though it worked fine:

PS C:\> get-winevent -ComputerName Server1.capacity.contoso.com -LogName "Microsoft-Exch..."

TimeCreated ProviderName Id Message
----------- ------------ -- -------
3/2/2011 4:34:39 PM Microsoft-... 325 Active...
3/2/2011 1:34:29 PM Microsoft-... 325 Active...
3/2/2011 1:19:46 PM Microsoft-... 221 Trunc ...

 

Solution:

1) Delete the stale computer accounts from the forest where your credentials are coming from.

2) Use the FQDN of the server name when trying to connect to the server instead of the flat name.

It kind of makes senses once you see all the pieces in play. By default the LDAP connection is binding to the user forest and finding the wrong spn based on the sort name. 

Hope this helps someone.