Wednesday, 16 December 2015

Azure PowerShell "Your Azure credentials have not been set up or have expired, please run Add-AzureAccount to set up your Azure credentials"

Azure PowerShell throws the error "Your Azure credentials have not been set up or have expired, please run Add-AzureAccount to set up your Azure credentials" when you try to run a PS command against an Azure service. This is using both the Get-AzurePublishSettingsFile and the Add-AzureAccount methods to authenticate to the Azure tenancy.


This is because there are a number of stale entries related to your account cached on the administrative device you are using, to display all of the cached accounts use the following command;

Get-AzureAccount


The following command can be used to delete all of the cached Azure credentials from the device;

foreach ($AzureAccount in (Get-AzureAccount).ID) {Remove-AzureAccount $AzureAccount}


Then try Add-AzureAccount, enter your credentials.


And you should re-authenticate to the Azure tenancy properly. You can now run any commands without being faced with the same error.


Tuesday, 15 December 2015

ADFS & WAP "Unable to retrieve proxy configuration data from the Federation Service. Status Code Unauthorized (401)".

A very common problem when installing WAP servers for ADFS is the error "Unable to retrieve proxy configuration data from the Federation Service. Status Code Unauthorized (401)". 

Check the bindings for your ADFS servers http.sys file (only for ADFS 3.0, older versions use IIS). The following command can be used to display the http.sys bindings.
netsh http show sslcert

The fix for me was to add the static binding of 0.0.0.0:443, I have highlighted it below. Without this I was receiving the "Unable to retrieve proxy configuration data from the Federation Service. Status Code Unauthorized (401)" error.

To add this static 0.0.0.0:443 binding use the netsh utility, it fails if you do not enter it in stages like it is listed below. The certhash and appid used for this binding should be the same that is used in your ADFS service name binding that is displayed when you use the netsh http show sslcert command.
netsh
http
add sslcert ipport=0.0.0.0:443 certhash=insert hash appid={insert appid}

Now you can try to re-run the WAP configuration utility. I have found this works best by using PowerShell. The following command can be used to perform this
Install-WebApplicationProxy –CertificateThumbprint certthumbprint –FederationServiceName adfsservicename

You will then be prompted to enter administrator credentials on the ADFS servers. The GUI is misleading at this stage as it states you should use "local administrator credentials", I can confirm this is not the case as you will get an error unless they are domain credentials.


When you run the WAP configuration wizard it is worth knowing that you sometimes have to run the command 2/3 times before it works correctly (without changing anything). This first time I run the command after making the binding change return the error.

"The federation server proxy could not renew its trust with the Federation Service.  

Additional Data 
Exception details: 
The remote server returned an error: (400) Bad Request. 

User Action 
Ensure that the federation server proxy is trusted by the Federation Service. If the trust does not exist or has been revoked, establish a trust between the proxy and the Federation Service using the Federation Service Proxy Configuration Wizard by logging on to the proxy computer."

The message returned from the PowerShell window was "an error occurred validating the SSL certificate". The length of the certificate hash is invalid. Did you forget to add the preceding '0'."

Without changing anything I then rerun the command and it worked correctly.



Friday, 11 December 2015

ADFS Server Farm Join Fails with "ADMIN0011: InvalidRequestFault" & “There was an error doing synchronization. Synchronization of data from the primary federation server to a secondary server did not occur”.

I was recently working on a project with a customer to extend their ADFS server farm to Azure for a passive backup in the event of DR.

When I run the command Add-AdfsFarmNode command ADFS returned an almost programmatic error. The error was “ADMIN0011: InvalidRequestFault” which was not very helpful.

The Event Log’s on the server I was trying to join to the ADFS server farm was logging Event 344 “There was an error doing synchronization. Synchronization of data from the primary federation server to a secondary server did not occur”.

The installation with the Add-AdfsFarmNode fails at 80% at the stage “synchronizing local database”.


The first step was to check the health of the ADFS server farm and to check all the relevant configurations such as SPN’s, DNS etc were configured correctly for an ADFS farm join. The following PowerShell command is handy for checking all these at once;

Test-AdfsFarmJoin

For some reason the command does not run correctly unless you store the ADFS service account in a variable and then call it from the variable, so to run the command you must enter it like this;

$ADFScred = Get-Credentials
Test-AdfsFarmJoin –ServiceAccountCredential $ADFScred –PrimaryComputerName SERVER



As you can see everything test successfully, one thing that is worth noting here as there is some conflicting information around, the ADFS service account SPN should be set to host/ not http/. The ADFS wizard should automatically sets the SPN for you.


The next stage in my troubleshooting was to enable ADFS logging, by default Verbose logging is not enabled for ADFS as every transaction such as a new claim being issued would be logged. Although this article relates to ADFS 2.0 it is relevant for 3.0 as well.


This particular ADFS infrastructure had a number of custom Relaying Party Trusts configured for home-grown applications. At this stage I had to open a support case with Microsoft.

Although I thought I knew ADFS fairly well, I did learn something new about Relaying Party Trusts. A Relaying Party Trust can only have one policy of each type.

PolicyUsage = 0 "Issuance Transform Rules"  
PolicyUsage = 1 "IssuanceAuthorizationRule"  
PolicyUsage = 2 "Delegation Authorization Rule"  
PolicyUsage = 3 "ImpersonationAuthorizationRules" 
PolicyUsage = 4 "StrongAuthenticationPolicy"

By querying the ADFS (WID) database directly Microsoft was able to identify that there was one of the custom Relying Party Trust had stored two entries for IssuanceAuthorizationRule and Delegation Authorization Rule.

To do this run the following PS command;
$stsWMIObject = (Get-WmiObject -Namespace root\ADFS -Class SecurityTokenService)
$connection = new-object system.data.SqlClient.SqlConnection($stsWMIObject.ConfigurationDatabaseConnectionString);
$connection.Open()
$connection.Database

$query = @“
SELECT  [ScopeId], [AdfsConfiguration].[IdentityServerPolicy].[Policies].[PolicyUsage],
[AdfsConfiguration].[IdentityServerPolicy].[ScopePolicies].[PolicyId]
FROM [AdfsConfiguration].[IdentityServerPolicy].[ScopePolicies]
INNER JOIN [AdfsConfiguration].[IdentityServerPolicy].[Policies]
ON [AdfsConfiguration].[IdentityServerPolicy].[Policies].[PolicyID] = [AdfsConfiguration].[IdentityServerPolicy].[ScopePolicies].[PolicyID]
ORDER BY [ScopeId],[AdfsConfiguration].[IdentityServerPolicy].[Policies].[PolicyUsage]
”@
$command = $connection.CreateCommand();
$command.CommandText = $query;
$result = $command.ExecuteReader();
$table = new-object “System.Data.DataTable”
$table.Load($result)
$table

Identify the duplicate entries;

Scope ID                                                                                   Policy Usage                      Policy ID
7ae60ee4-d27b-e511-80c7-00505689310d                                          0   cd983eb1-d47b-e511-80c7-00505689310d
7ae60ee4-d27b-e511-80c7-00505689310d                                          1   3a317185-d47b-e511-80c7-00505689310d
7ae60ee4-d27b-e511-80c7-00505689310d                                          1   63dc770a-fc91-e511-80c7-00505689310d
7ae60ee4-d27b-e511-80c7-00505689310d                                          2   64dc770a-fc91-e511-80c7-00505689310d
7ae60ee4-d27b-e511-80c7-00505689310d                                          2   3b317185-d47b-e511-80c7-00505689310d
7ae60ee4-d27b-e511-80c7-00505689310d                                          3   7ee60ee4-d27b-e511-80c7-00505689310d
7ae60ee4-d27b-e511-80c7-00505689310d                                          4   7ce60ee4-d27b-e511-80c7-00505689310d

Match a Scope ID to a Relaying Party Trust to identify which one is giving you problems;

$stsWMIObject = (Get-WmiObject -Namespace root\ADFS -Class SecurityTokenService)
$connection = new-object system.data.SqlClient.SqlConnection($stsWMIObject.ConfigurationDatabase
ConnectionString);
$connection.Open()
$connection.Database
AdfsConfiguration
$query = "SELECT * FROM IdentityServerPolicy.ScopeIdentities";
$command = $connection.CreateCommand();
$command.CommandText = $query;
$result = $command.ExecuteReader();
$table = new-object "System.Data.DataTable"
$table.Load($result)
$table


The Scope ID translates to your Relaying Party Trust. Interestingly enough if you opened the Relaying Party Trust from the ADFS GUI the secondary Policy Usage entry was not visible. Luckily in this case the problematic Relaying Trust Trust was only for testing and it could be removed without much of a drama.

Although if you are experiencing this issue with a trust you do require, the following steps can be taken to resolve the problem

1.      Stop the ADFS service

2.       Export the Relying Party Configuration with " Get-AdfsRelyingPartyTrust -Identifier <url identifier> 

(The <url identifier> can be any of the identifiers associated with the "Relying Party Trust" in the "[ScopeIdentities] " table)

Disabling the Relaying Party Trust does not work.

3.       From the Primary Server, remove the Relying Party causing the conflict.

4.       Start the ADFS service and attempt an ADFS farm join.

5.       Sync should work now.

Surprising there is no metadata clean up etc. required for ADFS, once you remove (or remove and then re-add) the trust and the duplicate Policy Usage statements are gone everything should sync properly.


Thursday, 10 December 2015

Query Windows for a specific Windows Update (KB)

I was recently working with MS Support and was asked to confirm if a specific KB patch was applied to my problematic servers. Instead of scrolling through the GUI's list of installed updates, hoping to notice the KB you can use the following command.

wmic qfe hotfixid | find "KBxxxxxx"

Simple but handy ;)

Comments system

Disqus Shortname