Trouble authenticating with OfficeJet CIFS client

[Andrew Bartlett]

On Thu, 2007-07-19 at 17:53 -0700, Bob Richmond wrote:
> Christopher R. Hertel wrote:
> 
> > Jeremy Allison wrote:
> >> On Thu, Jul 19, 2007 at 04:57:12PM -0700, Bob Richmond wrote:
> >>> Hmm, I see that now. So, what is the meaning of "User ID" in the context 
> >>> of the first sessionsetupX response for NTLMSSP_CHALLENGE, if the CIFS 
> >>> client hasn't yet specified the username it wants to authenticate as?
> >> It's a placeholder. On Windows it becomes the eventual uid used, but
> >> we allocate a new one. I'll look into fixing that.
> >
> > The [v]uid in the SMB header is not related to real user IDs as assigned by
> > the OS.  It is a token allocated by the server and associated with a login
> > instance.  There may be several valid authentications, all with different
> > [v]uid's assigned, within the same session.
> >
> > Chris -)-----
> 
> Is there a performance or resource consumption ramification in not 
> deferring the allocation of the real vuid until after the authentication 
> succeeds? 

Yes, you need to tie in the multiple-step authentication together.
Otherwise, we end up back where we started (where a client attempting
two simultaneous authentications breaks).  

> I imagine the rationale behind the current behavior is to 
> prevent unauthenticated clients from being able to get the server to 
> keep allocating uids (and associated state data) that aren't going to be 
> attached to active sessions. 

That's a limit we should investigate adding. 

> Is it legal after a failed authentication 
> to return the same uid to a new authentication attempt? Or does it have 
> to be a new id every time an attempt is made?

If windows returns the same token, we are free to match the behaviour.

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.                  http://redhat.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20070720/e35bf0a2/attachment.bin