Tuesday, October 28, 2003
net rpc vampire
Looks like the net rpc vampire command only brings over accounts which already appear in /etc/passwd
Looks like the net rpc vampire command only brings over accounts which already appear in /etc/passwd
Tuesday, October 21, 2003
Samba 3.0 passdb backend
Using the getsid.exe reskit tool, to double check the passdb.pdb, I found that none of my user sids matched.
This is because I originally imported the accounts with the net rpc vampire command while using passed backend = smbpasswd. And later coverted to a tdbsam. I wonder if subsequent runs of vampire corrected that info, but apparently not. I'm not even sure if subesquent runs of vampire do anything to existing accounts. I wonder how Samba generated those SIDs?
Using the getsid.exe reskit tool, to double check the passdb.pdb, I found that none of my user sids matched.
This is because I originally imported the accounts with the net rpc vampire command while using passed backend = smbpasswd. And later coverted to a tdbsam. I wonder if subsequent runs of vampire corrected that info, but apparently not. I'm not even sure if subesquent runs of vampire do anything to existing accounts. I wonder how Samba generated those SIDs?
Wednesday, October 15, 2003
Samba 3.0 Administrative accounts.
From the best I can tell, the net rpc vampire command doesnt bring over the Adminsitrator accounts, so it's best to created it manually- it needs an entry in /etc/passwd too, of course.
Once I got this working, I tried adding a machie to the test domain. While it "added" the machine from the machines perspective, upon rebooting, I couldn't authenticate the machine on the domain because the "account was missing".
Next step, try to add the machine under a different name, to make sure it isnt' conflicting with the old entry which was vampired in
From the best I can tell, the net rpc vampire command doesnt bring over the Adminsitrator accounts, so it's best to created it manually- it needs an entry in /etc/passwd too, of course.
Once I got this working, I tried adding a machie to the test domain. While it "added" the machine from the machines perspective, upon rebooting, I couldn't authenticate the machine on the domain because the "account was missing".
Next step, try to add the machine under a different name, to make sure it isnt' conflicting with the old entry which was vampired in
Friday, October 10, 2003
WINS and iptables
We changed the firewall from ipchains to iptables on one of our Samba 2.2 file servers. After several hours, we started seeing permission problems, which cleared up immediately once we brought down the iptable firewall.
Users were authenticating to our NT 4.0 PDC, but when the workstation tired to load their profile, stored on the Samba 2.2 server, they received a "Domain not found" error message.
Logged on to the workstation with the default profile, a user could bring up the fileserver, but a name/password logon window appeared- the symptoms suggested that Samba couldn't confirm the users SID when trying to validate their access to a particular file. Although there were reports that some workstation session were working fine.
This sort of inconsistent problem suggested a WINS/NetBios resolution issue.
Debugging (nmblookup -d) showed that the machine was not finding the Domain Controller when querying it's local nmbd, so we switched the smb.conf to point to our Windows WINS server. Which, incidentally is on another class-d subnet of our flat, three-subnet network.
This didn't solve the problem- we noticed that nmblookup was failing to use the WINS setting, moving on to attempting a broadcast resolution of the DC. But the broadcast probably wasn't reaching all of our subnets, because the ifconfig was using a 255.255.255.0 subnet- we modified it to 255.255.192.0, and the DC resolved. And it looks like this solved the problem.
But two questions remain:
We changed the firewall from ipchains to iptables on one of our Samba 2.2 file servers. After several hours, we started seeing permission problems, which cleared up immediately once we brought down the iptable firewall.
Users were authenticating to our NT 4.0 PDC, but when the workstation tired to load their profile, stored on the Samba 2.2 server, they received a "Domain not found" error message.
Logged on to the workstation with the default profile, a user could bring up the fileserver, but a name/password logon window appeared- the symptoms suggested that Samba couldn't confirm the users SID when trying to validate their access to a particular file. Although there were reports that some workstation session were working fine.
This sort of inconsistent problem suggested a WINS/NetBios resolution issue.
Debugging (nmblookup -d) showed that the machine was not finding the Domain Controller when querying it's local nmbd, so we switched the smb.conf to point to our Windows WINS server. Which, incidentally is on another class-d subnet of our flat, three-subnet network.
This didn't solve the problem- we noticed that nmblookup was failing to use the WINS setting, moving on to attempting a broadcast resolution of the DC. But the broadcast probably wasn't reaching all of our subnets, because the ifconfig was using a 255.255.255.0 subnet- we modified it to 255.255.192.0, and the DC resolved. And it looks like this solved the problem.
But two questions remain:
- Why isn't getting resolve responses from the WINS server?
- Why did moving from ipchains to iptables seem to mess up it's local nmbd? The machine appeared to resolve the DC fine for several hours after the iptables were brought up?
Wednesday, October 08, 2003
pdbedit
Samba 3.0's pdbedit is a bit of a mystery. When smb.conf is in the passsdb backend = smbpasswd mode, you can't use the program to edit the entries you see when doing a verbose listing-
...but once I converted the backend to tdbsam, I could edit it. -
So how were those SIDs being stored? They weren't in the smbpasswd file. I assumed that samba was storing them in the secrets.tdb, and had exported them though the net rpc vampire commad. But maybe it just auto enerated them somehow, based on the smb.conf or something. While the user and group SID on that account look awfully similar, there is no obvious relationship to the /etc/passwd uid or the gid.
What's going on here?
Samba 3.0's pdbedit is a bit of a mystery. When smb.conf is in the passsdb backend = smbpasswd mode, you can't use the program to edit the entries you see when doing a verbose listing-
Unix username: fooobar
NT username:
Account Flags: [U ]
User SID: S-1-5-21-3755442435-3957602856-2107517473-15880
Primary Group SID: S-1-5-21-3755442435-3957602856-2107517473-1021
Full Name: Bart Foo
Home Directory: \\testpdc.env.duke.edu\msdfs\home\%u
HomeDir Drive:
Logon Script: somthing.bat
Profile Path: \\testpdc.env.duke.edu\msdfs\home\%u\profile
Domain: TESTDOMAIN
Account desc:
Workstations:
Munged dial:
Logon time: 0
Logoff time: Mon, 18 Jan 2038 22:14:07 GMT
Kickoff time: Mon, 18 Jan 2038 22:14:07 GMT
Password last set: 0
Password can change: 0
Password must change: Mon, 18 Jan 2038 22:14:07 GMT
...but once I converted the backend to tdbsam, I could edit it. -
1. Set the passdb backend = tdbsam, smbpasswd.
2. Execute: root# pdbedit -i smbpassed -e tdbsam
3. Now remove the smbpasswd from the passdb backend configuration in smb.conf.
So how were those SIDs being stored? They weren't in the smbpasswd file. I assumed that samba was storing them in the secrets.tdb, and had exported them though the net rpc vampire commad. But maybe it just auto enerated them somehow, based on the smb.conf or something. While the user and group SID on that account look awfully similar, there is no obvious relationship to the /etc/passwd uid or the gid.
What's going on here?
Thursday, October 02, 2003
Samba 3.0 databases
I'm trying to determine exactly how the net rpc vampire works and what it brings in- seem it dumps the username and passwords into smbpasswd and the SIDs into secrets.tdb.
What I can't figure out is what happens on subsequent runs of the comand- there's all sorts of action and messages that its creating accounts, but doesn't seem to be adding them to smbpasswd. Maybe I don't have the add user scripts set correctly.
I'm trying to determine exactly how the net rpc vampire works and what it brings in- seem it dumps the username and passwords into smbpasswd and the SIDs into secrets.tdb.
What I can't figure out is what happens on subsequent runs of the comand- there's all sorts of action and messages that its creating accounts, but doesn't seem to be adding them to smbpasswd. Maybe I don't have the add user scripts set correctly.
Samba 3.0 play
more testing of the nt rpc join command reveals that it's not real flexible if you are trying to join an NT 4. 0 domain, which makes sense- the -S flag had to have the netbios name of the server- not the fully qualified name.
Which makes sense, since it's going to have to go to port 139 trust, and it's going to happen with netbios.
more testing of the nt rpc join command reveals that it's not real flexible if you are trying to join an NT 4. 0 domain, which makes sense- the -S flag had to have the netbios name of the server- not the fully qualified name.
Which makes sense, since it's going to have to go to port 139 trust, and it's going to happen with netbios.
