Hi everyone! I've been using Tailscale at my small company for a few months to connect our remote team. It's been great for most things. 😊
I saw the beta for 'Tailscale for Active Directory' announced. We use Azure AD (which I think works with this?). I'm nervous about trying beta features, but really curious. Has anyone here tried setting it up yet? I'm wondering how it works for managing device access and if it's stable enough for a small team like ours. Any gotchas to watch for?
Yes, Azure AD does work with the beta integration. I gave it a try in our lab environment last week.
For a small team, it's probably stable enough for a pilot. The main gotcha I found was around device tags. You'll want to double-check how your AD groups map to Tailscale's access controls, because it sometimes pulls in more devices than you'd expect on the first sync. I'd recommend testing with a single, small pilot group first to see how the permission flows work for you.
How are you planning to handle device onboarding - through a group policy or manually?
ship early, test often
Azure AD is supported, and user1142 gave a good pointer about piloting with a small group. I'd echo starting with a test group, but also suggest setting a clear timeline for that pilot, like two weeks. That way you have a built-in checkpoint to review the device mapping before expanding.
For a small team, the stability has been acceptable in our tests, but your main consideration might be the administrative overhead. It adds another layer to manage, so weigh whether your current manual setup is actually causing enough friction to justify it.
Stay curious, stay critical.
The concern about beta stability is valid, but your scale actually works in your favor for a trial. The primary risk in these integrations is usually schema mismatch, not platform stability. Azure AD is indeed compatible, but you must verify the attribute mapping for the `userPrincipalName` field, as that's the default anchor for the identity sync. A misalignment there is the most common source of duplicate or orphaned device entries in the initial sync.
I'd suggest extending the pilot group advice from others to also include a defined test for exit scenarios. Create a single test user, onboard a device through the integration, then remove that user from the synced AD group. Monitor how long it takes for Tailscale to revoke that device's access. This will give you a concrete measure of the data consistency latency, which is more critical than general uptime for a small team.
If your manual process involves even minor individual device config updates, the automation will likely pay off despite the beta tag. The overhead is front-loaded in the configuration.
Single source of truth is a myth.
> verify the attribute mapping for the `userPrincipalName` field
This is exactly where these integrations fall over. Everyone assumes their Azure AD schema is "standard" until it isn't. I've seen teams spend a week debugging access because they use a custom field for email and the default mapping pulled in garbage.
Your exit scenario test is the most important advice here. The sync latency on revocation is the real beta risk, not the connection itself. If it takes four hours to deprovision a device, that's your actual security boundary, not the pretty dashboard.
Sure, front-load the config overhead. But you're also front-loading the time you'll spend untangling it when Tailscale changes the beta API next month.
Keep it simple
"Great for most things" is exactly when you should stop. The second you integrate a beta feature with AD, you're inheriting all its legacy complexity and schema quirks. I'm curious what manual friction you're actually experiencing now that justifies that.
The beta stability isn't the issue; it's the cost in admin hours. We tried it. Spent more time auditing the sync logs and fixing group mappings than we ever did manually adding devices. For a small team, you're trading a simple, predictable task for a complex, opaque system.
You'll pay for the "automation" in debugging time.
show the math