Bug 33234 - Samba4 migration - Update Scenario 1 - wrong type in idmap objects
Samba4 migration - Update Scenario 1 - wrong type in idmap objects
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: Samba4
UNSTABLE
Other Linux
: P5 normal (vote)
: UCS 3.2
Assigned To: Arvid Requate
Felix Botner
: interim-5
Depends on:
Blocks: 33363
  Show dependency treegraph
 
Reported: 2013-11-11 11:23 CET by Felix Botner
Modified: 2016-08-27 21:45 CEST (History)
3 users (show)

See Also:
What kind of report is it?: ---
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments
univention.tar.gz (98.77 KB, application/x-gzip)
2013-11-11 11:31 CET, Felix Botner
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Felix Botner univentionstaff 2013-11-11 11:23:36 CET
On the first s4 dc (backup) in a UCS 3.2 s3 environment (Samba4 migration - Update Scenario 1) the idmap objects for special groups seems to have the wrong type (should be ID_TYPE_BOTH), see Bug #33129

-> ldbsearch -H /var/lib/samba/private/idmap.ldb objectsid=S-1-5-7
# record 1
dn: CN=S-1-5-7
cn: S-1-5-7
objectClass: sidMap
objectSid: S-1-5-7
type: ID_TYPE_UID
xidNumber: 65534
distinguishedName: CN=S-1-5-7
Comment 1 Felix Botner univentionstaff 2013-11-11 11:31:23 CET
Created attachment 5598 [details]
univention.tar.gz

Also, lots of

Traceback (most recent call last):
  File "/usr/lib/univention-directory-listener/system/samba4-idmap.py", line 262, in handler
    add_or_modify_idmap_entry(new_sambaSID, new_xid, xid_type)
  File "/usr/lib/univention-directory-listener/system/samba4-idmap.py", line 194, in add_or_modify_idmap_entry
    idmap.setup_name_mapping(sambaSID, idmap_type[type_string], xidNumber)
  File "/usr/lib/python2.6/dist-packages/samba/idmap.py", line 98, in setup_name_mapping
    self.add(self.parse_ldif(mod).next()[1])
ValueError: unable to parse ldif string
11.11.13 10:46:59.303  LISTENER    ( WARN    ) : handler: samba4-idmap (failed)


in the listener log.
Comment 2 Arvid Requate univentionstaff 2013-11-11 12:45:56 CET
This also affects "Enterprise Domain Controllers" which causes sysvol-sync to fail due to a non-official posixID mapped in the idmap.ldb:

===================================================================
root@sbackup:~# ldbsearch -H /var/lib/samba/private/idmap.ldb objectsid=S-1-5-9
# record 1
dn: CN=S-1-5-9
cn: S-1-5-9
objectClass: sidMap
objectSid: S-1-5-9
type: ID_TYPE_BOTH
xidNumber: 3000010
distinguishedName: CN=S-1-5-9


root@sbackup:~# univention-ldapsearch -xLLL cn="Enterprise Domain Controllers"
dn: cn=Enterprise Domain Controllers,cn=groups,dc=perf,dc=test
cn: Enterprise Domain Controllers
univentionObjectType: groups/group
gidNumber: 5017
sambaGroupType: 5
objectClass: top
objectClass: posixGroup
objectClass: univentionGroup
objectClass: univentionObject
objectClass: sambaGroupMapping
sambaSID: S-1-5-9
univentionObjectFlag: hidden
univentionGroupType: -2147483643
memberUid: sbackup$
memberUid: sslave$
memberUid: pslave$
memberUid: pbackup$
uniqueMember: cn=sbackup,cn=dc,cn=computers,dc=perf,dc=test
uniqueMember: cn=sslave,cn=dc,cn=computers,dc=perf,dc=test
uniqueMember: cn=pslave,cn=dc,cn=computers,dc=perf,dc=test
uniqueMember: cn=pbackup,cn=dc,cn=computers,dc=perf,dc=test
===============================================================
Comment 3 Arvid Requate univentionstaff 2013-11-11 12:51:17 CET
Analysis results:
=================
This affects all groups that are on the connector/s4/mapping/group/ignorelist.
In this migration scenario the story goes like this:

* In this migration scenario the S4 Connector is configured to
  write Samba4 SIDs to the special UCS LDAP attribute "univentionSamba4SID"
  (configured by connector/s4/mapping/sid=false).

* The affected groups here are created in 96univention-samba4.inst
  with sambaSID but without univentionSamba4SID.

* Since the affected groups are on the ignorelist, they don't get the
  univentionSamba4SID attribute.

* The samba4-idmap listener looks for the univentionSamba4SID attribute and
  generates a traceback.

Proposal:
=========
I suggest adding univentionSamba4SID in _create_group_with_special_sid in case (directory/manager/samba3/legacy == yes and connector/s4/mapping/sid == false)
Comment 4 Arvid Requate univentionstaff 2013-11-11 19:32:00 CET
Patch comitted, package built and changelog adjusted.
Comment 5 Felix Botner univentionstaff 2013-11-13 17:33:13 CET
still got a traceback in the listener, the object was a joined windows host
Comment 6 Arvid Requate univentionstaff 2013-11-13 18:08:31 CET
Ok, there are two other cases where the univentionSamba4SID attribute is missing:

1. UCS hosts without "Samba 4".
2. The group "Windows Hosts"

I committed a patch that fixes the traceback, so the listener will continue to work and just issue a warning message in these cases:
============================================================================
root@pbackup:~# /usr/lib/univention-directory-listener/system/samba4-idmap.py --direct-resync
13.11.13 17:53:29.572  DEBUG_INIT
13.11.13 17:53:30.038  LISTENER    ( WARN    ) : Samba account 'Windows Hosts' has no attribute 'univentionSamba4SID', cannot add
13.11.13 17:53:30.078  LISTENER    ( WARN    ) : Samba account 'pslave$' has no attribute 'univentionSamba4SID', cannot add
13.11.13 17:53:30.079  LISTENER    ( WARN    ) : Samba account 'pmaster$' has no attribute 'univentionSamba4SID', cannot add
============================================================================

The second half of the issue should be fixed via Bug 33363.
Comment 7 Felix Botner univentionstaff 2013-11-14 10:35:00 CET
OK
Comment 8 Stefan Gohmann univentionstaff 2013-11-19 06:44:08 CET
UCS 3.2 has been released:
 http://docs.univention.de/release-notes-3.2-en.html
 http://docs.univention.de/release-notes-3.2-de.html

If this error occurs again, please use "Clone This Bug".