Bug 3058 - ldapsam error with eDirectory between x86_32 and x86_64
ldapsam error with eDirectory between x86_32 and x86_64
Status: NEW
Product: Samba 3.0
Classification: Unclassified
Component: User/Group Accounts
3.0.20
x86 Linux
: P3 normal
: none
Assigned To: Jim McDonough
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-09-01 12:43 UTC by Ralf Herrmann
Modified: 2010-11-18 07:49 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ralf Herrmann 2005-09-01 12:43:35 UTC
The Problem:

Set up Samba for using ldapsam backend and store account data in a Novell 
eDirectory server (tested with Version 8.6.0.2 with LDAP interface).
Linux auth of users (login) works fine.

eDirectory runs on a x86_32 based machine, whereas samba is compiled and 
installed on Suse 9.2 x86_64.

When trying to add new users by issueing 'smbpasswd -a someusername' (as root),
an error occurs: 'ldapsam_modify_entry: could not modify entry for 
dn: cn=someusername, .......: syntax error. NDS additional Info: no information 
available (-306) .......Failed to add user .....'

When using an openLDAP server compiled on the same x86_64 machine, this error
does not occur.

The cause (afaik):

It was difficult to get sufficient information form samba logs or debug-output
of smbpasswd. Finally a trace of eDirectory LDAP server operation gave some
hint: 

   modify: dn (cn=testuser2,.......)
   Invalid integer syntax:"9223372036854775807"

smbpasswd tried to set this value for the attribute 'sambaPwdMustChange'

Obviousely this value is much too big to fit in a 32Bit Integer 
(max is +(2^31)-1, something above  2e9).

Preliminary analysis:

When setting up a new account in ldapsam, samba chooses default values
for most attributes including sambaPwdMustChange.
Seems the password is supposed to never expire as a default setting, so
a big value is choosen. On a 64Bit system, the value fits nicely in 
an Integer. When communicating with an LDAP server, there seems to be no
check, whether data types match.

Might be a flaw in eDirectory, but i used the schema definitions supplied with
samba source code. I have no idea of the OIDs used to specify the type of 
sambaPwdMustChange, but it translates into SYN_INTEGER in eDirectory.

Suggestions:

- Option 1: change schema definition, if there is a definitioon of 64Bit Integer
  supported by all LDAP servers, use this for time values.
  Will have implementation issues when running samba on 32Bit machines though.
- Option 2: check architecture differences between LDAP server and samba host
  and limit vlaues accordingly
- Option 3: do never use 64Bit values for time attributes (will be a problem
  in a couple of years:-)

You guys certainly have better ideas. Sorry, i'm quite new to this.

I did a quick 'n' dirty hack in passdb/pdb_ldap.c limiting 
the value for pass_must_change to 2e9 no matter what.
But the check is done only when the value has never been set (needs_update
for ldap_pass_must_change or the like) so it does not hinder the rest of the 
code from trying to write a 64Bit Int to LDAP.

Would be nice to have a fix or workaround.

Thx, Ralf
Comment 1 Gerald (Jerry) Carter 2005-10-07 07:55:43 UTC
Guether, could you take a look at this?  Thanks.
Comment 2 Guenther Deschner 2009-06-18 10:54:02 UTC
Jim, eDirectory => all yours :)
Comment 3 SPAMMER (mm) 2010-11-18 07:34:47 UTC
(In reply to comment #0)ougtiuhi
> The Problem:
> Set up Samba for using ldapsam backend and store account data in a Novell 
> eDirectory server (tested with Version 8.6.0.2 with LDAP interface).
> Linux auth of users (login) works fine.
> eDirectory runs on a x86_32 based machine, whereas samba is compiled and 
> installed on Suse 9.2 x86_64.
> When trying to add new users by issueing 'smbpasswd -a someusername' (as root),
> an error occurs: 'ldapsam_modify_entry: could not modify entry for 
> dn: cn=someusername, .......: syntax error. NDS additional Info: no information 
> available (-306) .......Failed to add user .....'
> When using an openLDAP server compiled on the same x86_64 machine, this error
> does not occur.
> The cause (afaik):
> It was difficult to get sufficient information form samba logs or debug-output
> of smbpasswd. Finally a trace of eDirectory LDAP server operation gave some
> hint: 
>    modify: dn (cn=testuser2,.......)
>    Invalid integer syntax:"9223372036854775807"
> smbpasswd tried to set this value for the attribute 'sambaPwdMustChange'
> Obviousely this value is much too big to fit in a 32Bit Integer 
> (max is +(2^31)-1, something above  2e9).
> Preliminary analysis:
> When setting up a new account in ldapsam, samba chooses default values
> for most attributes including sambaPwdMustChange.
> Seems the password is supposed to never expire as a default setting, so
> a big value is choosen. On a 64Bit system, the value fits nicely in 
> an Integer. When communicating with an LDAP server, there seems to be no
> check, whether data types match.
> Might be a flaw in eDirectory, but i used the schema definitions supplied with
> samba source code. I have no idea of the OIDs used to specify the type of 
> sambaPwdMustChange, but it translates into SYN_INTEGER in eDirectory.
> Suggestions:
> - Option 1: change schema definition, if there is a definitioon of 64Bit Integer
>   supported by all LDAP servers, use this for time values.
>   Will have implementation issues when running samba on 32Bit machines though.
> - Option 2: check architecture differences between LDAP server and samba host
>   and limit vlaues accordingly
> - Option 3: do never use 64Bit values for time attributes (will be a problem
>   in a couple of years:-)
> You guys certainly have better ideas. Sorry, i'm quite new to this.
> I did a quick 'n' dirty hack in passdb/pdb_ldap.c limiting 
> the value for pass_must_change to 2e9 no matter what.
> But the check is done only when the value has never been set (needs_update
> for ldap_pass_must_change or the like) so it does not hinder the rest of the 
> code from trying to write a 64Bit Int to LDAP.
> Would be nice to have a fix or workaround.
> Thx, Ralf