Issues with SCIM gateway
Beau Harrison (Senior Product Software Engineer) 3 years ago • updated 3 years ago • 21
- What credentials?
- Purpose of "Secret Token" in Azure portal
- Querying (used for test connection)
- Null reference exception
- Bad request returned from TLS1.2 Client Hello
Customer support service by UserEcho
Thanks for this. Could you please invite Bob here as well?
Since development of the gateway concluded, Microsoft has changed the aud parameter on the authentication token it sends on SCIM requests from the AAD instance id to either the app gallery id, or a generic value of 8adf8e6e-67b2-4cf2-a259-e3dc5476c621. See Microsoft documentation for more info. This value can be used in the gateways Audience configuration, but should not be used in a production environment until the gateways authentication process is improved.
The Azure portal option Secret Token gets sent as the auth token on SCIM requests, instead of one generated by AAD. This isn't currently supported, but may be employed as the solution to the problem above in the future.
Query SCIM requests (such as the AAD Test Connection action) can result in a null reference exception being thrown. Patch to follow.
HTTPS SCIM requests are attempting to use TLS 1.2, which fail with a Bad Request - Invalid Verb. This may be caused by the .NET framework version Broker is built upon not supporting TLS >1.0 by default. We have documentation for the process to enable this.
From the traced responses: Bad Request - Invalid Hostname. Guessing this refers to the tenant as the actual connection address is obviously working.
Check you have that setting right. This is the format mine is in. In the portal:
In the gateway:
I am pretty confident it's correct. Here's the Azure Portal:
And here's my SCIM gateway configuration:
Can you see any problem with what I've done?
Set address to your machines local IP. It doesn't like something to do with localhost, but then I wouldn't have imagined that would have worked at all.
Still no joy I'm afraid.
Do you think it might be related to the Host: header?
Could be. I've been using the VMs public ip, but the DNS name also works. Maybe try it with the IP just in case.
I tried but the UNIFYBroker UI won't accept my public IP address:
Also, Azure cycles my public IP - it changes over time.
I tried with the DNS name and it accepted it but still didn't work - same error, 400 Bad Request. Is there some way to find out more information about why it's failing?
(I also tried https, still no luck)
No, local IP configured in the gateway, I meant use your public IP in AAD portal. Not a long term solution, of course. Can't find any way to improve logging, either.
OK. I changed the UNIFYBroker Address configuration as shown below, and the error is unchanged (400 Bad Request)
What would you like to try next?
Is it still a invalid hostname bad request? Provide another trace if you're unsure
Yes, I see "Bad Request - Invalid Hostname" in the response text.
Correction: that error occurs when I have the gateway configured with Address=http://localhost:59988/
When I configure the gateway with Address=http://10.0.0.4:59988/ the response body from HTTPAPI is empty instead. As attached:
Did you upload the right file? Both requests in http4.pcapng have the usual "Bad Request - Invalid Hostname" in their response.
Are you running Broker under a non-admin account? If so, you may need to set an url acl for that account. Check for any other application or settings that may be blocking requests on that port.
I looked at http4.pcapng again, and you are correct. I think I must have been looking at the wrong packets.
UNIFYBroker is running as a local administrator on the server.
I tried to use "netsh add urlacl ..." as described on page you linked to, but that command is not found on my server:
The port 59988 is opened in Windows Firewall and in the Azure Network settings for the UNIFYBroker server VM:
I'm not aware of any other applications or settings that might be blocking that port. It is listening as expected, and if I stop the UNIFYBroker service then Wireshark only shows unrequited connection attempts (SYN packets) when I attempt to Test Connection from the Azure Portal.
It makes sense to me that the HTTP/1.1 hostname would be invalid - in UNIFYBroker I have this configured:
This is the address on the private ethernet interface of the UNIFYBroker VM (the public IP address is not available on any ethernet interface; it is only available via NAT).
The configured Address in the Azure Portal does not match:
Indeed, it is impossible for me to make them match, because the UNIFYBroker server can only have the internal IP or name configured (for binding, presumably) and the Azure Portal can only have the public IP or name configured.
Given that, how is it even possible to get this working? Can the hostname check be turned off in HTTPAPI, or is there some other approach?
The acl command is actually
but if Broker is running as admin it's probably not needed.
All your settings look correct. The only difference I can see is the configuration of your VMs inbound port. This is how mine is configured. Not sure if it could affect anything, but try matching this and see if anything changes.
Thanks Beau. I updated my firewall rule to match yours, but no luck :(
Turns out AAD premium trials are tied to the instance, not your account, so I was able to create a new enterprise app in a new AAD instance. Though this, I was able to figure out the behaviours we were seeing during the shared session.
For some yet unknown reason, my old app was sending requests on
<host:port>/scim/..., which is also what the SCIM library Broker users is hard-coded to listen on. To get requests to work in the new app I had to append the tenant URL with
/scim. No change required in the gateway configuration.
The 501 Not Implemented errors occur when the field being filtered on isn't configured in the gateway. Seems this is controlled by the mapping configuration in Azure. Didn't start working right away, but eventually started using the right field.
Thank you very much for your help Beau!
Nice. Wasn't sure if that was the cause of your hostname issue or not, but it's good that it was.