X-Recipient: archive-cygwin@delorie.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@FDSVAST06SXCH01.flooddata.net> <Pine.GSO.4.63.0805121820090.11953@access1.cims.nyu.edu> <20080513073720.GA22193@calimero.vinschen.de> <3B3EFBD49B94AD4DBB7B7097257A8046DD02FC@FDSVAST06SXCH01.flooddata.net> <20080513163756.GC18799@calimero.vinschen.de>
From: "Schutter, Thomas A." <tschutter@proxix.com>
To: <cygwin@cygwin.com>
X-IsSubscribed: yes
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie.com@cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe@cygwin.com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin@cygwin.com>
List-Help: <mailto:cygwin-help@cygwin.com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Delivered-To: mailing list cygwin@cygwin.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/


