[Samba] Samba 3.2 Ldap problem

Charlie medievalist at gmail.com
Mon Jul 7 04:22:05 GMT 2008

On 7/3/08, Ernesto Silva <silva at ort.edu.uy> wrote:
> I didn't copied the secrets.tdb, I've used smbpasswd -w. In my Ldap I have
> an object named "sambaDomainName=OPEN,dc=my,dc=company" which I didn't
> create, it's automagically created by samba. That object has it's own sid,
> I've even deleted the secrets.tdb file and the ldap OPEN object, they are
> recreated with "smbpasswd -w xxxxx", so I assume everything is automagically
> right.

That's very good, that means your LDAP and samba are communicating correctly.

If you want the new server to be a Primary Domain Controller or a
Backup Domain Controller you need to have the server's sambaSID
attribute match the domain SID.   I believe you also need to set up
all the netlogon stuff in order to be a PDC or BDC.

If you aren't going to be a PDC or BDC you need to use "net rpc join"
to join the local domain.  (You can use the "net rpc testjoin" command
to see if it's already joined.)

> In addition I've tried the index on sambaSID attribute, I already have an
> "eq" index on it, and I can't create a "sub" index, I think this is because
> of the attribute definition.

That's bad.  You need to check to make sure your LDAP has the samba
schema that matches your version of samba, and not an old schema.  As
I understand it, samba will be much less efficient without that
subinitial index.  I personally have sambaSID indexed as "eq, pres,
sub" in my /etc/openldap/slapd.conf and it works fine.

When I added the "sub" index, I used slapcat to dump the entire
database to LDIF format, then moved the old database files in
/var/lib/ldap into a backup directory to get them out of the way, then
I used slapadd to rebuild the database with the new index.  There are
other ways to create a new index (I think there's a slapindex
program?) but I have never learned any of them, I just dump the
database to LDIF and rebuild, it's reasonably quick and it defragments
the database at the same time.

> I've updated to samba-3.2.0-21 but I'm still stuck.

I haven't used 3.2 yet, so you should take my advice with a grain of
salt.  But you should always do that anyway ;) since I don't write
code for the Samba Team...

> I'm worried about your comment on users located by sid as all my users
> already has a sid assigned, is that sid server-dependant? I must assume it
> isn't, it's only user-dependant, isn't it?

SID stands for either System Identifier or Security Identifier (and
sometimes Security Context) depending on which documents you read.
The last part of a user or group SID is the RID.  RID always stands
for Relative Identifier.

SIDs are assigned by domain.  If you want a user who has a SID from
domain A to be able to log in to domain B, you have to set up a domain
trust relationship between the two domains, which is annoyingly
complicated.  If your new server is joined to the old domain, you
should have no problems.

Take a look in LDAP at one of your users, and see what that
individual's sambaSID is.  It should look something like
"S-1-5-21-xxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx-yyyyyy" except the x and y
will be numbers.  Everything in that string except the last -yyyyy
part is the domain SID, and the -yyyyyy part is the user's RID...
together they make up the user's SID.

SIDs are *almost* unique - user and group SIDs must always be unique,
but the SID of a server that is a PDC or a BDC is identical to the
domain SID of the domain being served.  Unfortunately, there is
nothing that enforces this uniqueness except human intervention, so it
is easy to break things when connecting two or more previously
unconnected networks.

If the above sounds stupid, self-limiting and unneccessarily complex,
that's probably because it is.  It's not the Samba Team's fault,
though - they inherited this madness from Microsoft.


More information about the samba mailing list