none
AGPM - Changed password on AD account - now can't connect to AGPM server - SPN issue?

    General discussion

  • I inherited a kind of complicated AD structure.

    There is an AGPM server in our forest root - AGPMServer.example.biz.  The AGPM service is running as example\AGPM.  If I log onto the server that hosts AGPM, I can connect no problem.

    My workstation is in us.example.biz.  I have AGPM installed on my workstation pointing to AGPMServer.example.biz.  I had no problems connecting until a few days ago.  Now I get the following error - 

    Failed to connect to the AGPM Server.  The following error occurred: A call to SSPI failed, see inner exception.  system.ServiceModel.Security.SecurityNegotiationException (80131501)

    From what I can gather, this is an authentication failure.

    us.example.biz ALSO has an AGPM service account, us\AGPM.  I reset the password on this account shortly before I started having the issues connecting, so I am pretty sure they are related.

    us\AGPM has 2 SPNs - AGPMServer/AGPMServer.example.biz/us.example.biz and AgpmServer/AGPMServer.example.biz/example.biz.

    When I attempt to connect to AGPM Server from my workstation, it fails twice, so I think it is attempting each of the 2 SPNs.

    Does anyone have any idea what I need to do to get the authentication to work again?  I haven't made any changes in example.biz or to the example\AGPM account.  I don't know how to get it to connect again.

    Any help is appreciated.

    Thursday, January 22, 2015 2:51 PM

All replies

  • Hi Chris,

    Thanks for posting in the forum. There is a dedicated AGPM forum. In order to get better help, it's recommended that we ask for suggestions in the following AGPM forum.

    Microsoft Advanced Group Policy Management

    https://social.technet.microsoft.com/Forums/en-US/home?forum=mdopagpm

    Best regards,

    Frank Shen


    Saturday, January 24, 2015 3:16 AM
    Moderator
  • If AGPM is running under a service (user) account the msds-supportedencryptiontypes attribute is not set effectively only supporting RC4 and DES.  
    Check to see if DES is disabled which would only leave RC4.  This means that there is not a common etype for the service ticket.

    Since a service account (user account) is being used the msds-SupportedEncryptionTypes attribute is not set by default.  In the absence of this value being set when service tickets are requested for the account it will treat it as a legacy account for the available encryption types and use RC4 and DES (but DES being disabled by default can effectively leave only RC4).  By checking the 2 checkboxes on the AGPM service account -

    This account supports Kerberos AES 128 bit encryption and This account supports Kerberos AES 256 bit encryption we are telling the KDC that it is ok to include the AES encryption types for the service ticket.  One note is that computer accounts have this attribute defined when they join the domain for Vista and later operating systems.

    2 blogs I found that have more detailed information on this:

    Windows Configurations for Kerberos Supported Encryption Type - http://blogs.msdn.com/b/openspecification/archive/2011/05/31/windows-configurations-for-kerberos-supported-encryption-type.aspx

    Encryption Type Selection in Kerberos Exchanges - http://blogs.msdn.com/b/openspecification/archive/2010/11/17/encryption-type-selection-in-kerberos-exchanges.aspx

    The resolution is to enable AES on the user account in AD so that AES would be considered supported.

    I hope this helps.

    Monday, December 14, 2015 7:46 PM