#2324 AD Users synced to IPA server are not added to "ipausers" group
Closed: wontfix 3 years ago Opened 9 years ago by mkosek.

https://bugzilla.redhat.com/show_bug.cgi?id=785201 (Red Hat Enterprise Linux 6)

Description of problem:

When Windows Active Directory Users are synced to IPA server, the AD user is
not added as a member of "ipausers" .

As per the ipa-winsync configuration on ipa server, ipawinsyncdefaultgroupattr:
ipaDefaultPrimaryGroup

and ipaDefaultPrimaryGroup is "ipausers"

dn: cn=ipa-winsync,cn=plugins,cn=config
objectClass: top
objectClass: nsSlapdPlugin
objectClass: extensibleObject
cn: ipa-winsync
nsslapd-pluginPath: libipa_winsync
nsslapd-pluginInitfunc: ipa_winsync_plugin_init
nsslapd-pluginDescription: ipa winsync plugin
nsslapd-pluginId: ipa-winsync-plugin
nsslapd-pluginVersion: FreeIPA/1.0
nsslapd-pluginVendor: FreeIPA project
nsslapd-pluginType: preoperation
nsslapd-pluginEnabled: on
nsslapd-plugin-depends-on-type: database
ipawinsyncrealmfilter: (objectclass=krbRealmContainer)
ipawinsyncrealmattr: cn
ipawinsyncnewentryfilter: (cn=ipaConfig)
ipawinsyncnewuserocattr: ipauserobjectclasses
ipawinsyncuserflatten: true
ipawinsynchomedirattr: ipaHomesRootDir
ipawinsyncloginshellattr: ipaDefaultLoginShell
ipawinsyncdefaultgroupattr: ipaDefaultPrimaryGroup
ipawinsyncdefaultgroupfilter: (gidNumber=*)(objectclass=posixGroup)(objectclas
 s=groupOfNames)
ipawinsyncacctdisable: both
ipawinsyncforcesync: true
ipawinsyncuserattr: uidNumber 999
ipawinsyncuserattr: gidNumber 999



After the AD user is synced, the gidNumber is same as the uidNumber i.e alloted
to AD User.

Example, Below is the entry of the ADUser that is synced from Windows 2008
Server.

dn: uid=rhipauser1,cn=users,cn=accounts,dc=iris,dc=gsslab,dc=pnq,dc=redhat,dc=
 com
mepManagedEntry: cn=rhipauser1,cn=groups,cn=accounts,dc=iris,dc=gsslab,dc=pnq,
 dc=redhat,dc=com
objectClass: top
objectClass: person
objectClass: organizationalperson
objectClass: inetOrgPerson
objectClass: ntUser
objectClass: inetuser
objectClass: posixaccount
objectClass: krbprincipalaux
objectClass: krbticketpolicyaux
objectClass: ipaobject
objectClass: mepOriginEntry
ntUserDeleteAccount: true
uid: rhipauser1
sn: user1
givenName: rhipa
initials: rh
cn: rhipauser1
ntUserCodePage: 0
ntUserAcctExpires: 9223372036854775807
ntUserDomainId: rhipauser1
ntUniqueId: 3ac04b5c42927642b4531edf54072c3f
krbPrincipalName: rhipauser1@IRIS.GSSLAB.PNQ.REDHAT.COM
homeDirectory: /home/rhipauser1
gecos: rhipauser1
loginShell: /bin/sh
uidNumber: 1297200004
gidNumber: 1297200004
ipaUniqueID: f75d6f70-494e-11e1-a08b-5254005a4de1



Version-Release number of selected component (if applicable):
ipa-server-2.1.3-9.el6.x86_64

How reproducible:


Steps to Reproduce:
1. Configure Windows AD Sync
ipa-replica-manage connect --winsync --binddn
cn=rhipasyncuser,cn=Users,dc=iris,dc=gsslab,dc=pnq,dc=redhat,dc=com --bindpw
1redsmB --passsync redhat@123 --cacert /etc/openldap/cacerts/certnew.cer
--win-subtree ou=ipa,dc=iris,dc=gsslab,dc=pnq,dc=redhat,dc=com
irene.iris.gsslab.pnq.redhat.com -v

2. Create users on AD  under "ou=ipa,dc=iris,dc=gsslab,dc=pnq,dc=redhat,dc=com
" on Windows Server.

3. The AD user on IPA will not be a member of "ipausers" group


Actual results:

 The AD user on IPA will not be a member of "ipausers" group

Expected results:

 The AD user on IPA should be a member of "ipausers" group

Additional info:

I have now been dealing with winsync so I should be able to handle this one.

Moving the ticket back to NEEDS_TRIAGE to re-target. Current 389-ds winsync plugin API does not have API for user-add post callback, i.e. we enroll the migrated user to ipausers group as it don't exist yet.

I already filed a RFE ticket to 389 to add this callback:

https://fedorahosted.org/389/ticket/316

Moved to later release to take advantage of the DS change.

Isn't the auto membership plugin supposed to handle this sort of thing?

When a new user is added, in some way other than via AD sync, how is the user added to the ipausers group?

Replying to [comment:6 rmeggins]:

Isn't the auto membership plugin supposed to handle this sort of thing?

Yes, auto membership can be used to handle this sort of things. But we keep from creating our system rules like "Put all AD synced users to ipausers" because it limits user's possibilities. The system rule would bias auto membership rules for AD users - for example default fallback group would never be applied for them.

When a new user is added, in some way other than via AD sync, how is the user added to the ipausers group?

It is enrolled during ipa user-add command. We considered using auto membership for this purpose, but then abandoned the effort because of the reasons above.

AFAIR the decision was to give users a description of how this can be accomplished with automembership in the documentation but not do it ourselves as it would limit user's possibilities.

Replying to [comment:8 dpal]:

AFAIR the decision was to give users a description of how this can be accomplished with automembership in the documentation but not do it ourselves as it would limit user's possibilities.

Ok. I'm just trying to determine if it is really necessary to extend winsync to handle this case. It sounds like it is, so I will proceed with https://fedorahosted.org/389/ticket/316

389-ds-base-1.2.11 added post add/mod callbacks in the winsync api v2.
http://port389.org/wiki/Windows_Sync_Plugin_API#Version_2_API_functions

This will allow you to add groups after a user has been added from AD to IPA.

Moving my tickets back to free-to-take pool.

Metadata Update from @mkosek:
- Issue assigned to someone
- Issue set to the milestone: Tickets Deferred

4 years ago

Thank you taking time to submit this request for FreeIPA. Unfortunately this bug was not given priority and the team lacks the capacity to work on it at this time.

Given that we are unable to fulfil this request I am closing the issue as wontfix. To request re-consideration of this decision please reopen this issue and provide additional technical details about its importance to you.

Metadata Update from @rcritten:
- Issue close_status updated to: wontfix
- Issue status updated to: Closed (was: Open)

3 years ago

Login to comment on this ticket.

Metadata