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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
vuid that was allocated whilst the connection is
being constructed and after the connection has been set up.
This is what Windows does and at least one client
(and HP printer) depends on this behaviour. As it
depends on the req struct not yet ported to SAMBA_3_2_0
(Volker, hint hint.... :-) I am not yet adding this
to that branch, but will investigate that tomorrow.
Jeremy.
This itself won't help much, because send_trans2_replies_new still allocates
the big buffers, but stay tuned :-)
Also add/update my copyright on stuff I recently touched.
Volker
The complete history of this patch can be found under
http://www.samba.org/~vlendec/inbuf-checkin/.
Jeremy, Jerry: If possible I would like to see this in 3.2.0. I'm only
checking into 3_2 at the moment, as it currently will slow down operations for
all non-converted (i.e. all at this moment) operations, as it will copy the
talloc'ed inbuf over the global InBuffer. It will need quite a bit of effort
to convert everything necessary for the normal operations an XP box does.
I have patches for negprot, session setup, tcon_and_X, open_and_X, close. More
to come, but I would appreciate some help here.
Volker
checkin will pull this up to srvstr_get_path. At that point we can get more
independent of the inbuf, the base_ptr in pull_string will only be used
to satisfy UCS2 alignment constraints.
when verifying a ticket from winbindd_pam.c.
I've found during multiple, fast, automated SSH logins (such
as from a cron script) that the replay cache in MIT's krb5
lib will occasionally fail the krb5_rd_req() as a replay attack.
There seems to be a small window during which the MIT krb5
libs could reproduce identical time stamps for ctime and cusec
in the authenticator since Unix systems only give back
milli-seconds rather than the micro-seconds needed by the
authenticator. Checked against MIT 1.5.1. Have not
researched how Heimdal does it.
My thinking is that if someone can spoof the KDC and TDS
services we are pretty hopeless anyways.
not just an NTLMSSP - grr. This complicates the re-use of
common client and server code but I think I've got it right.
Not turned on of valgrinded yet, but you can see it start
to take shape !
Jeremy.
to return a NT_STATUS_TIME_DIFFERENCE_AT_DC error to
a client when there's clock skew. Will help people
debug this. Prepare us for being able to return the
correct sessionsetupX "NT_STATUS_MORE_PROCESSING_REQUIRED"
error with associated krb5 clock skew error to allow
clients to re-sync time with us when we're eventually
able to be a KDC.
Jeremy.
Vista sends the NTLMv2 blob by default in the tconX
packet. Make sure we save off the workgroup the user
was logged into on the client in the sessionsetupX
and re-use it for the NTLMv2 calc.
Jeremy.
logic in smbd/process.c. All interested (Volker,
Jerry, James etc). PLEASE REVIEW THIS CHANGE.
The logic should be identical but *much* easier
to follow and change (and shouldn't confuse Klockwork :-).
Jeremy.
right now. r14112 broke it, in 3.0.22 register_vuid for security=share returns
UID_FIELD_INVALID which in current 3_0 is turned into an error condition. This
makes sure that we only call register_vuid if sec!=share and meanwhile also
fixes a little memleak.
Then I also found a crash in smbclient with sec=share and hostmsdfs=yes.
There's another crash with sec=share when coming from w2k3, but I need sleep
now.
Someone (jerry,jra?) please review the sesssetup.c change.
Thanks,
Volker
prevents a nasty failure condition in winbindd's pam_auth where a tgt
and a service ticket could have been succefully retrieved, but just not
validated.
Guenther
changing the token generation. I *hate* this code!
Jerry, you have been looking at this as well, can you double-check that I did
not screw it up?
Thanks,
Volker
