A large installation wants to use Lotus Domino as the LDAP server. Domino pre-defines the LDAP displayName attribute as read-only and auto-created by Domino. 1) Why do we require this attribute to be writable? 2) Is there any chance of a parameter that can allow use of an LDAP backend that does not allow this parameter to be changed externally? This is blocking deployment of Samba 3.4.x in a site with ~3000 users. Management will not permit installation of a second LDAP server. The alternative is Windows Server 2003 R2 which can be integrated with Domino. I have gone over our code and unless I have missed something obvious, it appears that we can operate with the default Domino LDAP behavior. I manually added user accounts to Domino with the SambaSAMAccount attributes and everything appears to be working OK with the default Dominion-generated displayName attribute. A work-around is needed for this site to be able to deploy Samba primarily for machine account handling, and secondly to permit use of the NT4 Domain User Manager for Samba user and group account settings. - John T.
Created attachment 4671 [details] patch for 3.4 Something like this? ldapsam:displayNameWritable = false will just ignore writing the fullname. Volker
In passdb/pdb_ldap.c we have: /* displayName, cn, and gecos should all be the same * most easily accomplished by giving them the same OID * gecos isn't set here b/c it should be handled by the * add-user script * We change displayName only and fall back to cn if * it does not exist. */ So it looks like if displayName exists we expect it to be writable. Maybe we should fail more elegantly is it can't be written to. Jeremy.
(In reply to comment #1) > Created an attachment (id=4671) [details] > patch for 3.4 > > Something like this? > > ldapsam:displayNameWritable = false > > will just ignore writing the fullname. > > Volker > That would be a great solution! Is this proposed only, or does that already exist? - John T.
(In reply to comment #2) > In passdb/pdb_ldap.c we have: > > /* displayName, cn, and gecos should all be the same > * most easily accomplished by giving them the same OID > * gecos isn't set here b/c it should be handled by the > * add-user script > * We change displayName only and fall back to cn if > * it does not exist. > */ > > So it looks like if displayName exists we expect it to be writable. Maybe we > should fail more elegantly is it can't be written to. Agreed! - John T.
(In reply to comment #3) > (In reply to comment #1) > > Created an attachment (id=4671) [details] [details] > > patch for 3.4 > > > > Something like this? > > > > ldapsam:displayNameWritable = false > > > > will just ignore writing the fullname. > > > > Volker > > > > That would be a great solution! Is this proposed only, or does that already > exist? > > - John T. > Sorry - I see the patch. Thank-you so much. Will try it. - John T.
Patch tested - fails. Here is a level 10 debug log: #> smbpasswd -a fornick -D 10 The LDAP server is successfully connected pdb backend ldapsam:ldap://localhost has a valid init New SMB password: Retype new SMB password: smbldap_search_ext: base => [o=smcaus], filter => [(&(uid=fornick)(objectclass=sambaSamAccount))], scope => [2] ldapsam_getsampwnam: Unable to locate user [fornick] count=0 Finding user fornick Trying _Get_Pwnam(), username as lowercase is fornick Get_Pwnam_internals did find user [fornick]! pdb_set_username: setting username fornick, was pdb_set_full_name: setting full name fornick, was pdb_set_domain: setting domain SMCTEST, was Home server: domino pdb_set_profile_path: setting profile path \\domino\fornick\profile, was Home server: domino pdb_set_homedir: setting home dir \\domino\fornick, was pdb_set_dir_drive: setting dir drive H:, was NULL pdb_set_logon_script: setting logon script scripts\logon.bat, was smbldap_search_domain_info: Searching for:[(&(objectClass=sambaDomain)(sambaDomainName=SMCTEST))] smbldap_search_ext: base => [o=smcaus], filter => [(&(objectClass=sambaDomain)(sambaDomainName=SMCTEST))], scope => [2] attribute sambaNextRid has 2 values, expected only one attribute sambaNextGroupRid does not exist smbldap_make_mod: attribute |sambaNextRid| not changed. smbldap_modify: dn => [SAMBADOMAINNAME=SMCTEST,O=smcaus] lookup_global_sam_rid: looking up RID 1001. smbldap_search_ext: base => [o=smcaus], filter => [(&(sambaSID=S-1-5-21-479813111-2747713287-1250922207-1001)(objectclass=sambaSamAccount))], scope => [2] ldapsam_getsampwsid: Unable to locate SID [S-1-5-21-479813111-2747713287-1250922207-1001] count=0 smbldap_search_ext: base => [o=smcaus], filter => [(&(objectClass=sambaGroupMapping)(sambaSID=S-1-5-21-479813111-2747713287-1250922207-1001))], scope => [2] ldapsam_getgroup: Did not find group, filter was (&(objectClass=sambaGroupMapping)(sambaSID=S-1-5-21-479813111-2747713287-1250922207-1001)) pdb_set_user_sid: setting user sid S-1-5-21-479813111-2747713287-1250922207-1001 pdb_set_username: setting username fornick, was fornick smbldap_search_ext: base => [o=smcaus], filter => [(&(uid=fornick)(objectclass=sambaSamAccount))], scope => [2] smbldap_search_ext: base => [o=smcaus], filter => [(&(sambaSID=S-1-5-21-479813111-2747713287-1250922207-1001)(objectclass=sambaSamAccount))], scope => [2] smbldap_search_ext: base => [o=smcaus], filter => [(uid=fornick)], scope => [2] ldapsam_add_sam_account: User exists without samba attributes: adding them smbldap_make_mod: attribute |uid| not changed. init_ldap_from_sam: Setting entry for user: fornick smbldap_get_single_attribute: [sambaSID] = [<does not exist>] smbldap_make_mod: adding attribute |sambaSID| value |S-1-5-21-479813111-2747713287-1250922207-1001| smbldap_make_mod: deleting attribute |displayName| values |uid=fornick/ou=People/ou=Users/o=smcaus| smbldap_make_mod: adding attribute |displayName| value |fornick| smbldap_get_single_attribute: [sambaAcctFlags] = [<does not exist>] smbldap_make_mod: adding attribute |sambaAcctFlags| value |[DU ]| smbldap_modify: dn => [UID=fornick,OU=People,OU=Users,O=smcaus] Failed to modify dn: UID=fornick,OU=People,OU=Users,O=smcaus, error: 19 (Constraint violation) (Failed, no user modification allowed on read only attribute ) ldapsam_add_sam_account: failed to modify/add user with uid = fornick (dn = UID=fornick,OU=People,OU=Users,O=smcaus) Failed to add entry for user fornick. Note: The Domino logs recorded that an external program tried to write to the displayName attribute which is read-only. - John T.
(In reply to comment #2) > In passdb/pdb_ldap.c we have: > > /* displayName, cn, and gecos should all be the same > * most easily accomplished by giving them the same OID > * gecos isn't set here b/c it should be handled by the > * add-user script > * We change displayName only and fall back to cn if > * it does not exist. > */ > > So it looks like if displayName exists we expect it to be writable. Maybe we > should fail more elegantly is it can't be written to. > > Jeremy. > Well, it seems that our process is to delete the displayName attribute if it exits, then write our new one. This happens when handling users and groups. The process appears to be handled within lib/smbldap.c in smbldap_make_mod(). When the displayName attribute is read-only, the attempt to delete it fails, as does the attempt to write (add) our new instance of it. Looks like we need to check that the displayName attribute exists. If it does not exist, and ldapsam:displayNameWritable is set to false, we should fail with a meaningful error message. If it does exist and ldapsam:displayNameWritable is set to false, we should leave it alone. Does that make sense? - John T.
Created attachment 4682 [details] Modified patch Added Volker's patch to additional instances of smbldap_make_mod(). This patch does NOT solve the problem. Have added it to show what was done to try to fix this.
To solve this, IMO someone with devel skills needs such a box or a similar setup to catch all the cases. Sorry, Volker
Created attachment 4693 [details] JHT patch for smbldap.c This patch replaces both prior patches. It has been tested and so far works. I changed the parameter name to: ldapsam:displayNameCanWrite This parameter needs to be set to "False" for domino LDAP server, and default or True for all others. The Domino LDAP directory now needs to be cleared (delete) off all test info, and then rebuilt with clean data to validate that this patch does not leave anything still broken. I will confirm within 24 hours. - John T.
(In reply to comment #9) > To solve this, IMO someone with devel skills needs such a box or a similar > setup to catch all the cases. > > Sorry, > > Volker > I can do no better than agree with this statement. - John T.
Created attachment 4714 [details] Updated smbldap.c patch The patch needed to be extended so that both: smbldap_make_mod() and smbldap_set_mod() are covered. I had missed the smbldap_set_mod. PS: The patch is still being tested. I will close the report when I receive an "all-clear" from the site.
File update. This is still an open issue and will hopefully be resolved before hell freezes over. Please hold off - no action required at this time. - John T.
Case is closed. Do NOT apply these patches. There is no simple way that Lotus Domino can be used as an LDAP server for Samba's use. The large installation will move ahead with an alternate solution.