DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:cc:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=Mu+lOynV7200OpHQYtLhtJHRQPMdSh3iZji4hy7DoCfSDtTGnstbX
	FFOC00Cl3364B03No6pN2hBcD0H+G2K0Nd12AmhEug0m7DhfxJXCBull5SR3Xh/X
	zHwkzVl0N3YSPeuhAmURvBYhWadLzPq6PbpWhsgmgrvhHf1+3cK/tE=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Date: Wed, 6 Mar 2019 15:17:16 +0100
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: Stephen Carrier <carrier AT berkeley DOT edu>
Cc: cygwin AT cygwin DOT com
Subject: Re: sshd problem on WS2008R2 64bit
Message-ID: <20190306141716.GS3785@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: Stephen Carrier <carrier AT berkeley DOT edu>, cygwin AT cygwin DOT com
References: <20190306010254 DOT GA4210 AT zebra> <20190306121154 DOT GN3785 AT calimero DOT vinschen DOT de> <20190306124816 DOT GR3785 AT calimero DOT vinschen DOT de>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;	protocol="application/pgp-signature"; boundary="WjWU9mUuKzTKEtBb"
Content-Disposition: inline
In-Reply-To: <20190306124816.GR3785@calimero.vinschen.de>
User-Agent: Mutt/1.11.3 (2019-02-01)

--WjWU9mUuKzTKEtBb
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mar  6 13:48, Corinna Vinschen wrote:
> On Mar  6 13:11, Corinna Vinschen wrote:
> > On Mar  5 17:02, Stephen Carrier wrote:
> > > Since upgrading a WS2008 R2 system to 3.0.1, attempts to ssh to the s=
erver
> > > fail unless some user logs into Windows first.  In this case, that is=
 by
> > > RDP, and it doesn't need to be the same user as the one logging in by=
 ssh.
> > > After logging out of the windows-native session, ssh continues to wor=
k.
> > >=20
> > > Windows event logs report a failed attempt for "NULL SID" and
> > >=20
> > > ----
> > > Failure Reason: An error occured during Logon.
> > > Status:         0xc00000bb
> >=20
> > This is weird.  Status 0xc00000bb is STATUS_NOT_SUPPORTED.  That
> > doesn't make sense, at least not on 2008 R2 with 64 bit Cygwin.
> >=20
> > Are you trying to login via sshd with a local account or a domain
> > account?
> >=20
> > I tried to reproduce your issue with Cygwin 3.0.2 on a Windows 10
> > machine.  I rebooted the machine and did not login locally or via
> > RDP.  Sshd login worked in both cases (local/domain account).
> >=20
> > Can you test this again, in particular with installing Cygwin 3.0.2?
> >=20
> > In the meantime, I need some time to set up a Windows 2008 R2
> > machine for testing.
>=20
> Never mind, I can reproduce the problem on Windows 7, but only
> for local machine accounts.  Domain accounts work fine.

This is *so* weird.

When I run the service under the cyg_server account, then the S4U logon
for the local SAM user works as expected, even right after reboot.
The weird thing here is that my cyg_server account is a domain account.

What this has to do with the MsV1_0S4ULogon for a local SAM account
beats me.  The only explanation I have for that is that the service
running under the domain cyg_server account constitutes some kind of
"local login", so MsV1_0S4ULogon subsequently starts working.

This cyg_server account does not necessarily require the "create token"
permission anymore, of course.

Big sigh here.

With S4U I had hoped to catch two birds with one stone:

- Getting rid of two old methods, cyglsa and "create token".

- Dropping the requirement for the cyg_server account.

But the old Systems like Windows 7 don't want to play nice.

- On Vista and Windows 7 WOW64, MsV1_0S4ULogon isn't implemented
  at all, which required to keep the create_token method
  available

- On Vista and Windows 7 MsV1_0S4ULogon does not work without
  some user logged in locally, even if it's just the cyg_server
  service account.

Question is, what is a good solution?  Reverting cyglsa as=20
well to allow the old methods to work as before?  This is
the opposite of what I had hoped to accomplish :(


Corinna

--=20
Corinna Vinschen
Cygwin Maintainer

--WjWU9mUuKzTKEtBb
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAlx/1mwACgkQ9TYGna5E
T6A8Qg/9FfmWWRvA1+BkdMat4PMRy5a5yEzYSNm/fs9VpkXC6APIqmTfhG3E2DHr
4nncAJ6pdW06WB64vuyysHhYvD7NfV27wZq01PYzg5WTU+IoVoFrvclduEURTvib
TFRXt2fcWn75s468ahSFynHzuBawqD37Jeew2h1ejbkuq2nWvKLc/6edYZYOc3ZN
NKikDoLUasFj5lXgL+f5FVn8LkqjjJTDhklE75JMYT0y2hJcZmrsrUCeOukH32Ae
my2zTNSf4JyEcbew8kPjhveaJgXiBhAIEOhwvdQXB4ctJ879+RAgkybxIE03hdAx
QYS50PxL0pxCW+ILzWwYDvfbT3J0kw/m8Cz4KZFj3xk4C6MVVjzPD8dTXXvX44pB
8ZkvuKZPDgii+URdlmtRJNxaPy2iDhw+vQ3jgQwRgYNnIY8NopdsT0DU+ERe+GBH
lL5A02OXPmHE4940AIXZilRx878lJp0K9QyXrDaALFv8oxcMWpSrpTl9FkOuxP35
6FVbMJELa9Z/+9mR3eiZoJhvWn7K0dwlGNbUsbuEXQOdFOEhhTzDROo2n7tFXgi4
KOievZQRNmdEdNEzJRIV7FV7eo2M07qb8s93WMQ/GSJKpNiNpPBhTxbJ+FVuyO2w
TdsKINk89eWfwa6chG3Dm2p5Ddji6hIlVxGhNvf1BMQYJLRGawY=
=rcp+
-----END PGP SIGNATURE-----

--WjWU9mUuKzTKEtBb--