Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT cygwin DOT com>
List-Help: <mailto:cygwin-developers-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT cygwin DOT com
Delivered-To: mailing list cygwin-developers AT cygwin DOT com
Date: Sat, 14 Dec 2002 09:43:32 +0100
From: Corinna Vinschen <vinschen AT redhat DOT com>
To: cygwin-developers AT cygwin DOT com
Subject: Re: Subauthentication
Message-ID: <20021214094332.M19104@cygbert.vinschen.de>
Reply-To: cygwin-developers AT cygwin DOT com
Mail-Followup-To: cygwin-developers AT cygwin DOT com
References: <3DF9FF0E DOT 6C0400DC AT ieee DOT org> <NFBBLLCAILKHOEOHEFMHEEAMCEAA DOT hartmut_honisch AT web DOT de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <NFBBLLCAILKHOEOHEFMHEEAMCEAA.hartmut_honisch@web.de>
User-Agent: Mutt/1.3.22.1i

On Sat, Dec 14, 2002 at 12:12:01AM +0100, Hartmut Honisch wrote:
> > I have one concern: does subauthentication require access
> > to the PDC for domain users?
> 
> Yes. The subauthentication dll would have to be installed on a domain
> controller. I suppose that's almost never
> going to be the case. So it's only going to work for local users.

?!?  Wait, I thought the subauth module is on the local box and
the LSA itself will connect the PDC if necessary ?!?

> Couldn't we just always call subauth and just check if it was successful?
> That way, a user could install the cygwin subauthentication module on
> whatever machine he needs to.
> If subauth is successful, we let verify_token decide whether to use the
> subauth token or to call create_token, but at least have create_token use
> the subauth token's logon session id.

I partly agree.  That would be ok since subauth fails immediately
if no matching subauth module is available on the machine.  So we
could use the result for getting a valid logon session id and construct
the token we really want using create_token().

However, I see two problems:

- What happens to the handle returned by subauth?  Can we close it
  after we constructed another token?  Or would that invalidate the
  logon session id?

- Pierre had put some effort into avoiding to call the PDC at all
  to e. g. speed up the DLL startup time in domain scenarios.  It
  would be nice if we could keep it that way.

  OTOH, we're not talking about DLL startup but about the setuid()
  call.  This call is made fairly seldom, mostly once from some of
  the usual suspects, sshd, ftpd, telnetd...

  If the authentication process calls the PDC... is that actually
  such a problem?

> SubauthToken = CallSubauthentication(...);
                 ^^^^^^^^^^^^^^^^^^^^^
you mean

  SubauthToken = subauth(...);
  
right?  Or are you going to rewrite that function so completely that
it should get another name?
 
> // Check if subauthentication was successful
> if(IsValidToken(SubauthToken))

Is that necessary?  subauth() returns INVALID_HANDLE_VALUE if it can;t
create a token.  Otherwise we should be allowed to assume a correct
token returned by a Windows function, shouldn't we?

> {
>   if(verify_token(SubauthToken))
>     // Use subauthentication token
>     NewToken = SubauthToken
>   else
>     // Call NtCreateToken, but use SubauthToken's logon session id
>     NewToken = create_token(SubauthToken.LogonSessionId, ...);
> }
> else
> {
>     // Call NtCreateToken and use current logon session id
>     NewToken = create_token(CurrentLogonSessionId, ...);
> }

That's basically the order it was before Pierre's changes, sans
verify_token().

Corinna