user/group mapping for NFS

Corinna Vinschen
Fri Jan 11 16:26:00 GMT 2019

Please don't top-post.

On Jan 11 14:47, Charles Hedrick wrote:
> > On Jan 11, 2019, at 4:17 AM, Corinna Vinschen <> wrote:
> > 
> > On Jan 10 20:28, Charles Hedrick wrote:
> >> On Jan 10, 2019, at 12:57 PM, Corinna Vinschen <<>> wrote:
> >> 
> >> 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.
> >> 
> >> In my scenario there’s nothing in /etc/passwd, AD, or SAM for most users, but they are all available from LDAP.
> > 
> > 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’t
> want to have to update a file on all windows machines. That’s 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


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

Corinna Vinschen
Cygwin Maintainer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <>

More information about the Cygwin mailing list