Samba Traffic #12 For 16 Feb 2000

This week was more or less your typical Samba hacking week. Last week's flurry of RPC function interface changes in the SAMBA_TNG branch have settled down and Luke is now working on the password database backends. While doing this, he came up with the New Idea of the Week, a password encryption function that has proved to be somewhat controversial -- not the function itself, really, but the idea of using one. The arguments flared up quickly but seem to have died down just as quickly.

Other happenings this week include more bug-stomping in preparation for Samba 2.0.7. Jeremy wants to put out at least one more pre-patch before the real thing, but the quirks that showed up in the first pre-patch seem to be getting ironed out with some dispatch.

There were 210 different contributors. 80 posted more than once. 55 posted last week too.

Luke Leighton needed a password encryption function. He wanted to be able to encrypt a Microsoft LanManager password hash, which itself is a rather weakly encrypted password. (And, in fact, for all intents and purposes the LanManager hash is plaintext-equivalent, thanks to wire protocols that only challenge the client's knowledge of the hash itself.) He wanted this new 'n' improved function so that he could store passwords in a publicly-readable file, but didn't want to duplicate Microsoft's mistakes. So he wrote up a proposal based on MD5 and a secret key, and asked samba-ntdom how it looked, security-wise. (MD5, invented at RSA, is a one-way encryption hash function. It is widely used for such varied tasks as checksums of network-distributed files, password hashing on some Unix systems, and random-number generation in the Linux kernel.) Ironically enough, for such a long thread, nobody commented on the security of the proposed encryption method....

Jeremy Allison asked the obvious question: "Why ? SYSKEY is a silly idea ! Either you trust root, or you don't. If you don't trust root, then all the SYSKEY in the world doesn't help. If you do trust root, then why not let them see the hashed passwords ?" Later: "Luke - just because NT does it doesn't mean it is a good idea. Don't code this up. If you do it'll be a waste of your efforts as it will not go into a stable release." Phil Mayers was just as skeptical.

Luke was ready with an answer: "think. ldap. sql. nis+. we can't trust them, and they're all publicly accessible network protocols." In other words, in order to store Samba passwords using various methods including directory services, they would need to be encrypted, since the underlying protocols are not considered secure.

Jeremy was emphatic. "IT IS NOT OUR JOB TO FIX THESE PROTOCOLS !!!!!! We are NOT responsible for fixing LDAP or NIS. When they add session based encryption we will be secure. Stop trying to solve other peoples problems in Samba. It is NOT our job."

Someone used the phrase "fixing NT" in connection with Samba, and there followed a bit of digression concerning the semantics of fixing versus replacing versus whatever. Mike Warfield put it well: "No offense, but that interpretation sounds like you would call purchasing a Porshe to be a fix for a Ford. I won't disagree with your view..."

Back on topic, Luke and Jeremy continued to battle it out. Luke: "sorry ppl, fed up with arguing and explaining this, my hands are now constantly hurting. i'm creating a syskey2, it's going in the source code, if you don't like it, jeremy, well, work it out for yourself as to why it's needed." Jeremy: "Luke, this is not going into the shipping source, for reasons I have already explained. This is why I don't like you running off in a branch. This is why your branches get abandoned. You have not demonstrated a need for this, you have not demonstrated how it improves security in any way. You are just adding this as NT does it. This is not a good enough reason." Jeremy again: "Bringing up LDAP and NIS+ as a justification for SYSKEY is not valid, as therse protocols are better secured in other ways (transport level security) than a hack in Samba. I have a 'stupid SMB security tricks' talk that covers this in more detail (if you get to attend a talk I do you can hear part of it :-)." Luke:

well, i don't trust administrators to do a decent job (read the README on security, or go to a security talk), so i'd like to add a mechanism that will make me not wince when i see this kind of message: hi, my name is joe, and i'm setting up samba with ldap. i just wanted to check that my schema is right. please could you review it for me, thank you:

accountName: administrator smbPassword: 01fc5a6be7bc6929aad3b4351404ee

Jeremy: "When I'm back in the USA I'll call him and we'll agree. That's what usually happens. You're just seeing the public face of Open Source technical discussions. Like making Law, and sausage, it's not always pleasant to watch :-). But it'll turn out ok, honest :-)." Luke, responding to the charge that SYSKEY2 is unnecessary since the admins should just Know Better Than To Do That: "in this case, i'd still like samba admins to be able to use these protocols, without even having to KNOW that their passwords are protected over-the-wire. i.e if they didn't read the damn documentation, they still don't get screwed over, and we don't end up with a report on bugtraq." Luke, later explaining that he was not just trying to redo Microsoft's SYSKEY security: "let's see. places where microsoft messed up with rc4 that i can think of in under 1 minute...


NetrSamSync

SamrSetUserInfo

- info levels 0x23 and 0x24
SYSKEY
tick... tick... tick... damn, there's one more, i know it...
SamrChgUserPassword
.. sure there's another. anyway, you get the picture? i'm not about to bother with somestupid algorithm if i didn't think it was necessarey, yes?"

Then, in an abrupt change of pace, Jeremy posted: "You are correct though, that I'm trying to keep current on SAMBA_TNG and with the rate of change it's very hard at the moment. I hope that to get easier soon(hint hint :-) :-)." Seth Vidal thought maybe he could read between the lines: "For whatever reason I think you're trying to hint at maybe a code freeze of some type. If this is the case I'd love to see it. Keeping up with the CVS is not very easy for me right now." There was a deafening consensus for a code freeze for Luke's SAMBA_TNG branch -- perhaps surprisingly, Luke was part of it. Well, sort of: "except for the following, yes:

So everyone agrees on a code freeze for SAMBA_TNG. Even Luke. But, as Jeremy pointed out: "Unfortunately Luke is the one who has to stop adding new code and do the freeze before we can look at the merge :-). How about it Luke ? Don't say yes please, just stop adding new code :-)."

The same disk quota "bug" discussed last week in Section #7 came up again. Terry McCoy speculated samba-technical: "While the copy is in progress an listing of the destination directory on the Samba server shows that the file is in the directory with the allocated size of 1.9GB. It would appear that perhaps the file is being created and a seek ahead is being done, then the process of coping the file over from the client to the server is begun. Hence a method to preallocate disk space for the new file." He wanted to know why, and whether you could turn this behavior off.

Maulik Desai piped up: "When I used explorer to write a file on samba server (drag & drop) and canceled it before it was completely written, the (corrupt) file still existed in the directory instead of being deleted. It appears that NT handles this correctly by deleting the file if it was canceled before completely written." Was this a Samba bug? Yes, Jeremy Allison answered, if NT handles this case correctly and Samba doesn't. The latter assertion was never really demonstrated during the thread, however.

Richard Sharpe and Dave Collier-Brown went looking for this bug, whether it be client-side or server-side, and concluded that it is an NT-only optimization (Windows95, at least, did not do it). One prevailing theory is that the NT Explorer does this in order to know immediately whether or not a file will fit on a filesystem, so the user won't have to wait for a partial copy that will ultimately be unsuccessful.

Talk turned to how Samba should work around NT's behavior (see last week's coverage for exactly how this "optimization" can mess things up). Jeremy Allison explained, "The client is expliticly setting the file size, then one of the writes into the file is failing (probably with ENOSPC). Now what should Samba do here ? The client explicitly told us what file size to set. Do we then override that and deliberately truncate the file on write fail ? Should we do this ? Opinions please."

Nico Williams had the idea of preventing Samba from creating sparse files in the first place. "The impact on performance would not be nice though," he noted. Dave Collier-Brown thought about trying to check disk space when a file was extended, to anticipate disk-full errors, but Nico Williams pointed out that there was a nice race condition there: the filesystem might fill up between the time Samba checked and the time Samba tried to use it, so this bug would not entirely go away. His next idea was to truncate the file in question when it filled up the disk without being fully written to, so that its size would not be deceptively large.

Luis Claudio Goncalves, at this point, posted a small patch to implement the truncate alternative. It generated a bit of discussion, including a rehash of what Unix sparse file semantics really were. (One gets the feeling, from this whole thread, that many Samba list regulars do not really understand how sparse files work. This is not surprising. Even many longtime Unix users only vaguely know about sparse files. The feature seems to be unique to Unix-like OSes, just like the concept of a setuid bit.)

Any old Unix hand will know all about line endings. MS-DOS text files are supposed to end their lines with the two ASCII characters CR and LF, whereas Unix text files usually just end lines with LF. Mac OS, like the earliest Apple II DOS before it, simply uses CR. Any user of a system that supports file access to/from multiple platforms will run into this incompatibility sooner or later; usually, text files must be converted manually from one format to another, since it is difficult for a computer to divine what is or isn't a "text file", as opposed to a binary file which must not be tampered with. Periodically, the issue comes up on the Samba lists of how to convert text files to and from the MS-DOS line-ending standard. One standard answer: on Windows, just use WORDPAD instead of NOTEPAD, since WORDPAD can work with Unix-style text files. Another common answer: use a preexec script to convert all the files in a share whenever a client mounts the share.

And it came to pass that John Malmberg had an idea, and he spake unto samba-technical, saying: "With the registry calls that you can do now, is it possible or practical to look up the file type in HKEY_CLASSES_ROOT before it is transferred, and if it is registered as a known text type to translate the CR-LF information as the file is being transferred? Just a thought."

Beau Kuiper protested: "A very evil thought. They tried to do that with the linux msdos filesystem support. It really stuffed life up for many people with scilent data corruption. To do the same with samba would be not to learn from the mistakes of others. to be specific: YOU CAN NEVER DETERMINE WHAT IS STORED IN A FILE GIVEN THE NAME OF THE FILE :-)"

John was not deterred. "Windows actually uses two methods of determining a file type. The first is a registry, and the second is to examine the first two bytes of the file for a signature. Some programs use the signature over the file type. Somewhere there is a list of these magic codes, but I can not recall where it is at the moment." He continued, "It would certainly be evil if it was manditory, but it could be very useful as a per-share option." Finally, "Remember the average user thinks all this stuff works by magic." Tim Cole replied, to that last: "/etc/magic ? *evil grin*"

As to the two ways to identify a file, Beau was impressed. "I learn new stuff every day :-). I never knew windows used a second way to identify files." Luke Leighton knew something about it: "it's the storage / streams - structured file storage system. if you have access to the MSDN, look up the CStream and CStorage classes in the MFC source code, and go from there." Presumably this is that infrastructure which is supposed to make efficient use of the NTFS feature of multiple forks per file (like Mac OS, only an arbitrary number of them). Gunnar Degnbol also had some tidbits to add:

I have looked at how Windows determines MIME types. The url is http://msdn.microsoft.com/workshop/networking/moniker/overview/appendix_a.asp.

It can be done using FindMimeFromData(), but it won't work. If the MIME type can't be determined more precisely than 'text/plain' (after considering the type reported by a web server, magic bytes, whether the data looks like a binary or text, and the extension), and the file is associated with an application, the type is set to 'application/octet-stream'. So, for example, a .C file will not be reported as a text file if you have a C++ compiler. Nothing in the registry indicates that it is a text file.

The reasoning behind this behaviour is amazing:

"As an example, this is necessary when downloading, among others, .bat and cmd files, which are plain text files, are frequently identified by the server as 'text/plain', and have no associated MIME type in the registry. Without the final check for an associated application, these would be displayed in-pane, whereas the desired behavior is to launch the command interpreter."

The Internet is just like your hard disk, or your LAN, so when you click on a .BAT file in your integrated file manager/browser you will obviously want to run it before reading it.

I guess this has been fixed many times over (once for each dangerous file type).

Gunnar had a nice parting shot, too: "The average user should not be led to believe it is possible to successfully ignore how computers work."

Steve Langasek was trying to get information from samba-technical about Samba compatibility with Windows 2000. Among other things, he wondered: "I remember catching something last month about Win2k running in "NT4 compatibility mode". Is this still required for domain logins? What about Kerberos 5 support--are we likely to see that in Samba any time soon? :)"

Jeremy Allison had a quick answer: "Well, I intend to add kerb5 support as soon as we get significant user demand for it. I'm trying not to get onto the Microsoft treadmill of adding new stuff to keep up with Windows - that way lies an endless sprint to keep up :-). I expect to get demand for kerb5 as it's such an improved authentication method - but not for a few months yet."

Terry McCoy thought it was easy. "Adding support for kerb5 on platforms that support PAM should actually be just a few lines as long as the machine's PAM configuration is working. We are using Samba (on Solaris 2.6) as an gateway to our AFS file space. By using PAM we are able to compile Samba without having to link in the AFS libraries from Transarc that would be required to do authenticate with AFS's KDC. Instead we just link with --with-pam option." He posted the very minimal changes they had had to make to Samba to get this working.

Several people pointed out that what Terry was doing was quite different from interacting with Windows 2000 Kerberos. He was just authenticating a normal NT client (using unencrypted passwords) with a Kerberos server, whereas what was needed was to accept Kerberos authentication credentials directly from the NT5 client and pass them on to the Kerberos server. Chris Hertel explained even further:

Microsoft is using a proprietary Privilage Authorization Certificate. Note the word "Authorization". Kerberos was originally designed as an Authentication service. PACs were added as an option for K5. Microsoft has (last I heard) chosen not to release info about their PACs.

The upshot is that many, many systems will have trouble. I heard an MBONE multicast of a Q&A session with Vixie the other night. He was explaining that in certain configurations a W2K box will expect to use it's PAC as authoriziation for DynDNS registrations. Of course, a non-W2K DNS server won't recognize the encrypted, proprietary PAC and will drop the request on the floor, logging an unauthorized registration request.

The result will be that the DNS server will be filtering out large numbers (depending upon the network size and number of W2K boxes) of such packets and the W2K boxes won't be getting thier names registred. Instant DoS.

Steve's reaction: "So... how much work goes into figuring out an undocumented PAC?"

Luke Howard replied: "Assar Westerlund, author of Heimdal (a freely available Kerberos V implementation) has done some work decoding the PACs. See the notes in the Heimdal distribution and/or Kerberos mailing list archives." URL, please? Several people knew that one: http://www.pdc.kth.se/heimdal/ and http://www.padl.com/~lukeh/heimdal/ were mentioned.

Greg Dickie posted the following information to samba-ntdom: "I just downloaded vmware 2.0beta for linux and it "looks like" they are packaging samba in with it to provide connectibility between the host and guest OSes. Was anybody aware of this? Does anybody care? I guess its not a bad thing..."

Greg Leblanc explained: "If you bother to read the help that 2.0beta provides when you run vmware-config.pl <grin>, you'll notice that it suggests that you DON'T allow it to set up samba if you already have it running. From the looks of the files that shipped with my VMware install, it doesn't actually include Samba, but probably checks to see if you have samba, and then volunteers to configure it. I heard that VMware has donated a handful (bunch?) of VMware licenses to the Samba gurus so that they can test NT-samba connectivity without so many PeeCees floating around, or so many reboots."

In another message: "I also don't see any documentation/license information for samba. I think I'll take this up with somebody at vmware unless somebody ojbects..." Luke Leighton jumped in: "yes please. samba should ALWAYS be provided with a copy of the GPL license. they are in violation of the GPL license, otherwise."

Greg Leblanc posted back not long after, forwarding a message from the VMWare people. They had written: "Yes, we are shipping a version of samba with VMware. Although it is not available yet on our web site, we are going to have a technote page that describes the filesystem integration using samba, and includes a link to the source diffs. These source diffs are very small and we are hoping that the maintainer of samba and copyright owner, Andrew Tridgell, will incorporate them soon." Later: "Andrew is aware of the project and very supportive of it. I specifically asked him if he wanted a copyright banner displayed as part of the installation, but he declined."

For some reason VMWare chose not to explain why they were shipping Samba without a copy of the GNU General Public License. As Luke said, this would appear to be a license violation.

This was one of those delightful threadlets with a list-defying signal-to-noise ratio. Richard Sharpe had this query for samba-ntdom: "I am trying to do net time \\server /set /yes from a logon scipt that runs from an NT 4.0 WS machine that has joined a Samba 2.0.6 domain. NTW complains that the user does not have a required privilege ..."

Now how often do you see that? Three responses, three completely different approaches to solve the same problem. All signal, no noise. It was beautiful. Your editor was deeply moved. (:

This thread, the 363-kg gorilla of the week, touched on life, the universe, and everything (not necessarily in that order). Nico Williams started it by just posting "just a view from the sidelines" on a few current issues. He thought the proposed TNG code freeze should wait a few weeks; he thought the SYSKEY2 proposal was a good one thanks to the necessity of supporting legacy directory services without strong session encryption. He also thought the merge of TNG features into the stable Samba code base should be pretty easy: just cut 'n' paste certain subsystems, particularly RPC. He finished with the mildly provocative "I think it's safe to say that TNG is so jam-packed with good ideas that it will become the next Samba."

Clearly there was plenty of fodder there for lots of healthy discussion (or flame-warmongering, if one prefers). An image is called to mind of tossing a short treatise on the Five Points of Calvinism into an inter-faith prayer breakfast. It actually wasn't that bad, but one could say Nico's post was a good conversation piece....

Charles Owens was impatient for the new LDAP schema support: "Is there any update available as to when Luke Howard's SAM-via-LDAP-with-win2k-schema will make into the codebase (either TNG or TNG-post-merge) ? Getting a somewhat finalized schema in place seems to me to be a critical milestone for obvious reasons. I need to roll out some more implementations and would much prefer to use the new schema (as would everyone I'm sure ;-)." So Luke Howard gave a status report: "Only the nt5ldap passdb stuff is anywhere near complete. The nt5samrldap stuff is just not done. That's really tricky, and I need to get some serious time to work on that again, and I'm busy the next couple of weeks." Luke Leighton, meanwhile, said of the code: "it's experimental and subject to change."

Jean-François Micouleau disagreed with Nico's suggestion to delay freezing TNG: "NO. freeze Now ! I know Luke well enough to say that if you leave him just a week, he will have a new idea he'll want to code." He also thought Nico was severely oversimplifying the TNG->production merge: "totally unrealistic. You know why ? Because I've done it. And give up. And felt some much depressed than I was close to install win95 on my machines. Merging TNG in HEAD is not much realistic. I also tried, still have a tar.gz of the result somewhere. The only viable path is to extract features of TNG in diff files and incorporate by hand in HEAD." John Koyle agreed about the freeze: "I agree, I've spent about the last 2 weeks just trying to get TNG setup and working properly against an LDAP backend. I've done so many cvs updates my head is spinning. Code compiles then doesn't, etc. Finally, I got it working [...] The point is new people like myself (to TNG) would very much like to test/debug TNG, and it's nearly impossible to do that when there are 30 cvs updates per day." At this point, Luke Leighton made an astonishing statement: "*sigh*. ok, i promise i won't do anything more than bug-fixes, samrtdbd and libsurs work." Was he serious? Luke Leighton?

Nico asked Luke at one point, "Why are you so willing to code up SYSKEY, which we all agree is only necessary for some SAM backend implementations, AND YET you don't want to code up an ACL system that's more reusable than SYSKEY??" Luke's reply: "SYSKEY is 4 lines of code and maybe 10 or 15in strategic place to use it to secure all not, some, SAM impls. an ACL system is an indeterminate number of lines, used in an estimated 100 to 150 places."

Luke L. and Jeremy Allison had some exchange concerning how to merge code between branches. Luke hates the 2.0.x RPC code -- doesn't want to ever see any of it in any future release branch. Jeremy pointed out that there have been quite a few fixes that have gone into the 2.0 branch that Luke's TNG branch hasn't got, and that there are a few things the 2.0 RPC codebase actually does better than the TNG codebase. That sent Luke on a mission: he did some CVS checkouts and diffs, to determine what all has been committed to the 2.0 RPC code that he didn't have in his own branch. Over the course of several messages he analyzed each changed file in terms of what it did better or worse than his own code -- the goal being to eventually be able to debunk Jeremy's claim that the 2.0 code has any continued raison d'être.

Without more than passing familiarity with Microsoft RPC and Samba's implementation thereof, it is impossible to really follow Luke's journey through the CVS archives, but in summary, he seems to have found a few diamonds here and there that he can use; for the most part, though, he dismissed the 2.0 code as obsolete and broken.

Jeremy didn't think he and Luke were talking about the same bits of code at all. "I'm not talking about the functions you are referring to at all. I know the code that implements these in TNG is better and should be used (once reviewed). I am talking about the whole underlying substrate of the rpc_parse stuff, and the way the 2.0.x code handles the PDUs and buffers for the RPC packets. It is this code that is more advanced in 2.0.x, not the server functions." Jean-François apparently agreed. Luke looked again, and saw Jeremy's point. However, he said, "you trust that code and think it's more advanced, because you wrote it, and understand it." Which is hard to argue with, so Jeremy didn't. Instead, he replied: "Well don't get too upset. You want someone to look at your code and review it, and if you've implemented this functionality in a stable mannor, I'd love nothing better than to drop your code right in. I won't do that without looking at it however (which is what I thought you wanted :-)."

Moving on. Luke reaffirmed one reason to have his SYSKEY2 support: "private/smbpasswd can be made world-readable. sounds weird, neh? WAIT - hear me out, before shooting mouths and telling me it's a stupid idea." He elaborated: this way a lot of code wouldn't have to run as root any more. Insert standard run-as-root-or-don't-run-as-root exchange here (see the end of Issue #4, Section #5 -- Andrew Tridgell, for one, believes that Luke puts much too much stock in avoiding running things as root). Nico was blunt: "Trust me: the SAM RPC daemon should always run as root." In other posts he reiterated: "We've already settled that point by having SMBD pass in PID/VUID information with the DCE/RPC calls and storing the user context info in a TDB keyed by PID/VUID. Why rehash this? So the MSRPC daemons will have access to the user context information. They have to implement authorization functionality internally because the objects which most of those MSRPC daemons deal with are NOT Unix kernel objects (files, pipes, Unix sockets, processes, whatever); if those objects are not Unix kernel objects then switching Unix security contexts (euid/egid) HAS NO EFFECT." Andrew Tridgell posted a nice summary of the issue from this same point of view:

We have to decouple the unix security context from the RPC security context. We have the SMB and Unix security contexts coupled in smbd, but we get away with that because we are dealing with objects that the unix kernel knows about so the unix security handling does all the work for us. In msrpcd the situation is quite different as we are manipulating objects that have no parallel in the unix world - so we must not couple the security contexts or we end up relying on protection that the kernel just can't provide.

In NT things are different. There they have the objects in the kernel and the kernel knows how to protect them. The NT kernel security context provides protection of the objects manipulated by msrpc calls so there is no issues as to whether these two contexts should be coupled - they are the same thing. On non-NT systems we must design things quite differently.

Think about the above couple of points carefully Luke. They are central to what you are working on.

Luke's response to most of the above: "because i am not thinking in terms of just NT, here, any more. i'm thinking in terms of a proper dce/rpc full implementation. except, without the thread library, for now." He also said, "if you're suggesting that just because some msrpc service implementations should, in your opinion (and a few others), be run as root, that the entire MSRPC service-running-system must run all services as root, then i have to say, that's silly."

Predictably, this stuff went on for quite awhile. Between Tridge, Nico and a few more supporters that came out of the woodwork, these points were duly made over and over again. One refreshing diversion concerned the NT implimentation of password authentication. Todd Sabin informed the world: "Actually, it's not implemented at kernel level. The \winreg server is contained inside winlogon.exe. Unfortunately, if winlogon.exe exits for some reason (like, umm, someone crashing it), the kernel notices it and actually forces a blue screen itself." In another post: "you can observe this empirically by crashing winlogon interactively. They've been making it harder for power users to do it (gee, I wonder why? :)), but something that has always worked is attaching a debugger to it, and then closing the debugger. That terminates the debuggee."

Oh, and while we're on the subject of weaknesses in Microsoft software, Luke Leighton posted a nice tidbit: "actually, if you add a BDC to a domain using NT4, you can use rpcclient's samsync command to pretend to be that BDC because the trust account password is BDCNAMEUNICODELOWERCASE, and grab the entire SAM database anonymously. the window of opportunity is between when the BDC is added to the domain during the BDC-install stage and when the BDC installation is compelted and yuou are presented , for the first time, with the ctrl-alt-delete box on the BDC. so yes, microsoft allows anonymous users to download the passwords, but not in the way you perceive or describe. the word from microsoft is that microsoft does not consider this to be a serious security risk, by the way. oh, and they've probably fixed it for nt5."

Matthew Geddes had two Samba servers running, and wanted to use them for redundant browse masters. He posted a summary of his configuration to samba-ntdom: both machines were using the parameters

except the second had os level = 60. He asked if the second machine would force (and win) a browser election assuming the first one went down.

No, it will not necessarily force an election. The things that will cause an election are:

A client trying to browse (send GetBackupList) and not getting a response within the timeout.
A backup browser trying to get the browse list from the master and not getting a response.
A server coming up and having prefered master = yes
Maybe something else.

You have not necessarily configured it wrong, but you do not need the preferred master on the second server, as that just forces it to have an election when it comes up, which is useless if the other one is running, I think.

Matthew's other question was about backup domain controller functionality: "does Samba BDC pass all authrentication on to the PDC, or does it cache or store a copy of the SAM?" The latter, answered Richard.

Greg Leblanc added: "I don't know exactly how samba does it, but NT propogates (sp?) changes to the SAM at regular intervals. I think you can even change it in the registry of the PDC, and it is most definately a "push" operation for a strictly NT network." Luke Leighton, sure enough, knew more: "the way it works is that the PDC sends out "delta" notifications on UDP 138 braoadcasts, and the BDCs notice them (hopefully), and do a "pull"of hte SAM using a NetrSamLogon MSRPC call. we have a client-side and server-side netr_sam_logon implementaion in samba tng netlogond and rpcclient, we don't have the UDP 138 notifications."

Greg then pointed out that NT BDC's update their databases when triggered by a "push" operation from the PDC, but Samba PDC's do not issue these, ergo an NT BDC with a Samba PDC probably would not work too well. Luke concurred.

Cord-H. Fricke was interested in letting his users drag their Netscape Navigator profiles around their NT network automatically. He posted this question to samba-ntdom.

Aaron Brooks and Todd Pfaff both suggested an interesting tactic: tell Netscape on NT to look in your Unix home directory for its profile; assuming you arrange to have your home directory mounted on each NT box you log into, this will work. Todd went into some detail:

after installing netscape on an nt workstation, set these registry keys:

  \Registry\Machine\SOFTWARE\Netscape\Netscape Navigator\Users =
    CurrentUser = Default
    Default
        DirRoot = h:\.netscape
        UserName =
        EmailAddr =

then add something like this to your nt workstation logon script:

  rem copy netscape preferences file if it doesn't exist.
  if not exist H:\.netscape md H:\.netscape
  if not exist H:\.netscape\prefs.js xcopy /f /v
    s:\netscape\users\default\prefs.js H:\.netscape\

this will create a default h:\.netscape profile directory at user logon if it does not yet exist. you could also do a little more work to, for example, merge global changes to the netscape preferences into each user's h:\.netscape\prefs.js.

h: is mapped to the user's unix/nt shared home directory on a samba server. h:\.netscape is then shared by netscape in both unix and nt environments. as far as i know, this is working fine as of netscape 4.7 (at least no one has complained to me about problems with their netscape preferences when moving between the two platforms).

In addition, Aaron noted: "Another alternative, actually a set of alternatives, is to use Netscapes roaming profile configuration. This can be implemented either via LDAP or an Apache module. Due to how Netscape implements this, however, it seems to be less reliable. Plus, these methods make the system less maintainable since they are not part of the filesystem."

Next question: how a user can get a new profile automatically when first logging in. Todd's solution above seems to have addressed this already, but Andy Polyakov volunteered another solution:

If your setup is policy driven (NTconfig.POL on DC's netlogon share), then consider throwing following to CLASS USER section:

    CATEGORY "Netscape"
      KEYNAME "Software\Netscape\Netscape Navigator\UserInfo"
      POLICY "Freeze Profile location"
         VALUENAME "ProfileDirectory"
         VALUEON "Z:\.nt\Netscape\profile"
         ACTIONLISTON
            KEYNAME "Software\Netscape\Netscape Navigator\UserInfo"
               VALUENAME "DirRoot"
               VALUE "Z:\.nt\Netscape\profile"
         END ACTIONLISTON
         PART "Bind Netscape profile to Z:\.nt" TEXT
         END PART
      END POLICY ; Freeze Profile location
   END CATEGORY ; Netscape

It's based upon http://help.netscape.com/kb/consumer/19990708-9.html.

Martin Lorenz put an urgent problem before samba-ntdom: "my boss wants me to get a NT domain-controller up and running by friday next week and i definitely want to do this with samba under linux. the main problem is: he wants to have three different domains managed by one server. how do i do this?"

Luke Leighton had a good laugh. "and he wanted it to be done with NT? HA! lovely :) that tickles me, that does." He and Seth Vidal both suggested running three separate smbd processes on three separate IP numbers. Not an uncommon configuation, at least with Samba. (Not possible with NT, as far as anyone knows. Unless perhaps one could run multiple instances of NT under VMWare. Essentially one would be using VMWare much like its namesake, VM, IBM's recursive OS for mainframes.)

Then Robert Magier reported that starting multiple smbd processes didn't work: only one would start. After some traffic between him and Seth, trying to debug the situation, it came to light that all the smbds wanted to use the same PID file. Separate PID files solved the problem.


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

1.	2 Feb 2000 - 8 Feb 2000	(65 posts)	The Rise and Fall of a Crypto Proposal
2.	3 Feb 2000 - 8 Feb 2000	(28 posts)	The Quota Problem Again
3.	5 Feb 2000 - 8 Feb 2000	(21 posts)	Automatic Line-Ending Conversion?
4.	6 Feb 2000 - 10 Feb 2000	(13 posts)	The Microsoft Kerberos Implementation
5.	7 Feb 2000	(8 posts)	Another GPL Violation?
6.	7 Feb 2000	(4 posts)	Setting System Time on NT
7.	8 Feb 2000 - 10 Feb 2000	(115 posts)	The Amazing, All-Purpose Thread!
8.	8 Feb 2000	(9 posts)	Browsing Semantics, and BDC Auto-Updating
9.	9 Feb 2000	(8 posts)	How to Share Netscape Profiles, Cross-Platform
10.	11 Feb 2000	(14 posts)	Another Simultaneous-Multi-Domain Question

Samba Traffic #12 For 16 Feb 2000

By Peter Samuelson