RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 868841 - Newly created users with organizationalPerson objectClass fails to sync from AD to DS with missing attribute error
Summary: Newly created users with organizationalPerson objectClass fails to sync from ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: 389-ds-base
Version: 6.4
Hardware: All
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Rich Megginson
QA Contact: Sankar Ramalingam
URL:
Whiteboard:
Depends On:
Blocks: 881827
TreeView+ depends on / blocked
 
Reported: 2012-10-22 09:26 UTC by Sankar Ramalingam
Modified: 2020-09-13 20:19 UTC (History)
4 users (show)

Fixed In Version: 389-ds-base-1.2.11.15-4.el6
Doc Type: Bug Fix
Doc Text:
Cause: Even if an entry in AD does not have all the required attributes for the posix account entry, the entry is being synchronized to the directory server as an posix account entry. Consequence: The synchronization fails due to the missing attribute error. Fix: If the entry does not have all the required attributes, the posix account related attributes are dropped and the entry is synchronized as an ordinary entry. Result: Even if there are missing posix account related attributes, the entry is successfully synchronized.
Clone Of:
Environment:
Last Closed: 2013-02-21 08:21:07 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github 389ds 389-ds-base issues 500 0 None None None 2020-09-13 20:19:25 UTC
Red Hat Product Errata RHSA-2013:0503 0 normal SHIPPED_LIVE Moderate: 389-ds-base security, bug fix, and enhancement update 2013-02-21 08:18:44 UTC

Description Sankar Ramalingam 2012-10-22 09:26:12 UTC
Description of problem: Synchronization of newly created users from AD to DS fails with missing attribute "uidNumber" required by object class "posixAccount". The user is created with organizationalPerson objectClass in AD. 

Version-Release number of selected component (if applicable): 389-ds-base-1.2.11.15-2

How reproducible: Consistently

Steps to Reproduce:
1. Install the latest build of 389-ds-base-1.2.11 on RHEL64.
2. Create an instance and configure winsync.
3. Enable Posix Winsync plugin - "cn=Posix Winsync API,cn=plugins,cn=config"
4. Run full sync to create the existing users from DS to AD and vice versa.
5. Create few posix users on AD with posixAccount objectClass, uidNumber and gidNumber attribute.
6. Check whether the users synced to DS. Successfully created user on DS.
7. Create a normal user without posixAccount(with organizationalPerson) objectClass from AD.
8. Check whether users synced to DS. Failed to create user on DS.
  
Actual results: 
[22/Oct/2012:01:24:20 -0400] - Entry "uid=adadnewadad1,ou=dswinsync,dc=passsync,dc=com" missing attribute "uidNumber" required by object class "posixAccount"
[22/Oct/2012:01:24:20 -0400] - Entry "uid=adadnewadad1,ou=dswinsync,dc=passsync,dc=com" missing attribute "gidNumber" required by object class "posixAccount"
[22/Oct/2012:01:24:20 -0400] NSMMReplicationPlugin - add operation of entry uid=adadnewadad1,ou=dswinsync,dc=passsync,dc=com returned: 65

Expected results:
Winsync should support the normal user synchronization as well.


Additional info: This looks like a regression.

Comment 2 Noriko Hosoi 2012-10-29 23:37:46 UTC
Upstream ticket:
https://fedorahosted.org/389/ticket/500

Comment 3 Noriko Hosoi 2012-11-13 19:49:45 UTC
These are the verification steps.  Please note that this change is included in 389-ds-base-1.2.11.15-4.el6 or after.

Verification steps:
test case 1) add a user entry to AD, which contains required attributes: unixHomeDirectory, uidNumber, gidNumber. The entry is supposed to be synchronized to the DS as a posix entry which includes:

objectclass: posixaccount
homeDirectory: <home directory>
uidNumber: <uid number>
gidNumber: <gid number>

test case 2) add a user entry to AD, which contains no required attributes, but an allowed attribute, loginShell. The entry is supposed to be synchronized to the DS as an ordinary entry which does not include any posix account related attributes.

test case 3) modify an ordinary entry on AD to add required attributes unixHomeDirectory, uidNumber, gidNumber. The entry on the DS is supposed to become a posix account entry with the above attributes.

test case 4) modify an ordinary entry on AD to add no required attributes, but an allowed attribute loginShell. The modification is supposed to be ignored.

Comment 5 Sankar Ramalingam 2012-11-27 13:14:14 UTC
The above mentioned tests successfully passed after upgrading the 389-ds-base package to 1.2.11.15-4. Hence marking the bug as Verified.

Comment 6 errata-xmlrpc 2013-02-21 08:21:07 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2013-0503.html


Note You need to log in before you can comment on or make changes to this bug.