I have an AAD/AD Federated tenant setup. Obviously AAD in Azure, local AD is lab setup with VMs. I've gone through a few permutations of the AADConnect setup, but I always end up with this same error. Looking it up, it seems usually associated with SQLServer, but I don't think that applies here. I'm simply trying to use IWA to authenticate to this AAD federated app but cannot escape this exception.
Local AD
Domain: vandelay.local
ADDS,ADFS,DNS: WIN-H9QGD6BJ2IN.vandelay.local
ADFS DNS: adfs.ad.vandelay.local
Alternate UPN: vandelay.firstresponse911.net
AAD Connect setup with Federation and Password Hash Sync
AAD
AADConnect setup appears to be happy (see screenshot) App added with globally granted admin consent for app (does not require user interaction to grant permission) Users synced with AADConnect appear in portal with permission for App.
Code
// Signed into machine as [email protected]
static void Main(string[] args)
{
app = PublicClientApplicationBuilder.Create(CLIENT_ID)
.WithAuthority(AzureCloudInstance.AzurePublic, TENANT_ID, false)
.Build();
while (true)
{
var result = _retry.Execute((ctx) => GetToken2().GetAwaiter().GetResult(), new Context("acquireToken", new Dictionary<string, object>() { { "userId", "[email protected]" }, { "password", "AGF11nfn" } }));
Console.WriteLine($"IdTok: {ComputeSha256Hash(result.IdToken)}, Exp: {result.ExpiresOn}");
Thread.Sleep(1000 * 60 * 2);
}
}
private static Task<AuthenticationResult> GetToken2()
{
var upn = System.DirectoryServices.AccountManagement.UserPrincipal.Current;
var cachedResult = app.AcquireTokenByIntegratedWindowsAuth(scopes).WithUsername(upn.UserPrincipalName).ExecuteAsync().GetAwaiter().GetResult();
return Task.FromResult(cachedResult);
}
}
Exception
Microsoft.Identity.Client.MsalClientException: 'The target principal name is incorrect.'
This is accompanied on the same client machine by an EventLog Entry:
The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server fsgma$. The target name used was HTTP/win-h9qgd6bj2in.vandelay.local. 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. Ensure that the target SPN is only registered on the account used by the server. This error can also happen if the target service account password is different than what is configured on the Kerberos Key Distribution Center for that target service. Ensure that the service on the server and the KDC are both configured to use the same password. If the server name is not fully qualified, and the target domain (VANDELAY.LOCAL) is different from the client domain (VANDELAY.LOCAL), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server.
- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
<Provider Name="Microsoft-Windows-Security-Kerberos" Guid="{98E6CFCB-EE0A-41E0-A57B-622D4E1B30B1}" EventSourceName="Kerberos" />
<EventID Qualifiers="16384">4</EventID>
<Version>0</Version>
<Level>2</Level>
<Task>0</Task>
<Opcode>0</Opcode>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2020-10-30T15:24:32.660502800Z" />
<EventRecordID>3393</EventRecordID>
<Correlation />
<Execution ProcessID="0" ThreadID="0" />
<Channel>System</Channel>
<Computer>DESKTOP-BJ6P4H4.vandelay.local</Computer>
<Security />
</System>
- <EventData>
<Data Name="Server">fsgma$</Data>
<Data Name="TargetRealm">VANDELAY.LOCAL</Data>
<Data Name="Targetname">HTTP/win-h9qgd6bj2in.vandelay.local</Data>
<Data Name="ClientRealm">VANDELAY.LOCAL</Data>
<Binary />
</EventData>
</Event>
Http Traffic
It looks like the MSAL code successfully asks AAD to Authenticate for this app, which via discovery sends the response back to talk to the locally federated ADFS server. After getting the local metadata, the MSAL code attempts 3 times to get a token from the windowstransport endpoint. The first attempt with no Authorization header, the 2nd and 3rd attempt have differing Authorization(Negotiate) headers with encoded data, but they all fail with 401.
The posted request looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<s:Header>
<wsa:Action s:mustUnderstand="1">http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue</wsa:Action>
<wsa:messageID>urn:uuid:42420a0c-3505-455f-914d-639c5685b43d</wsa:messageID>
<wsa:ReplyTo>
<wsa:Address>http://www.w3.org/2005/08/addressing/anonymous</wsa:Address>
</wsa:ReplyTo>
<wsa:To s:mustUnderstand="1">https://adfs.ad.vandelay.local/adfs/services/trust/2005/windowstransport</wsa:To>
</s:Header>
<s:Body>
<wst:RequestSecurityToken xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust">
<wsp:AppliesTo xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
<wsa:EndpointReference>
<wsa:Address>urn:federation:MicrosoftOnline</wsa:Address>
</wsa:EndpointReference>
</wsp:AppliesTo>
<wst:KeyType>http://schemas.xmlsoap.org/ws/2005/05/identity/NoProofKey</wst:KeyType>
<wst:RequestType>http://schemas.xmlsoap.org/ws/2005/02/trust/Issue</wst:RequestType>
</wst:RequestSecurityToken>
</s:Body>
</s:Envelope>
and the sequence looks like this:
