Win Lin

Had a lot of problems getting the net rpc vampire command to work, though it turned out the machine had never really joined the domain, and the samba 3.0 documentation was a bit deficient.

Here's the official steps:

The Account Migration Process

1. Create a BDC account in the old NT4 domain for the Samba server using NT Server Manager. a) Samba must not be running.
   
2. net rpc join -S NT4PDC -w DOMNAME -U Administrator%passwd
   
3. net rpc vampire -S NT4PDC -U administrator%passwd
   
4. pdbedit -L a) Note — did the users migrate?
   

The missing step here is that samba does need to run, and you need to have an "add user script" in place for the machine to properly join the domian.


Here is what worked - I got this from a search on linux.samba on google groups -

 

X-Original-Cc: samba@lists.samba.org

X-Original-Date: Tue, 2 Sep 2003 11:09:59 +0200

X-Original-Message-ID: 

X-Original-Sender: samba-bounces+linux.sambamail2news.bofh.it@lists.samba.org







Hi all,



Thank you for your help, and sorry for my late answer.

Everything works fine by now !



Yes, you have to become a BDC to vampire the accounts ! This is why I w

as

getting an "Access denied" error :

I thought my Samba was a BDC, but I forgot to add "domain logon = Yes

" in

my smb.conf, so Samba was a simple share server.



Here is the steps I followed to suck the accounts :



1 - smb.conf extract :



-----------------------------------------------------------------------

-----------------------------------------------------------------------

--------

; low OS level

os level = 40

domain logons = Yes

domain master = No

local master = No



; Undocumented : this is compulsory to allow Samba to create Unix accou

nts

on the Samba server

; Created in two groups : samba and machines

add machine script = /usr/sbin/useradd -g machines -c "Samba Machine"

 -d

/dev/null -s /bin/false '%u'

add user script = /usr/sbin/useradd -g samba -c "Samba User" -d /dev/

null

-s /bin/false '%u'

add group script = /usr/sbin/groupadd '%g'

add user to group script = /usr/sbin/usermod -G `/usr/bin/id -G '%u' 

|

/bin/sed 's/ /,/g'`,'%g' '%u'

-----------------------------------------------------------------------

-----------------------------------------------------------------------

--------



2 - Testparm should report : ROLE DOMAIN BDC

3 - Add an account for the Samba machine on the NT4 station (via server



manager)

4 - Start Samba

5 - Join the domain : net rpc join -S nt4 machine's netbios name  -w

 -U Administrator

(the samba machine should appear as a BDC on the NT4 server manager)

6 - Vampire : net rpc vampire -S nt4 machine's netbios name -U

Administrator%password

So, the Invalid Target Problem I mention below seems directly related to Samba 2.2 not correctly reproducing SID or at least the RID portion of the SID in ntuser.dat in a migrated profile.

The solution is to regenerate the RID for every account. Which look scriptable, but not easy. While working on this, Samba 3.0 moved to final release, so I've been investigating using Samba 3 as the PDC. It certainly has a lot more tools, and the "vampire" command should bring in the accounts automatically.

Invalid Target Problem

A freshly loaded profile, generated by the \\SAMBA_PDC\Netlogon\Default User, doesn't have this problem.

The setting is controlled by \\HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Personal
In the freshly loaded profile, the user has permission to alter the key directly - the perms show as DOMIAN\username : Full Control

But with the profile I migrated from our old network, it inherits CREATOR OWNER permissons from teh CURRENT_USER key.

...next step, test other migrated accounts.

another fine tuning problem-

The default Network profile points the desktop "My Documents" folder to the mapped home drive- (z:\). On the test domain, I've noticed that this setting (controlled by a registry entry) is reverting to the default (c:\documents and settings\%username%\My Documents).

When I try to manually change this back to Z:, I get a error on XP-

Invalid Target

The location you requested is not allowed as a target.

and I get no warning on W2K Pro, but it doesn't actually let you change the setting, even though it lets you click 'Apply'.

I tried adding "profile acls = yes" to the profile share in smb.conf. Nope. Is it somthing about the user key in NTUSER.dat?

So Far:

Old NT Domain                     Test Samba Domain

Authenticate Users                 done 

Authenticate Groups                done

Machine Trusts                     done - but XP clients need to be tweaked

Roaming Admin Authority            probably need to re-import Admin account

Firewall                           still need working IP chains (Open UDP on Windows ports?)

Roaming Profiles                   not follwing symbolic links? 

Default Domain Profile             not in NETLOGON folder, untested



also need to test MSDFS for home path links

Well, since it looks like I recreated the Admininstrator account on the test domain, it generated a new SID, and so that account doesn't have admin access on existing workstations.

Workstation trusts working okay. We've narrowed the problem down to XP boxes. The O'Reilly Samba book points out you have to change this registry setting:

\\HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NetLogon\Parameters\requiresignorseal

...set it to 0 and everything is okay.

Got a Samba PDC running on a private switch, and while the user accounts authenticate correctly, and while I can add machines to the domain, existing machine trust accounts are not being recognized.

Raised the log level from 0 to 10 in smb.conf. In the detailed logs, it looks like password check-confirm dialogs between the server and workstation aren't allways checking right

Some things we're suspecting:

• Oops. Forgot to migrate the SID of the domain. Checked out the smbpasswd -W option. But it still doesn't work.


• the SAM entries created by pwdump2.exe utility look different than those created by the smbd.
  - the machine trust records are in uppercase from the dump, lowercase from the smbd
  - the password hashes are in lowercase from the dump, upper from the smbd
  the smbd records have the ...

  [W           ]

  field filled in.

...and when I started troubleshooting all this, I noticed that I couldn't grep the /etc/samba/smbpasswd file- it said it was a binary file. Careful examination of the file show a bunch of null charachters showing up around lines 400 and 800. This file was orginally created on ntfs filesystem with the pwdump2 utillity.

So right now, I'm investigated other SAM -> smbpasswd conversion utilities.

after much messing around, I belive these are the best step for getting the admin account going when migrating from an NT 4 to a Samba PDC domain.

1) dump the accounts database from the NT PDC using pwdump2.exe.
2) put the contents of the dump into /etc/samba/smbpasswd
3) open smbpasswd, remove the adminstrator entry (which might be listed as Adminstrator, creating case problems too)
4) add a domain admin with this command
smbadduser root:administrator
5) open /etc/samba/smbusers
make sure the entry for root doesn't have any aliases for administrator"
root = adminstrator
6) check smb.conf to make sure the user add script parameter is pointed to the correct useradd command on your system. A lot of the current samba documentation assume a Redhat machine where useradd is in /usr/bin. But it's in /usr/sbin on 7.3.

Had trouble adding a machine to TESTDOMAIN. First problem was that the administrator account in the smbpasswd file was case sensitive- from /var/log/samba/

[2003/09/03 17:00:35, 0] passdb/pdb_smbpasswd.c:build_sam_account(1194)
build_sam_account: smbpasswd database is corrupt! username Administrator not in unix passwd database!

changing the 'A' to lowercase corrected the problem

Back working on Samba migration after a long break of getting the school year underway. Now all our clinets are on DHCP, and we're pushing out a 255.255.192.0 subnet mask. Servers are on an isolated subnet, and clients are authenticating okay.

The IPC vulnerabilities have made migrating the Domain Controller to Linux a priority. My plan right now

1) Set up a TESTDOMAIN domain, and transfer the domain SAM database.
2) Test the behavior of this domain
3) Try putting the domain behind a switch, along with a few ACTIVEDOMAIN clinets.
- change the name of TESTDOMAIN to ACTIVEDOMAIN

See if it works.

4) Go Live.

I've set up the test domain, using the program pwdump2.exe. It took a few days of troubleshooting to realize that the default RedHat ipchains were getting in the way of stuff- I couldn't add new workstations to this domain. I think this is because I wasn't allowing UDP traffic through the chains. I'm going to test this...