X-Recipient: archive-cygwin AT delorie DOT com X-Spam-Check-By: sourceware.org Date: Fri, 8 Jan 2010 15:59:57 +0100 From: Corinna Vinschen To: cygwin AT cygwin DOT com Subject: Why you can't load ws2_32.dll (was Re: Can't use key authentication on x64 Server 2003 R2) Message-ID: <20100108145957.GB23992@calimero.vinschen.de> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com 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 AT 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 AT 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