From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 91468 invoked by alias); 11 Jan 2019 16:26:07 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 91458 invoked by uid 89); 11 Jan 2019 16:26:07 -0000 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 Received: from mout.kundenserver.de (HELO mout.kundenserver.de) (212.227.126.134) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 11 Jan 2019 16:26:05 +0000 Received: from calimero.vinschen.de ([24.134.7.25]) by mrelayeu.kundenserver.de (mreue011 [212.227.15.167]) with ESMTPSA (Nemesis) id 1MfYgC-1hATkf1FQO-00g2JH; Fri, 11 Jan 2019 17:26:01 +0100 Received: by calimero.vinschen.de (Postfix, from userid 500) id 79B52A80758; Fri, 11 Jan 2019 17:26:00 +0100 (CET) Date: Fri, 11 Jan 2019 16:26:00 -0000 From: Corinna Vinschen To: Charles Hedrick Cc: cygwin@cygwin.com Subject: Re: user/group mapping for NFS Message-ID: <20190111162600.GY593@calimero.vinschen.de> Reply-To: cygwin@cygwin.com Mail-Followup-To: Charles Hedrick , cygwin@cygwin.com References: <0562D98D-714A-4620-878E-B37282E8F688@rutgers.edu> <20190110175718.GN593@calimero.vinschen.de> <9DE7A0B2-68EB-4DA2-99AD-AA3693F1651E@rutgers.edu> <20190111091750.GT593@calimero.vinschen.de> <8BCE0CCE-61B9-49E7-A213-35BE60CAC3C5@rutgers.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) X-SW-Source: 2019-01/txt/msg00076.txt.bz2 --MM5RgFPKyuP3gDcV Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 2489 Please don't top-post. On Jan 11 14:47, Charles Hedrick wrote: > > On Jan 11, 2019, at 4:17 AM, Corinna Vinschen wrote: > >=20 > > On Jan 10 20:28, Charles Hedrick wrote: > >> On Jan 10, 2019, at 12:57 PM, Corinna Vinschen > 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" Content-length: 833 -----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--