We're using posixAccount as an auxiliary objectclass and are not using
inetOrgPerson or 'organization'.
lchfn nevertheless tries to modify the 'gecos', 'roomNumber', and 'telephoneNumber' attributes. Only 'gecos' is available, so the mod always fails.
I think that either
- lchfn should only modify attributes already present
- libuser should perform an objectclass check also for modifications.
The 2nd solution would be cleaner, of course.
Also, being able to mark some attributes as taboo in the config would be nice.
Thanks for your report.
lu_ldap_user_mod is already supposed to modify object classes if necessary. Rather than me going on a general hunt, could you please attach a complete dump of an existing object (with appropriately anonymized values, but keeping all classes and attribute structure) and the precise lchfn command line to reproduce the problem, please?
Well lchfn should definitely not even think of modifying object classes, it almost certainly won't have the permissions to do so.
Instead it should check the list of classes it got in the search result and check against the objectclasses of the attributes it would like to modify - and skip the incompatible ones.
Anyway, I attached a sample LDAP entry in the format that we use here.
Reproduce by starting lchfn (binding via SASL using a Krb5 ticket) and modify either the room or phone
Also attached: My patch for the 1st solution in the original ticket. Not ingenious (probably even wrong for many cases) but it solved the problem for me quickly.
to comment on this ticket.