Why teams move from WinSync to an AD trust in FreeIPA
A team that copies Active Directory users into FreeIPA with WinSync is maintaining a second copy of every identity and every password change, and that copy is the thing to retire. WinSync is deprecated in FreeIPA, and a cross-forest trust is the replacement. The trust lets Active Directory users authenticate to Linux hosts enrolled in FreeIPA through Kerberos, so Linux access no longer depends on passwords being copied from one directory to the other. Before planning the move, confirm with your own FreeIPA version and documentation how WinSync is currently supported in your deployment, since the deprecation status is the reason the migration exists.
The trust is established through Samba components, which FreeIPA uses to talk to Active Directory. That has a hard prerequisite that often surprises teams: the IPA domain must use a DNS domain that does not overlap with any domain in the AD forest. If your Linux estate was named with the same DNS suffix as the Windows forest, or a subdomain of it, you will need to settle the naming question before anything else. Check your current IPA domain, realm and every AD domain name in the forest, and record any overlap as a blocking item for the project plan.
Treat the move as a change of identity model, not a file copy. Decide which AD users and groups must log in to which Linux hosts, which copied accounts in FreeIPA will be retired, and how existing sudo and HBAC rules will reference AD objects. Confirm with your AD team who will own the trust configuration on the Windows side, and agree the cutover order before any copied accounts are removed. Keep a current backup of the FreeIPA servers before changing identity sources, because the backup documentation warns that restoring an outdated backup into an active replica topology can break replication.
What limits WinSync and why it becomes a liability
WinSync keeps Linux accounts aligned with Active Directory by copying objects and password changes between two directories. The cards below describe the points where that arrangement tends to break down, and each one is a risk to check in your own environment before you plan the move to a trust.
One-way copying of users
WinSync copies user objects from Active Directory into FreeIPA, so AD effectively remains the source of truth for those accounts. Attributes changed on the IdM side do not flow back, and a user disabled or renamed in one place can stay active or mismatched in the other. Export the attribute list and sync direction from your current configuration, then change a test user on each side and record what actually propagates. Your findings determine which accounts are safe to leave alone during the cutover.
Password changes depend on PassSync
Password changes reach FreeIPA only when a PassSync agent on an AD domain controller captures them and passes them along. Every domain controller that can process a password change needs the agent installed and working, and a missed domain controller means a password that works in one directory and fails in the other. Confirm which domain controllers run PassSync, how they are patched, and what users see when a change does not arrive.
Duplicated identities in two directories
Each person often exists as an AD account and as a separate FreeIPA account, with different UIDs, group memberships and lifecycle states. When someone leaves, both records must be removed, and a gap in either one leaves a working login behind. Ask for a report that counts users present in both directories, accounts that exist in only one, and identities whose enabled or disabled status differs. Illustrative example: an engineer disabled in AD but still active in FreeIPA.
Group and policy drift
Sudo rules and host-based access control rules in FreeIPA refer to groups that WinSync has copied from AD. When membership changes in AD, the copied groups update only as fast as the sync runs, so a rule can grant or deny access based on stale group membership. List every HBAC and sudo rule that references a synced group, and record who should be in each group after a change so you can compare the results.
Maintenance across two teams
Keeping WinSync working involves the Windows team, which owns domain controllers, PassSync installs and patch windows, and the Linux team, which owns IdM servers, the sync configuration and SSSD on clients. A platform update on either side can break the other, and troubleshooting usually needs both teams in the same call. Ask who owns each component, which runbook covers a sync failure, and when the sync configuration was last reviewed.
Namespace overlap with AD
A FreeIPA trust requires the IPA domain to use a DNS domain that must not overlap with any domain in the AD forest. Many WinSync deployments were built with names chosen before a trust was considered, so the planned trust may need a different domain name or a separate DNS plan. Record your IPA domain, realm and AD forest names now, along with every DNS zone that both sides serve.
How duplicated users cause access drift
WinSync leaves a copy of each synchronized AD user inside FreeIPA, and that copy starts to drift the moment either side changes. A user disabled in AD may still log in to a Linux host if the FreeIPA entry remains active, and a password reset in one directory does not reliably reach the other. Group membership adds a second source of drift: an AD user removed from a privileged group still holds the FreeIPA group membership that a sudo rule or HBAC rule relies on. Password policy differs too, because the FreeIPA password policy and the AD password policy each apply to their own entry. The result is that the same person can have different answers to the question of who may log in to Linux, depending on which directory the host consults.
Before cutover, build an inventory of every identity that WinSync created. Export the synchronized users and groups from FreeIPA and match them to their AD objects by UPN or SID so you know which copies have no live original. Then list every sudo rule and HBAC rule that names a copied user or group, because these are the rules that will break or quietly change meaning after the trust is in place. Record disabled accounts, accounts with expired or locked passwords, and any manually added memberships that do not come from AD. Ask the AD team to confirm which groups are the authoritative source for Linux access. Treat the inventory as the input to the cutover plan, not as a one-time report, and repeat it immediately before the change window.
Choosing the trust direction and ID mapping before cutover
The first decision is whether AD users need to reach FreeIPA resources, whether FreeIPA users need to reach AD resources, or both. WinSync only moved accounts from AD into FreeIPA, so it never gave AD users a trust-based login path. Trust direction changes what each side can reach and how authentication works, including whether Kerberos FAST and two-factor authentication need a two-way relationship. The direction also decides which team holds the AD-side configuration.
- Inbound needs: List the AD groups that must log in to Linux hosts and confirm whether they need access without a copied account.
- Outbound needs: Identify any FreeIPA users or services that must reach AD resources, such as file shares or applications.
- Two-factor dependencies: Check whether any login path depends on OTP or Kerberos FAST, since these can force a two-way design.
- Ownership: Agree with the AD team who creates the trust and who validates each half.
- Change control: Record the chosen direction in the design document, because changing it later means reworking trust objects.
Before cutover, confirm the direction against the sibling topic on one-way versus two-way trust and the list of AD groups that must log in.
AD users need UIDs and GIDs on Linux, and FreeIPA assigns them from an ID range tied to the trust. The two common approaches map UIDs from AD security identifiers or read POSIX attributes already stored in AD. The choice affects every Linux file ownership and login decision that follows, so it is hard to reverse once users log in. Treat the range approach as a design decision, not a configuration detail.
- SID-derived mapping: IDs are computed from each user's SID, so no AD attribute maintenance is required.
- POSIX-attribute mapping: IDs come from values the AD team maintains, which suits sites that already run AD as a Unix identity source.
- Auto private groups: Confirm how primary groups are created for AD users and whether existing Linux groups conflict.
- Overlap checks: Make sure the new range does not collide with ranges already used by FreeIPA users or local accounts on hosts.
- Irreversibility: Ask the implementation partner to document how a changed range would affect existing file ownership.
The sibling topic on ID ranges covers the mapping methods in full. Confirm the chosen approach with the AD team before any user logs in.
WinSync created FreeIPA accounts that were copies of AD users, usually with a stored password hash synchronized through PassSync agents. After cutover, an AD user may exist once as a WinSync account and again as a trust-derived identity. Before changing anything, the team needs to decide how each existing account maps to a SID and what happens to its UID, groups, sudo rules and home directory.
- Inventory: Export every WinSync-synchronized user and record its UID, groups and attached rules.
- Matching key: Decide how each FreeIPA account is matched to an AD SID, using account names and any stored AD identifiers.
- Duplicate resolution: Choose whether to retire the old account, keep it for a transition period or merge its rules into the trust identity.
- Ownership of files: Find files and home directories owned by the WinSync UID, because a new ID will not match them.
- Password dependencies: Note which services still rely on synchronized passwords, since they will not follow the trust login path.
Validate the mapping on a test host with a copy of the data before the production run. The migration section on this page gives the steps for that validation.
The decisions above interact, so they should be recorded together in one place that both the FreeIPA and AD teams can review. A short decision record lets the team see that a choice of direction limits the range options, or that a mapping rule depends on the range. It also gives auditors a clear account of why access changed during cutover. The record should name the owner of each decision and the evidence needed to approve it.
- Decision list: Capture trust direction, range approach, matching key and duplicate handling as separate entries.
- Dependencies: Note which decisions constrain others, such as a two-way trust affecting Kerberos settings.
- Evidence: Attach test results from a lab or staging trust, not assumptions.
- Approvers: Name the security, identity and AD owners who sign off on each entry.
- Rollback point: State the condition under which the team returns to WinSync-era logins during cutover.
Before moving on, check that every AD group needing Linux access appears in the record with its direction, range and mapping decided.
Cutover steps from WinSync to a trust
This sequence moves Linux logins from WinSync-synchronized accounts to AD users resolved through a cross-forest trust, with a verified backup and a documented rollback point at each stage before WinSync and PassSync are removed.
Confirm DNS and domain naming
The IPA domain must use a DNS domain that does not overlap with any domain in the AD forest, so confirm this before anything else changes. Check the IPA realm, the AD forest DNS domains, and the NetBIOS names with the AD team, and confirm that each side can resolve the other's SRV records. Done when both DNS checks return the expected records from the IPA servers and from an AD domain controller, and the naming decision is written down.
Back up the IdM topology before changes
Run ipa-backup on the first server and confirm the archive is complete and stored off the server. Choose a full backup, since the cutover changes account data and you will want a restore point that matches the current state. Restoring an outdated backup into an active replica topology can break replication, so restores must be planned as a topology-wide action and never run on one server alone. Done when the backup file is copied to separate storage and a test restore procedure has been reviewed by the operations team.
Establish the trust with the AD team
Coordinate the trust setup with the AD administrators so each side configures its own half and no FreeIPA administrator needs AD domain admin credentials. Confirm the trust direction and the Samba-based components on the IPA side before the AD team creates its trust object. Done when the trust reports as established from both sides and the trust status check passes on the IPA servers.
Verify AD users resolve on Linux clients
On a test client enrolled in IPA, look up an AD user and an AD group by name and confirm that the UID, GID and group membership resolve through SSSD. Compare these values with the WinSync-created accounts that exist for the same people, since duplicated users can appear with different identifiers. Done when lookups return AD identities consistently on at least one test host and the team has a list of every account that now exists twice.
Move sudo and HBAC rules to AD groups
Update HBAC and sudo rules so they reference external groups or AD objects instead of the WinSync-created groups. Make these changes in a copy or a staging rule set first, so the current access stays unchanged until the new rules are tested. Done when every rule that previously referenced a synchronized group points at the AD-backed group and the rule review shows no orphaned references.
Test logins for each access group
Test SSH and console logins for a representative user from each access group, on each host class the rules cover. Confirm that sudo elevation works for the right groups and fails for the others, and record the results. Keep the WinSync accounts active during this step so a failed test can be rolled back. Done when every access group has a passing login and sudo test and the results are signed off by the Linux and AD owners.
Disable and remove WinSync and PassSync
Once all tests pass, disable the WinSync replication agreement and stop the PassSync agents on the AD domain controllers, then confirm no new password changes flow through them. Remove the WinSync configuration and the PassSync software only after a waiting period agreed with the AD team, and keep the final backup until the cutover is accepted. Done when the replication status shows no active WinSync agreement, the PassSync agents are removed from the domain controllers, and a fresh login test succeeds.
Security and operational risks during the cutover
A WinSync-to-trust cutover changes who can authenticate Linux users and where their credentials live, so the risks cluster around credentials, authentication paths and recovery. The cards below cover the controls to set and the checks to run before, during and after the change.
Keep AD admin credentials out of FreeIPA
Under WinSync, PassSync agents and synchronization accounts have historically touched AD password handling, which pushed teams toward sharing privileged credentials. A trust set up with a shared secret lets each team configure its own half, so FreeIPA administrators do not need AD domain admin rights. Agree the split of responsibilities in writing with the AD team before the cutover window, and confirm which accounts hold which rights on each side.
Remove PassSync agents deliberately
PassSync agents on domain controllers forward password changes to FreeIPA, and they keep running until someone removes them. Leaving them active after the trust is live can keep an old password path open that the trust was meant to replace. List every domain controller where the agent was installed, record the removal in your change log, and confirm that password changes in AD no longer write to the IPA directory.
Verify Kerberos and authentication paths
After the cutover, test Kerberos ticket issuance for both AD users and existing IPA users on representative Linux hosts. Check that SSSD resolves the expected identity, that the correct authentication flow runs, and that multi-factor settings behave as they did before. Run these tests from a host in each data center you operate, and record the results so a later failure can be compared against a known good baseline.
Back up before any change
Take a full FreeIPA backup on the first server before the trust or any user changes begin. FreeIPA's backup documentation warns that restoring an outdated backup into an active replica topology can break replication, so restore decisions need the current topology in view. Keep the backup off the server being changed, and rehearse a restore in a non-production environment if your recovery plan depends on it.
Confirm the running FreeIPA version
FreeIPA 4.13.4, a stabilization release dated July 9, 2026, fixed two CVEs, including LDAP access control flaws that could let unauthenticated clients obtain credentials, and hardened authentication checks across the API. Confirm the version on every server and replica before cutover, and plan the upgrade first if any server runs an earlier release. Treat this as a prerequisite, not an optional follow-up.
Monitor login failures during the window
Watch authentication failures on Linux hosts, KDC logs and SSSD logs for the first hours and days after cutover. A rise in failures for one group often points to a missing external group mapping, a changed UID, or an HBAC rule that no longer matches. Set alert thresholds before the window opens, assign an owner for each alert, and define who can roll back a host or a policy without waiting for a wider decision.
Questions teams ask before the WinSync cutover
How long does a WinSync to AD trust move take?
The duration depends mostly on how many users and groups are involved, how many sudo and HBAC rules reference them, and how much time the Active Directory team can give to the trust setup and validation. No fixed duration applies to every estate, so ask for a schedule built from your own counts. Start by inventorying WinSync-synced users, their groups, sudo rules and HBAC rules, then have the AD team confirm when they can work on DNS, trust setup and testing. Those three inputs usually decide the timeline more than the FreeIPA commands themselves.
What drives the cost of replacing WinSync with a trust?
Cost follows the work that has to be done by each party. The main drivers are the number of users and groups, how many sudo and HBAC rules must be rewritten to reference AD objects, how many Linux hosts need access testing, and how much coordination the AD team needs. Some costs are one-time, such as planning, migration of rules and cutover testing. Others recur, such as maintaining ID views and monitoring the trust. Ask any quote to break these items out separately so you can see what your own team could absorb.
What does the client need to provide for this work?
You need a FreeIPA deployment you control, administrative access to the IdM servers, a documented list of the AD forest and domains involved, and named contacts on the AD side who can approve DNS and trust changes. You also need an inventory of current WinSync scope, sudo and HBAC rules, and the Linux hosts that rely on them. Confirm early whether the AD team can grant the trust setup steps without giving FreeIPA administrators domain admin credentials, since that choice affects who performs each step.
Can our internal team move from WinSync to a trust without a partner?
Yes, a capable internal team can do this, provided it has FreeIPA operations experience, access to the AD team, and time for testing. The work is not only command execution. It requires careful DNS planning, a decision on ID ranges, and a cutover plan that keeps Linux logins working for every host. Teams without recent FreeIPA trust experience often underestimate the rule rewrites and validation. A useful test is whether someone on your team can explain the current WinSync scope and the target trust design without consulting documentation.
What happens to Linux access when WinSync is removed?
Removing WinSync stops synchronizing Active Directory accounts into FreeIPA, so users and groups that depended on synced copies can lose access if the trust is not working first. The safe order is to establish the trust, confirm that AD users resolve on test hosts, rewrite sudo and HBAC rules to reference the correct objects, and only then disable the synchronization. Expect duplicated users during the transition, and plan how to remove or retire those copies. Also check any PassSync agents, because they depend on the synchronization path you are replacing.
What are the main risks of duplicated users during the cutover?
Duplicated users arise when a synced WinSync account and an AD trust user refer to the same person under different identifiers. This can split group membership, break sudo and HBAC matching, and produce inconsistent UIDs and GIDs on Linux hosts. Before cutover, decide which identity is authoritative for each user, check how names map through the realm and NetBIOS settings, and test login on representative hosts. Confirm with the AD team how account changes such as renames or disables will reach FreeIPA after the move.
When should we bring in a partner for this migration?
Bring in a partner when the estate is large, when several AD domains or sites are involved, when the AD team cannot commit time for testing, or when the trust must be cut over with little tolerance for failed logins. A partner is also useful when ID mapping decisions, sudo rule rewrites or PassSync dependencies are unclear. DeployOpen works on fixed-scope engagements, with scope, deliverables and timelines agreed in writing before work starts, so you can compare a partner quote against the internal effort you have identified.
What to confirm in your environment
Most of the risk in moving from WinSync to a trust sits in facts about your existing Active Directory forest, your DNS and your Linux estate, not in the FreeIPA commands themselves. The cards below list what to verify before a cutover date is set, and each one names the decision it feeds.
AD forest and domain functional levels
Confirm the forest and domain functional levels of every AD domain that will hold users who need Linux access. Ask the AD team to export the values rather than rely on memory, because the levels decide which Windows Server versions can act as domain controllers in the trust. Record the answer next to your FreeIPA version so the trust design can be checked against both sides.
Supported Windows Server versions
List every domain controller version in the AD forest, including the ones planned for the next year. A trust needs domain controllers that FreeIPA's Samba components support, and mixed fleets often hide an older controller that becomes the weakest link. Ask whether your RHEL release supports the Windows Server versions you run, because that support depends on the operating system, not only on FreeIPA.
DNS overlap rules
The IPA domain must use a DNS domain that does not overlap with any domain in the AD forest. Check your zone list on both sides for an existing name that matches the planned IPA domain, including delegated subdomains and internal names that were never published. An overlap found after cutover forces a rename, which is far harder than correcting it on paper first.
Samba components on your RHEL version
Trusts depend on Samba components on the FreeIPA servers. Confirm that your RHEL release ships the packages you need at the versions the trust requires, and check whether they are in the base repositories or a separate channel your organization must subscribe to. Test the package set on a non-production replica first, because a missing or mismatched package can stop the trust setup late in the project.
Applications bound to WinSync accounts
Inventory every system that authenticates against accounts created by WinSync, including SSH keys, sudo rules, file ownership, service accounts and scripts that look up users by UID or username. Accounts created by WinSync may have different UIDs and home directories from those a trust will assign, so each dependency needs an owner and a test. Ask application owners to confirm what they depend on before any account is removed.
Password sync agents still in use
Identify every Windows domain controller that runs a PassSync agent and every application that still depends on synchronized passwords. Confirm who owns the agents and whether their removal needs a change request on the Windows side. Once users authenticate through the trust, the agents stop being the source of truth for Linux logins, but services that read the synchronized password may keep failing until they are updated.
Official FreeIPA documentation for trusts and migration
Before you change anything, read the FreeIPA Trusts page in full. It sets out the rule that matters most for this move: the IPA domain must use a DNS domain that does not overlap with any domain in the AD forest. If your current WinSync setup uses a DNS namespace that overlaps with AD, that is the first thing to resolve, because the trust cannot be built until it is fixed. Confirm the trust prerequisites against the release you run in production, since the page describes the Samba components that the trust depends on and their packaging varies by distribution.
Next, read the FreeIPA backup and restore documentation before the cutover rehearsal. The backup page notes that the first server handles certificate renewal and CRL publication by default, and that restoring an outdated backup into an active replica topology can break replication. Plan your cutover around a fresh full backup taken from a healthy server, and decide in advance which server holds the renewal role during the change window. Test restore on a separate environment, not on the live topology.
Finally, read the migration how-to. It explains that ipa migrate-ds moves users and groups from another LDAP server while excluding Kerberos attributes that FreeIPA regenerates, and that sudo and HBAC rules need manual migration through LDIF. Map every WinSync-era sudo and HBAC rule to its trust-era equivalent before cutover, and verify with the FreeIPA release notes for your version that the migration path you choose is supported. Where the documentation leaves a step unclear for your topology, ask your FreeIPA support contact or DeployOpen to confirm it in writing before you rely on it.
