On 7/3/08, Ernesto Silva <[EMAIL PROTECTED]> 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. --Charlie -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
