Restore a LDAP object

Problem:

A LDAP object is lost (or removed) by accident and should be restored.

Solution:

A DC Master backups its LDAP each night in /var/univention-backup:

/var/univention-backup/ldap-backup_timestamp.gz

You can simply open the file and extract the relevant object with the help of any editor. Save the extracted object to new file, called lost.ldif, here

There are a few attributes which have to be removed as a preparational step: (keep entryUUID if the user is an o365 user)

structuralObjectClass
entryUUID
creatorsName
modifiersName
createTimestamp
modifyTimestamp
entryCSN

If you are not running a Univention Active Directory Domain you can simply add the lost.ldif back to the LDAP database by running ldapdd:

ldapadd -x -D "cn=admin,$(ucr get ldap/base)" -w "$(cat /etc/ldap.secret)" -f lost.ldif

In case you have also these users in Azure (o365), we use the entryUUID from the user to recognize the user in Azure. So if you restore a user without this attribute, the user in new created in azur and has no access to his old data. To prevent that you can restore the entryUUID , with not extracting it from the ldif and restoring via ldapadd and -e relax as additional argument.

ldapadd -x -D "cn=admin,$(ucr get ldap/base)" -w "$(cat /etc/ldap.secret)" -e relax -f lost.ldif

If you are running an Univention Active Directory Domain and you want to restore user, host or group objects (or any other object type with a sambaSID/objectSid attribute), additional steps are required to have the object restored with the correct SID in AD.

At first, check if there still is a “deleted object” of the object you rant to restore in Active Directory. To do so, search the AD for the SID of the object to restore:

# grep sambaSID lost.ldif
sambaSID: S-1-5-21-1738911416-233897720-2251434911-1745
# univention-s4search --show-deleted --cross-ncs objectSid=S-1-5-21-1738911416-233897720-2251434911-1745 dn

# record 1
dn: cn=deleteme0ADEL:9a1932de-e0cd-42cf-9339-9d8133b04e1a,CN=Deleted Objects,DC=s4lish,DC=qa

# returned 1 records
# 1 entries
# 0 referrals

In this example, one “deleted object” record for this sambsSID/objectSid was found. You will have to completely remove it from AD to allow the sambaSID/objectSid to be “reused” when restoring the object:

# ldbdel -H /var/lib/samba/private/sam.ldb --relax 'cn=deleteme0ADEL:9a1932de-e0cd-42cf-9339-9d8133b04e1a,CN=Deleted Objects,DC=s4lish,DC=qa'
Deleted 1 record

To allow the sambaSID/objectSid to be written from UCS LDAP to Samba4 AD, the Samba4 Connector mapping needs to be temporarily adapted. Please make sure that no new objects are created while this configuration is active as they may not be assigned a valid sambaSID/objectSid.

ucr set connector/s4/mapping/sid_to_s4='true'
/etc/init.d/univention-s4-connector restart

Now you may restore lost.ldif via ldbadd:

ldapadd -x -D "cn=admin,$(ucr get ldap/base)" -w "$(cat /etc/ldap.secret)" -f lost.ldif

Afterwards please check if the object was successfully created with correct sambaSID, uidNumber etc. in LDAP and Active Directory. If everything went okay, revert the changes made to the Samba4 Connector mapping and restart the connector:

ucr unset connector/s4/mapping/sid_to_s4
/etc/init.d/univention-s4-connector restart

There exists a Cool Solution package to accomplish this more easily now with UCS 4.3:
https://wiki.univention.de/index.php/Cool_Solution_-_Restore_LDAP_objects,_attributes_and_memberships

It also takes care of the sync back to Samba.

Cool Solutions are articles documenting additional functionality based on Univention products. Not all of the shown steps in the article are covered by Univention Support. For questions about your support coverage contact your contact person at Univention before you want to implement one of the shown steps.

1 Like
Mastodon