[jcifs] Re: Pass Through Authentication [was dcerpc.net - developer forum]
Michael B. Allen
mballen at erols.com
Thu Sep 6 17:16:28 EST 2001
On Wed, Sep 05, 2001 at 03:02:24PM +0200, Luke Kenneth Casson Leighton wrote:
> > > using this approach, you then _wouldn't_ have to implement the
> > > NETLOGON server service.
> > Server service? I just need a simple client function like:
> > boolean Toolkit.isAuthorized(String domain, String username, byte password)
> > > 5,000 to 6,500 loc? at a guess?
> > What! The entire jCIFS client is something like 7000 lines of code. I
> > thought all I needed to do was implement a few (1 req, 1 resp?) NT
> > Transact Named Pipe calls to the PDC. Provided I use off the shelf crypto
> > and it's anything like any other transaction I was thinking _500_ lines
> > of code.
> yes, really, it's not going to be small.
> take a look at pam_smb and pam_ntdom (pam_ntdom is available
> by anoncvs on samba.org).
> the equivalent function in both these pam modules is Valid_User.
> yes, it's a simple front-end.
> behind pam_ntdom is, quite literally, 8 or 9 thousand lines
> of code, including the smb clientgen.c code.
> now, whatyou're telling me is that
> you already have the smb client code, so that
> saves you 3,000 LOC.
> okay, i'll do an analysis for you, listing
> function names as we go.
> domain_client_validate :
> lsa_open_policy *
> lsa_open_secret *
> lsa_query_secret *
> lsa_close *
> lsa_close *
> cli_net_req_chal *
> cli_con_set_creds *
> cli_net_auth2 *
> [forget the SChannel authentication for now]
> cli_net_sam_login *
> cli_net_sam_login *
> now, the functions listed with a * are those that
> send network traffic on-wire. i'm not going
> into those in detail because the above tree starts
> to get complicated, then.
> but basically, each of those functions is what
> i believe you were expecting to have to implement,
> from network traffic, yes?
Well, I'm really only interested in authenticating client against the
PDC but I understand there's going to be necessary foundation work.
> the rest of the functions - not listed with a * -
> are support infrastructure to make sense of and to
> make use of the stuff that goes on-wire.
> the functions listed with a * are typically
> 60 lines long each, that do this:
> prs_init (request NDR buffer)
> prs_init (response NDR buffer)
> prepare request parameters
> marshall request parameters NDR buffer
Is there a spec on NDR? This would be a good little abstract piece to
byte off and get learned.
> call rpc_hnd_pipe_req() which is the function that
> exchanges data on-wire
> unmarshall response parameters NDR buffer
> free the temporary request/response NDR buffers.
> again, rpc_hnd_pipe_req() is noteworthy of further
> description. it eventually gets down to rpc_api_pipe_req()
> which is the function ultimately responsible for
> breaking down and reassembling the request/response
> data into and from PDUs, including doing any
> encryption / decryption. so you get a clean, contiguous
> stream of bytes out, having put a contiguous stream in.
> note the function calls to rpc_api_write, rpc_api_send_rcv_pdu
> and rpc_api_rcv_pdu? _that's_ where SMBwriteX, SMBtrans
> and SMBreadX get called.
I suspect when you refer to PDUs you're just talking about the breakup
of the at most 64K transaction buffer into ~MTU sized fragments for
transmission on the network. This is all handled by the pipe layer. In
jCIFS just write bytes to an OutputStream and you get the response in
> anyway: like i said, this is all support infrastructure
> and i hesitate to mention that you really should not
> underestimate how much work is involved, which is why
> i was advocating that you try to save some effort and
> do this in manageable stages, replacing each layer
> as you have time, one at a time.
> even in freedce, i'm not going to integrate all of that
> code from TNG into freedce, but am going to insist
> that if you want freedce to interoperate with Windows
> NT, you have to install TNG to use the NamedPipe
> emulation layer in TNG (or samba, if the guys there
> add in the TNG NamedPipe emulation layer too).
> there _is_ a simpler way: do the pam_smb style
> auth. it's not nice [i hate it :)] but it
> 'Does The Job'.
> you'll only need an SMBnegprot and SMBsesssetupX for
> that. oh, and get_any_dc_name() to locate a DC from
> the Domain name. i'm sure you have that NetBIOS/UDP
> call available in jCIFS.
Well, for this all we do is NbtAddress.getByName("mydc", 0x1c,
"scope.com"). I believe 0x1c will return the domain controller.
> all best,
Thanks a lot Luke. I really appriciate your help. I have cc'd our list
so that I may refer back to this information (an assure jCIFS users that
I am looking into the pass-trough authentication functionality). It is
clear that I need to look at the code you outlined above, take a hard
look at the wire with your book in hand, etc. Perhaps after doing so I
can present more focused questions.
Wow a memory-mapped fork bomb! Now what on earth did you expect? - lkml
More information about the jcifs