user/group mapping for NFS
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 <email@example.com> wrote:
> > On Jan 10 20:28, Charles Hedrick wrote:
> >> On Jan 10, 2019, at 12:57 PM, Corinna Vinschen <firstname.lastname@example.org<mailto:email@example.com>> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: not available
More information about the Cygwin