Mail Archives: cygwin/2006/08/21/12:13:48
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/
- Raw text -