Windows Authentication Rollout Across a Distributed Server
An organization is deploying Alteryx Server across a Controller, two Workers, and a separate Gallery/MongoDB host, all domain-joined Windows servers. The security team wants users to log into the Gallery with their Active Directory credentials (single sign-on) and wants workflow run-as credentials to use a dedicated service account rather than the logged-in user. Currently the Gallery is configured for built-in authentication with local accounts. The team has 1,200 AD users in three OUs and a mix of laptops that are and are not domain-joined. They plan to flip authentication to Windows/AD in a single change window.
1. What must be verified before switching the Gallery from built-in to Windows/AD authentication, and what is the biggest risk in a single-window cutover?
Read the worked answer
Verify: (1) the Gallery service account can read AD (LDAP bind or Windows auth path) and that the domain controllers are reachable from the Gallery host; (2) the AD group(s) that will map to Curators/Artisans/Viewers exist and are populated; (3) the built-in admin account remains usable as a fallback so you are not locked out if AD binding fails; (4) time sync between hosts and DCs (Kerberos is sensitive to clock skew); (5) SPN and delegation settings if true SSO/Kerberos is required rather than a credential prompt. The biggest risk is lockout: flipping authentication in one window with no tested fallback means a misconfigured bind or missing group mapping leaves all 1,200 users unable to log in and admins unable to fix it through the UI. Mitigate by keeping the built-in admin enabled, testing with a pilot AD group first, and validating group-to-role mapping before the window.
2. How should the team handle the 1,200 users and the non-domain-joined laptops?
Read the worked answer
For domain users, map AD security groups to Server roles rather than assigning 1,200 individual permissions; this keeps administration sane and matches how the OUs are likely structured. For non-domain-joined laptops, Windows/AD authentication will not provide seamless SSO; those users will get a credential prompt (which still works if the Gallery accepts AD credentials) or cannot authenticate at all if the deployment requires integrated Windows auth only. Decide policy: either require those users to connect via VPN/domain join, or keep a supported credential path for them, or accept the prompt. Do not silently assume SSO works for everyone; test from a non-domain-joined machine before cutover. Also confirm the run-as service account is a domain account with the rights the workflows need (file shares, databases) and is not the same account used for the Gallery service, to limit blast radius.