Samba Traffic #8 For 19 Jan 2000

This was a very busy week for Samba domain-controller support, and thus for the samba-ntdom list. Luke Leighton's SAMBA_TNG branch of code is now moving so fast that bug reports and followups make frequent mention of exactly when the reporter last checked out the CVS code ("I am running combined SAMBA_TNG which I downloaded today at 1:00 pm..."). An exciting time, to be sure.

The word seems to be out that SAMBA_TNG is the happening place. So many people are trying it out now that Luke made the general request: "i just wanted to say that i'd really appreciate it if you could all muck in: those people who have SAMBA-TNG (or mixed cvs main smbd/nmbd + SAMBA-TNG msrpc services) working, please help out those people who haven't got some things going yet." This really almost goes without saying, on the Samba lists as in other open-source projects.

SAMBA_TNG is not the only branch where the action is, though; Jeremy Allison is now running full-tilt squashing bugs in what will soon become Samba 2.0.7. [Note: he hasn't so much as hinted at a release date, so don't bother asking him or me!]

Finally, following a suggestion from Tridge himself, we present the debut of a stats table for CVS activity. In CVS terms, a "commit" is an individual act of telling CVS to update its repository to reflect files you have edited. The table also gives the total number of files affected, and which CVS branches people are working in. Please send feedback if you have ideas on how the data should be presented differently/better/not at all. [Also: my apologies to Lynx users. I myself am a Lynx user, so I know that Lynx butchers HTML tables to near-illegibility. But the only alternative I could think of was preformatted ASCII text, which I didn't want to do but might consider.]

There were 225 different contributors. 80 posted more than once. 53 posted last week too.

Richard Meglino couldn't get Windows95 to print to his Canon printer on Linux. He had no trouble with file sharing.

Giulio Orsero asked if he could print via smbclient -- no, he couldn't. Richard then noticed a log message:

Giulio noted: "There's a problem: your smb.conf shows you are using encrypted passwords, but the log shows that pam auth is used. If you use encrypted password samba authenticates against the smbpasswd database, so pam has no say. If you don't use encrypted passwords then samba authenticates against /etc/passwd using pam if available on your system." Steve Langasek had a different theory: "making the smbpasswd file isn't enough to let you use encrypted passwords; you also have to populate the file with actual encrypted passwords. The smbpasswd command should help you with this."

I gave a 2nd look to your smb.conf:

you use "encrypt passwords = yes" and then "encrypt passwords = no", so that you use /etc/passwd and smbpasswd is ignored.
you use "log level = 0" so that samba doesn't log anything.

The problem never was tracked down, but Richard did have an interesting encounter with printer drivers: "I think the problem lies in Windows. I changed the printer driver (in Windows) to Cannon BJC 100e (I have the BJC 610) and it printed. The quality was somewhat poor but it printed. However, when I switched it back to the BJC 610 driver it didn't print."

James Tait kicked this one off on samba-ntdom. He couldn't get roaming profiles to fly from Windows98 using Samba 2.0.6. Giulio Orselo fired off the boilerplate response about Samba 2.0.6 and profiles in general: "samba-2.0.6 has a problem that causes profiles to be stored in the homedir, whatever you put in "logon path". See if they are there :)" Later, he expanded on this: "samba-2.0.5 worked. But a change in ipc.c to make net use h: /home work, had the side-effect to make logon path ineffective. In samba < 2.0.6 net use h: /home would map to the profile share and logon path worked. In samba 2.0.6 net use h: /home correctly maps to the home share but logon path doesn't work."

Luke Leighton posted his well-known opinion of NT-domain features being totally unsupported in Samba 2.0, but Jean François Micouleau corrected him: "you're mixing NT and 95/98 profiles. NT profiles are working. Guilio is talking about 95 profiles." Meanwhile, Jeremy Allison promised to have the bug fixed by Samba 2.0.7.

But Johan Meiring didn't think it was actually possible to fix this bug. "Everybody seems to be worried about whether het use x: /home or roaming profiles should work for Win 95. If the one works, the other one breaks. Keep in mind that in an NT ONLY environment Windows 95 will store roaming profiles in your home directory! This is by M$ braindead design. Samba should therefore do this as well. i.e. 2.0.6 behaviour."

Keith Lynn had a question for samba-ntdom: "Does Samba give the option of tracking activity through the spooler such as the number of pages printed?"

Claus Färber saw an implementation problem: "What printer drivers actually send is raw printer data or raw Postscript. You would have to parse that in order to determine the pages printed." Michael Glauche didn't think that was so hard: "IIRC that is possible when using postscript printers. You should give the LPRng project some closer look, (www.lprng.org) It comes with some filters that DO printing accounting for postscrpipt printers. (They just count the "begin page" words in postscript documents :) But ... this is more a LPR issue than a samba issue ... :)"

As Jean François Micouleau pointed out, "yep. but you can hack postscript files to return a null number of pages whatever the real number is." But, said Matthew Keller, "A crafty user can hack your print spooler. :) The LPRng solution is ideal for most environs." Peter Svensson had a different approach: "There are also filters which query the printer's page counter. They work rather nicely."

Margarita Parker couldn't add NT workstations to a domain controlled by a Samba 2.0.6 server. Lars Kneschke pointed out that Samba 2.0 could not control a domain of NT machines, but Doug Breshears challenged that: "2.0.6 will allow NT 4.0 SP4 machines to join the domain, I have 2 networks running right now on 2.0.6 with nothing but NT4 clients and nothing but samba server." [Note: controlling an NT domain with 2.0 is possible, but not recommended by the Samba team. Version 3.0, currently in development as the CVS HEAD branch, will have full NT domain controller support.]

Nils Ohlmeier asked if Margarita had run smbpasswd -a -m server_name; he also asked the world at large if this was documented anywhere. Lars posted a pointer to his ever-popular recent-Samba-how-to page, http://www.kneschke.de/projekte/samba_tng/index.php3.

Margarita answered Nils's original question, putting the thread to rest: "Yes I did add the server and that did not make any difference. But now I made a couple of changes in my smb.conf and I can join the domain with an NT machine. I cannot logon though I appears that I have some problems with the roaming profile. I am not sure how to tell it that I do not want any rowming profiles."

Keith Lynn thought someone on samba-ntdom might be able to help him with NT printer drivers: "Does someone know how to make the drivers download and setup on an NT Client?" Giulio Orsemo pointed out: "Samba docs (printer_driver.txt) says driver download works with win9x only; nt is not supported yet." However, Jean François Micouleau had new information: "NT is supported in SAMBA_TNG. only NT4 x86 SP3 and below." [Your editor has no idea what changed in NT4 SP4.]

Luke Leighton has just published a Samba book. He proudly posted to three Samba lists:

It's now available from Macmillan Technical Publishing.

The only source of information publicly available on Windows NT authentication and password-update methods, including NTLMv1, NTLMv2, NTLMSSP, the Domain Logon Protocol (NETLOGON and NETLOGON "Secure Channel"), Windows 95 user, NT user and NT Administrative password changes, and how the SAM database is encrypted when transferred from a PDC to a BDC.

It also contains information on how to understand, at a very detailed and boring level, NT Domain traffic (DCE/RPC) such as NT Domain Logons and running User Manager for Domains. It also matches official MSDN functions with unpublished Microsoft APIs, evidence for the existence of which can only be deduced from examining network traces or by purchasing an NT Source Code License.

Jeremy Allison replied, having already bought a copy, "It's also a VERY good book. Congratulations Luke - you really did a nice job on this one. Now I can use your own words to argue with you about packet details :-) :-)."

Somehow the discussion got onto benchmarks between Linux and NT at file service. Maybe there is a law of physics about this sort of thing. Anyway, Matthew Geddes mentioned, in passing: "I have seen other (truly) independent tests - I think ZDNet did some. They all say that Samba / Linux is up to 2.5 times better than NT at it's own job. Windows NT is a little better than Samba for up to 16 users and then it tends to go rapidly downhill. He He He...." Luke corrected him: "12 users, not 16."

This was not a single thread, per se (this section is highly multi-threaded, if you will). Luke Leighton, like several Samba developers, occasionally posts status reports of what he is working on. He had four this last week:

Jan 9: "this is just so cool. i have the "biggie" to code up (netlogon "sec channel" authentication token parsing) in a bit. i just wanted to say tht the principle of having authentication apis is so cool. the changes to the main code to add netlogon secure channel - NetrSamLogon - will be zero changes. the changes to NetrAuth2 implementation was to put neg_flags in there as a proper parameter like it should have been already. the changes to NetrReqChallenge - zero. a little bit of code to set up the netlogon sec channel, if negotiated (10 lines), in cli_nt_setup_creds()."

ok, i got so fed up with all the reports of people using smbpasswd bitching about how it couldn't be used to join its own domain that i fixed it.

HOWEVER...

you should be aware that smbpasswd sets the initial trust account password to server_name_in_lower_case, and then changes it, using the initial password to encrypt the new one. this is to be compatible with NT 4.0.

IF you are concerned about network sniffing from hostile users, THEN:

use rpcclient instead (lsaquery; createuser sambaserver$ -j).

the password change is done using the administrator's username / password to encrypt the trust account change, NOT the old trust account password.

Jan 12: "i had some memory uninitialisation issues after UNICODE strings, so i do a memset(.. 0.. ) on all NDR marshalling, now. this cleared up a lot of problems. i've yet to test usrmgr."

Jan 13: "ok. if there are more than 16 groups (appx 0x400 bytes) in a samr_query_dispinfo infolevel-3 (groups) response, we get an RPC failed error. if anyone wants to see if they can track this down, feel free to. i'm back in again tomorrow morning on the test network."

large PDUs work again. symptoms of problem: USRMGR.EXE not working if you had more than about 16 Domain Groups. there are plenty of other symptoms, such as printing not working.
profiles work again. symptoms of problem: user profile path is not available etc etc. i had to hack this one, for now.
SamrSetInfoUser info level 0x17 works. symptoms of problem: NT5rc3 being added do a samba-tng domain failed to work.

there were a couple of others. can't remember. i'm off home: see you all again either from dial-up or tomorrow. thank you everyone for sending in reports, i'm sorry i keep telling some of you to back off a bit, there really are too many of them, but that's my own fault for coding away without access to my nt test network for 10 days.

Several people reported trouble, on this thread, with getting Samba-TNG working as a primary domain controller. Ulf Mehlig led out, listing in some detail the procedure which had failed to work for him. Luke told him to try "smbpasswd -j <domainname>", but Ulf already had.

Lonnie Borntreger seemed to be going through much the same thing. He posted: "The latest TNG (9PM CST). Getting closer, I have the .mac file, so I'm assuming that something is wrong with my config." He posted log and config files. Luke replied the next day: "please could people remember that logs of less than 100 for dce/rpc errors are almost completely useless to me, and please also remember that i absolutely detest the "debug timestamps", so please either set this parameter to "no", or use grep -v "2000/01/11" on the log output, to get rid of the dated lines, they're a damn nuisance. log level 100s are a bit like netmon traces / packet dumps, only better :-) :-)" Then he addressed the question itself: "lonnie, please disable "client ntlmv2" and "server ntlmv2", for now, by setting both these parameters to "no". there are issues with them that i need to resolve: they produce challenges that are >24 bytes long, and some of the buffers they get copied into are only 24 bytes long. dur!"

Then it was Mike Harris's turn. His nmbd was spitting out errors about connections to Unix domain sockets. [Unix domain sockets are somewhat confusingly named. They are local files on a computer which behave rather like network sockets, but they have very little to do with "domains" in the usual network senses of the word.] Mike ended with "And my clients can browse but not connect to the latest Samba TNG, well as of two days ago...." Luke's advice, referencing this last bit: ":) that's well over 48 hours, mike!!!!! damn, i dunno. some people, they expect code to just stay the same :) do another cvs update, see what happens." Mike's response was to get code "only about 3 hours out of date, surely not much could have changed since then? Still get the same problem though :-("

Luke was a bit puzzled, since the same code worked well for him, but asked whether Mike was running smb-agent. Since Mike [and your editor] didn't know what smb-agent does, Luke explained that it's a lot like ssh-agent:

if you run smb-agent, you can share it between your own processes (e.g, if you are logged in as mike on two unix bash$ shells, you can run smb-agent as a background daemon and then connect from both unix bash$ shells to the same smb-agent.

basically, smb-agent operates in exactly the same way that "net use" does on NT and 95. it caches username / domain name / passwords, so that if you don't specify a password when you run rpcclient, smbclient, smbwrapper, smb-agent will supply one for you from its cache.

Then, out of the blue (screen), Mike posted: "Don't know whether this helps, but suddenly it works for me:" followed by details of his setup.

Larry Blunk posted a URL to a Microsoft Knowledge Base article he thought everyone on samba-ntdom might enjoy. It deals with how to resolve a problem caused by a Samba server on an NT network trying to usurp the role of an NT primary domain controller. The advice given: "To resolve this behavior, turn off the Samba server."

A lot of people took issue with Microsoft's perceived arrogance, that taking down a Samba server was the only option in a situation like that, not to mention the fact that the problem -- having two PDC's trying to serve the same domain -- is not the least bit Samba-specific.

Karl Denninger, for example, said: "This kind of thing - "remove the piece we didn't sell you from your network" - went out of favor when IBM's monopoly on hardware and software was broken up in the mainframe world." Stephen Waters sighed, "talk about brute force problem resolution. ;) they couldn't just have you edit the smb.conf file and restart the daemon now could they?" This drew Luke Leighton to observe: "well, of course not. the person who set up the samba server was probably so stupid that they don't know what an smb.conf file IS. .. which is 100% of the problem in the first place."

Inevitably, the urge to start Microsoft-bashing hit. A small debate arose on what "NT" really stands for. They say it means "New Technology", but various alternatives posed on the list included "Not Tested", "Needs a Terabyte", "No Technology" and "Nice Try". Two people noted that in the cracker community it is "Nice Target"....

On the practical side, Martin Kuhne of Microsoft (Our Man in Redmond, as it were) asked for suggestions for what the KB article should say instead. After some feedback, he posted the proposed change:

To restore PDC functionality, take the Samba server off the network and restart the netlogon service on the original Windows NT PDC.

To resolve this problem, disable the domain controller functionality on the Samba server. This can be done by changing the following values in the Samba configuration file (smb.conf):

  domain master = no
  preferred master = no
  domain logons = no

For further information, please refer to the product documentation or to the manufacturer's web site (http://www.samba.org)

Apparently Martin does have some influence with the Knowledge Base people, because Microsoft changed the page.

Of course, that didn't stop the anti-Microsoft ranting. That went on for post after post. Jeremy Allison was disappointed, if not surprised: "I have been watching this thread degenerate into a "I hate Microsoft" rant (too busy to post anything as I'm trying to get all the pending patches integrated for 2.0.7. I shouldn't be posting this :-). Not very inspiring for anyone working with NT on a daily basis (this includes me !). Remember, Samba is an outreach tool to help NT and UNIX interoperate (at least that's how I'd classify it). It's the glue between UNIX and Windows. I always welcome the chance to talk to Windows administrators because they are usually very interested in improving their skillset and see Samba running on a UNIX system as a good way to move their skills into the higher paid UNIX world."

Luke Leighton didn't go for all the flamage either; in fact, in a sense he agreed with the original article: "this is because people xxxx up the samba installation by puttting "domain master = yes" and "domain logons = yes" when there's already a PDC on the network. anyone that's stupid enough to do this deserves to have their samba server switched off, as suggested by the KB article. [...] so, like i said, anyone who is stupid enough to do this does not deserve to have any computers on their network."

(Also, about this time, he posted a very interesting tidbit, which didn't fit the flow of discussion too well but is well worth knowing about: "if you put "fstype = CDFS" in a [sharename], and put an AUTORUN.INF file in the root of the share, windows will run the program at the pathname listed in AUTORUN.INF when that share is first accessed, like it was a CDROM drive. i'm sure that if you configured samba as a BDC, you could get a script to view that share on first user-login. this is a very easy way to upgrade all your windows workstations." )

Then, as in most good flamewars, there came the backlash stage. Steve Cody was prominent: "A bunch of complaining, whining, OS bashing doesn't do anything but boost your ego. There has always been one thing you could tell about Linux lovers... About 90% of them are fanatics, and the remaining 10% get things accomplished." This was quickly followed by the backlash to the backlash. Matthew Keller was very annoyed: "First of all, "fanatics" can be found anywhere. There are raving MS fanatics. I have a client that runs, NT/98, with MS SQL server for database, Exchange for email serving, Outlook for and email client, Word for word processing, Excel for spreadsheets, etc, etc. etc. NOT because it is the best solution, but because he believes in Bill Gates and Microsoft as a copmany. I have colleagues who won't touch a computer unless it has an Apple logo on it. "Fanatics" are everywhere. There are a lot of "new school" IT professionals that swear by NT/Microsoft... They wear ties, use Internet Explorer, have AOL as an ISP, and believe that UNIX is for geeks and geriatrics. I call them 'zealots', you call them 'fanatics'... Same thing."

The thread didn't show any signs of slowing down, although there continued to be bits and pieces of signal cutting through the noise, so Luke Leighton finally put his foot down: "right. if i see anyone else use this thread over the next few days, i'll unsubscribe them. i won't stop you resubscribing, unless you do it again."

Suddenly everyone shut up. Except for an indignant Jeremy Jones: "I hope you're happy... You've scared Bill Gates, he's quit and he's going home. I want you to go to your room and think about what you've done. Then you're going to call his mom and apologize for being bullies. Maybe make him some cookies, too. :)" (He posted this on a new thread, quite possibly to keep from getting unsubscribed....)

Andrew Tridgell announced: "This is just to let people know that I have finished an initial implementation of a new byte range locking system in Samba 3.0. It seems to work." This module, based on his tdb code (see Issue #5, Section #5 and Issue #6, Section #2) would eliminate Samba's dependence on POSIX file locking facilities, which apparently have a number of disadvantages:

a close() on posix clears all locks on that file for the process. In SMB it clears only the locks on that file descriptor. Thats why we have the ugly file descrriptor multiplexing in samba.
posix locks have 31 bit ranges as they are signed. SMB locks can be 64 bit. This matters a lot as SMB clients use high lock ranges as semaphores. We use a kludge to get around this.
posix and SMB locks have quite different rules for lock contexts, coalescing locks and overlapping locks.

He and Jeremy Allison argued some about various technical details, such as exactly how broken the current hacks are and how many of them can actually be removed thanks to the new locking code. Eventually, either Tridge convince Jeremy, or Jeremy convinced himself, that a lot of the locking ugliness really could go away: "Once all the tdb lock record processing is done, with the tdb database still locked, we attempt a mangled POSIX lock as best we can and then roll back on a fail. This will actually simplify the locking code processing immensely, as the nasty mangling details can be confined to one place. Blocking and timeout locks will be fun though, but can still be handled in the same way we do currently, with a timer tick function. Hmmmm. This should work...."

A few other people joined in with various other comments and arguments, ranging from NFS server bugs (byte-range locks on some old NFS lock daemons, it seems, only support the low 30 bits of a nominally 31-bit range) to data corruption mixing SMB oplocks with POSIX locking.

Dejan Ilic had a question: "smbclient can send to a specific (netbiosname) machine but not to a specific user on that machine. You can only supply the senders user, not receiver. This is not a problem today as we have WinNT workstations where only one user at time work, and the messages are usualy directed to that user." However, targetting a machine rather than a user has problems, not least of which is NT Terminal Server, which allows multiple simultaneous users. Michael Glauche noted that not only can NT 4 send messages to a user, it can send a message to an entire workgroup/domain at a time, which can also be handy.

Timothy Cole believed that NT probably looks up the user with NetBIOS (registered as a type 03 entity when you log in) and sends to the machine in question. He and others recommended just doing that ("nmblookup <username>\#03"). This would not solve the multiple-users-per-machine question, however -- Dejan Ilic found that NT Terminal Server had a command "msg", similar to "net send", but specifically targetting a user. Nobody, it seems, has reverse-engineered that yet, though.

Mark de Jong wondered (on samba-ntdom): "Is it possible to create NT user accounts using Samba if it is configured as a BDC? Is it still possible to set up Samba as a BDC?" Luke answered, "yes, but remember that you need to run rpcclient samsync command as root from a cron job to update, it doesn't happen automatically, yet." Later, he elaborated:

  domain logons = yes
  domain master = no
  security = user
  password server = THEPDCNAME
  workgroup = THEPDCDOMAINNAME

  unixrootprompt# rpcclient -S THEPDCNAME -U admin%pass -W THEPDCDOMAINNAME
  [DOM\admin@PDC$ ] lsaquery
  [DOM\admin@PDC$ ] createuser YOURSAMBASERVERNAME$ -s -j
  create trust account: OK
  join domain: OK.
  [DOM\admin@PDC$ ] samsync

you WILL need to have created unix /etc/passwd entries in advance of doing the sam sync command.

This piqued Steve Langasek's interest: "Is this 'samsync' command the same as or different from the replication used between NT PDC/BDC groups? (I.e., how far do we have to go yet before peering relationships are possible? :)" Luke gave the answer we all wanted to hear: "exactly the same protocol." The to-do list for full BDC functionality? "auto updates. promote BDC to PDC. that's it." Indeed!


Kernel Traffic Latest \| Archives \| People \| Topics	Wine Latest \| Archives \| People \| Topics	GNUe Latest \| Archives \| People \| Topics
Czech

1.	7 Jan 2000 - 10 Jan 2000	(11 posts)	Printing Problems from Windows95
2.	8 Jan 2000 - 10 Jan 2000	(19 posts)	Roaming Profiles
3.	8 Jan 2000 - 11 Jan 2000	(6 posts)	Setting Up Printer Accounting
4.	7 Jan 2000 - 12 Jan 2000	(9 posts)	NT 4 Joining a Samba Domain
5.	9 Jan 2000	(3 posts)	Automatic Printer Driver Downloads
6.	9 Jan 2000 - 11 Jan 2000	(14 posts)	Luke's New Samba Book
7.	10 Jan 2000 - 12 Jan 2000	(4 posts)	Luke's Development Status Reports
8.	11 Jan 2000 - 12 Jan 2000	(21 posts)	More Samba/NT-Domain Trouble
9.	11 Jan 2000 - 13 Jan 2000	(94 posts)	Microsoft Acknowledges Samba Again
10.	12 Jan 2000 - 14 Jan 2000	(12 posts)	Tridge's TDB Code Strikes Again
11.	13 Jan 2000 - 14 Jan 2000	(17 posts)	Sending a WinPopup Message to a Specific User
12.	14 Jan 2000	(5 posts)	BDC Functionality Getting Closer

Samba Traffic #8 For 19 Jan 2000

By Peter Samuelson