On Mar  6 13:47, Bill Stewart wrote:
> On Wed, Mar 6, 2019 at 1:14 PM Corinna Vinschen wrote:
> 
> > > > > What precisely happens when Cygwin uses MSV1 S4ULogon on versions
> older
> > > > > than 6.3 before a user has logged on?
> > > >
> > > > MsV1S4ULogon returns with STATUS_NOT_SUPPORTED.  Funny status code,
> > > > given it works if some user already logged in by other means...
> > >
> > > OK, so here's another potential workaround that doesn't require running
> the
> > > service as a specific user...
> > >
> > > Create a scheduled task to run using the following settings:
> > >
> > > General -> Run using user account - > choose a local account
> > > General -> "Run whether user is logged on or not"
> > > Triggers -> Run at system startup
> > > Actions -> Start a program -> Program/script:
> %SystemRoot%\Cystem32\cmd.exe
> > > Actions -> Start a program -> Add arguments: /c exit
> > >
> > > Full password logon is required (seems we can't use "do not store
> password"
> > > option).
> > >
> > > The local account does not have to be a member of Administrators, but it
> > > does require user right "Log on as a batch job" (SeBatchLogonRight).
> > >
> > > In my prefunctory testing this seems to fix this problem.
> > >
> > > Does this work?
> >
> > This does indeed work in my local testing on Windows 7, with a local
> > dummy user just for this scheduled job and sshd running under SYSTEM.
> >
> > Now, if that's a feasible workaround for users of these older
> > systems...?
> 
> Good -- this works for me also. (My wild guess, which may be wrong, is that
> the older OS versions don't initialize MSV1 S4ULogon for some reason until
> somebody logs on.)
> 
> Whether this workaround is feasible likely depends on the end user. The
> workaround has its own limitations. Here are at least 2 that I can think of
> right now:
> 
> 1. The local user must have "Log on as a batch job" (SeBatchLogonRight)
> user right.
> 
> 2. The "Network access: Do not allow storage of passwords and credentials
> for network authentication" security policy must be set to "Disabled". (If
> this policy is set to "Enabled", then you can't create scheduled tasks with
> stored passwords.)
> 
> It's a weird problem. The best option would be for Microsoft to provide a
> fix (if we can provide a short example program that reproduces it).

I'm reasonably sure there won't be any fix for these systems for at
least two reasons:

- All affected systems are EOLed or in the last year of their Extended
  Support Cycle, all ending on 2020-01-14.

- I opened a support case for an older Windows release a couple of years
  ago.  A fix for the problem has been refused because the problem was
  fixed in the newer OS.  I got told literally that the fix is to upgrade
  to the newer OS.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer