1007 AccessDenied: Access Denied when trying to renew Federation Certificate


The 1007 AccessDenied event is usually tied to a time skew issue and that should always be confirmed before proceeding, however, that is also the error you will get when you try to renew a federation certificate in Exchange, when the old certificate has already exceeded the expiration date.

Scenario

I am trying to replace an expired Federation certificate. I have already set it as the next certificate in federation as per https://support.microsoft.com/en-us/kb/2810692 but when I run Set-FederationTrust -PublishFederationCertificate to make the federation trust use the new certificate, I get the following error:

An unexpected result was received from Windows Live. Detailed information: “1007 AccessDenied: Access Denied.”.

   + CategoryInfo         : InvalidResult: (:) [Set-FederationTrust], LiveDomainServicesException

   + FullyQualifiedErrorId : [Server=MBX01,RequestId=612495e6-4e5e-45c2-80b7-71d8bd272448,TimeStamp=7/20/2016 4:25:36 PM] [Fa

   let-LiveDomainServicesException] 907DD98C,Microsoft.Exchange.Management.SystemConfigurationTasks.SetFederationTrust

   + PSComputerName       : cas01.contoso.com

If I run it with the Verbose switch, I see the following:

[PS] C:\Windows\system32>Set-FederationTrust ‘Microsoft Federation Gateway’ -PublishFederationCertificate -Verbose

VERBOSE: [16:25:35.869 GMT] Set-FederationTrust : Runspace context: Executing user: contoso.com/Users/Administrator,

Executing user organization: , Current organization: , RBAC-enabled: Enabled.

VERBOSE: [16:25:35.883 GMT] Set-FederationTrust : Initializing Active Directory server settings for the remote Windows PowerShell

session.

VERBOSE: [16:25:35.887 GMT] Set-FederationTrust : Active Directory session settings for ‘Set-FederationTrust’ are: View Entire

Forest: ‘False’, Default Scope: ‘contoso.com’, Configuration Domain Controller: ‘DC1.contoso.com’,

Preferred Global Catalog: ‘DC1.contoso.com’, Preferred Domain Controllers: ‘{ DC1.contoso.com }’

VERBOSE: [16:25:35.888 GMT] Set-FederationTrust : Beginning processing Set-FederationTrust

VERBOSE: [16:25:35.898 GMT] Set-FederationTrust : Instantiating handler with index 0 for cmdlet extension agent “Admin Audit Log

Agent”.

VERBOSE: [16:25:35.987 GMT] Set-FederationTrust : Current ScopeSet is: { Recipient Read Scope: {{, }}, Recipient Write Scopes: {{,

}}, Configuration Read Scope: {{, }}, Configuration Write Scope(s): {{, }, }, Exclusive Recipient Scope(s): {}, Exclusive

Configuration Scope(s): {} }

VERBOSE: [16:25:35.991 GMT] Set-FederationTrust : Searching objects “Microsoft Federation Gateway” of type “FederationTrust” under

the root “$null”.

VERBOSE: [16:25:35.997 GMT] Set-FederationTrust : Previous operation run on domain controller ‘DC1.contoso.com’.

VERBOSE: [16:25:35.999 GMT] Set-FederationTrust : Processing object “Microsoft Federation Gateway”.

VERBOSE: [16:25:36.002 GMT] Set-FederationTrust : Admin Audit Log: Entered Handler:Validate.

VERBOSE: [16:25:36.003 GMT] Set-FederationTrust : Admin Audit Log: Entered ClassFactory:InitializeConfig.

VERBOSE: [16:25:36.040 GMT] Set-FederationTrust : Admin Audit Log: Exited ClassFactory:InitializeConfig.

VERBOSE: [16:25:36.075 GMT] Set-FederationTrust : Admin Audit Log: Exited Handler:Validate.

VERBOSE: [16:25:36.076 GMT] Set-FederationTrust : Resolved current organization: .

VERBOSE: [16:25:36.077 GMT] Set-FederationTrust : Searching the local certificate store for a certificate with thumbprint

“896F1D0B4B6A4FC1C97A5FB0B00718B4104A2572”.

VERBOSE: [16:25:36.089 GMT] Set-FederationTrust : Searching the local certificate store for a certificate with thumbprint

“D3DC73C0FD40716CD20AD8A4D5C3899440C72EF7”.

VERBOSE: [16:25:36.108 GMT] Set-FederationTrust : Calling

‘UpdateAppIdCertificate(applicationId=’000000004C004234′,certificate=’bunchofcharacters==’)’ at the domain services endpoint https://domains.live.com/service/managedelegation2.asmx.

VERBOSE: [16:25:36.606 GMT] Set-FederationTrust : The request to Windows Live Domain Services failed with the following exception:

[0]: Microsoft.Exchange.Management.FederationProvisioning.LiveDomainServicesException

An unexpected result was received from Windows Live. Detailed information: “1007 AccessDenied: Access Denied.”

[1]: System.Web.Services.Protocols.SoapException

AccessDenied: Access Denied.

Code: http://schemas.xmlsoap.org/soap/envelope/:Client

Detail: <detail><ErrorCode>1007</ErrorCode><ErrorEnum>AccessDenied</ErrorEnum><Retryable>False</Retryable><ErrorDescription>Access

Denied.</ErrorDescription></detail>

   at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream

responseStream, Boolean asyncCall)

   at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)

   at Microsoft.Exchange.Management.FederationProvisioning.ManageDelegationClient.ExecuteAndRetry(String description,

WebMethodDelegate webMethod)

   at Microsoft.Exchange.Management.FederationProvisioning.ManageDelegationClient.ExecuteAndHandleError(String description,

WebMethodDelegate webMethod)

.

VERBOSE: [16:25:36.621 GMT] Set-FederationTrust : Admin Audit Log: Entered Handler:OnComplete.

An unexpected result was received from Windows Live. Detailed information: “1007 AccessDenied: Access Denied.”.

   + CategoryInfo         : InvalidResult: (:) [Set-FederationTrust], LiveDomainServicesException

   + FullyQualifiedErrorId : [Server=MBX01,RequestId=612495e6-4e5e-45c2-80b7-71d8bd272448,TimeStamp=7/20/2016 4:25:36 PM] [Fa

   let-LiveDomainServicesException] 907DD98C,Microsoft.Exchange.Management.SystemConfigurationTasks.SetFederationTrust

   + PSComputerName       : cas01.contoso.com

So, how do I renew an already expired federation certificate?

You can renew the certificate, but you can’t apply it to the federation trust. It literally requires the old certificate to authenticate the process before moving it to the new certificate. If the old certificate is expired, you will fail authentication which will in turn return the error above. This leaves only one recourse; remove and recreate the Federation Trust:

Remove the federated Domain using using the switch “ -Force”

Remove-FederatedDomain -DomainName Contsoso.com -force

Do this for each federated domain.

Remove the federation trust. (I prefer to do this via the GUI).

https://technet.microsoft.com/en-us/library/jj657500(v=exchg.150).aspx

After the federation trust has been removed, confirm that the attributes listed in https://support.microsoft.com/en-us/kb/2995731 are cleared appropriately then do the following:

Step 1: Create a federation trust with the Microsoft Federation Gateway. https://technet.microsoft.com/en-us/library/dd351047(v=exchg.160).aspx

Step 2: Set-FederatedOrganizationIdentifier for your primary domain. https://technet.microsoft.com/en-us/library/dd351037(v=exchg.160).aspx

Step 3: If required create TXT record in external DNS for the Primary name.

Step 4: Configure the remaining domains for federated delegation (add-FederatedDomain). https://technet.microsoft.com/en-us/library/dd351208(v=exchg.160).aspx

Once that is completed and the TXT records have propagated throughout DNS (if they had to be configured), you will then need to have your partner environments and tenants that you are federated with update their TargetApplicationUri to match the new ApplicationUri as found in get-federationTrust. https://technet.microsoft.com/en-us/library/dd351262(v=exchg.150).aspx

NOTE

Back in 2010, if you wanted to, you were able to use the same ApplicationUri, preventing the need to update the ApplicationUri on your tenants and partners environments. You had to use the -skipnamespaceproviderprovisioning switch. If you did this you would have needed to provide the following:

  1. ApplicationIdentifier
  2. ApplicationUri
  3. AdministratorProvisioningId

Once upon a time, you could get the values of those from the get-FederatedDomain cmdlet. Since then, however, the AdministratorProvisioningId was made to not be discoverable for security reasons, thereby making the skipnamespaceproviderprovisioning switch obsolete, as it still requires all three of those parameters to be manually populated. So in a nutshell, you will have to let is assign an ApplicationUri and update your tenants and partner environments to reflect the new ApplicationUri.

Comments (0)

Skip to main content