Hi everyone.
We've got Tessitura v15.0.6 up and running in our DEV and TEST environments and it's working with Active Directory login pretty flawlessly. It was a bumpy ride getting it all working due to some issues with authentication errors but now we've pretty much got it all worked out.
However, we have bumped into what I would consider a major issue with On The Go. We have a public facing On The Go site that is supposed to be available to our managers and executives from any device no matter where they are. At least that's the whole purpose of On The Go's existence as far as I can tell. Our executives are very keen to get access to their Analytics Dashboards from any location at any time.
But our public facing OTG site will not authenticate with manually provided AD credentials. It's in the DMZ. So I'm hoping that someone else out there figured this out - what ports we need to open, etc. - so that we can move forward with our Active Directory integration when we go LIVE with v15 on May 20th.
When we go to our public facing OTG site, we can provide our AD username and it will pull up our assigned Tessitura User Groups in the drop-down with the default group selected.
But after providing the password and clicking Log In, we're getting this error:
This error does not happen with our internal OTG site. Only the external, public facing site.
FYI I've already been working with TASK and haven't gotten any solution thus far other than to create TWO user accounts for each user that needs to access OTG from outside the organization, which we will not do. We have Office 365 with ADFS and it would be really nice if we could authenticate users with that, but unless I'm mistaken that capability has to be built into the actual OTG .net project and can't just be instantiated with a config file setting.
Thanks for any help that anyone can provide.
The two options I've heard recommended for this sort of thing would be to either create a firewalled route from your DMZ to your DC limited solely to AD traffic required for auth from the OTG server. Or: build a RODC in your DMZ and create your exception there. Two separate user accounts strikes me as user-hostile and ultimately creating new reasons for users to self-implement insecure workarounds, so your intuition there sounds correct.
Nick,
Thanks for the response. We really want to just create the rules to allow IIS on the public facing OTG site to collect the domain\user and password from the user and authenticate the same way it does with our internal OTG site. I'm not really liking the RODC route too much because we need real-time authentication and people change their passwords frequently here. I believe there is a delay but I'm not a network engineer.
Our network admin tried opening LDAP between OTG and the DC and go no traffic at all during the login. He's never done this before so we did some research and found many different and confusing and even contradictory articles, some of them opening so many ports you may as well not have a DMZ at all.
If anyone out there knows what rules to set up for this we would be forever grateful. TASK is looking into it, but it's my general feeling that if OTG is supposed to be a mobile-friendly site for Tessitura and Analytics access, and since no one in their right mind would not use a DMZ for public facing web sites and applications, the solution to using AD with OTG should already be known and documented.
Thanks for your help. We've got our fingers crossed that someone has done this and knows how to set it up.
Hi Gerald - do you have a separate domain for your DMZ or are these standalone servers? We have a separate AD forest and domain that our DMZ servers are joined to that has a one-way trust with our internal domain (i.e. DMZ domain trusts internal domain, but internal domain does not trust the DMZ domain). This has typically worked well for AD authentication. (It is essentially the Forest Trust Model described in this article: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd728030(v%3dws.10.) I haven't tested this with TOTG using AD authentication yet, but I hope to do so shortly and will report the results here if that is of interest.
In order to facilitate this model, we had to open up ports between the DCs in the DMZ and the DCs on the inside. Essentially it is the ports listed in the Windows Server 2008 and later versions section of this article: https://support.microsoft.com/en-us/help/179442/how-to-configure-a-firewall-for-domains-and-trusts. It seems like a lot of ports; however, the nice part about this approach is that we can isolate them to the DCs; we don't need to open these ports for application or web servers in the DMZ.
Unless the answer comes from your TASK ticket, my suggestion is to perhaps use the ports in the above article as a starting point; see if you can get it to work with that. If successful, you could potentially do some testing to pull one or more of these out and see if it still works.
Thanks,David
David,
I really appreciate the time and thoroughness of your response. Thank you very much.
In the DMZ are all Standalone servers (not on the domain). I think there must be a way to get the DC to trust the standalone server. The DC can see that server, but the server can't see the DC unless we open ports.
Again, I'm a DBA not a network admin but I will pass this along to the guys who are.
Thanks again for your very excellent and thorough assessment.