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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
back to working order. The main change is that the cli_*() RPC
functions from libsmb/*.c now should accept a struct cli_state*.
The reason for this is that rpcclient should establish the
connection to the server at startup so that it is not necessary
to keep the clear test or password hash in memory for each command.
enumports and enumprinters now works as well. lsa* functions
have been tested. SAMR calls may or may not work (one of the core
dumps I know), but it compiles :-)
jerry
(This used to be commit d98ac8852a)
head/tng merge.
It goes something like this:
- headers from tng get copied over one at a time
- the old headers get renamed to *_old.h
- server side code that used the old headers gets a
#define OLD_NTDOMAIN 1
#undef OLD_NTDOMAIN
at the start and end of the code
- mkproto.awk recognises these special defines and does magic stuff so
that each .c file sees the right headers
- we start moving the rpc client libraries from tng to head.
if this goes OK then, in theory, we should be able to move the client
side rpc code from tng to head without disturbing the existing head
server side code. Then when that works we can consider merging the
server side.
it remains to be seen if this scheme will work. So far I've moved
rpc_samr.h and don't seem to have broken anything.
Note this this is still a very delicate operation, as at every step of
the way I want to keep head fully functional. Please don't take part
unless you discuss it with me first.
(This used to be commit f76c037255)
pdus, and then feeds them over either a "local" function call or a "remote"
function call to an msrpc service. the "remote" msrpc daemon, on the
other side of a unix socket, then calls the same "local" function that
smbd would, if the msrpc service were being run from inside smbd.
this allows a transition from local msrpc services (inside the same smbd
process) to remote (over a unix socket).
removed reference to pipes_struct in msrpc services. all msrpc processing
functions take rpcsrv_struct which is a structure containing state info
for the msrpc functions to decode and create pdus.
created become_vuser() which does everything not related to connection_struct
that become_user() does.
removed, as best i could, connection_struct dependencies from the nt spoolss
printing code.
todo: remove dcinfo from rpcsrv_struct because this stores NETLOGON-specific
info on a per-connection basis, and if the connection dies then so does
the info, and that's a fairly serious problem.
had to put pretty much everything that is in user_struct into parse_creds.c
to feed unix user info over to the msrpc daemons. why? because it's
expensive to do unix password/group database lookups, and it's definitely
expensive to do nt user profile lookups, not to mention pretty difficult
and if you did either of these it would introduce a complication /
unnecessary interdependency. so, send uid/gid/num_groups/gid_t* +
SID+num_rids+domain_group_rids* + unix username + nt username + nt domain
+ user session key etc. this is the MINIMUM info identified so far that's
actually implemented. missing bits include the called and calling
netbios names etc. (basically, anything that can be loaded into
standard_sub() and standard_sub_basic()...)
(This used to be commit aa3c659a8d)
damn, this one is bad.
started, at least two days ago, to add an authentication mechanism to
the smbd<->msrpc redirector/relay, such that sufficient unix / nt
information could be transferred across the unix socket to do a
become_user() on the other side of the socket.
it is necessary that the msrpc daemon inherit the same unix and nt
credentials as the smbd process from which it was spawned, until
such time as the msrpc daemon receives an authentication request
of its own, whereupon the msrpc daemon is responsible for authenticating
the new credentials and doing yet another become_user() etc sequence.
(This used to be commit 30c7fdd6ef)
from previous lsaquery command. over-ridden from DOMAIN\username
2) initialisation of cli_state is a little more specific: sets use_ntlmv2
to Auto. this can always be over-ridden.
3) fixed reusage of ntlmssp_cli_flgs which was being a pain
4) added pwd_compare() function then fixed bug in cli_use where NULL
domain name was making connections multiply unfruitfully
5) type-casting of mallocs and Reallocs that cause ansi-c compilers to bitch
(This used to be commit 301a6efaf6)
found out that getopt() _must_ have optind set to 0 before reuse.
still haven't decided what to do with the net* api yet...
(This used to be commit 29c480085e)
if microsoft bothered to publish it. actually, there are good reasons
for not publishing it: people might write programs for it, and then
those programs wouldn't work on nt5, for example...
(This used to be commit 8ce93b80d3)
verified that lsaquery, lsalookupsids work, and found some bugs in the
parameters of these commands :-)
soo... we now have an lsa_* api that has the same arguments as the nt
Lsa* api! cool!
the only significant coding difference is the introduction of a
user_credentials structure, containing user, domain, pass and ntlmssp
flags.
(This used to be commit 57bff6fe82)
msrpc client code. the intent is to hide / abstract / associate
connection info behind policy handles.
this makes the msrpc functions look more and more like their nt equivalents.
who-hou!
(This used to be commit c01b18e632)
means that some commands need more work, as they still use next_token(),
the use of which i wish to avoid.
plus, i was getting fed up of the poor command-line processing in some
of these commands. i'm starting to need getopt() in them, especially
in samsetuser.
WARNING: only cmd_samr has been modded to use getopt() so far! reg
commands won't work, esp.
(This used to be commit 9a1efa03c8)
have we got. and what data do we have. hmm.. i wonder what the NTLMv2
user session key can be... hmmm... weell.... there's some hidden data
here, generated from the user password that doesn't go over-the-wire,
so that's _got_ to be involved. and... that bit of data took a lot of
computation to produce, so it's probably _also_ involved... and md4 no, md5?
no, how about hmac_md5 yes let's try that one (the other's didn't work)
oh goodie, it worked!
i love it when this sort of thing happens. took all of fifteen minutes to
guess it. tried concatenating client and server challenges. tried
concatenating _random_ bits of client and server challenges. tried
md5 of the above. tried hmac_md5 of the above. eventually, it boils down
to this:
kr = MD4(NT#,username,domainname)
hmacntchal=hmac_md5(kr, nt server challenge)
sess_key = hmac_md5(kr, hmacntchal);
(This used to be commit ab174759cd)
request name.
modified createuser rpcclient command to examine name being added. if it
ends in a $, assume that a workstation trust account is being added.
(This used to be commit 4aea261cb0)
samr opcode 0x25. _yet_ another failed attempt to get nt5rc2 to join
a samba domain. what _is_ it with this stuff, dammit?
(This used to be commit c3913f8ae2)
for which a PDC is responsible. typical answers are:
<Name of Domain> plus <Builtin>.
against a hierarchical, down-level-compatible NT5 PDC, there's likely to
be more than these two entries!!!!!
(This used to be commit 3146aa6b60)
spoolss_r_io_enumprinters doesn't decode strings correctly
as printer_info_1/2 code has only been written to write
structures, not read them.
(This used to be commit 135eaa9773)
added samaliasmem <aliasname> rpcclient command (shows members in alias)
added tab command-completion to SAM alias related commands (inc 2 above).
(This used to be commit 0c700fb609)
