Bug 35566 - AD connector in with machine account as binddn does not delete users in UCS
AD connector in with machine account as binddn does not delete users in UCS
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: AD Connector
UCS 3.2
Other Linux
: P5 normal (vote)
: UCS 3.2-2-errata
Assigned To: Arvid Requate
Felix Botner
:
Depends on:
Blocks: 34091
  Show dependency treegraph
 
Reported: 2014-08-05 11:06 CEST by Felix Botner
Modified: 2014-08-07 17:46 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
grant_LSRP_DSACL_to_master70.ldif (370 bytes, text/plain)
2014-08-05 13:18 CEST, Arvid Requate
Details
make_Deleted_Objects_readable_for_this_machine.py (11.69 KB, text/plain)
2014-08-05 16:26 CEST, Arvid Requate
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Felix Botner univentionstaff 2014-08-05 11:06:09 CEST
At least in AD member mode the connector does not delete users in UCS if they are deleted in windows.
Comment 1 Arvid Requate univentionstaff 2014-08-05 11:29:04 CEST
This was observed in AD Member mode joined into a Windows 2008R2 AD:

After deleting user1 in AD the user was not deleted in UCS. The internal.sqlite shows:

DN Mapping UCS:
uid=user1,cn=users,dc=arw2k8r2i2,dc=qa|cn=user1,cn=users,dc=arw2k8r2i2,dc=qa

DN Mapping CON:
cn=user1,cn=users,dc=arw2k8r2i2,dc=qa|uid=user1,cn=users,dc=arw2k8r2i2,dc=qa

AD GUID:
DtTsplLr2ESQ/XjZCFNcmQ==
|CN=user1,CN=Users,DC=arw2k8r2i2,DC=qa


root@master40:~# ldbsearch --show-deleted -H ldap://10.200.8.237 -UAdministrator%Univention.99 sAMAccountName=user1
# record 1
dn: CN=user1\0ADEL:a6ecd40e-eb52-44d8-90fd-78d908535c99,CN=Deleted Objects,DC=arw2k8r2i2,DC=qa
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn:: dXNlcjEKREVMOmE2ZWNkNDBlLWViNTItNDRkOC05MGZkLTc4ZDkwODUzNWM5OQ==
distinguishedName: CN=user1\0ADEL:a6ecd40e-eb52-44d8-90fd-78d908535c99,CN=Dele
 ted Objects,DC=arw2k8r2i2,DC=qa
instanceType: 4
whenCreated: 20140731084758.0Z
whenChanged: 20140801112144.0Z
uSNCreated: 16475
isDeleted: TRUE
uSNChanged: 24983
name:: dXNlcjEKREVMOmE2ZWNkNDBlLWViNTItNDRkOC05MGZkLTc4ZDkwODUzNWM5OQ==
objectGUID: a6ecd40e-eb52-44d8-90fd-78d908535c99
userAccountControl: 512
objectSid: S-1-5-21-1950644492-691169364-2646992570-1106
sAMAccountName: user1
lastKnownParent: CN=Users,DC=arw2k8r2i2,DC=qa
isRecycled: TRUE



The connector.log at debug level 10 shows no trace of the delete, only
01.08.2014 13:23:07,466 LDAP        (INFO   ): Search AD with filter: (uSNCreated>=25004)
01.08.2014 13:23:07,469 LDAP        (INFO   ): Search AD with filter: (uSNChanged>=25004)
Comment 2 Arvid Requate univentionstaff 2014-08-05 12:18:30 CEST
Hmm, now I deleted another user and after deleting it has uSNChanged: 25014 but the connector keeps looking for "uSNChanged>=25004":

01.08.2014 14:21:23,94 LDAP        (INFO   ): Search AD with filter: (uSNCreated>=25004)
01.08.2014 14:21:23,97 LDAP        (INFO   ): Search AD with filter: (uSNChanged>=25004)

root@master70:~# sqlite3 /etc/univention/connector/internal.sqlite  'select * from AD;'
lastUSN|25003




Then I create a new user in AD and the AD Connector recognizes the change and synchronizes the new user:

01.08.2014 14:25:08,652 LDAP        (PROCESS): sync to ucs:   [          user] [       add] uid=user11,cn=users,dc=arw2k8r2i2,dc=qa
[...]
01.08.2014 14:25:16,58 LDAP        (INFO   ): Search AD with filter: (uSNCreated>=25031)
01.08.2014 14:25:16,62 LDAP        (INFO   ): Search AD with filter: (uSNChanged>=25031)


My impression is that the machine account cannot read/find the deleted objects in AD. Using ldbsearch (from another Samba4 DC where this tool is usable):

ldbsearch --show-deleted -H ldap://10.200.8.237 \
   -Umaster70$%348RdMHrJ49FOXDWNukW sAMAccountName=user2 

returns nothing but the same search as "Administrator" returns the deleted object.
Comment 3 Arvid Requate univentionstaff 2014-08-05 12:23:05 CEST
http://support.microsoft.com/kb/892806/en-us
Comment 4 Arvid Requate univentionstaff 2014-08-05 13:18:44 CEST
Created attachment 6056 [details]
grant_LSRP_DSACL_to_master70.ldif

Following the knowledge base article creates the attached nTSecurityDescriptor for "CN=Deleted Objects". It's possible to do this from the AD Member wizard via python-ldap. These points have to be considered for this:

* The SID of the local DC must be looked up as it needs to be written into the nTSecurityDescriptor.

* The "CN=Deleted Objects" doesn't have a nTSecurityDescriptor by default, but it may have one set in the domain we join into. So we have to provide a default (see attached ldif) or manipulate the existing DSACLs.

* The new rule "(A;;RPLC;;;<SID_of_the_UCS_DC>)" should maybe be put as the first of the SACL list and after the D:PAI flags (but they don't necessarily look that way).

* via samba.dcerpc we can decode and modify the nTSecurityDescriptor, either textually via SDDL manipulation or via the methods of the object. Maybe the latter is more safe.

* We can only modify the object via python-ldap, as ldapmodify CLI doesn't seem to allow passing the required "show delted objects" control.
Comment 5 Arvid Requate univentionstaff 2014-08-05 16:26:29 CEST
Created attachment 6058 [details]
make_Deleted_Objects_readable_for_this_machine.py

I hit a wall here: "CN=Deleted Objects" doesn't have a nTSecurityDescriptor set by default. If it is not set, the python ldap.modify_ext_s fails with 'Insufficient access'.

So currently there are only three ways to do this:
1) Run
     dsacls "CN=Deleted Objects,..." /takeownership
   once as Administrator on the AD Server commandline.
2.A) Then run dsacls "CN=Deleted Objects,..." /G:MYDOM\UCSMASTER$:LCRP
2.B) Or the attached script from UCS (with --binddn and --bindpwd)

or

3) run
     ldbmodify --controls=sd_flags:1:1 --show-deleted -H ldap://10.200.8.237 \
     --simple-bind-dn=CN=Administrator,CN=Users,DC=ARW2K8R2I2,DC=QA \
     --password=Univention.99 \
     grant_LSRP_DSACL_to_master70.ldif
   from a Samba4 system. Unfortunately ldbmodify is not available without
   having a couple of samba4 libraries installed, which are unavailable
   in "AD Member" mode.


Somehow I could not get the required controls passed through properly via python-ldap until now.
Comment 6 Arvid Requate univentionstaff 2014-08-05 17:39:42 CEST
Ok, now it seems to work. The control value was required to be a BER encoded structure. Rebuilding and testing.
Comment 7 Arvid Requate univentionstaff 2014-08-05 19:03:43 CEST
The AD Member wizard now calls "make-deleted-objects-readable-for-this-machine" with the given AD Admin credentials via univention-lib before finally starting the connector. Deleted objects are then recognized by the AD Connector.

Advisory: 2014-07-03-univention-ad-connector.yaml
Comment 8 Felix Botner univentionstaff 2014-08-06 10:07:48 CEST
works great, tested on w2k3r2 (de), w2k8r2 (en) and w2k12

AD ACL's look good:

@w2k8r2 (en) -> dsacls "cn=deleted objects,dc=base"
Owner: W2K8R2EN\Domain Admins
Group: NT AUTHORITY\SYSTEM
Access list:
{This object is protected from inheriting permissions from the parent}
Allow W2K8R2EN\master$        SPECIAL ACCESS
                              LIST CONTENTS
                              READ PROPERTY
Allow BUILTIN\Administrators  SPECIAL ACCESS
                              LIST CONTENTS
                              READ PROPERTY
Allow NT AUTHORITY\SYSTEM     SPECIAL ACCESS
                              DELETE
                              READ PERMISSONS
                              WRITE PERMISSIONS
                              CHANGE OWNERSHIP
                              CREATE CHILD
                              DELETE CHILD
                              LIST CONTENTS
                              WRITE SELF
                              WRITE PROPERTY
                              READ PROPERTY

@w2k12 (de) -> dsacls "cn=deleted objects,dc=base"
Besitzer: W2K12\Domänen-Admins
Gruppe: NT-AUTORITÄT\SYSTEM
Zugriffsliste:
{Objekt ist vor Vererbung von Übergeordneten Berechtigungen geschützt}
Zulassen   W2K12\master$                 Beschränkter Zugriff
                                         LIST CONTENTS
                                         READ PROPERTY
Zulassen   VORDEFINIERT\Administratoren  Beschränkter Zugriff
                                         LIST CONTENTS
                                         READ PROPERTY
Zulassen   NT-AUTORITÄT\SYSTEM           Beschränkter Zugriff
                                         DELETE
                                         READ PERMISSONS
                                         WRITE PERMISSIONS
                                         CHANGE OWNERSHIP
                                         CREATE CHILD
                                         DELETE CHILD
                                         LIST CONTENTS
                                         WRITE SELF
                                         WRITE PROPERTY
                                         READ PROPERTY

univention-adsearch with machine account can now see deleted objects:

-> univention-adsearch cn=*| grep DN:| grep -i del
DN: CN=Deleted Objects,DC=w2k3,DC=test
DN: CN=win1\0ADEL:f9c82ee8-8d78-4ebe-91c8-c5f0f7d524ae,CN=Deleted Objects,DC=w2k3,DC=test

-> univention-adsearch cn=deleted\ objects
DN: CN=Deleted Objects,DC=w2k12,DC=test

-> -> univention-adsearch 'cn=*\0ADEL*' dn
DN: CN=win4 win4\0ADEL:fd18c71d-5824-4797-964f-d545e46bb7d3,CN=Deleted Objects,DC=w2k8r2en,DC=test
DN: CN=win5 win5\0ADEL:b754122d-4fe2-482c-95ac-ab6d429e675b,CN=Deleted Objects,DC=w2k8r2en,DC=test
DN: CN=win6 win6\0ADEL:112f9d24-92e1-4ee6-b6eb-7bb2699d7cd1,CN=Deleted Objects,DC=w2k8r2en,DC=test

And the connector deletes objects deleted in AD:

-> cat /var/log/univention/connector.log| grep delete
06.08.2014 10:29:02,469 LDAP        (PROCESS): sync to ucs:   [          user] [    delete] uid=win3,cn=users,dc=w2k12,dc=test

-> cat /var/log/univention/connector.log| grep delete
06.08.2014 18:48:49,574 LDAP        (PROCESS): sync to ucs:   [          user] [    delete] uid=win6,cn=users,dc=w2k8r2en,dc=test
06.08.2014 18:48:49,640 LDAP        (PROCESS): sync to ucs:   [          user] [    delete] uid=win5,cn=users,dc=w2k8r2en,dc=test
06.08.2014 18:48:49,698 LDAP        (PROCESS): sync to ucs:   [          user] [    delete] uid=win4,cn=users,dc=w2k8r2en,dc=test

-> cat /var/log/univention/connector.log| grep delete
06.08.2014 09:38:57,699 LDAP        (PROCESS): sync to ucs:   [          user] [    delete] uid=win1,cn=users,dc=w2k3,dc=test

The program also recognizes when the ACL are already fine:

-> make-deleted-objects-readable-for-this-machine --binddn "CN=Administrator,CN=Users,DC=w2k12,DC=test" --bindpw Univention.99
INFO: DSACL of Deleted Objects is already OK.

Please fix these two typos:

-> grep -n sys,exit scripts/make-deleted-objects-readable-for-this-machine 
298:                    sys,exit(1)
304:                    sys,exit(1)
Comment 9 Arvid Requate univentionstaff 2014-08-06 10:28:44 CEST
Ok, fixed, advisory updated.
Comment 10 Felix Botner univentionstaff 2014-08-06 10:34:12 CEST
YAML 2014-07-03-univention-ad-connector.yaml - OK
YAML 2014-07-23-univention-lib.yaml - OK
Comment 11 Janek Walkenhorst univentionstaff 2014-08-07 17:44:38 CEST
http://errata.univention.de/ucs/3.2/162.html
Comment 12 Janek Walkenhorst univentionstaff 2014-08-07 17:46:03 CEST
http://errata.univention.de/ucs/3.2/165.html