Why you can't load ws2_32.dll (was Re: Can't use key authentication on x64 Server 2003 R2)

[Greg Fury]

Just wondering why this worked under 1.5 ?

-Greg


On Fri, Jan 8, 2010 at 9:59 AM, Corinna Vinschen
<corinna-cygwin@cygwin.com> wrote:
> On Jan  7 14:33, Greg Fury wrote:
>> [...]
>> -  Domain user that is a local administrator AND has the local
>> administrator as primary group in /etc/passwd, - login with key
>> authentication works fine.
>>
>> - Domain user that is a local administrator WITHOUT the local
>> administrator as primary group in /etc/passwd, - cannot login with key
>> authentication.
>>
>> - Local user regardless of primary group in /etc/passwd or local group
>> setting - login with key authentication works fine
>>
>> - Local user with key authentication and not a member of local
>> administrators fails when an argument is passed on the command line:
>>
>> linux$ ssh user@host1-w2k3 pwd
>>      20 [main] sshd 244 D:\cygwin-1.7\usr\sbin\sshd.exe: *** fatal
>> error - could not load user32, Win32 error 1114
>
> I can't reproduce this one, but I can reproduce the other problem
> with pubkey authentication reported  in this thread:
>
>   # ssh foo@bar
>   Last login: [...]
>          1 [main] -bash 6832 C:\cygwin\bin\bash.exe: *** fatal error -
>   couldn't dynamically determine load address for 'WSAGetLastError'
>   (handle 0xFFFFFFFF), Win32 error 126
>   Connection to bar closed.
>
> The problem is this:
>
> If you're running in a domain, then the account running the sshd service
> must be a member of the domain as well.  Instead of creating a local
> cyg_server account, you must create a domain account called cyg_server
> with the specific rights required to create a user token, add it to the
> /etc/passwd file of the machine on which you want to install sshd, and
> *then* run ssh-host-config on that machine.
>
> If you did that, the ssh-host-config script will note that such an
> account exists in /etc/passwd and will offer to use that account for the
> sshd service.
>
> Ok, back to square one.  Assume you're using a local cyg_server account,
> and you're using the default method of switching the user context
> without password according to Method 1(*).  That means, Cygwin has to
> create a user token from scratch.
>
> Now you try to ssh into the machine with a domain account.  cyg_server
> is a local machine account.  Thus it is not known to the DC.  However,
> the incoming ssh connection requests a logon for a domain account.
>
> To be able to create a matching user token, sshd has to access the DC
> and fetch the user information for that account.  But the DC doesn't
> know the cyg_server account under which the calling process is running,
> so it refuses to deliver the information for security reasons.
>
> So cyg_server gets no information about that account.  It has to fall
> back to the information in /etc/passwd and /etc/group.  From that it
> constructs a crippled user token which only contains the SID of the user
> and the SID of the primary group, plus the well-known SIDs for the LOCAL
> and the INTERACTIVE group.
>
> Now let's have a look into the default permissions of ws2_32.dll on
> a Windows Server 2003:
>
>  $ cacls C:/WINDOWS/system32/ws2_32.dll
>  C:\WINDOWS\system32\ws2_32.dll BUILTIN\Users:R
>                                 BUILTIN\Power Users:R
>                                 BUILTIN\Administrators:F
>                                 NT AUTHORITY\SYSTEM:F
>
> Oh, too bad.  None of these groups is in the user token of the just
> logged on user.  Bingo.
>
> So, bottom line is, the most important thing to keep in mind is that you
> must use a domain cyg_server account to run sshd under, to be able to
> correctly log on with domain accounts using password-less logon Method 1(*).
> Additionally you have to create a domain policy so that the special
> permissions required to create a user token(*) are propagated to the
> machines which are supposed to run sshd.  Fortunately, since that's how
> domains work, you only have to do this once on the DC.
>
> Nevertheless, having said that, I'm wondering if we should always add
> the local BUILTIN\Users group to a user token, if we failed to fetch the
> user information from the DC...
>
>
> HTH,
> Corinna
>
>
> (*) http://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-nopasswd1
>
>
> --
> Corinna Vinschen                  Please, send mails regarding Cygwin to
> Cygwin Project Co-Leader          cygwin AT cygwin DOT com
> Red Hat
>
> --
> Problem reports:       http://cygwin.com/problems.html
> FAQ:                   http://cygwin.com/faq/
> Documentation:         http://cygwin.com/docs.html
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
>
>



-- 

-Greg

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple