Description of problem: I would like to see that the sync future of the IPA support sync of groups from AD to DS Version-Release number of selected component (if applicable): How reproducible: setup IPA configure winsync enable newgroupsync Steps to Reproduce: 1. Setup IPA 2. configure ipa-winsync 3. enable newgroupsync Actual results: groups are not synced Expected results: groups synced from AD to IPA Additional info: This is a future request, this is not supported by IPA today.
Hello Daniel, Thank you for creating the RFE. However, we are no longer working on enhancing the AD sync feature, i.e. including implementing the support for group synchronization. AD sync mechanism of using AD users&groups in Linux environment was superseded by the Active Directory Trust feature, available from FreeIPA 3.0 and being heavily worked since then. You can check for example this page about AD Trust background: http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/active-directory-trust.html ... and also our wiki about practical AD Trust testing instructions: http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup
Hi Martin, Yes we know but the trust future see the AD users as separate users and not as IPA users... A user in IPA is only "username" while a AD user is called "username@AD" We as many other companies already have a LDAP with users and groups in it that is more or less the same as in the AD. What we would like is to map the AD and the IPA users to etch other so the existing group membership in the LDAP is kept as well as the AD groups for etch existing user in the IPA that matches a AD user... For this to work today we need to use sync.
I am not sure I understand. With AD Trust feature enabled, AD users can access Linux resources managed by FreeIPA without having to sync the users and groups from AD to FreeIPA and having them separate. Note that even though that the users are kept in AD, you can still add them to groups kept in FreeIPA, i.e when such users log in to FreeIPA managed computer, the system will recognize both AD groups and FreeIPA native Linux groups and assign those to user. For example, you can have group "webadmins" and have both selected users from FreeIPA and from AD to be in this group and then use this group for file ownership or sudo rules etc. Is this what you meant? Also adding Jan to CC, he has also a lot of experience with cooperation between Linux and AD users ("username@AD") in a system and applications.
Do I get the use case correct: You are currently syncing users and groups to a directory and you want to use IPA but you can't because it syncs only users on one hand or trusts because your setup assumes that groups are synced to IPA too. Now the question what is using groups from LDAP and why? Is it the clients or something else? We just need to understand more about the setup. This does not mean we will enable group sync, this means we will consider this use case as a part of the trust based setup.
Hi, As described earlier we do have a LDAP environment setup for our Linux and Unix systems, here we have users matching the AD users. For example we have a user named "dafo" in AD and in LDAP. If we use trust in this scenario the dafo user will be dafo@AD1 from AD1 and dafo@IPA1 from IPA1 so they are not the same user here, but in reality they are... What we want to do is syncing the dafo@AD1 user to the dafo@IPA1 user so that it is no difference in group membership and so on... The best would be, in my opinion that the IPA detects matching user in from the AD and maps the dafo@AD1 user to the dafo@IPA1 so that group membership is kept. what you get today is that you can map dafo@AD1 to a group, after first login!! and then you can map that group to a AD group and so on but all other groups that dafo is already a member of is lost... Yes they can be added again after first login but this is not a good enough option. it should be mapped to the already existing dafo user in IPA. The group sync function would be nice to have so that we could use AD groups instead of LDAP groups in the future to get one point of administration for the directory. The scenario you describe above is also a valid one, I think there is a lot of old LDAP solutions out there and if you cant keep your current configuration it is a lot harder to migrate to IPA.
(In reply to Daniel Forsberg from comment #5) > Hi, > > As described earlier we do have a LDAP environment setup for our Linux and > Unix systems, here we have users matching the AD users. > > For example we have a user named "dafo" in AD and in LDAP. > If we use trust in this scenario the dafo user will be dafo@AD1 from AD1 and > dafo@IPA1 from IPA1 so they are not the same user here, but in reality they > are... With AD trusts in place, you do not need both dafo@IPA1 as you already have the one in AD server and it is the authoritative source of this user. > What we want to do is syncing the dafo@AD1 user to the dafo@IPA1 user so > that it is no difference in group membership and so on... Ok, so we are talking about group memberships in LDAP. I think that currently recommend approach would be to use create a so called "external group" with FreeIPA and assign dafo@IPA1 to this group. This group of external objects can be then added as a member of a standard POSIX group and used for file ownerships, HBAC, etc. External groups in FreeIPA: http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/trust-groups.html This way, you do not need to sync anything, have dafo user identity on one place and still have him assigned to groups in FreeIPA LDAP. > > The best would be, in my opinion that the IPA detects matching user in from > the AD and maps the dafo@AD1 user to the dafo@IPA1 so that group membership > is kept. > > what you get today is that you can map dafo@AD1 to a group, after first > login!! and then you can map that group to a AD group and so on but all > other groups that dafo is already a member of is lost... > Yes they can be added again after first login but this is not a good enough > option. it should be mapped to the already existing dafo user in IPA. This seems wrong, see doc pointers as above. Group membership can be set without user logging in and it is permanent. > The group sync function would be nice to have so that we could use AD groups > instead of LDAP groups in the future to get one point of administration for > the directory. Just like with users, you should be able to assign AD groups added to FreeIPA "external group" as a member of your LDAP groups. > The scenario you describe above is also a valid one, I think there is a lot > of old LDAP solutions out there and if you cant keep your current > configuration it is a lot harder to migrate to IPA. I realize that the migration to AD Trust based solution needs some work compared to syncing groups and users from LDAP, but it is needed for you to be able to start using AD Trust advantages that are not available in sync solution - like SSO from AD to Linux or single user identity for accessing both domains. Alexander, did I forget anything about migrating to AD trusts?
(In reply to Martin Kosek from comment #6) > I realize that the migration to AD Trust based solution needs some work > compared to syncing groups and users from LDAP, but it is needed for you to > be able to start using AD Trust advantages that are not available in sync > solution - like SSO from AD to Linux or single user identity for accessing > both domains. > > Alexander, did I forget anything about migrating to AD trusts? looks ok, barring possible bugs we haven't stumbled upon yet, of course. We don't really have automatic solution for sync->trust case yet.
I will create an upstream ticket, just for tracking purposes. It will most likely end in "Deferred" bucket due to reasoning in Comment 6.
Upstream ticket: https://fedorahosted.org/freeipa/ticket/3946
Thank you taking your time and submitting this request for FreeIPA in Fedora. Unfortunately, this bug was not given a priority and was deferred both in Fedora and in the upstream FreeIPA project. Given that we are unable to fulfill this request in following Fedora releases, I am closing the Bugzilla as DEFERRED. To request re-consideration of this decision please reopen this Bugzilla and provide additional technical details about its importance to you. Note that you can still track this request or even contribute patches in the referred upstream Trac ticket.