RE: Auth question.
I'm pretty sure that Kerberos uses port 88, but that's just for authentication. Port 445 is used for connecting to shares. We've been running tests blocking ports. With ports 137 - 139 and 445 blocked for UDP and TCP, the join fails but the computer name is still entered in the AD. With just ports 137 - 139 blocked (445 enabled), the join succeeds and all client share operations seem to function correctly as long as there is no NetBIOS name resolution involved. Hope this helps. Ken -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Christopher R. Hertel Sent: Wednesday, January 22, 2003 1:42 AM To: Andrew Bartlett Cc: [EMAIL PROTECTED] Subject: Re: Auth question. On Wed, Jan 22, 2003 at 05:30:45AM +, Andrew Bartlett wrote: > On Tue, Jan 21, 2003 at 09:13:38PM -0600, Christopher R. Hertel wrote: > > I *think* it's a rule that Kerberos authentication is always used > > with > > SMB over TCP (port 445) and that Kerberos is *not* used with SMB over NBT > > (port 139). > > > > Am I wrong? > > I think you are wrong. As far as I know there is no per-port stuff. Quite possibly. That's why I asked. :) ...but which clients would actually do this, and under what conditions? Of the Windows clients and servers, only W2K and XP-pro know how to work with Kerberos (does /Me handled Kerberos auth?). I *imagine* that those systems use port 445 instead of 139 whenever they can. If both client and server know how to handle Kerberos then they likely also know how to use port 445. So, unless I'm totally insane, the likelihood of Kerberos auth being used over port 139 is low. Totally Insane -)- -- Samba Team -- http://www.samba.org/ -)- Christopher R. Hertel jCIFS Team -- http://jcifs.samba.org/ -)- ubiqx development, uninq. ubiqx Team -- http://www.ubiqx.org/ -)- [EMAIL PROTECTED] OnLineBook -- http://ubiqx.org/cifs/-)- [EMAIL PROTECTED]
Bug in nmbd_become_dmb.c (CVS 1.7 3.somehting) [patch]
I dont know if this is the rigth list for this..
I'm using the latest samba 3.x. from CVS.. (because of the wins replication)
I have it set up as master browser, but it wont register itself (to the WINS
server running in the same nmbd) as DMB (WROKGROUP#1b..)
I played arround the code a bit and filay did this:
Index: nmbd_become_dmb.c
===
RCS file: /cvsroot/samba/source/nmbd/nmbd_become_dmb.c,v
retrieving revision 1.17
diff -u -r1.17 nmbd_become_dmb.c
--- nmbd_become_dmb.c 12 Nov 2002 23:15:49 - 1.17
+++ nmbd_become_dmb.c 22 Jan 2003 11:00:56 -
@@ -375,7 +375,7 @@
add_logon_names();
/* Do the domain master names. */
- if(lp_server_role() == ROLE_DOMAIN_PDC)
+ if (lp_domain_master() == True)
{
if(we_are_a_wins_client())
{
Now it works..
I have no idea if this is the right wayto do it, but ROLE_DOMAIN_PDC is set
only if the config says it so (and I dont wat it)..
Plus 'lp_domain_master()' answers True if nmbd should be PDC.. so no
functionalyty should be lost..
q:)
-Zobo
Re: Bug in nmbd_become_dmb.c (CVS 1.7 3.somehting) [patch]
I looked at the log of this file and found: revision 1.12 date: 2001/08/24 19:21:40; author: tpot; state: Exp; lines: +1 -1 Only register the #1b name if we are ROLE_DOMAIN_PDC rather than lp_domain_master() .. Guess I dont know some things, or somebody made a mistake.. -Z
Re: Auth question.
On Wed, Jan 22, 2003 at 12:41:34AM -0600, Christopher R. Hertel wrote: > On Wed, Jan 22, 2003 at 05:30:45AM +, Andrew Bartlett wrote: > > On Tue, Jan 21, 2003 at 09:13:38PM -0600, Christopher R. Hertel wrote: > > > I *think* it's a rule that Kerberos authentication is always used with > > > SMB over TCP (port 445) and that Kerberos is *not* used with SMB over NBT > > > (port 139). > > > > > > Am I wrong? > > > > I think you are wrong. As far as I know there is no per-port stuff. > > Quite possibly. That's why I asked. :) > > ...but which clients would actually do this, and under what conditions? > > Of the Windows clients and servers, only W2K and XP-pro know how to work > with Kerberos (does /Me handled Kerberos auth?). I *imagine* that those > systems use port 445 instead of 139 whenever they can. If both client and > server know how to handle Kerberos then they likely also know how to use > port 445. > > So, unless I'm totally insane, the likelihood of Kerberos auth being used > over port 139 is low. Samba 3.0 listening on 139 only. This can and does happen. Firewall rules, or anything else that makes the 445 connect fail. I would not attempt to draw this genralisation in a published work ;-) Andrew Bartlett
FW: [Ethereal-dev] New Features: SMB RTT statistics and TopTalkers
New feature added to Ethereal, available via their CVS. SMB Round Trip Time calculation. It will be in the next release after 0.9.9. (Screen shot attached. MUST SEE!) -Original Message- From: Ronnie Sahlberg [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 21, 2003 8:31 PM To: [EMAIL PROTECTED] Subject: [Ethereal-dev] New Features: SMB RTT statistics and TopTalkers Due to popular demand, I have checked in two new features: SMB RTT statistics similar to the ones already in ethereal for ONC-RPC Calculates Min/Max/Average response times for SMB packets with a breakout for Transaction2 and NT-Transaction subcommands Supported both for tethereal and ethereal try tethereal ... -z smb,rtt TopTalkers: IO-Users Calculates number of frames/bytes in each direction and total number of bytes/frames for all conversations and presents it as a list sorted by total number of frames. Supports Ethernet/IP/TokenRing Only implemented for tethereal right now. See manpage for tethereal or try tethereal ... -z io,users,ip ___ Ethereal-dev mailing list [EMAIL PROTECTED] http://www.ethereal.com/mailman/listinfo/ethereal-dev smbrtt.png Description: Binary data
Trash can patch
Hi, I found a trash can patch quite some time ago on the Internet and managed to get it to work with the latest Samba source. Got a friend who runs a fairly large network and is interested in using such a patch. I'm a little worried about it getting used because it hasn't been tested thoroughly. I figure the best way to get it working better is to let people know where they can get it if they want to try it. http://leederville.net/samba/ Please note, I'm not the original author of it, I can't find who it was. So if the original author could contact me, that'd be great. Cheers Joe
Re: DOS mode bits missing from Folders
Why not store DOS bit modes in an accompanying dot file? (The DOS modes then read by smbd if it (the dot file) exists) Ron ;) On Monday, January 20, 2003, at 10:04 AM, Gerald (Jerry) Carter wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 14 Jan 2003, Esh, Andrew wrote: I have a question about the following piece of code in HEAD smbd/dosmode.c, at line 139: if (S_ISDIR(sbuf->st_mode)) result = aDIR | (result & aRONLY); This causes the DOS mode "HSA" Hidden, System, and Archive bits to be stripped off if a folder is being processed. This makes it impossible to store these bits on a Samba server. Windows allows them to be stored for folders, except for the "S" System bit. Why are these bits being stripped off folders? Shouldn't it be: if (S_ISDIR(sbuf->st_mode)) result |= aDIR; When I made that change, folders began to retain DOS bits like the ones stored on Windows do. The e(X)exute bits are special on folders. For example, if you remove the archive (user 'x' bit) from a directory, you will not be able to change to that directory. The DOS mode bit stuff really needs a better solution. cheers, jerry -- Hewlett-Packard- http://www.hp.com SAMBA Team -- http://www.samba.org GnuPG Key http://www.plainjoe.org/gpg_public.asc ISBN 0-672-32269-2 "SAMS Teach Yourself Samba in 24 Hours" 2ed "You can never go home again, Oatman, but I guess you can shop there." --John Cusack - "Grosse Point Blank" (1997) -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.0 (GNU/Linux) Comment: For info see http://quantumlab.net/pine_privacy_guard/ iD8DBQE+LDpKIR7qMdg1EfYRAvkiAJ9cA8Gm9t9iPSBeYudtluJxJRuZ6ACfT3k7 ExM1uo7m6Eaf5RGXO6Y8wLQ= =WSgs -END PGP SIGNATURE-
[PATCH] parameter 'passwd chat timeout'
The 'passwd chat' script currently has a hard coded 2 second timeout
that it uses when waiting for a response. This is too small for us
since we propogate the password to a corporate meta-directory via java,
soap and ssl (which takes 10 seconds on a clear day).
Is there any performance/usability reason why this timeout has been
kept small ?
Attached is a patch for 2.2.7a and HEAD for the parameter 'passwd
chat timeout' that allows this timeout to be adjusted. The default
value for this parameter is kept at 2 seconds.
Jeff McElroy
Index: source/param/loadparm.c
===
RCS file: /cvsroot/samba/source/param/loadparm.c,v
retrieving revision 1.475
diff -u -r1.475 loadparm.c
--- source/param/loadparm.c 13 Jan 2003 13:03:24 - 1.475
+++ source/param/loadparm.c 22 Jan 2003 17:31:34 -
@@ -279,6 +279,7 @@
int restrict_anonymous;
int name_cache_timeout;
param_opt_struct *param_opt;
+ int passwd_chat_timeout;
}
global;
@@ -1110,6 +,7 @@
{"winbind enum users", P_BOOL, P_GLOBAL, &Globals.bWinbindEnumUsers, NULL,
NULL, FLAG_ADVANCED | FLAG_DEVELOPER},
{"winbind enum groups", P_BOOL, P_GLOBAL, &Globals.bWinbindEnumGroups, NULL,
NULL, FLAG_ADVANCED | FLAG_DEVELOPER},
{"winbind use default domain", P_BOOL, P_GLOBAL,
&Globals.bWinbindUseDefaultDomain, NULL, NULL, FLAG_ADVANCED | FLAG_DEVELOPER},
+ {"passwd chat timeout", P_INTEGER, P_GLOBAL, &Globals.passwd_chat_timeout,
+NULL, NULL, FLAG_BASIC},
{NULL, P_BOOL, P_NONE, NULL, NULL, NULL, 0}
};
@@ -1453,6 +1455,8 @@
Globals.bUseSpnego = True;
string_set(&Globals.smb_ports, SMB_PORTS);
+
+ Globals.passwd_chat_timeout=2000; /* In milliseconds */
}
static TALLOC_CTX *lp_talloc;
@@ -1827,6 +1831,7 @@
FN_GLOBAL_BOOL(lp_hide_local_users, &Globals.bHideLocalUsers)
FN_GLOBAL_BOOL(lp_algorithmic_rid_base, &Globals.bAlgorithmicRidBase)
FN_GLOBAL_INTEGER(lp_name_cache_timeout, &Globals.name_cache_timeout)
+FN_GLOBAL_INTEGER(lp_passwd_chat_timeout, &Globals.passwd_chat_timeout)
/* local prototypes */
Index: source/smbd/chgpasswd.c
===
RCS file: /cvsroot/samba/source/smbd/chgpasswd.c,v
retrieving revision 1.100
diff -u -r1.100 chgpasswd.c
--- source/smbd/chgpasswd.c 15 Jan 2003 22:15:07 - 1.100
+++ source/smbd/chgpasswd.c 22 Jan 2003 17:31:37 -
@@ -245,7 +245,9 @@
if (strequal(expected, "."))
return True;
- timeout = 2000;
+ timeout=lp_passwd_chat_timeout();
+ DEBUG(100, ("expect: passwd_chat_timeout=%d\n", timeout));
+
nread = 0;
buffer[nread] = 0;
diff -uwrB samba-2.2.7a.dist/source/param/loadparm.c
samba-2.2.7a/source/param/loadparm.c
--- samba-2.2.7a.dist/source/param/loadparm.c Tue Dec 10 14:58:15 2002
+++ samba-2.2.7a/source/param/loadparm.cTue Jan 21 20:18:53 2003
@@ -286,6 +286,7 @@
BOOL bUseMmap;
BOOL bUnixExtensions;
int name_cache_timeout;
+ int passwd_chat_timeout;
}
global;
@@ -1118,6 +1119,7 @@
{"winbind enum users", P_BOOL, P_GLOBAL, &Globals.bWinbindEnumUsers, NULL,
NULL, 0},
{"winbind enum groups", P_BOOL, P_GLOBAL, &Globals.bWinbindEnumGroups, NULL,
NULL, 0},
{"winbind use default domain", P_BOOL, P_GLOBAL,
&Globals.bWinbindUseDefaultDomain, NULL, NULL, 0},
+ {"passwd chat timeout", P_INTEGER, P_GLOBAL, &Globals.passwd_chat_timeout,
+NULL, NULL, FLAG_BASIC},
{NULL, P_BOOL, P_NONE, NULL, NULL, NULL, 0}
};
@@ -1467,6 +1469,8 @@
*/
interpret_coding_system(KANJI);
+
+ Globals.passwd_chat_timeout=2000;
}
static TALLOC_CTX *lp_talloc;
@@ -1822,6 +1826,7 @@
FN_LOCAL_CHAR(lp_magicchar, magic_char)
FN_GLOBAL_INTEGER(lp_winbind_cache_time, &Globals.winbind_cache_time)
FN_GLOBAL_BOOL(lp_hide_local_users, &Globals.bHideLocalUsers)
+FN_GLOBAL_INTEGER(lp_passwd_chat_timeout, &Globals.passwd_chat_timeout)
/* local prototypes */
diff -uwrB samba-2.2.7a.dist/source/smbd/chgpasswd.c
samba-2.2.7a/source/smbd/chgpasswd.c
--- samba-2.2.7a.dist/source/smbd/chgpasswd.c Tue Jan 21 19:32:42 2003
+++ samba-2.2.7a/source/smbd/chgpasswd.cTue Jan 21 23:36:13 2003
@@ -239,7 +239,8 @@
if (strequal(expected, "."))
return True;
- timeout = 2000;
+ timeout=lp_passwd_chat_timeout();
+ DEBUG(100, ("expect: passwd_chat_timeout=%d\n", timeout));
nread = 0;
buffer[nread] = 0;
Re: Auth question.
On Wed, Jan 22, 2003 at 06:14:49AM -0500, Ken Cross wrote: > I'm pretty sure that Kerberos uses port 88, but that's just for > authentication. Port 445 is used for connecting to shares. > > We've been running tests blocking ports. With ports 137 - 139 and 445 > blocked for UDP and TCP, the join fails but the computer name is still > entered in the AD. With just ports 137 - 139 blocked (445 enabled), the > join succeeds and all client share operations seem to function correctly > as long as there is no NetBIOS name resolution involved. > > Hope this helps. Thanks, Ken, but it's not really what I'm trying to figure out. The problem, though, is in my presentation of the question. More... On Wed, Jan 22, 2003 at 02:26:43PM +, Andrew Bartlett wrote: > On Wed, Jan 22, 2003 at 12:41:34AM -0600, Christopher R. Hertel wrote: > > So, unless I'm totally insane, the likelihood of Kerberos auth being > > used over port 139 is low. > > Samba 3.0 listening on 139 only. This can and does happen. Firewall > rules, or anything else that makes the 445 connect fail. I would not > attempt to draw this genralisation in a published work ;-) What I am trying to do is understand the relationship between the different authentication types and the different transports. It's not the ports, per. se., that I'm interested in (139 vs. 445), but the relationship between the different implementations and the different auth types. >From a Windows perspective, Kerberos Auth is tied in with Active Directory. I suspect, then, that only W2K and WXP.pro can cope with Kerberos auth. I would also suspect that other Windows systems can't. (I don't know about /Me or /XP.home). XP.pro and W2K are also the only Windows systems of which I'm aware that can do SMB over naked TCP transport on port 445. So, from a simple perspective, there is a relationship between SMB over naked TCP and Kerberos Auth. That relationship is that the Windows systems that can handle the former can handle the latter. Anyway, I'm just trying to gain a better sense of that relationship and its limits. This helps. Thanks! Chris -)- -- Samba Team -- http://www.samba.org/ -)- Christopher R. Hertel jCIFS Team -- http://jcifs.samba.org/ -)- ubiqx development, uninq. ubiqx Team -- http://www.ubiqx.org/ -)- [EMAIL PROTECTED] OnLineBook -- http://ubiqx.org/cifs/-)- [EMAIL PROTECTED]
Re: DOS mode bits missing from Folders
On Wed, 22 Jan 2003, Pagani Jr, Ronald wrote: > Why not store DOS bit modes in an accompanying dot file? (The DOS > modes then read by smbd if it (the dot file) exists) this idea has already been bitten to death. When you backup files, you have to backup the dot file. Renaming is more complex. What does happen if you delete the file from the unix side and create a new file with the same name ? A more elegant solution is to use EA. J.F. > On Monday, January 20, 2003, at 10:04 AM, Gerald (Jerry) Carter wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > On Tue, 14 Jan 2003, Esh, Andrew wrote: > > > >> I have a question about the following piece of code in HEAD > >> smbd/dosmode.c, > >> at line 139: > >> > >>if (S_ISDIR(sbuf->st_mode)) > >>result = aDIR | (result & aRONLY); > >> > >> This causes the DOS mode "HSA" Hidden, System, and Archive bits to be > >> stripped off if a folder is being processed. This makes it impossible > >> to > >> store these bits on a Samba server. Windows allows them to be stored > >> for > >> folders, except for the "S" System bit. > >> > >> Why are these bits being stripped off folders? > >> > >> Shouldn't it be: > >> > >>if (S_ISDIR(sbuf->st_mode)) > >>result |= aDIR; > >> > >> When I made that change, folders began to retain DOS bits like the > >> ones > >> stored on Windows do. > > > > The e(X)exute bits are special on folders. For example, if you remove > > the > > archive (user 'x' bit) from a directory, you will not be able to > > change to > > that directory. > > > > The DOS mode bit stuff really needs a better solution. > > > > > > > > cheers, jerry > > -- > > Hewlett-Packard- http://www.hp.com > > SAMBA Team -- http://www.samba.org > > GnuPG Key http://www.plainjoe.org/gpg_public.asc > > ISBN 0-672-32269-2 "SAMS Teach Yourself Samba in 24 Hours" 2ed > > "You can never go home again, Oatman, but I guess you can shop there." > > --John Cusack - "Grosse Point Blank" (1997) > > > > > > -BEGIN PGP SIGNATURE- > > Version: GnuPG v1.2.0 (GNU/Linux) > > Comment: For info see http://quantumlab.net/pine_privacy_guard/ > > > > iD8DBQE+LDpKIR7qMdg1EfYRAvkiAJ9cA8Gm9t9iPSBeYudtluJxJRuZ6ACfT3k7 > > ExM1uo7m6Eaf5RGXO6Y8wLQ= > > =WSgs > > -END PGP SIGNATURE- > > > > >
[PATCH] Winbind IDMAP Backend rearchitecture
Ok, I'm posting this on Anthony's behalf. Corporate legal blabla blabla blablaladl )U@#)# Yes, we're working on getting him approval to post code directly :-| Jim McDonough IBM Linux Technology Center Samba Team 6 Minuteman Drive Scarborough, ME 04074 USA [EMAIL PROTECTED] [EMAIL PROTECTED] Phone: (207) 885-5565 IBM tie-line: 776-9984 - Forwarded by Jim McDonough/Portland/IBM on 01/22/2003 04:59 PM - Anthony Liguori To: Jim McDonough/Portland/IBM@IBMUS, Steven French/Austin/IBM@IBMUS 01/22/2003 04:25 cc: PM From: Anthony Liguori/Austin/IBM@IBMUS Subject: [PATCH] Winbind IDMAP Backend rearchitecture Jim, This patch adds the architecture for an IDMAP backend system including a new smb.conf parameter "winbind backend". Right now, the only valid value is "tdb" but I'm currently working on an LDAP backend (I guess we should eventually do an ads backend too). Untar this in the top-level Samba repository (it adds the file source/nsswitch/winbindd_idmap_tdb.c) and apply the patch with -p0. (See attached file: wb_idmap_backend.tar) Anthony Liguori Linux/Active Directory Interoperability Linux Technology Center (LTC) - IBM Austin E-mail: [EMAIL PROTECTED] Phone: (512) 838-1208 Tie Line: 678-1208 wb_idmap_backend.tar Description: Binary data
linking smbclient commands with libsmb?
Please CC me in reply as I am not on the mailing list. > Just a quick question regarding samba, is there a way > to compile all the samba commands to be linked with libsmb > so that not each of them are big in size like they are right now? > > I tried with the --libsmbclient configure option but the binaries > like smbmount, smbumount, smbmnt, smbclient, nmblookup are not linked > with it and are pretty big in size. > > I tried with Samba 2.2.7a, is that something you think is being worked on? > > The reason I'm asking is because I am compiling samba for a small linux > embedded device, and I don't have much room on it :) > > -Christian >
Re: [PATCH] Winbind IDMAP Backend rearchitecture
Anthony,
it would be nice if you can remane the parameter 'winbind backend' ->
'idmap backend'
and add a
NTSTATUS or int smb_register_idmap(const struct idmap_backend *backend, int
version)
function
with
struct idmap_backend {
const char *name;
struct idmap_methods *methods;
struct idmap_backend *prev,*next;
}
so that we can have modules witch can register a new backend.
And as I said yesterday on IRC, it would be nice to move the idmap code
to a new dir idmap and remove the winbind_prefix of the functions and file
names.
and thwe current winbind idmap code should call the idmap code
because the get_rid_from_[u|g]id function should only be in the winbind
idmap code because winind know the domain sid for this rids.
Simo,
did you have comments on this, I remember we discused this topic very long
last year:-)
metze
-
Stefan "metze" Metzmacher <[EMAIL PROTECTED]>
Payment Due, order 31977
dgnPlease block future notices. rel
