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