X-Spam-Check-By: sourceware.org 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> <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 X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk 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 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/