1

Disclaimer - this isn't my area of expertise, I'm learning as I go, if I need to adjust level of detail here or redact information please let me know, no offense intended.

Customer needed to pass a PCI scan and the last high item was that when certain HTTP message were sent to the CAS server (really just blasted at the IP which happens to host the CAS server/exchange backend), without a URL specified, it was still responding with a message that disclosed its internal IP.

The fix (at least to pass the scan) - was to add a 'binding' in IIS for the 'default web site' which houses CAS and is currently the only listener for HTTPS/443 structured as:

  • Type - HTTPS
  • Hostname - CASFQDNHERE
  • Port - 443
  • IP Address - *

Although the scan now passes (presumably because when the unqualified header comes in there's no matching binding - before there was a binding as mentioned above that had no value in the 'hostname' field), users have reported a popup prompting them to sign in from outlook. When they enter credentials, it just keeps reprompting them. If you close the prompt, it stays away for a variable length of time but will eventually re-pop. Mail delivery is un-impacted.

I've already tried removed cached credentials from credential manager and having the user input fresh credentials to no effect.

Very much looking forward to any feedback / help - thanks in advance!!

1

CASURLHERE should be the FQDN, not a URL.

A URL would be http://host.fqdn.com

The host and domain name host.fqdn.com without the http:// prefix is the fully qualified domain name.

Assuming you've now got a site binding for host.fqdn.com, that's interesting. I'd have guessed that it perhaps wasn't in your Local Intranet Zone, but the prompt returning instantly indicates that authentication perhaps isn't being successful at all, and that it might be worth looking at the Security event log when this type of problem is occurring. HTTPERR (c:\windows\system32\logfiles) and W3C (c:\inetpub\logs) logs would also be worth looking at.

It could also be worthwhile adding a host (i.e. unqualified hostname) binding as well - if the site is configured for host headers, it will now only accept those host headers, and if anyone's using the short host name for any reason, that'll now be rejected (and anything with a dot in it is considered Internet by default, etc).

You didn't mention explicitly whether HTTPS was new - but a broken (or un-revocation-check-able) certificate might lead to similar seeming issues as well.

2
  • Bad lingo on my part, I do just have an fqdn in the binding.. If i were to add a blank host binding, wouldn't that allow the nessus scan to successfully retrieve the internal IP (because an unaddressed (uses an IP not an fqdn) HTTP query could be responded to?). Maybe I've gone about this all wrong, if there are host header settings I can use to prevent unaddressed queries to the server maybe that's the way I should go. I'll look into HTTPERR logs though - thanks for that lead. – A L Dec 11 '18 at 15:11
  • Right - I meant a hostname binding, not an un-named binding (un-named would assume the default for that port). Having the short (unqualified) name bound would cover another "named" scenario as opposed to an un-named one. – TristanK Dec 16 '18 at 22:54
0

What is your Exchange sever version? Did you encounter any issue in OWA?

By default, the RPC Client Access service on an Exchange 2010 Client Access server uses the TCP End Point Mapper port (TCP/135) and the dynamic RPC port range (6005-59530) for outgoing connections, every time an Outlook clients establish a connection to Exchange.

We need to Configure Static RPC Ports on an Exchange 2010 Client Access Server.

https://social.technet.microsoft.com/wiki/contents/articles/864.configure-static-rpc-ports-on-an-exchange-2010-client-access-server.aspx?Redirected=true

1
  • We're using Exchange 2016 on the most current CU (I think that's .. 11?). Zero issues with OWA. To be clear, the credential box only pops up in outlook hard client, not on the web. Login to the web / OWA is fine. This only started after we removed the anonymous HTTPS binding and replaced it with one that had a host URL matching the owa URL.. and we only did that to pass a PCI scan. – A L Dec 6 '18 at 21:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.