Re: machine names same as usernames - problems... -- here's arealworld NetBIOS clusterfsck ...
On Thu, Feb 06, 2003 at 04:15:52PM -0800, Richard Sharpe wrote: On Thu, 6 Feb 2003, Richard Sharpe wrote: On Thu, 6 Feb 2003, Bryan J. Smith wrote: No, not really. The \$ in the name of the trust account is an MS thing. Samba requires a machine account be backed up on the server with an account of that name. However, as far as I can see, we could remove that restriction, as we could keep all the needed info in the secrets file or another tdb. OK, I withdraw the last sentence, since when we are operating as a PDC, we should use the same account mechanisms for trust accounts and ordinary user accounts. Actually it depends on direction of trust ie. whether we're dealing with _trusted_ domain or _trusting_ domain. Just my 2 cents... -- cheers, ++ |Rafal 'Mimir' Szczesniak [EMAIL PROTECTED] | |*BSD, GNU/Linux and Samba / |__/
Security registry settings.
Okay, folks. Here's where I am on security settings and their impact. The settings below are all based on NT4SP6, but similar stuff is (should be?) available for W2K and other Windows flavors. 1) MAC Signing: On the server: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanManServer\Parameters The parameter EnableSecuritySignature is used to enable and disable SMB MAC signatures. If enabled (set to one (1) instead of zero (0)), the server will sign SMB packets if the client wants to sign packets. The parameter RequireSecuritySignature is used to force SMB MAC signatures. The RequireSecuritySignature parameter has no effect unless EnableSecuritySignature is also enabled. If both are set to one (1), the server will require that the client use MAC signatures. On the client: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Rdr\Parameters Notice that the path is different (Rdr instead of LanManServer). Otherwise, this is all similar to the server, if EnableSecuritySignature is enabled then the client will perform MAC signing if the server supports or requires it. If both EnableSecuritySignature and RequireSecuritySignature are enabled, then the client must use MAC signing. The session will fail if the server does not have MAC signing enabled. (The client closes the TCP connection immediately after the server sends the NegProt Response with the SecurityMode field indicating that it doesn't support MAC signing.) There are docs which state that W/9x cannot do server-side MAC signing, but can do client-side. 2) Challenge/Response algorithm: The following KB articles are useful references: 147706, 239869. The registry variable HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\control\LSA\LMCompatibilityLevel is used to set the minimum challenge/response algorithm. On W/9x boxes the variable is LMCompatibility rather than LMCompatibilityLevel. (Why do they do things like that?) Anyway, this is an annoying variable because it does too much. There are six possible values, ranging from 0..5. They work like so: Client Domain Controller (or Server) -- - 0 Default. Client sends both LM Default. DC accepts LM, NTLM, and NTLM[v1] Response. LMv2, and NTLMv2 responses. 1 Discussion below. Discussion below. 2 Client sends the NTLMv1 responseDC accepts LM, NTLM, LMv2, in both password fields (the same and NTLMv2 responses. value twice...I've seen it, it's real). 3 The Client places the 24-byte LMv2 According to the docs, at this response into the ANSI password setting the DC still accepts field, and the longer NTLMv2LM, NTLM, LMv2, and NTLMv2. response into the Unicode password field. 4 The client sends both a 24-byte The DC does not compare any response (probably the LMv2) andresponse against the LM response the longer NTLMv2 response. NTLM, LMv2, and NTLMv2 are accepted. 5 Same as level 4.The DC does not compare against LM or NTLM. Only LMv2 and NTLMv2 are accepted. From the testing I've done, the above is pretty close to reality. The setting that bangs me on the head until my feet ache is LMCompatibilityLevel = 1. The docs say that this enables NTLMv2 Session Security, but I can't find docs on that. Abartlet tells me that it's specific to NTLMSSP. My question, at this point, is: how do the client and server know to use NTLMSSP? Digging... 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]
missing config.h.in for CVS SAMBA_3_0?
Double checked cvsweb - its config.h.in is gone? I got this message this morning when I updated my CVS tracking copy: cvs server: source/include/config.h.in is no longer in the repository Did someone do an oops, adding both config.h and config.h.in to .cvsignore?
RE: Annoying Minor Bug In Winbind 2.2.x
On 7 Feb 2003, Martin Pool wrote: On 6 Feb 2003, Boyce, Nick [EMAIL PROTECTED] wrote: I find what seems to be an obvious, simple and annoying buggette - if I stop and restart winbind (the sort of thing you do a lot at this stage) then it fails to restart, with this message in /var/log/samba/log.winbindd : invalid permissions on socket directory /tmp/.winbindd Here's the permissions : /etc# ls -ld /tmp/.w* drwxr-x---2 root root 4096 Feb 6 21:33 /tmp/.winbindd The error is emitted from create_pipe_sock, which checks that the permissions on the directory are exactly what winbind expects them to be (0755). Obviously those permissions are not correct, which would seem to be a problem because it might prevent non-root processes from accessing winbindd. This looks very much like a umask problem. Thanks - that was it. I now have a script /usr/local/bin/winbind, which does umask 000 /etc/init.d/winbind $1 umask 027 and everything is working ok now - I can stop restart winbind to my heart's content without any problem (well no socket directory permissions problems anyway ;-) [ I'm afraid I always run with umask=027 ... it's a hangover from my mainframe days ... I can't get away from the idea that you should grant only the access that is needed ... all files world-readable by default ? ... Just Say No ] Thanks a lot. Nick Boyce EDS Southwest Solution Centre, Bristol, UK
Re: Annoying Minor Bug In Winbind 2.2.x
On 7 Feb 2003, Boyce, Nick [EMAIL PROTECTED] wrote: Thanks - that was it. I now have a script /usr/local/bin/winbind, which does umask 000 /etc/init.d/winbind $1 umask 027 and everything is working ok now - I can stop restart winbind to my heart's content without any problem (well no socket directory permissions problems anyway ;-) You would be better off -- and you would be helping us too -- if you would apply the patch and let us know if it works. (I'm pretty sure it will, but it's always worth testing.) That way, rather than a temporary workaround, there will be a proper fix for future releases. Thanks, [ I'm afraid I always run with umask=027 ... it's a hangover from my mainframe days ... I can't get away from the idea that you should grant only the access that is needed ... all files world-readable by default ? ... Just Say No ] That's fine, winbindd ought to work with that. -- Martin
Re: msdfs referrals at share-level
hi, now that the msdfs-proxy is in cvs (thanks again for taking a deeper look on that) i still have a small fix for the dfsenum-pipe that just prints the first dfsroot and then stops. with that fix it'll show you all dfsenum-infolevels. attached you'll find a backport of the msdfs-proxy for 2_2, maybe you could have a quick look and comment on that one too. thanks again, guenther On Mon, Oct 14, 2002 at 12:15:17PM -0700, Shirish Kalele wrote: Hi, This is cool. Which Windows clients have you tested with? As for the patch, it might be better if you coded this such that a self-referral either pointed to itself, or to the proxied share. Having something like 'msdfs proxy = server\share' in smb.conf, and sending that whenever a self-referral was to be sent would be better than the hack you have where you manipulate the client's requested path to become the msdfs link to the proxy. imho, anyway. This might also make it easier to code the NETDFS interface to this proxy stuff. Cheers, Shirish - Original Message - From: Guenther Deschner [EMAIL PROTECTED] To: Shirish Kalele [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; Thomas Wiebach [EMAIL PROTECTED] Sent: Monday, October 14, 2002 6:36 AM Subject: Re: msdfs referrals at share-level hello shirish, we made some more experiments with the dfs-code and now have a running solution for our smb-proxy, without breaking msdfs (well, i didn't had a look on the dfs_rpc-pipe for now...) you can now have a samba-share behave like an mdfs-symlink. if you set a share to msdfs proxy = yes and declare the link in its path to msdfs link name = linkname the clients will reveive correct referrals already when they access the share :) since we are planning to use this patch in production, it would be very nice if you could comment on this. -8--snip--8-- add to smb.conf: [global] host msdfs = yes [dfs-fake] path = /export/dfs-fake msdfs root = yes msdfs proxy = yes msdfs link name = linkname create a link: ln -s msdfs:unimak\\storage /export/dfs-fake/linkname -8--snap--8-- thanks a lot, guenther On Thu, Sep 05, 2002 at 09:50:51AM -0700, Shirish Kalele wrote: Hi, Clients do request dfs referrals for every share they connect to. In a dfs reply for a share, you could try and send a different sharename and see what happens. I don't know if clients will be able to handle this. Look for self_referral in the setup_dfs_referral() code to find out where to start making changes. Let me know how the clients take it.. Thanks, Shirish - Original Message - From: Guenther Deschner [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, September 04, 2002 2:48 PM Subject: msdfs referrals at share-level hello everybody, as far as i have looked into msdfs.c it seems to be impossible to send a client a dfs-referral at the share level (\\fileserver\msdfs-link). maybe there is another way to proxy a request to \\samba\thisshare to \\anothersamba\thatshare ? i currently want to migrate a couple of nt-servers transparently for clients. the basic idea is to setup one samba-server that offers faked file-service via netbios-aliases and dfs-redirects to the real samba-fileserver. unfortunatly touching the clients is a no-go. old setup with *nt*: client - //fileserver/share1 planned setup with *samba*: client - //fileserver/share1 where share1 - msdfs:samba-file\whatever any help is much appreciated. bye, guenther -- Guenther Deschner [EMAIL PROTECTED] SuSE Linux AGGnuPG: 8EE11688 Berliner Str. 27 phone: +49 (0) 30 / 430944778 D-13507 Berlin fax: +49 (0) 30 / 43732804 -- Guenther Deschner [EMAIL PROTECTED] SuSE Linux AGGnuPG: 8EE11688 Berliner Str. 27 phone: +49 (0) 30 / 430944778 D-13507 Berlin fax: +49 (0) 30 / 43732804 -- Guenther Deschner [EMAIL PROTECTED] SuSE Linux AGGnuPG: 8EE11688 Berliner Str. 27 phone: +49 (0) 30 / 430944778 D-13507 Berlin fax: +49 (0) 30 / 43732804 --- source/param/loadparm.c 20 Dec 2002 20:23:05 - 1.472 +++ source/param/loadparm.c 29 Dec 2002 23:29:07 - 1.473 @@ -343,6 +343,7 @@ char *fstype; char *szVfsObjectFile; char *szVfsOptions; + char *szMSDfsProxy; int iMinPrintSpace; int iMaxPrintJobs; int iWriteCacheSize; @@ -468,6 +469,7 @@ NULL,
Call for Paper SambaXP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi! Just a short reminder: The call for papers for SambaXP 2003 has a deadline in seven days, on February 14. I would like to ask all of you to submit your proposal to http://sambaxp.org/call_for_papers/paper_registration.html if you have not done it yet. With some people (you know who you are ;-)) I've already had personal contact via email or irc. Could you please also find some minutes and upload your proposal there? I know only too well how these things tend to fill the inbox, and how much better you feel after you have done it :-) Have a nice weekend! Thanks, Volker -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Key-ID D32186CF, Fingerprint available: phone +49 551 370 iD8DBQE+Q71WOmSXH9Mhhs8RAtpkAKCQ4Y+yd1UlaYjlgP0lzhxaO8CVeQCeOvIX fmvmbqpgikbqT0w+jeMSAfE= =syB6 -END PGP SIGNATURE-
Re: missing config.h.in for CVS SAMBA_3_0?
hi, just call autogen.sh and it will be recreated. bye, guenther On Fri, Feb 07, 2003 at 08:21:21AM -0500, Richard Bollinger wrote: Double checked cvsweb - its config.h.in is gone? I got this message this morning when I updated my CVS tracking copy: cvs server: source/include/config.h.in is no longer in the repository Did someone do an oops, adding both config.h and config.h.in to .cvsignore? -- Guenther Deschner [EMAIL PROTECTED] SuSE Linux AGGnuPG: 8EE11688 Berliner Str. 27 phone: +49 (0) 30 / 430944778 D-13507 Berlin fax: +49 (0) 30 / 43732804 msg05892/pgp0.pgp Description: PGP signature
Re: missing config.h.in for CVS SAMBA_3_0?
OK... its just a pain because one of the platforms I automatically build from CVS on doesn't have the tools required to run autogen.sh, so I have to do some convoluted tricks to run autoheader and autoconf on my Linux server against my Solaris source tree. Seems as though it would be better to put config.h.in back into CVS for less priviledged folk among us. Just my 2 cents. Rich B - Original Message - From: Guenther Deschner [EMAIL PROTECTED] To: Richard Bollinger [EMAIL PROTECTED]; Samba Technical [EMAIL PROTECTED] Sent: Friday, February 07, 2003 9:25 AM Subject: Re: missing config.h.in for CVS SAMBA_3_0? hi, just call autogen.sh and it will be recreated. bye, guenther On Fri, Feb 07, 2003 at 08:21:21AM -0500, Richard Bollinger wrote: Double checked cvsweb - its config.h.in is gone? I got this message this morning when I updated my CVS tracking copy: cvs server: source/include/config.h.in is no longer in the repository Did someone do an oops, adding both config.h and config.h.in to .cvsignore? -- Guenther Deschner [EMAIL PROTECTED] SuSE Linux AGGnuPG: 8EE11688 Berliner Str. 27 phone: +49 (0) 30 / 430944778 D-13507 Berlin fax: +49 (0) 30 / 43732804
Re: LSA Privileges
Volker, I'm CCing this to samba-technical as others may be interested in the answer. I hope you don't mind. First off, MSDN has quite a lot of info on privileges. You should read up on the LSA privileges calls there. I will soon be ripping the privileges code out of the group mapping code, as it just doesn't belong there. Instead I will create a separate privileges.tdb and make this go via pdb so it can be remoted via LDAP. The main things to understand about privileges are: - logically each privilege is a string name and a set of SIDs associated with that string name. - The SIDs do not have to be group SIDs (they can, for example, be users) - The names do not have to have fixed numbers associated with them (although I will probably associate fixed bitmasks with each name for programming convenience). - when we create a NT token we need to query the privileges db and ask it 'what union of privileges are associated with this list of SIDs'. That then defines the privileges for a security context. - privileges act a bit like setuid bits on executables in Unix. If you have a privilege then you get to do the associated operation whether or not the ACL on that object allows it. - If you don't have the required privilege then the ACL is checked. If you wish to play with privileges then you may wish to use the rpcclient commands 'lsaenumacctrights', 'lsaaddacctrights' and 'lsaremoveacctrights' that have been recently added to the HEAD branch. They should allow you to experiment easily. One thing I don't understand yet is how the numbers used during a SAMR replication of the privileges database are derived from the string names used in LSA. Cheers, Tridge Hi, Andrew! Currently I'm looking at getting the group mapping into LDAP. JF has put privileges into the group mapping database. I'm not sure whether they really belong there. But on the other hand, I don't really understand what is going on with privileges (what the heck is a systemaccount?) Do you have any reference from where you can read about privileges? Volker
