IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
We should map from lp_server_signing() just once in srv_init_signing().
metze
Signed-off-by: Günther Deschner <gd@samba.org>
Autobuild-User: Günther Deschner <gd@samba.org>
Autobuild-Date: Wed Nov 16 18:59:49 CET 2011 on sn-devel-104
This matches W2K (at least sp4) and higher.
metze
Autobuild-User: Stefan Metzmacher <metze@samba.org>
Autobuild-Date: Fri Nov 4 15:50:06 CET 2011 on sn-devel-104
This adds support for the 2 stage negprot, from SMB 1 to SMB 2.1.
Support for this of for now and "max protocol = SMB2" still maps
to "max protocol = SMB2_02" PROTOCOL_SMB2_02.
In order to activate smb2.1, you need to use "max protocol = SMB2_10".
metze
Autobuild-User: Stefan Metzmacher <metze@samba.org>
Autobuild-Date: Mon Sep 5 19:30:58 CEST 2011 on sn-devel-104
If a smb1 negprot negotiated smb2 we forked the echo responder. This will
eventually lead to a panic from
[2011/08/30 10:33:29.212578, 0, pid=3846917] smbd/smb2_server.c:243(smbd_smb2_request_create)
Invalid SMB packet: first request: 0x0009
because from the echo responder we always read using the normal smb1 protocol
handling routine. If that is a bit down the smb2 stream, we get a non-negprot
packet and panic.
BTW, the echo responder is not required for smb2 anyway, Microsoft confirmed
that it probes the server liveness using TCP keepalives and not smb2 echo
requests.
Autobuild-User: Volker Lendecke <vlendec@samba.org>
Autobuild-Date: Wed Aug 31 17:58:48 CEST 2011 on sn-devel-104
This tests if the auth_generic_start() hook is available on the auth
context during the negprot, and if so it uses auth_generic_start() to
hook to GENSEC to handle the full SPNEGO blob.
Andrew Bartlett
Signed-off-by: Andrew Tridgell <tridge@samba.org>
There is no reason this can't be a normal constant string in the
loadparm system, now that we have lp_set_cmdline() to handle overrides
correctly.
Andrew Bartlett
This enables activating the echo responder also if SMB2 is enabled, albeit it
will only be used for SMB1 at this moment.
Autobuild-User: Volker Lendecke <vlendec@samba.org>
Autobuild-Date: Fri May 20 15:06:03 CEST 2011 on sn-devel-104
This is strlcpy, just with an extra check of the parameters with
sizeof(), use only where that works.
Andrew Bartlett
Autobuild-User: Andrew Bartlett <abartlet@samba.org>
Autobuild-Date: Wed Mar 23 03:39:35 CET 2011 on sn-devel-104
This patch, based on the suggestion by Goldberg, Neil R. <ngoldber@mitre.org>
turns off the sending of the principal in the negprot by default, matching
Windows 2008 behaviour.
This slowly works us back from this hack, which from an RFC
perspective was never the right thing to do in the first place, but we
traditionally follow windows behaviour. It also discourages client
implmentations from relying on it, as if they do they are more open to
man-in-the-middle attacks.
Andrew Bartlett
message_push_string() and message_push_blob() both update
the bcc value, so we don't need the old code that tries to
do it manually.
Jeremy.
Autobuild-User: Jeremy Allison <jra@samba.org>
Autobuild-Date: Mon Nov 29 22:24:01 CET 2010 on sn-devel-104
into negprot_spnego() where it belongs (it's not an SPNEGO operation).
Add a TALLOC_CTX for callers of negprot_spnego(). Closer to unifying all
the gen_negTokenXXX calls.
Jeremy.
Turn the freeing function into a destructor and attach it to the
auth_context.
Make all callers TALLOC_FREE() the auth_context instead of calling
the free function.
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
When a samba server process dies hard, it has no chance to clean up its entries
in locking.tdb, brlock.tdb, connections.tdb and sessionid.tdb.
For locking.tdb and brlock.tdb Samba is robust by checking every time we read
an entry from the database if the corresponding process still exists. If it
does not exist anymore, the entry is deleted. This is not 100% failsafe though:
On systems with a limited PID space there is a non-zero chance that between the
smbd's death and the fresh access, the PID is recycled by another long-running
process. This renders all files that had been locked by the killed smbd
potentially unusable until the new process also dies.
This patch is supposed to fix the problem the following way: Every process ID
in every database is augmented by a random 64-bit number that is stored in a
serverid.tdb. Whenever we need to check if a process still exists we know its
PID and the 64-bit number. We look up the PID in serverid.tdb and compare the
64-bit number. If it's the same, the process still is a valid smbd holding the
lock. If it is different, a new smbd has taken over.
I believe this is safe against an smbd that has died hard and the PID has been
taken over by a non-samba process. This process would not have registered
itself with a fresh 64-bit number in serverid.tdb, so the old one still exists
in serverid.tdb. We protect against this case by the parent smbd taking care of
deregistering PIDs from serverid.tdb and the fact that serverid.tdb is
CLEAR_IF_FIRST.
CLEAR_IF_FIRST does not work in a cluster, so the automatic cleanup does not
work when all smbds are restarted. For this, "net serverid wipe" has to be run
before smbd starts up. As a convenience, "net serverid wipedbs" also cleans up
sessionid.tdb and connections.tdb.
While there, this also cleans up overloading connections.tdb with all the
process entries just for messaging_send_all().
Volker
The first is "kerberos method" and replaces the "use kerberos keytab"
with an enum. Valid options are:
secrets only - use only the secrets for ticket verification (default)
system keytab - use only the system keytab for ticket verification
dedicated keytab - use a dedicated keytab for ticket verification.
secrets and keytab - use the secrets.tdb first, then the system keytab
For existing installs:
"use kerberos keytab = yes" corresponds to secrets and keytab
"use kerberos keytab = no" corresponds to secrets only
The major difference between "system keytab" and "dedicated keytab" is
that the latter method relies on kerberos to find the correct keytab
entry instead of filtering based on expected principals.
The second parameter is "dedicated keytab file", which is the keytab
to use when in "dedicated keytab" mode. This keytab is only used in
ads_verify_ticket.
