Hopefully, the following sample will give us all some orientation on how to make the ws-trustSTS/AAD integration actually work.
The project comes with a client and service, along with the “usual” instructions on how to configure the cloud projection records of these processes. So, having downloaded the sample/ code, we make our client seek to talk to our (existing) todoservice’s API:
On our ADDS/ADFS v3 server, we created a user, bound to a domain that is already certified in our netmagic.onmicrosoft.domain AAD tenant (rapmls.info). Our goal is thus to challenge the user “email@example.com”, intending that ADFS checks the credentials of name and password.
To the ADFS config we guess we need to add a relying party, with name urn:federation:MicrosoftOnline – guessing at the required claims.
We know our ADFS setup is good, since we can emulate ADALs use of ws-trust – which also allows us to easily see “what” ADFS does. (for example it uses sha256).,
When we try the sample now, we DO get further:
on actually creating the aad user, in the right tenant, we that we can at least the issued token processed, properly, by AAD – which then objects to the content defining the subject.
To get that far we had to (obviously) align the ADFS parameters with the federationdomain record in AAD. Next, we will actually create a user, under that domain.
$msolcred = Get-Credential -UserName firstname.lastname@example.org `
-Message “password for netmagic is FRED!”
Connect-MsolService -Credential $msolcred -ErrorAction Stop
$setfed = Get-MsolDomainFederationSettings -DomainName rapmls.info
$aActiveLogOnUri = $setfed.ActiveLogOnUri
$aFederationBrandName = $setfed.FederationBrandName
$aIssuerUri = “http://petervm32.rapmls.info/adfs/services/trust”
$aLogOffUri = $setfed.LogOffUri
$aMetadataExchangeUri = $setfed.MetadataExchangeUri
$aPassiveLogOnUri = $setfed.PassiveLogOnUri
$aSigningCertificate = “MIIC5jCCAc6gAwIBAgIQELcx5ZetWLxLu947oG+anjANBgkqhkiG9w0BAQsFADAvMS0wKwYDVQQDEyRBREZTIFNpZ25pbmcgLSBwZXRlcnZtMzIucmFwbWxzLmluZm8wHhcNMTQwNzAyMTg0NTIwWhcNMTUwNzAyMTg0NTIwWjAvMS0wKwYDVQQDEyRBREZTIFNpZ25pbmcgLSBwZXRlcnZtMzIucmFwbWxzLmluZm8wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDlrHS0Y6LIak6OFJulzl0EWAm/1CZbBTnGuh+geRt/Wllegtwfl7b+v8irjyDYeB59q0SlLb58H0Q4j5iYzDiuyXUwwNioTv4DKmDPsUQV3nbmV7HUqG0Ddc68Y46VRiLTN914QqKxgtaxLXx1qtxhOrrjlEGgyfpk4hDJv7njsCkI3YxBhBpNYdOQI23EX/LUP0Y2UiUdPlxueAqcoN0syR6WArBaVHARa35zJABevjm5jM9Qh8LiD+E3IhXjfMisi7xYYHiq3IogLZDg+y6hx4Nu/xpHuWHYqa+yNeB9GLjKrFpkK9xcWjMZkxeZ14Rd7GbhG7dGquRQIFomvdf1AgMBAAEwDQYJKoZIhvcNAQELBQADggEBAI/tJE+eFaFA7GsMYRzMWP2BiNY2MyaJfErSovq9IuvrQ7iqitJUkbCHcEjxhd2VmSo/EC+56feoyaoowwgq5q2qBA8oWg7LOg0UIP1EWCbeWbM6u3asU0rnyD6QD1RWjSkDI6G0G3NffbTPPjnOqAl99ZO1SYA50nwbM85dubHvMU2R1beFw1VXXVYjtyFft7c0Ksrg15jpYhQqKSjKkez/tGv9YIkt1mOHcJSO2QKuv/vyQjrqMM/bwxIet+hJ095RjoxaVnboWNZN2DHB/DVP0hBZlKkBOYRabJm6tWQMuxSzc4wqog1YYN5judGiORmaNJq5danHw98Sia7DLP4=”
$newuri = “http://rapmls.info/foo”
Set-MsolDomainFederationSettings -DomainName rapmlsqa.com -FederationBrandName $aFederationBrandName -ActiveLogOnUri $newuri -IssuerUri $aIssuerUri -PassiveLogOnUri $aLogOffUri -LogOffUri $aLogOffUri -SigningCertificate $cert -MetadataExchangeUri $aMetadataExchangeUri
Get-MsolDomainFederationSettings -DomainName rapmlsqa.com
$name = “andy”
$upn = $name + “@rapmls.info”
$displayname = $name + “_at_rapmls_info”
$guidstring = “12e48fe7-96be-40a9-9ffb-8fd1e91891d3”;
$base64ofstring = [System.Convert]::ToBase64String(
new-msolUser –userprincipalname $upn -immutableID $base64ofstring `
-lastname At_Rapattoni –firstname $name –Displayname $displayname `
where we get the “official” guid for the immutableid field from the directory record for the user:
Since this is all difficult, we also installed AAD sync (beta) – and it seems worth figuring this out now. So far, we can make it sync only a couple of strange accounts!
more to come on this, I feel.
PS, we fiddled some more, deleting the user and adding him a new, this time with the know same immutableID as is being asserted by the issuer.