Starting with Calendar Server 7 Update 3 (Patch 08) we introduce a new attribute davUniqueId in the davEntity objectclass, to use as the unique identifier.
The reason behind this is quite simple, the LDAP operational attribute nsUniqueId has been chosen as the default value used for the unique identifier.
It was discovered that this choice has a potential serious
downside. The problem with using nsUniqueId is that if the
LDAP entry for a user, group, or resource is deleted and recreated in
LDAP, the new entry would receive a different nsUniqueId
value from the Directory Server, causing a disconnect from the existing
account in the calendar database. As a result, recreated users cannot
access their existing calendars.
How To Configure Calendar Server to Use the davUniqueId Attribute?
Populate the davUniqueId to the ldap users. You can create a LDIF output file only or (-x option) directly run the ldapmodify from the populate-davuniqueid shell script. # ./populate-davuniqueid -h localhost -p 389 -D "cn=Directory Manager" -w <passwd> -b "o=red" -O -o /tmp/out.ldif
The ldapmodify might failed like below, in that case the LDAP entry already have the 'daventity' objectclass, in those cases run populate-davuniqueid script without the -O option. # ldapmodify -x -h localhost -p 389 -D "cn=Directory Manager" -w <passwd> -c -f /tmp/out.ldif
modifying entry "uid=mparis,ou=People,o=vmdomain.
tld,o=red"
ldapmodify: Type or value exists (20)
In this case the user 'mparis' already have the objectclass 'daventity', ldapmodify do not take care of this DN and just take the next DN (if you start ldapmodify with -c option otherwise it stop's completely)
dn: uid=mparis,ou=People,o=vmdomain.
tld,o=red
changetype: modify
add: objectclass
objectclass: daventity
-
add: davuniqueid
davuniqueid: 01a2c501-af0411e1-809de373-18ff5c8d
Even run populate-davuniqueid without -O option or changing the outputfile to
dn: uid=mparis,ou=People,o=vmdomain.
tld,o=red
changetype: modify
add: davuniqueid
davuniqueid: 01a2c501-af0411e1-809de373-18ff5c8d
The ldapmodify works fine now. The only issue I see here is you need verify which user might need the 'daventity' objectclass as well. On the other hand start without the objectclass and only add the objectclass for the users where you get 'Objectclass violation' report. That's indicate the objectclass is missing.
# ldapmodify -x -h localhost -p 389 -D "cn=Directory Manager" -w <passwd> -c -f /tmp/out.ldif
modifying entry "uid=mparis,ou=People,o=vmdomain.
tld,o=red"
Now it is time to change the configuration to use the davuniquid attribute
# ./davadmin config modify -o davcore.uriinfo.permanentuniqueid -v davuniqueid
It is also needed to modfiy the search filter to use davuniqueid instead of nsuniqueid
# ./davadmin config modify -o davcore.uriinfo.subjectattributes -v "cn davstore icsstatus mail
mailalternateaddress davUniqueId owner preferredlanguageuid objectclass ismemberof uniquemember
memberurl mgrprfc822mailmember"
Afterward IWC Calendar works fine and my test user able to access all his old events.
