Mail Archives: cygwin-developers/2002/12/14/03:43:38
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
- Raw text -