X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; 	charset="us-ascii"
Subject: RE: Unable to run sshd under a domain sshd_server account [SOLVED]
Date: Tue, 13 May 2008 11:49:08 -0500
Message-ID: <3B3EFBD49B94AD4DBB7B7097257A8046DD031A@FDSVAST06SXCH01.flooddata.net>
In-Reply-To: <20080513163756.GC18799@calimero.vinschen.de>
References: <3B3EFBD49B94AD4DBB7B7097257A8046DD020D AT FDSVAST06SXCH01 DOT flooddata DOT net> <Pine DOT GSO DOT 4 DOT 63 DOT 0805121820090 DOT 11953 AT access1 DOT cims DOT nyu DOT edu> <20080513073720 DOT GA22193 AT calimero DOT vinschen DOT de> <3B3EFBD49B94AD4DBB7B7097257A8046DD02FC AT FDSVAST06SXCH01 DOT flooddata DOT net> <20080513163756 DOT GC18799 AT calimero DOT vinschen DOT de>
From: "Schutter, Thomas A." <tschutter AT proxix DOT com>
To: <cygwin AT cygwin DOT com>
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id m4DGntMA010465

Corinna Vinschen wrote:
> On May 13 11:09, Schutter, Thomas A. wrote:
> > > -----Original Message-----
> > > On May 12 18:29, Igor Peshansky wrote:
> > > > On Mon, 12 May 2008, Schutter, Thomas A. wrote:
> > > > Yes -- Windows does not understand user impersonation and does
> not
> > > allow
> > > > real user switching.  So what sshd does is invoke processes with
> the
> > > > appropriate token privileges for the user it's impersonating,
> while
> > > > updating internal Cygwin data structures, but still running as
> > > > sshd_server.  So Cygwin sees the right user (in its internal
> state),
> > > but
> > > > Windows processes, of course, don't.
> > >
> > > That's not correct.  This problem cropped up on the list a lot
> > already.
> > > When not using password authentication, Cygwin has to create a
user
> > > token from scratch.  The resulting processes are running under a
> > normal
> > > user token with correctly set user and group ownership.
> >
> > Except that is not what I am seeing.  When I run "id" from a console
> > cygwin shell:
> >   $ id
> >   uid=18718(tschutter) gid=10513(Domain Users)
> > groups=544(Administrators),545(Users),10513(Domain
> > Users),18169(FDSV-GG-PrxBLD),22611(FDSV-GG-PrxPCAdmins)
> >
> > But when I run "id" from a ssh shell:
> >   $ id
> >   uid=18718(tschutter) gid=10513(Domain Users)
> > groups=545(Users),10513(Domain Users)
> >
> > So when I am using pubkey authentication, the user token is not a
> member
> > of the "Administrators", "FDSV-GG-PrxBLD", or "FDSV-GG-PrxPCAdmins"
> > groups.
> 
> That wasn't what I was talking about.  I was just referring to the
> assertion that Windows doesn't know about user impersonation or
> user switching.
> 
> As for your user token, Cygwin tries to get information about the user
> by asking the local machine what local and global groups the user is
> member in.  Some local groups are only in the user's group list,
> because
> one of the global grouyps is in turn member of a local group, which is
> probably the case for the Admin's group.  For some reason your local
> machine doesn't return any of the information about the global domain
> groups your user is member in.  Possible reasons are that retrieving
> the
> PDC for the user's domain fails, or that the PDC refuses to list the
> user's groups for some reason.  That's something you would have to
> debug
> in your local installation.

Ahh.  From my original email from a console cygwin shell:
  $ echo $USERDOMAIN
  FLOODDATA

But when I login via ssh:
  $ echo $USERDOMAIN
  FDSVBLD01SGRAPE

So when I login via ssh, the USERDOMAIN is set to the local machine
rather than the domain.  So I would suspect that the PDC is not even
being queried.

So to summarize, if sshd is run under the local sshd_server account,
then the USERDOMAIN for a ssh shell is set to the local machine.  But
if sshd is run under a domain account, then the USERDOMAIN for a ssh
shell is set to the domain.  This is then the root cause of most of
my issues.

So why is USERDOMAIN set incorrectly?

--
Tom Schutter
First American - Proxix Solutions
(512) 977-6822

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