Message-Id: <200608211613.k7LGDQjH007124@tigris.pounder.sol.net>
from: cygzz AT trodman DOT com (Tom Rodman)
To: cygwin AT cygwin DOT com
Subject: Re: group"S-1-2-0"(users who login locally)in ssh;windows 2003
In-reply-to: <20060818142824.GB18635@calimero.vinschen.de>
References: <200608161821 DOT k7GIL5VW024015 AT tigris DOT pounder DOT sol DOT net> <ebvsj3$bu7$1 AT sea DOT gmane DOT org> <200608162049 DOT k7GKnTTE024729 AT tigris DOT pounder DOT sol DOT net> <20060816211108 DOT GD27256 AT calimero DOT vinschen DOT de> <200608172349 DOT k7HNnaBK002833 AT tigris DOT pounder DOT sol DOT net> <20060818065817 DOT GP20467 AT calimero DOT vinschen DOT de> <200608181335 DOT k7IDZpmc008129 AT tigris DOT pounder DOT sol DOT net> <20060818142824 DOT GB18635 AT calimero DOT vinschen DOT de>
Date: Mon, 21 Aug 2006 11:13:26 -0500
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

On Fri 8/18/06 16:28 +0200 cygwin AT cygwin DOT com wrote:
> On Aug 18 08:35, Tom Rodman wrote:
> > On Fri 8/18/06 8:58 +0200 cygwin AT cygwin DOT com wrote:
> > > On Aug 17 18:49, Tom Rodman wrote:
> > > > 
> > > > tried that.. no joy, take a look:
> > > > --v-v------------------C-U-T---H-E-R-E-------------------------v-v-- 
> > > >   $ $WINDIR/system32/whoami /all #we're in an ssh session before edits made to /etc/group
> > > >   
> > > >   USER INFORMATION
> > > >   ----------------
> > > >   
> > > >   User Name  SID
> > > >   ========== =============================================
> > > >   DOMxx1\adm_usr1 S-1-5-21-1390067357-1202660629-682003330-5774
> > > 
> > > Must be a password logon session, otherwise you would not see this
> > > user name here, but sshd_server.
> > 
> > Your right, it is a *password authenticated* logon session, such sessions are
> > fine w/me for system administration work. On a separate issue, rightly
> > or wrongly we use an expect script w/cron to schedule cron jobs that
> > access and change files on network shares.
> 
> That's bad.  The user token created by cron is the same style as the
> user token created with ssh /w pubkey authentication.  The main problem
> is that the token has no network credentials.  There's no way around
> that, not for the time being, not ever.  

Our automated workaround is using a cron lauched expect script wrapper
to ssh back to the local host, sending the username and password, so
that a new ssh *password authenticated* session is used in the cron job.

> The only way to access network
> shares using a cron job is to access public shares, or the cron job has
> access to the necessary user/password combination and calls `net use'
> directly.  And even then, you can only access the shares directly
> (//server/share), not with drive letters.

right, we use UNC PATHs; also our mount table contains mounts w/UNC paths

> But, Tom, this is all not new.  This has been talked about in this list
> for years, really.  You should be able to find that information eaasily
> by googling.

I've known about the password authentication requirement for access to
network shares for years.  We've been using ssh sessions w/password
authentication, that therefore allows us to write to network shares, for years. :->

> > again - A home dir on a network share, works fine for us w/password
> > authentication, so the original post/problem is for the password
> > authentication case - sorry I did not make that clear :-<
> 
> The trick using /etc/group only works for password-LESS authentication,
> sorry for not mentioning it, but usually the problems reported here are
> with passwordless authentication so I just assumed this is the case here, too.  

A trick using /etc/group *does* work for password authentication - at
least for domain groups. We edit /etc/group, every day via a cron job -
we merge in a comma delimited list of usernames for all domain groups
a given ssh user is in; we do this for all users that need ssh access.
This became a requirement after we moved to a much larger domain -
without this workaround, even password authenticated ssh sessiosn did
not get write access to network shares.

  Related thread: http://cygwin.com/ml/cygwin/2005-07/msg01287.html

The following approach was inspired by Pierre A. Humblet; if I were to
get /etc/group configured correctly in a manual approach for just 1 user;
I would log in as the user that needs an ssh account, run this in a
console or RDP bash session:

  echo $(id -G|tr ' ' \\n|awk '$1 > 9999'|sort -n|tr \\n ,)|sed 's~,$~~'
    # "> 9999" because this approach is only applicable (or required) for domain groups AFAIK

  Ex:
    $ echo $(id -G|tr ' ' \\n|awk '$1 > 9999'|sort -n|tr \\n ,)|sed 's~,$~~'
    10513,16024,16025,16026,16027,19858,19968

Next edit /etc/group to append the respective username to each of the
above groups in the comma delimited list.  If this is done correctly,
then `id -G` lists the same groups at the console, as it does in a password
authenticated ssh session, and the user can write to network drives.
  
I'm not sure if it matters, but our domain has quite a few domain local groups,
and many of these are not seen by "mkgroup -l" or "mkgroup -d".  Pierre
speculated that our IT department may have done something to cause this - I
did some asking around but got no where on that.

> The /etc/group trick can work, though.  The code is just not in
> Cygwin.  I put this on my TODO list for an upcoming Cygwin version, but
> don't hold your breath.

thx/great

New Info:

  Over the weekend I ssh'd into the same w2k3 server w/password
  authentication using a local user account (all the cases I showed
  earlier were domain accounts). This local account, was an administrator,
  and this username does *not* show up anywhere in /etc/group. Windows
  "whoam /all" *did* show membership in S-1-2-0. Does that help the
  analysis at all?

> > It would be interesting to see if you or otheres can duplicate the problem,
> > using password authentication.
> 
> Yes, I can duplicate this with password authentication.  However, keep
> in mind that the token is generated by Windows.  The token is not
> further massaged by Cygwin, so whether or not the LOCAL group is
> available in the token is not under control of Cygwin.

ok

> > Yes I see the local group "S-1-2-0", but when I ssh'd in, I typed the
> > password in for this session and so I expect "whoami /all" to return
> > the username that goes with the password - more importantly I need the
> > credentials to write to the network shares, that I normally get when
> > using ssh via password authentication.
> 
> No go.  Either you use password authentication, then you get the correct
> username and network credentials, or you use pubkey authentication and
> Windows returns the wrong username and you don't have network credentials.
> I have a solution which allows to get the right username at one point
> (again, don't hold your breath), but when you don't give a password
> at logon time, where should the network credentials come from?  This
> will never work.
> 
> > I appreciate your help on this Corinna, *thank-you*.  Most work I do does
> > not seem to require membership in "S-1-2-0", so it's not that big a deal.
> > 
> > > This is a long standing problem, for
> > > years.  There's no workaround for the time being.  However, if you take
> > > a look into the user token of the process using other means
> > > (OpenProcessToken/GetTokenInformation), you'll see that the token user,
> > > as well as the token owner is set to the user account you logged in to,
> > > DOMxx1\adm_usr1 in this case.  
> > 
> > Thanks, I trust your right, I don't have the experience or time to
> > write a simple tool using (OpenProcessToken/GetTokenInformation); maybe
> > I can google and find such a tool..
> 
> Take the attached file and compile with g++.  It's my crude token
> helper application I'm using for some years now.  It shows the
> access token you're using when calling the application.  The SIDs are
> not translated in user or group names because I don't need that.
> Without arguments, everything but the user rights are printed,
> with any argument, it also prints the user rights.

thank-you!  I have saved the file, will try it in a few days.

--snip

--
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/