samba - Dec 2003 - Transfering Machine Accounts / MACHINE.SID

I have a Samba 2.2.7 PDC, and I am now trying to set up a new 3.0.1 server. 
I want this machine to act as a BDC initially and replicate all the
accounts over.  When I followed the howto it said to use smbpasswd -S to
transfer the machine SID and then to replicate the smbpasswd file to the
new server.  This has caused two major problems:

  1) the smbpasswd command does not support the -S option

  2) My user accounts transfered to the new machine, but not the machine
     trust accounts.

Anyone know how I can fix these two issues?

Thx
Kevin Fries

Kevin Fries wrote:
> I have a Samba 2.2.7 PDC, and I am now trying to set up a new 3.0.1
> server. I want this machine to act as a BDC initially and replicate all
> the
> accounts over.  When I followed the howto it said to use smbpasswd -S to
> transfer the machine SID and then to replicate the smbpasswd file to the
> new server.  This has caused two major problems:
> 
>   1) the smbpasswd command does not support the -S option
> 
>   2) My user accounts transfered to the new machine, but not the machine
>      trust accounts.
OK, found this one.  I forgot to move the posix accounts over to the new
machines and Samba silently ignored the accounts.  pdbedit on the other
hand screamed bloody murder.  Added PosixAccount to my machine entries in
the new LDAP server, and Samba 3 found them thanks to nss_ldap.

However, I still do not have a MACHINE.SID file because the smbpasswd
command does not work as advertised.  Is it OK to just copy that file from
the old machine?

Thx
Kevin Fries

On Sat, 2003-12-27 at 15:51, Beast wrote:
> Saturday, December 27, 2003, 5:41:37 AM, Andrew wrote:
> 
> > On Sat, 2003-12-27 at 07:10, Information Technology wrote:
> >>
> >> My goal is to rebuild my PDC as I mentioned earlier.  I stated in
another
> >> thread my plan was to create a 3.0.1 BDC; tranfer the accounts;
transfer the
> >> shares; then, move the user and system accounts into LDAP.  Once
the PDC is
> >> rebuild and I need to transfer control back, It should be simple
to move the
> >> LDAP first, point the new Samba to the new primary LDAP, and
demote the
> >> temporary PDC back down to BDC. 
> 
> > And to make it a real BDC, setup an LDAP slave.
> 
> If I put PDC in slave ldap, is this means that it will update the
> slave (because samaba will bind as ldap-root which has authority of
> updating this replica)?
> No way to prevent samba to using other ldap account to update the
> directory?
You should never list the Manager account as the replicator.  Instead,
create a new account, and use it only for the replication.  That way,
everybody who is not the replicator account will be forced to talk to
the master.

Andrew Bartlett

-- 
Andrew Bartlett                                 abartlet@pcug.org.au
Manager, Authentication Subsystems, Samba Team  abartlet@samba.org
Student Network Administrator, Hawker College   abartlet@hawkerc.net
http://samba.org     http://build.samba.org     http://hawkerc.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url :
http://lists.samba.org/archive/samba/attachments/20031227/0eae2358/attachment.bin

On Sat, 27 Dec 2003, Beast wrote:
> Saturday, December 27, 2003, 5:41:37 AM, Andrew wrote:
>
> > On Sat, 2003-12-27 at 07:10, Information Technology wrote:
> >>
> >> My goal is to rebuild my PDC as I mentioned earlier.  I stated in
another
> >> thread my plan was to create a 3.0.1 BDC; tranfer the accounts;
transfer the
> >> shares; then, move the user and system accounts into LDAP.  Once
the PDC is
> >> rebuild and I need to transfer control back, It should be simple
to move the
> >> LDAP first, point the new Samba to the new primary LDAP, and
demote the
> >> temporary PDC back down to BDC.
>
> > And to make it a real BDC, setup an LDAP slave.
>
> If I put PDC in slave ldap, is this means that it will update the
> slave (because samaba will bind as ldap-root which has authority of
> updating this replica)?
> No way to prevent samba to using other ldap account to update the
> directory?
Have you trtied this? Did you monitor it using ethereal?

If not, I recommend that you do this.

-- 
John H Terpstra
Email: jht@samba.org

Saturday, December 27, 2003, 1:45:33 PM, Andrew wrote:
> On Sat, 2003-12-27 at 15:51, Beast wrote:
>> Saturday, December 27, 2003, 5:41:37 AM, Andrew wrote:
>> If I put PDC in slave ldap, is this means that it will update the
>> slave (because samaba will bind as ldap-root which has authority of
>> updating this replica)?
>> No way to prevent samba to using other ldap account to update the
>> directory?
> You should never list the Manager account as the replicator.  Instead,
> create a new account, and use it only for the replication.  That way,
> everybody who is not the replicator account will be forced to talk to
> the master.
This is expected behaviour :-)
as long as openldap did not support multimaster or samba can not
chasing update referral, i have to live with un-synch sambapassword
attributes in ldap :-(



--beast

> -----Original Message-----
> Tried what? ;-)
> 
> Setup :
>    unix password sync = yes
>    passwd program = /usr/local/sbin/ldap-passwd.pl %u
> 
> Note: ldap-passwd.pl is custom script to modify userpassword 
> attribute,
>      modify master server/able to chase referral if any.
> 
> BDC -> Slave Openldap:
> 
> 1. ldapmanager as replica account.
> User was able to change password from Win WS.
> ldap-passwd.pl update master, samba update slave.
> 
> 2. ldapmanager not as replica account.
> - user unable to change password, err from Windows is "you 
> did not have permision to change your password".
> - run smbpasswd to change user password also giving error.
> 
> but i did not try :
>  passdb backend = ldapsam:"ldap://slave ldap://master"
> Will it solve my problem?
> 
> Another question:
> On what interval client changed their machine password? is it 
> triggered forn client or server?
> 
> 
> --beast 
Passdb backend = ldapsam:"ldap://master ldap://slave" works just fine
for me.  I have the passwd program set to /usr/bin/passwd and Samba
updates the Samba related entries in the Master LDAP (with passwd
updating the posixAccount related entries).  Took me a while to find the
ldapsam:"ldap://master ldap://slave" workaround too, but it's
worked
flawlessly for me in production since.

Clint

Quotes are required around the two ldap:// URIs AFAIK.  I've not used AS
3, but on 8 I've always built from Source RPM as I've also added ACL
support (pretty easy with the Redhat kernels, and even though they say
it's not stable, I've yet to have any problems with it).  I'd go
grab
Samba 3.0.1 source RPMs from the Samba website and build from there, or
even upgrade to 3.0.1 from the Redhat RPMs on the Samba site, as those
are known to have proper LDAP support included.

Clint
> -----Original Message-----
> perhaps this is a problem with only the version of Samba 3 
> that shipped in Red Hat AS 3 but if I put in...
> 
>  passdb backend = ldapsam:ldap://localhost/ ldap://slave/
> 
> I end up with the following in /var/log/samba/log.smbd...
> 
> [2003/12/29 10:04:58, 0]
> passdb/pdb_interface.c:make_pdb_methods_name(447)
>   No builtin nor plugin backend for ldap found
> 
> Official Samba-3 Howto also states that default (meaning undeclared
> value) for ldap ssl = Start_tls but that doesn't seem to be the case.
> 
> Craig
> 
>