Multi-Forest as well as Multi-Domain support for Windows authentication

[DavidJohnson]

We have several clients that operate in a Multi-Forest environment due to mergers and acquisitions.  Currently with Alteryx Server the only option we can offer them is to use Built-In authentication.  A lot of corporate and particularly finance institutions prefer a single sign on approach and utilise Windows authentication to do this.

Would it be possible to add support for Multi-Forest organisations into Server to support organisations going through mergers and acquisitions?

This would really benefit us in selling Server in to organisations with complex structures and reduce friction in publishing or preparing workflows.

[DanHare]

Agreed, this would be really helpful for multi-jurisdiction clients with more complex security models (which is becoming more common, sadly).

[Hiblet]

I have a big financial institution interested in Server.  Data Governance is a high priority for them (should be for everyone!).  Would love to see this suggestion taken very seriously.

[JPKes]

As a global financial player we need this feature to move on with Alteryx!

---

---

[NicoleNwoha]

Hi,

Implementing this would be an ideal solution for my company as well. We originally wanted to use windows authentication, however, this created issues amongst our users on a different domain in a different forest. We are now deciding what would be the best course of action in order to resolve this issue while maintaining an appropriate degree of security.  Is this something that the Alteryx team is currently working on, or will be working on in the future? 

[TommyB]

Require support for multiple forests in Federal customer space as well. Thank you.

[batmore]

As one of the worlds leading Industrial Design and Automation businesses this would be critical to help us provide workspace automation to new mergers and disparate entities each with their own ActiveDir in multiple forests. Following a merger, a parent company often pulls the objects from new companies and merges them into the parent AD, which helps for emails, others layers, especially Windows native interaction, but Alteryx Server doesn't have the capability to configure one, or more, ActiveDir. Instead the original design relies on an nebulous, ill defined 2-way trust model. It'd be *much* more useful if the Alteryx Server had a real LDAP/ActiveDir client that could be configured via XML or other means, to identify, execute, use multiple ActiveDir installs. And no SAML, OAuth, other SSO layers would *not* be the answer. Until this happens, Alteryx Server is/will be a small departmental player.

[TanyaS]

While I'm very aware of the value of this feature, it is a very heavy lift. This is not on the immediate roadmap. That being said, it is under evaluation for how and when we can implement this. If there was a status of "Planning to put Under Review", we would be marking it as that. We'll be sure to let you know if and when this plans to be addressed.

-Tanya

[NicoleJohnson]

Would like to bring some attention back to this idea, as I believe a significant improvement has been made with 2020.1 that helps to address the multi-forest issue. We have two Domains, separate forests, with full bilateral trust, but with Windows Authentication on 2019.2, we were not able to find a way to grant access to collections (users from the "other" domain could navigate to the site, and a "User" would be created for them, but they couldn't be added to any collections/etc.)...

We received a suggestion to try upgrading to 2020.1, however, since there were some changes made to the way authentication works (something about looking globally first, rather than domain first? Maybe?)... at any rate, this solved the problem of getting our "other" domain users access/authenticated - we can now see them on the Users tab and are able to assign them roles. So now they're in the Gallery, they have roles, they can run things on the Home tab, and the cross-forest issue appears to have been resolved, at least from an initial user set up perspective. (SO EXCITING!!)

However... this does NOT appear to be how the Collections work when it comes to adding users, because I cannot add my "other" domain users to any of the Collections. Which makes me think that however the Collections are looking up users, they're still doing so domain first, not globally first. 

So it appears to be *so close* to being able to properly use multi-domain/forest environments with Windows Authentication, but we just need that last hurdle of getting the Collections to recognize users the same way the Users tab does in the Admin side. I have some (probably not supported) workarounds for the time being, but being that we are so close on this, I am hoping Product Management will consider revisiting this, as the ask will hopefully be a bit smaller now that we're already almost there? 

If this should be a new idea, as the environment has changed a bit since the original idea, please let me know, happy to re-submit.

Thank you!!

NJ

[MarcSchonwandt]

Thanks for your insights @NicoleJohnson ! I'm in a similar situation, being SO close. Has there been any development in this from your end, since your last reply back in October 2020?

[NicoleJohnson]

@MarcSchonwandt - no change here. We are still on 2020.1 and plan to be for the time being, though I have a colleague on 2020.3 and believe they've been able to successfully adopt a similar strategy with multi-domain users.

As a recap, the key things to configure, for those looking to do the same thing:

• Must be on at least version 2020.1 (TBD on whether this will also work for all higher versions)
• May need to enable SSL certificate (so https:// instead of http:// for the Gallery URL)
• Must have full bilateral trust between the domains
• May have to address firewall rules between users & server, depending on your IT configuration

For Windows Authentication method, the user will not show up on the admin side until they have physically navigated to the Gallery URL, at which point a role could be assigned. This presented some challenges for us (how do I assign a role to someone if they've never been there before??), BUT we got around this by including a "Gallery Access Request Form" on our Gallery Home Page, and then set the default role to Viewer, which means everyone can run the request form, which then sends me an email telling me that person wants access to certain collections. Then I can set them up with a role on the admin side, and add them as a user to the appropriate collections (either via the normal add user method for users on the same domain as the Gallery, or via the method below for cross-domain users). 

As for adding users to Collections, after users navigate to Gallery and a role is assigned, there are two methods we know of for the cross-domain users, i.e. if they don't show up when looking to add users from your domain:

• Add their studio to the Collection. This "hack" will grant them access to the collection and the workflows in it... however keep in mind that there might be implications for this, depending on how you are assigning your roles for users as Members vs Artisans, so some testing is advised to make sure folks have access to what they should, but not to what they shouldn't. Additionally, as studios are going away in future releases, I'm not sure of the impact this method might have for future versions that no longer use studios the same way.
• If you want to add the user as a user to a Collection, you can technically do so by manually modifying the MongoDB entry for the users in that collection. Modifying the MongoDB directly is pretty much never advised... but in a pinch, and if you are really really realllllllllly careful, it is an option for this particular area of the MongoDB, as it is relatively lower risk of screwing up your database. I can provide more details about our process if you message me directly 🙂

Hope this helps provide a few more tips on working around this limitation!

Cheers,

NJ