Thanks for the feedback so far.
Vinod - we do have a mid-tier and a smartreporting server public facing and then another set private facing. We've had mid-tier setup like this for years, which works perfect. I can log directly into SmartReporting on the public side all day. I just can't get mid-tier to take the setting in the config page. I actually tried to load both mid-tier and smartreporting on the same server too in test to get away from the cert configurations between servers. No luck.
Lee - absolutely no performance issues at all doing this. From a security standpoint I believe this is the only way you should setup your web tier (I'm sure that's open for debate). I'm trying to move our small subset of users on the private side to move over to the public side. That would give us less servers to maintain.
Tauf - I'm waiting to hear back from RoD Ops Team. I think the issues are SSL and NAT. Not sure if they are completely independent issues or somewhat related. Unfortunately I can't turn off the SSL enforcement on the public facing side to test that.
I am curious on the SSO side of the house also. SmartReporting once integrated into ITSM will log you in auto-magically. That could very well be the issue also. That authentication won't happen because of the address translation, which triggers the error
configuring this in mid-tier. I wonder now if load balancers would cause a bunch of issues too with SmartReporting.
From: Action Request System discussion list(ARSList) <arslist@ARSLIST.ORG> on behalf of Tauf Chowdhury <taufc.is@GMAIL.COM>
Sent: Thursday, December 8, 2016 4:18 PM
Subject: Re: SmartReporting over SSL in DMZ
Not sure about Control M. Truesight does not support Okta, which is what we use for our SSO and we have no need to make it publicly available so it's not a huge issue for us.
We built Truesight in AWS
Sent from my iPhone
On Dec 8, 2016, at 4:09 PM, Lee Cullom <Lee.Cullom@NORTHCRAFTANALYTICS.COM> wrote:
_ARSlist: "Where the Answers Are" and have been for 20 years_