[jcifs] Re: Pass Through Authentication [was dcerpc.net - developer forum]

[Michael B. Allen]

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).

Ok, check.

> 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 :
> 
> 	get_any_dc_name
> 
> 	msrpc_lsa_query_trust_password
> 
> 		msrpc_lsa_query_secret
> 
> 			lsa_open_policy *
> 			lsa_open_secret *
> 			lsa_query_secret *
> 			lsa_close *
> 			lsa_close *
> 
> 		secret_to_nt_owf
> 
> 			secret_get_data
> 			nt_owf_genW
> 
> 	domain_client_validate_backend
> 
> 		cli_nt_setup_creds
> 
> 			cli_net_req_chal *
> 			cli_con_set_creds *
> 			cli_net_auth2 *
> 			[forget the SChannel authentication for now]
> 
> 		cli_nt_login_interactive 
> 
> 			cli_get_sess_key
> 			make_id_info1
> 			cli_net_sam_login *
> 
> 		cli_nt_login_network
> 
> 			cli_get_sess_key
> 			make_id_info2
> 			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
an InputStream.

> 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.

Ok.

> 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,
> 
> luke

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.

Ta,
Mike

-- 
Wow a memory-mapped fork bomb! Now what on earth did you expect? - lkml