samba - Jun 2003 - Samba 3 beta + LDAP going from Samba 2.2.7a GID problem

Hello,
I am trying to test out the new beta 3.0 version but I am running into an issue
with GID/UID's in my OpenLDAP tree.  I have compiled the beta with:
--with-ldapsam --with-ads=no
I do not run a PDC environment and do not plan to do so.
The problem I see in the log is this error:
sid_to_gid: SID S-1-5 bla bla -1002 is *NOT* a group

(the user that I am trying to authenticate with has a primary group membership
of 1002)
I have in my smb.conf file this:
passdb backend = ldapsam_compat

The log shows that Samba sees the LDAP database and sees the MD4 password for
the user but it seems to not understand the existing LDAP
attribute "primaryGroupID".  I would guess this is due to the fact of
the ADS uid/gid additions the SAMBA team is adding. If I read the SAMBA
notes right, it states that the "ldapsam_compat" switch (without
quotes) would allow you to use the old LDAP attributes/schemas that were used
in the past.  Is this not the case or am I missing something?  An additional
note, I used my old schemas and did not use the new SAMBA 3 schemas
so this should work like it does with the existing 2.2.7a, correct?

I would like to not update the LDAP database to the new schema extensions if at
all possible, hence using the ldapsam_compat switch.  I also hope
that the SAMBA team does not force ADS as the main backend and keep the
"REAL" LDAP trees that are out there today =)

Thanks.
Mike

I have confirmed the problem to be the "primaryGroupID" attribute
within the LDAP tree.  If this attribute is in your LDAP tree with a group value
associated with it, SAMBA 3.0 beta1 WILL NOT authenticate with LDAP.  The new
attribute "sambaprimaryGroupSID" has to be used where it used to be
"primaryGroupID".  BOTH attributes CAN RESIDE within the LDAP tree at
the same time BUT you can not have any value associated with
"primaryGroupID" or SAMBA will not authenticate.  I have tried and for
some reason, SAMBA will look at the "primaryGroupID" attribute first
(if there is a GID number within the data field) but does not know how to
resolve the GID number.  It seems that the new UID/GID code ONLY knows how to
resolve the "sambaprimaryGroupSID" attribute.  This is the only thing
that is not backward compatible with the new beta code that I have found MEANING
that you can't run 2.2.8a OR 3.0 beta in the same WAN.  I have modified the
"convertSambaAccount" perl script to NOT delete the OLD attributes
that SAMBA used to look at and the only one that the beta version has to have
removed is the attribute mentioned.  Has anyone else run into this?  Is there
any way that the new version of SAMBA will ALSO work with either attributes?
If so, it would seem that this could be an easier migration path (to the newer
SAMBA release) than having to eventually modify every production servers LDAP
entries.  If I am wrong, please could somebody point out my wrongfullness? =)
Thanks.


Hello,
I am trying to test out the new beta 3.0 version but I am running into an issue
with GID/UID's in my OpenLDAP tree.  I have compiled the beta with:
--with-ldapsam --with-ads=no
I do not run a PDC environment and do not plan to do so.
The problem I see in the log is this error:
sid_to_gid: SID S-1-5 bla bla -1002 is *NOT* a group

(the user that I am trying to authenticate with has a primary group membership
of 1002)
I have in my smb.conf file this:
passdb backend = ldapsam_compat

The log shows that Samba sees the LDAP database and sees the MD4 password for
the user but it seems to not understand the existing LDAP
attribute "primaryGroupID".  I would guess this is due to the fact of
the ADS uid/gid additions the SAMBA team is adding. If I read the SAMBA
notes right, it states that the "ldapsam_compat" switch (without
quotes) would allow you to use the old LDAP attributes/schemas that were used
in the past.  Is this not the case or am I missing something?  An additional
note, I used my old schemas and did not use the new SAMBA 3 schemas
so this should work like it does with the existing 2.2.7a, correct?

I would like to not update the LDAP database to the new schema extensions if at
all possible, hence using the ldapsam_compat switch.  I also hope
that the SAMBA team does not force ADS as the main backend and keep the
"REAL" LDAP trees that are out there today =)

Thanks.
Mike