Identity Broker authentication issues with ISA Proxy

Hi Mark,

Without a test environment with an identical proxy configuration it's difficult for me to provide much help outside of trying to detail what each of the communicator options means.

We use a standard .NET library for this, so I'd be happy to do some research in to what some common setups are, but before I do can you have a quick look through the comments on IDBAUR-18 if you haven't already?

It seems Peter had the exact same problems as you're having here with 407s when specifying custom credentials. It appears he had to use their "unauthenticated proxy" which I'm guessing may not be an option here, but it may also be worth talking to him in case he ever found a way around this.

Failing all that, I'll start doing some of that .NET research I mentioned earlier.

(minor note for next time - you should use "Product Group Support" issue type so that Adam is also alerted internally to this issue just in case I'm unavailable to address this - but otherwise perfect, thank you for including logs/config already!)

Thanks for looking at this so quickly. I've discussed this with Peter already - he had the option to avoid using the authenticated proxy. I've had no issues with unauthenticated proxies, but looks like there's an underlying issue with authentication.

This is for a proof of concept, so potentially I can use a CSV export rather than live data. It would be ideal to resolve this issue however as we'll hit this problem again, ISA is a very common proxy.

Another option is to have TGA configure ISA to not require auth from the IdB host. But again, that's not ideal.

Cheersm

Mark.

Completely agree that we should try and fix it now - I just hope you don't mind playing a little bit of back & forth since I don't have anywhere to test my own thoughts.

To start, is the "svc_proxy" user what you want to use to authenticate with the proxy server or the aurion web service? (NOT referring to the security user credentials supplied to authenticate with Aurion - I'm just talking about HTTP authentication with the web server)

If it's the proxy server you want to authenticate against, is the Identity Broker service running as this svc_proxy user?

Hi Patrick, the SVC_Proxy account is a user account of the prodother domain, it's a service account used by TGA to auth to the ISA proxy as required. The IdB server is a member of another domain (idmpoc), with no trust relationships to the prodother domain. Launching an Internet explorer session on the IdB server and supplying the SVC_Proxy credentials results in successful auth and internet browsing. the IdB service is running under a domain admin account from the idmpoc domain.

Thanks,

Mark.

Sorry Mark, didn't see that you'd replied until just now.

Based on the description you've supplied I expect the problem is Identity Broker after all. The credentials you're passing it are for the destination server and not the proxy server. It will use the credentials of the service account by default and I don't believe there's a way to override it as it stands now.

Let me have a talk with Adam to see how difficult it will be to provide a workaround.

Hi Mark,

Can you grab v3.0.4.4 from SUBIDBAUR:Downloads and add the following attributes to your communicator element:

"customProxyUsername", "customProxySecurePassword" and "customProxyDomain". Populate each with the windows account that can successfully authenticate against the proxy server.

As we don't have an environment for this it may not be perfect first try, so let me know and I'll supply you with any additional changes ASAP.

Requested a site visit today to test the new version.

If you run in to any problems, feel free to give me a call in the office so we can work through it as quickly as possible.

Hi Patrick

Testing was a bit stunted today - started testing. Got the errors in the "application log errors.txt" file attached to this case after adding the three new attributes. The PoC lab was having power issues, so the rest of today's work has been bumped. The call has been made to disable proxy authentication and use a Websense proxy for the IdB host for the PoC. However I will have oportunity to test revisions against the ISA proxy during the remaining time for PoC deployment.

Thanks.

Mark.

That's (sadly) an annoying windows event log permission thing that's hiding the actual error... the best way around it (until v4.0) so you can discover the real error is to use the "service debugger" located on SUBIDB:Downloads. If you haven't used it before I'd be happy to provide you with some loose instructions.

Waiting to get back onsite. TGA were having power issues, expect to be onsite again on Monday 12th.

Issue has been addressed by utilising alternative proxy server and caching proxy credentials using Internet Explorer. This will be suitable for the PoC, production deployment will not be affected by this issue as the service account will have proxy authentication rights.

Does this mean the fix I provided worked, didn't work or wasn't tested? This is certain to come up somewhere else and I don't have anyway to test this myself.

Hi Patrick, initial fix did not work and caused the additional error in the Application log extract. Outstanding task on me to run the debug toolset to capture the error which is obfuscated by a logging permission error catured in the event log. This task may have to wait until after the PoC demo to the TGA Executive as we are running seriously behind schedule on this project. Carol and I are meeting shortly with TGA to sort out the demo requirements, I can then provide an eta on the demo and when the PoC lab can be re-used to diagnose this issue. Unfortunately we do not have remote access to this site, so time is limited.

Re-opened for ISA testing updated Aurion connector - post PoC demo to TGA.

Can confirm that V3.0.4.5 of the Identity Broker for Aurion connector works with authenticated proxies. Tested with Threat Management Gateway 2010. Communicator config options required are below:

<communicator uri="<HOST Aurion Instance URI" credentials="Custom" proxy="Custom" proxyUri="http://<server>:<port>" customProxyUsername="<Account Name" customProxySecurePassword="<Password>" customProxyDomain="<account Domain>">

Testing of v3.0.4.5 complete - works perfectly.

Re-opening to correct Billing Key