The current Winsync functionality in 389 allows basic user and group entries to be synchronized from AD, and can optionally synchronize POSIX related attributes. This functionality can be enhanced to allow more control of what users/groups are synchronized as well as converting non-POSIX users from AD into POSIX users in 389 automatically. This flexibility can come in handy for various migration use-cases.
The following use-cases should be covered by the new enhancements:
We can show how these use cases in matrix form. These are broken down into two separate scenarios:
Scenario 1: Sync all users
Sync UID/GID from AD SID->UID/GID
POSIX users + +
Non-POSIX users N/A +
Scenario 2: Sync only POSIX users
Sync UID/GID from AD SID->UID/GID
POSIX users + +
In scenario 1, there is some flexibility in how you can treat AD entries that already have POSIX attributes. This flexibility is needed to support different migration strategies:
Scenario 2 is much more straight-forward. All POSIX attributes in AD will either be abandoned or preserved for the whole sync agreement. This behavior can not be switched on a per-user basis.
The new functionality should be implemented in the 389 POSIX Winsync plug-in, as the enhancements all revolve around POSIX users/groups. The high-level behavior will be controlled by two new configuration settings:
Attribute value generation will be supported for the following attributes:
Details on how we generate these values are as follows:
The generation of uidNumber and gidNumber values will be performed by ID mapping from the SID. There is already logic for this in SSSD, which is implemented in the libsss_idmap library. We should reuse this library instead of implementing the logic ourselves. There are some details on the algorithm available at http://jhrozek.fedorapeople.org/sssd/1.9.4/man/sssd-ad.5.html
Generation of the homeDirectory, loginShell, and gecos values is already supported in the FreeIPA Winsync plug-in. We should use the same logic in our own value generation code for these attributes. Here is an overview of the way FreeIPA generates these attribute values:
TBD
All of the configuration for these enhancements will be set in the main POSIX Winsync plug-in entry (dn: cn=Posix Winsync API,cn=plugins,cn=config). The high-level control for these enhancements will be handled by the two new settings described in the Design section above.
The value generation logic will also require a number of configuration settings. New settings that will be needed are:
The SID ID mapping in SSSD allows configuration to control how the mapping is performed. These settings are defined in the SSSD manual that is linked to in the SID Mapped Values section above. We will probably need to add configuration settings that mimic the settings that SSSD uses. Specifically, we will likely need settings for the following:
The enhancements are focused on synchronization in the AD->389 direction only. We need to determine how things should behave when bi-directional synchronization is enabled. There are a few outstanding questions I can think of:
For both of these scenarios, we should probably allow the behavior to be configurable with regards to synchronizing POSIX attributes from 389->AD. There might be situations where this is desirable, though our default behavior should be to avoid overwriting POSIX attributes in AD.
The enhancements should not have any impact on the core Replication functionality (non Winsync).
The new behavior will be turned off by default, so upgrades should not change the behavior. The new functionality can be manually enabled post-upgrade.
The SID ID mapping functionality is implemented in SSSD. We should make every effort to use their existing library, which will require us to add a dependency on SSSD. Most of what we need is already exposed by libsss_idmap.so, but there are some pieces that still need to be exposed. This has been filed as a ticket for the SSSD team at https://pagure.io/sssd/issue/1844.
The FreeIPA Winsync plug-in should handle the changes outlined above with no modifications. The reason this should work is that the FreeIPA Winsync plug-in currently checks if the POSIX attributes are already defined in the entry it receives from the 389 Winsync plug-in. If the attributes are already defined, FreeIPA leaves them intact instead of generating new values. The FreeIPA Winsync plug-in will be unable to differentiate between a value that truly came from AD and those that are generated by the 389 POSIX Winsync plug-in, so the generated values will be left intact.