This site uses different types of cookies, including analytics and functional cookies (its own and from other sites). To change your cookie settings or find out more, click here. If you continue browsing our website, you accept these cookies.

when you say "different domains" do you actually mean different subdomain like "europe.company.com" and "america.company.com" or really different ones like "companyA.com" and "companyB.com"? because Connect can handle the subdomains as long as is part of one itself. But if there are two completely different domains, then yes, that doesn't seem feasible.

People folder allows XLS export, but not XLS import. What it does support though is XML export and import. I tried to export users from one instance and import them into another and it seems to be working. So "the only" thing you need is to find a way how to export your users into xml of desired structure.

The AD loader is on our roadmap for Q4 this year (but I believe we make it to have it earlier) and I guess that should solve your issues. But in such case Connect will still need to have visibility to all AD servers - that means they need to be on the same network. And so I would ask why the WinAuth isn't working in first place. The users don't have to be all in the same domain. They only need to have different email addresses.

> when you say "different domains" do you actually mean different subdomain> like "europe.company.com" and "america.company.com"> or really different ones like "companyA.com" and "companyB.com"?> because Connect can handle the subdomains as long as is part of one itself.> But if there are two completely different domains,> then yes, that doesn't seem feasible.

In this case, "different domains" that we said are really different like "companyA.com" and "companyB.com"

> People folder allows XLS export, but not XLS import.> What it does support though is XML export and import.> I tried to export users from one instance and import them into another> and it seems to be working.> So "the only" thing you need is to find a way how to export your users into xml of desired structure.

OK, we understand.

> The AD loader is on our roadmap for Q4 this year> (but I believe we make it to have it earlier)> and I guess that should solve your issues.> But in such case Connect will still need to have visibility to all AD servers - that means they need to be on the same network.> And so I would ask why the WinAuth isn't working in first place.> The users don't have to be all in the same domain.> They only need to have different email addresses.

We have questions about AD Roader.

What is the role of "AD Roader"?We think/assume AD Roader takes up users information from Active Directory, and AD Roader imports it to Alteryx Connect.Are our thinking/assumption correct?

yes, you are correct. AD Loader is a job that connects to the AD server and based on the configuration like starting point and filters it extracts all relevant users and groups and creates their counter-part in Connect. Of course it is not able to extract their password, so the users have to create their own first using the "Forgotten password feature" (working SMTP required).

But one thing is not clear to me - AD servers are usually accessible only from the internal network, so I am not sure if even this loader would work in your case anyway if your users are in two different domains. The Connect server will need to be able to connect to both AD servers, so I would advise to validate this condition.

in that case what you are looking for is an external "vault" that would Connect utilise. I'm afraid that is not we would plan for Connect in this or next year.

If you want to avoid any password management in Connect, you already have two options:

to use the Windows authentication - in such case, the password in Connect doesn't exist as the AD is doing all the authentication

to use the SAML authentication method - in such case, a 3rd party is taking over the authentication and Connect doesn't store any password as well.

Since you have two different domains, the 1st case cannot be utilised. (Or maybe if the domains would have trust established between them, then it could work as long as Connect is at least in one of those domains).

In the second case - I know the SAML providers are usually able to connect to your AD, so if they would be able to connect to two ADs, it could merge all users from both ADs and users could authenticate via that SAML provider.