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
backgrounds...

> 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
to \\$COMPUTERNAME.

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,,*}" ]
    then
      # Lowercase of USERDOMAIN
      csih_PRIVILEGED_USERNAME="${COMPUTERNAME,,*}+${username}"
    fi

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
https://cygwin.com/cygwin-ug-net/ntsec.html,

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

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