Kernel Traffic
Latest | Archives | People | Topics
Wine
Latest | Archives | People | Topics
GNUe
Latest | Archives | People | Topics
Czech
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic
 

Samba Traffic #2 For 7 Dec 1999

By Peter Samuelson

Table Of Contents

Introduction

Anyone who was following Linux kernel development two years ago has heard this one before: how long is too long? As with many free software projects, the kernel was going through a period of development, adding lots of new features and restructuring things, in preparation for the new major version, 2.2.0, and this cycle took about two years. Naturally, with all the new optimizations, new drivers, new architectures, etc., people started getting restless for the stable release to happen. But it is evidently the nature of software developers that most of them prefer adding new features over stabilizing old features, so these cycles can tend to draw themselves out much longer than intended.

This same phenomenon is happening now in the Samba world. The NT Primary Domain Controller (PDC for short) functionality was forked off as BRANCH_NTDOM in the master CVS tree something over a year ago, early in the Samba 1.9.18 series. Some of that code made it into the Samba 2.0.x releases; specifically, the code that allows Windows95 (including its bastard service pack, Windows98) clients to join a Samba domain is considered stable in 2.0. However, the real action is happening in the 2.1.0 prealpha code, where NT clients are now allowed to play as well. (Supporting NT clients, it seems, is completely different from and much harder than the other sort.) The other happening scene is getting Samba to play well with Windows 2000, and again, this is only going on in the unstable branch of code.

(Actually, Samba 2.0 does include some NT-to-NT domain code, but it is old, unmaintained and considered unreliable. About a year ago, Luke Leighton actually removed this code from the 2.0 CVS branch, because, as he reasoned at the time, he didn't want to give Microsoft an excuse to say "Don't use Samba, it can damage your NT machines" -- a true statement -- in their Knowledge Base. Someone (Tridge, maybe? can't recall) convinced Luke to reverse that patch, restoring the "broken" functionality. It should also be noted that there do exist success stories of using this code in production, though the Samba team strongly advises against doing so.)

Apparently there are a lot of shops out there (your editor works at one of them) that would really like to get rid of NT in favor of Unix for their domain controllers, but are wary of running "pre-alpha" code in production. The Samba team has so far not given any timelines for when this will be possible, according to many reports, the CVS Samba is already stable enough to use in some of these circumstances. Whenever the sparkling new stable release happens, it will surely be greeted with enthusiasm.

Mailing List Stats For This Week

We looked at 461 posts in 1005363K.

There were 248 different contributors. 66 posted more than once. 109 posted last week too.

The top posters of the week were:

1. Emulation of NT Network Client Tools, And a Little Microsoft-Bashing

26 Nov 1999 - 29 Nov 1999 (30 posts) Archive Link: "vote / opinions required on rpcclient"

People: Luke LeightonAlan HourihaneTim PotterGreg DickieTodd SabinMarty LeisnerBeau KuiperSteve Langasek

Luke Leighton has recently been hacking on rpcclient, which (as the name implies) is a way to send Microsoft RPC requests from the command line. rpcclient can do a wide variety of useful things, such as adding users to a domain. In the Windows world, this functionality is handled by several programs, so Luke asked the world at large (that is, the world of samba-technical and samba-ntdom):

i need to know whether people think it would be a good idea to retire rpcclient in favour of the following command suite:

net
usrmgr
srvmgr
regedit
eventvwr
cmdat

basically, a suite of programs that match nt's .EXE equivalents.

There were a lot of varied suggestions. Many people liked rpcclient already; others wanted the NT-like programs. Others thought Luke meant to write GUI-driven client programs, which turned out not to be the case (he does not even use X). Alan Hourihane wanted both: "I would love to see windows .exe's. But rpcclient is great for automating routines. So I'd like both. Very Greedy - I know." Greg Dickie wanted wrapper scripts that use rpcclient "under the covers". Tim Potter expanded on this: "You could always do the check the name of argv[0] and have the executable behave differently depending on the name it was invoked as trick. Not sure how portable this is though." Steve Langasek (self-described as a "postmodern programmer") reminded us all that ARGV and ARGC are specified by ANSI C, which makes quite as portable as anything need be anymore. But in any case, said Greg, "Just please don't break command line rpcclient to make it more NT'ish!"

Todd Sabin wanted a library-based approach. Luke was one step ahead: "already working on it. [...] the api you are asking for is already done. you want to write a gnume regedit? be my guest." Todd grinned. "Cool. That's what I get for looking at week old code. :)" He also said he was considering writing the GUI-based bits himself.

Marty Leisner, a one-time regular who hasn't been on the scene much recently, did not want a Unix command "net". His preamble out of the way, he then went off into an unrelated bug report: Samba 2.0.5a managed to crash NT's SERVICES.EXE. He went on about the NT machine in question: "The machine is in a very odd state now (can't do anything, no BSOD, trying to reboot...can't seem to...finally did... Such pleasant software..." Luke sympathized, "isn't nt just?" As to the bug report, he was unsurprised: "that's normal. i suggest you report it on ntbugtraq and securityfocus. don't mention my name: after i sent in a report to ntbugtraq, certain people at microsoft went absolutely nuts. i mean, acted like no-one had told them about this sort of thing, before, and how irresponsible i was for telling people publicly what has been known by other certain people for a long time." Finally, Luke asked for a network trace, to track down the Samba half of the bug. Beau Kuiper agreed about Microsoft server programs being fragile in the face of invalid data, and pleaded: "Microsoft, for once in your life, try to get windows 2000 right this time. I don't think you customers will be very pleased to have the same service pack mess NT 4 has had. [...] Sigh, I don't think this will happen, though."

2. Status of NT Domain Controller Code

28 Nov 1999 - 30 Nov 1999 (13 posts) Archive Link: "Samba 2.0.6 PDC - almost there, but stuck for now"

People: Tim O'BrienDetlef MaurelKevin ColbyAndrew Perrinlluisma

Tim O'Brien decided to try PDC functionality from Samba 2.0.6. Several things didn't seem to be working right from the NT (client) end of things. He also asked the Great Ones of samba-ntdom:

How do I use the following smb.conf parameters (IE: What goes there? A path? A user name? What? The man pages tell nothing useful on this):

 domain groups
 domain admin group
 domain guest group
 domain admin users
 domain guest users

Detlef Maurel explained, "if you put "domain admin group = root" into your "smb.conf" any user who is in the group root on the unix system will get administrative privileges on the NT machine." The "domain guest group" works the same, it seems, and "domain admin users" and "domain guest users" as well, except with lists of users.

Kevin Colby reminded everyone, "just for the record, PDC stuff is mostly only in the 2.1.x source branch. It is available via CVS as explained in the docs, and via FTP at http://sernet.pair.com/" . This confused Hauke Fath, who asked for a general explanation of what functionality was where. Andrew Perrin replied:

The 2.1 series (also known as the head branch), available via cvs, contains up-to-the-minute development code for PDC support. Most of what you see discussed on this list pertains to the 2.1 series.

My understanding is that the BRANCH_NTDOM cvs code is no longer applicable, as PDC code was rolled into the main development branch.

The 2.0.x series (at least where x > 3a) DOES support LIMITED PDC functionality, but not in an 'official' way. This PDC functionality, however, includes NT, 95, and 98 domain logins, roaming profiles, and group memberships, which (for our site at least) are the main benefits of domainhood. Do NOT let anyone tell you that the 2.0.x series will not support NT domain logins - it's simply not true.

lluisma added another limitation of the Samba 2.0 series, and gave some good technical information: "Also in Samba 2.0.6 there is no support for WINS replication (even between two samba wins servers) as well as Backup Domain Controller (PDC). Also by Microsoft design an NT PDC is always at the same time the domain master browser. This means you can not have NT PDC with Samba domain master browser. If you have a mixture of NT and win98/95 clients, you must use NT server as your PDC, unless you use workgroups instead of domains. You can however use Samba as your WINS server even with a mixture of NT/win98/95 clients. But if you use Samba as your WINS server then this is the only WINS server you can use for your whole domain. Because there is no WINS replication support yet. However Samba WINS server is very reliable. I would bet my life on one Samba WINS server than 5 NT WINS servers, for example. Remember WINS communication is point-to-point and no directed broadcasts, which is good and is the best solution for a domain comprising multiple subnets."

3. Security Risk With Private DOMAIN.TRUST_ACCT.mac Files

29 Nov 1999 (1 post) Archive Link: "security risk with private DOMAIN.TRUST_ACCT.mac files"

People: Luke Leighton

This was just a single post by Luke Leighton, but worth reading:

i have seen people reporting log files that show .mac files to be in the /etc/ directory.

if these files are world-readable then there is a risk that these files can be used to compromise the security of your PDC (i.e use them to obtain user SMB password hashes, or do a brute-force login attack).

please therefore read the following carefully.

IF you have DOMAIN_NAME.TRUST_ACCT.mac files in /etc (or any other world-readable directory) AND

IF a ls -al /etc/*.mac shows that you have permissions other than rw-------, or an owner other than root, THEN:

please report, direct to myself at lkcl@samba.org and NOT to the above lists:

any information received will remain confidential and will enable me to report to any samba distributors that they correct their (or our :-) samba installation scripts, and to create an appropriate bugtraq report, if necessary.

if you find that these files are not root-owned or do not have the correct permissions, do this:

chown root /etc/*.mac
chmod go-rwx /etc/*.mac

IF these files are owned by root AND are not world-readable, THEN:

there is no risk to the security of your Samba Domain. except of course if you don't trust root.

there is a very good reason why the samba team decided to put these files in /usr/local/samba/private (the default permissions on the private/ directory is rwx- to root only).

4. Samba 2.0.x and Windows 2000

2 Dec 1999 - 3 Dec 1999 (4 posts) Archive Link: "WIN 2K and Samba 2.0.5a"

People: Bill JojoLuke Leighton

Bill Jojo was attempting to generate some chemistry between Windows 2000 RC2 and a Samba 2.0.5a PDC, to no avail. On the samba list, he listed the steps he had tried so far. He is clearly not a beginner: "we already have 600 NT4sp4 stations talking to it." Luke Leighton filled in the standard Samba-2.0-NT-PDC scoop:

chances of getting 2.0.x as a pdc to win2k workstations: zero. in fact, negative, because i am going to kick up a stink if anyone says, "hey i just ported the samba 2.1prealpha code that gets win2k to join a domain, here's the patch!".

almost a year ago i actually removed all the nt PDC code from 2.0.x, and it was put back in.

i did not, and i do not want to see samba 2.0.x as a PDC, ever. the MSRPC code base is now well over a year old, and it was only set up experimentally, anyway.

if you want a PDC that works with nt5, use the latest cvs code. you will find that all sorts of other things work, too. microsoft has made their MSRPC code SEVERELY more robust than nt4 MSRPC code, and as samba is a network-reverse-engineering project, we can only work from existing netmon traces. the new versions of nt5 show us new things about the MSRPC services, and i do NOT want to see those back-ported to samba 2.0.x.

time to move on. the split for 2.0.x and 2.1prealpha was well over a year ago, and that's way, way too long.

Bill replied, "Thanks so much for the reply. It clears up a great deal for me. I've used the CVS code before, but since we're production with 4600 student accounts and 600 workstations, I can't in good conscience use "prealpha" code in our student environment." Luke understood the difficulty, and started to suggest a hybrid approach, where file service was from Samba 2.0 and domain services from Samba 2.1, then remembered: "then again, if you use win2k it doesn't matter if the target is a pdc or not: if it's 2.0.x, you will run into difficulties with the 2.0.x msrpc code."

5. NIS+ Support Questions

19 Nov 1999 - 30 Nov 1999 (4 posts) Archive Link: "nisplus backend support"

People: Jerry CarterDavid Davis

James Harris runs Solaris with NIS+, Sun's famous troublesome yet powerful directory service. He wanted to integrate it with Samba, particularly with regards to synchronizing user info between the two systems. He noticed that you can "enable NIS+ support" but couldn't find any documentation on this. He asked samba-ntdom for pointers.

Jerry Carter redirected things to samba-technical, since this doesn't have a great deal to do with NT domain code. He wasn't sure about NIS+ support either: "ummm...is anyone using a NIS+ SMB password backend on the list? What is the status? I know we're all moving towards LDAP :-), but..." David Davis, for one, hadn't switched to LDAP yet: "We are using NIS+ also. We have written a shell hack using AdminSuite to sync passwords. I would like to see more NIS+ support. But if LDAP becomes more robust we might consider the change." James replied that he was looking for something better than a "shell hack", and (like the others) didn't see a compelling reason to move to LDAP. The thread was short and rather inconclusive, as it turned out.

 

 

 

 

 

 

Sharon And Joy
 

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.