Web lists-archives.com

Re: ssh-host-config: patch fix debug option + broken for me on Vista (non-domain)

On Jan 23 14:12, Shaddy Baddah wrote:
> On 21/01/17 09:40, szgyg wrote:
> > On 1/19/2017 7:16 PM, Corinna Vinschen wrote:
> >> The idea is that if LOGONSERVER == COMPUTERNAME your
> >> machine is not in a domain.  Actually, I *never* encountered an
> >> environment
> >> in which LOGONSERVER isn't set.
> >
> > It's empty if you're using RunAs.
> Thank you szgyg. This is on the right track. There is a variation. I
> didn't use the RunAs command.
> Instead I did what I think is the almost 100% use case for running
> ssh-host-config. Which is to launch mintty by select "Run as
> administrator", elevate privilege to allow the script to add users and
> services, etc.
> The difference is as follows. And I test for this. I login to the
> desktop as a non-administrator. When I select "Run as administrator" I
> am prompted to enter a password for (one of) the administrator users.
> That mintty (and cmd prompt too obviously) do not have LOGONSERVER set.

Yes, you're both right, but it's even more weird.  If I use "RunAs" from
an unprivileged user account, and the Admin account I "RunAs" as is
logged on in another terminal session at the same time, the "RunAs"
session has LOGONSERVER set.  Something isn't quite right in the

> Also, there is another use case which I haven't tried, but I would feel
> would result in no LOGONSERVER as well... not sure. I can try it as I
> complete this email...
> That is logging in to an administrator user via ssh itself.

No, that works as desired with LOGONSERVER set.

> As an aside... doesn't seem like the administrator user has the elevated
> privileges anymore. It was the case in the past. I never picked up on
> that change.

I don't understand what you mean here.  The privileges are not in the
user token of the non-privileged processes in a non-elevated session,
but as soon as you use "runas", the privileges are in the user token.

> To that end, please find attached the patch to fix the LOGONSERVER
> problem. I think it should be fine for a domain environment. Because if
> you run as a domain assigned local administrator, LOGONSERVER will be
> set, even on a "Run as administrator".
> If you just run as a local computer administrator (whatever the
> accurate terminology is here), then you will have an empty LOGONSERVER
> and the script will run for the local user.

No, that's not right.  If you run a logon session as a local admin (in
contrast to running a process via "RunAs"), LOGONSERVER will be set

I'm also not quite sure if the patch is right.  The comment preceeding
the check explains what we want.  The idea is this (omitting the
extra test for "MicrosoftAccount"):

   # This test succeeds on domain member machines only, not on DCs.
    if [ "\\\\${COMPUTERNAME,,*}" != "${LOGONSERVER,,*}" ]
      # Lowercase of USERDOMAIN

COMPUTERNAME is the same as LOGONSERVER on non-domain machines as well
as on domain controllers.  So this `if' test if the machine is a domain
member machine.

If it is, local accounts will have the Cygwin username
"$COMPUTERNAME+$username", while on non-domain machines and DCs the
Cygwin username of a local user will be "$username" only,

This is according to the rules of automatic username generation per

What your patch does is to handle an empty LOGONSERVER as an indicator
that we're on a domain member machine.  This doesn't look right to me.

So the basic question is this:  Assuming I'm running a simple bash
script, and assuming I can't rely on the value of LOGONSERVER for the
test on being a domain member machine, how *can* I check for that?
nltest, somehow?  But as far as I can see, nltest was only bundeled
with Windows 7 and later...  Do we have to write another helper tool?


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Attachment: signature.asc
Description: PGP signature