X-Recipient: archive-cygwin AT delorie DOT com
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=esA1RuD8pDhXML5M76Ku8xQLi6YEJdvxHATII4Pzgw/BaoN8lhZ6r
	E5sD5ILzJKrzwc7SGYiD9KE7tk9xHC5RBthZd7X7dQrbH0+xC5zeNs+ougA1iSpo
	K9d6KHZ2n95En80Jv6boG2VkXhLZd1O5hZYTto9xVBPlUlFCTJlw5I=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; 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; s=default;
	 bh=uMaycSe2/N0K1aBeSSsnx35CF3g=; b=h0+TDSJCqpzqWf7yqOMVno59Gfy7
	S6DZnbWV3/X/WrSYkTjj107pMHc+A72Np6fZiRQpRwIkq6tbrDwa35xKVCyAMgf3
	1rTRGvV+KKCLZNQ663aFjJ5+RsgYRrQRSEUyQZiv0sKbUx1RKIeh0TCk0Jrngo9W
	HO1WyB5oYSi1VXs=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=-100.9 required=5.0 tests=BAYES_00,GOOD_FROM_CORINNA_CYGWIN,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=dbs, Hx-languages-length:2447, H*F:D*cygwin.com
X-HELO: mout.kundenserver.de
Date: Fri, 11 Jan 2019 17:26:00 +0100
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: Charles Hedrick <hedrick AT rutgers DOT edu>
Cc: cygwin AT cygwin DOT com
Subject: Re: user/group mapping for NFS
Message-ID: <20190111162600.GY593@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: Charles Hedrick <hedrick AT rutgers DOT edu>, cygwin AT cygwin DOT com
References: <0562D98D-714A-4620-878E-B37282E8F688 AT rutgers DOT edu> <20190110175718 DOT GN593 AT calimero DOT vinschen DOT de> <9DE7A0B2-68EB-4DA2-99AD-AA3693F1651E AT rutgers DOT edu> <20190111091750 DOT GT593 AT calimero DOT vinschen DOT de> <8BCE0CCE-61B9-49E7-A213-35BE60CAC3C5 AT rutgers DOT edu>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;	protocol="application/pgp-signature"; boundary="MM5RgFPKyuP3gDcV"
Content-Disposition: inline
In-Reply-To: <8BCE0CCE-61B9-49E7-A213-35BE60CAC3C5@rutgers.edu>
User-Agent: Mutt/1.10.1 (2018-07-13)

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

Please don't top-post.

On Jan 11 14:47, Charles Hedrick wrote:
> > On Jan 11, 2019, at 4:17 AM, Corinna Vinschen <corinna-cygwin AT cygwin DOT co=
m> wrote:
> >=20
> > On Jan 10 20:28, Charles Hedrick wrote:
> >> On Jan 10, 2019, at 12:57 PM, Corinna Vinschen <corinna-cygwin AT cygwin.=
com<mailto:corinna-cygwin AT cygwin DOT com>> wrote:
> >>=20
> >> Well, it should.  What happens is this:  After asking the non-AD LDAP
> >> server for the account name, it asks the account fetching algorithm for
> >> that name from scratch.  This depends on the /etc/nsswitch.conf
> >> settings, of course (*).  Assuming "passwd: files db", it first checks
> >> the local /etc/passwd file for a matching entry for that account name,
> >> then the OS, preferring AD on an AD member machine, then local SAM.
> >>=20
> >> In my scenario there=E2=80=99s nothing in /etc/passwd, AD, or SAM for =
most users, but they are all available from LDAP.
> >=20
> > Sure there's nothing in /etc/passwd.  The file is created by *you* on
> > demand, not automatically by Cygwin (except on older releases).
>
> I have thousands of users and they change all the time. I really don=E2=
=80=99t
> want to have to update a file on all windows machines. That=E2=80=99s the
> point of having LDAP.

Then you'll have to debug why you don't get the right info.  I don't
have a setup with a non-AD LDAP server, I just have AD for testing, and
with AD everything works as expected.

Again, what's supposed to happen with non-AD LDAP:

- For a user id "uidNumber" ask LDAP for the user name "uid".

- For a group id "gidNumber" ask LDAP for the group name "cn".

- If Cygwin gets a valid result of one of the above, ask all available
  sources (AD, local SAM, /etc/passwd, /etc/group) for the user name or
  group name.  If one is returned, use the available info.  This usually
  accounts for an in-memory passwd or group entry with the user/group
  name and the Windows SID of the user, *iff* it's available in one of
  the above sources.

- If that's not sufficient, somebody(*) will have to come up with a
  Cygwin patch, implementing and documenting another method, e.g.,
  something like a documented SID storage in a standard RFC 2307 LDAP
  server as an extension to the current technique.  Ideally without
  breaking the current implementation


Corinna

(*) Not me.  I already spent months implementing and debugging the
    current methods of fetching info from Windows user DBs on the fly.

--=20
Corinna Vinschen
Cygwin Maintainer

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

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

iQIzBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAlw4w5gACgkQ9TYGna5E
T6DyyA//b62EBl1KEm3BkSCHqPaCXwghhrS3YqZQIPOPeOSvMJySfWzSMVutBpEk
K+Acf/+LLGEdy8hdMPkXqi+rG5DIeoTlwUY8nA7A2yjQeg/osHWFKEX6lAyCtwoK
sLC/5disvf3ADvkwpSI2Fj/1ez7bwGYHSk/7ljJP+nW4BgkeIiuLfYC+uUAikBa1
xLdarrsHYUcQeFia80/dixVtufyG6f8xhBlvuOEkWzQdigM4Tgs52bxVRUZU5pLw
x780CRs8i4an5Vr8vtpvi63YPyRQLKA3+MxXsnly512HeM011AEcx3DfbdQ9g6Wm
VCcTtM3+z8g1Ff3qEFpgRYd9RLj/7pRsAIpNc8cRBd90yORAVVGw2704czcG68i5
pXXH5x9uiN0EnTZWsdHPAv6YrQq6V0KKwtDQKkyBkqQuast+i70VwXb2g6guctNJ
rlAM9HTFEPMlZYZlNCbjaPuJ0YhXTgPImIsmqe4C35YIikv6bTogwCCbXWwucz5d
zchDuNQkG+dbMF6CUU5CVbUpEHjRUMNfDGpHschKjjD9cG+M+/6/+ACN0qGBoCQ/
dDOkZaO9qfbddYcDcrFxtr9LUqspav1DPD5eYB0E3WKNkAdQUAxJNH2a75yRDrg2
gKwhE6ybn+JBp9d0aqgTVxfTnkXq59Svk/MPXPOz+fRgqj3aMnc=
=NSMC
-----END PGP SIGNATURE-----

--MM5RgFPKyuP3gDcV--