Bug 6702 - Why do we need LDAP displayName attribute writable
Why do we need LDAP displayName attribute writable
Status: RESOLVED FIXED
Product: Samba 3.4
Classification: Unclassified
Component: User & Group Accounts
3.4.1
Other Linux
: P3 normal
: ---
Assigned To: Jeremy Allison
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-09-09 18:03 UTC by John H Terpstra
Modified: 2010-02-18 02:00 UTC (History)
0 users

See Also:


Attachments
patch for 3.4 (1.05 KB, text/x-diff)
2009-09-09 18:24 UTC, Volker Lendecke
no flags Details
Modified patch (3.13 KB, patch)
2009-09-10 22:57 UTC, John H Terpstra
no flags Details
JHT patch for smbldap.c (1.30 KB, patch)
2009-09-15 02:26 UTC, John H Terpstra
no flags Details
Updated smbldap.c patch (2.41 KB, patch)
2009-09-17 11:21 UTC, John H Terpstra
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description John H Terpstra 2009-09-09 18:03:25 UTC
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.
Comment 1 Volker Lendecke 2009-09-09 18:24:17 UTC
Created attachment 4671 [details]
patch for 3.4

Something like this?

ldapsam:displayNameWritable = false

will just ignore writing the fullname.

Volker
Comment 2 Jeremy Allison 2009-09-09 18:25:17 UTC
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.
Comment 3 John H Terpstra 2009-09-09 18:48:53 UTC
(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.
Comment 4 John H Terpstra 2009-09-09 18:49:28 UTC
(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.
Comment 5 John H Terpstra 2009-09-09 18:56:42 UTC
(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.
Comment 6 John H Terpstra 2009-09-09 20:44:22 UTC
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.
Comment 7 John H Terpstra 2009-09-10 22:54:17 UTC
(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.
Comment 8 John H Terpstra 2009-09-10 22:57:11 UTC
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.
Comment 9 Volker Lendecke 2009-09-11 10:10:42 UTC
To solve this, IMO someone with devel skills needs such a box or a similar setup to catch all the cases.

Sorry,

Volker
Comment 10 John H Terpstra 2009-09-15 02:26:08 UTC
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.
Comment 11 John H Terpstra 2009-09-15 02:27:02 UTC
(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.
Comment 12 John H Terpstra 2009-09-17 11:21:11 UTC
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.
Comment 13 John H Terpstra 2010-02-04 14:47:23 UTC
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.
Comment 14 John H Terpstra 2010-02-18 02:00:04 UTC
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.