user/group mapping for NFS

user/group mapping for NFS

[Charles Hedrick]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1015 bytes --]

We have a system that is doing a Kerberized NFS mount of directories on Linux. We have our LDAP system set up as a mapping server, with samaccountname added to users so that the Windows mount command does the mount as the right user.

ls -l causes a query that looks like (&(objectClass=posixAccount)(uidNumber=26780))" attrs=“uid”. We sent back a response. If there’s a local account for the user, “ls -l” shows them. But we only have loal accounts for people who actually use the Windows box. I’d like “ls -l” to work for everyone. It appears that cygwin generates SIDs for entries in /etc/passwd. How can I make it do that for kid’s returned from LDAP? I’m willing to generate SIDs and put them in LDAP, but it doesn’t look like Cygwin is asking for a SID.

\0ТÒÐÐ¥\a&ö&ÆVÒ\a&W\x06÷'G3¢\x02\x02\x02\x02\x02\x02\x06‡GG\x03¢òö7–wv–âæ6öÒ÷\a&ö&ÆV×2æ‡FÖÀФd\x15\x13¢\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x06‡GG\x03¢òö7–wv–âæ6öÒöf\x17\x12ðФFö7VÖVçF\x17F–öã¢\x02\x02\x02\x02\x02\x02\x02\x02\x06‡GG\x03¢òö7–wv–âæ6öÒöFö72æ‡FÖÀÐ¥Vç7V'67&–&R\x06–æfó¢\x02\x02\x02\x02\x02\x06‡GG\x03¢òö7–wv–âæ6öÒöÖÂò7Vç7V'67&–&R×6–×\x06ÆPРÐ

Re: user/group mapping for NFS

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 3194 bytes --]

Hi Charles,

On Jan 10 15:24, Charles Hedrick wrote:
> We have a system that is doing a Kerberized NFS mount of directories
> on Linux. We have our LDAP system set up as a mapping server, with
> samaccountname added to users so that the Windows mount command does
> the mount as the right user.
> 
> ls -l causes a query that looks like
> (&(objectClass=posixAccount)(uidNumber=26780))" attrs=“uid”. We sent
> back a response. If there’s a local account for the user, “ls -l”
> shows them. But we only have loal accounts for people who actually use
> the Windows box. I’d like “ls -l” to work for everyone.

Sorry, I don't understand the problem, maybe because I'm looking at it
from the other side.

ls -l calls stat(2).  Stat(2) on NFS returns the uids and gids returned
by a stat(2) call on the NFS server.  ls -l then calls (basically)
getpwuid(3)/getgrgid(3) which in turn ask the account server via LDAP;
differently, depending on the server being AD or non-AD LDAP.

If there's no mapping from a uidNumber/gidNumber to a SID in AD, nor a
mapping from uidNumber/gidNumber to an account name ("uid" for users,
"cn" for groups) in LDAP, Cygwin will create a mapping in memory on the
fly.  Example:

  $ ls -l foo
  -rwxr-xr-x 1 Unix_User+4 Unix_Group+7 47456 Oct 30  2015 foo

So the fake account names are "Unix_User+<uid>" and "Unix_Group+<gid>"
The Cygwin uids/gids follow a certain computation rule (details don't
matter here) which is used for Samba accounts as well.  Ultimately
the in-memory passwd and group entries look like this:

  $ getent passwd Unix_User+4
  Unix_User+4:*:4278190084:4278190084:U-Unix_User\4,S-1-22-1-4:/:/sbin/nologin
  $ getent group Unix_Group+7
  Unix_Group+7:S-1-22-2-7:4278190087:

> It appears that cygwin generates SIDs for entries in /etc/passwd.

No, it generates the info on the fly in memory.  In fact, if there's
info in /etc/passwd or /etc/group, and if /etc/nsswitch.conf is set up
to actually _use_ these files (*), you can override the user name to
something more readable:

  $ echo 'MyUser:*:4278190084:4278190084:U-Unix_User\4,S-1-22-1-4:/:/sbin/nologin' >> /etc/passwd
  $ echo 'MyGroup:S-1-22-2-7:4278190087:' >> /etc/group

  [exit from Cygwin terminal, start a new one]

  $ ls -l foo
  -rwxr-xr-x 1 MyUser MyGroup 47456 Oct 30  2015 foo

For the more exact details how to use /etc/nsswitch.conf and how the
mapping is performed, see

(*) https://cygwin.com/cygwin-ug-net/ntsec.html

> How can I make it do that for kid’s returned from LDAP? I’m willing to
> generate SIDs and put them in LDAP, but it doesn’t look like Cygwin is
> asking for a SID.

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.

Does this help?


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: user/group mapping for NFS

[Charles Hedrick]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1111 bytes --]

On Jan 10, 2019, at 12:57 PM, Corinna Vinschen <corinna-cygwin@cygwin.com<mailto:corinna-cygwin@cygwin.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.

I’d like it to act as if there was something in /etc/passwd. It’s got all the information it needs to generate an /etc/passwd entry from LDAP.

nsswitch is files db, or missing, which should default to files db.


\0ТÒÐÐ¥\a&ö&ÆVÒ\a&W\x06÷'G3¢\x02\x02\x02\x02\x02\x02\x06‡GG\x03¢òö7–wv–âæ6öÒ÷\a&ö&ÆV×2æ‡FÖÀФd\x15\x13¢\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x06‡GG\x03¢òö7–wv–âæ6öÒöf\x17\x12ðФFö7VÖVçF\x17F–öã¢\x02\x02\x02\x02\x02\x02\x02\x02\x06‡GG\x03¢òö7–wv–âæ6öÒöFö72æ‡FÖÀÐ¥Vç7V'67&–&R\x06–æfó¢\x02\x02\x02\x02\x02\x06‡GG\x03¢òö7–wv–âæ6öÒöÖÂò7Vç7V'67&–&R×6–×\x06ÆPРÐ

Re: user/group mapping for NFS

[Charles Hedrick]

Incidentally, I’m actually more concerned about groups than users. Users could reasonably want to do chgrp to adjust group membership of a file or directory, but they can’t do much about user. However it would be nice to see the real user as well.

On Jan 10, 2019, at 12:57 PM, Corinna Vinschen <corinna-cygwin@cygwin.com<mailto:corinna-cygwin@cygwin.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.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: user/group mapping for NFS

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 914 bytes --]

On Jan 10 20:28, Charles Hedrick wrote:
> On Jan 10, 2019, at 12:57 PM, Corinna Vinschen <corinna-cygwin@cygwin.com<mailto:corinna-cygwin@cygwin.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).


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: user/group mapping for NFS

[Charles Hedrick]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1430 bytes --]

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.

> On Jan 11, 2019, at 4:17 AM, Corinna Vinschen <corinna-cygwin@cygwin.com> wrote:
> 
> On Jan 10 20:28, Charles Hedrick wrote:
>> On Jan 10, 2019, at 12:57 PM, Corinna Vinschen <corinna-cygwin@cygwin.com<mailto:corinna-cygwin@cygwin.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).
> 
> 
> Corinna
> 
> -- 
> Corinna Vinschen
> Cygwin Maintainer

\x03B‹KCB”\x1c›Ø›\x19[H\x1c™\^[ܝ\x1cΈ\b\b\b\b\b\b\x1a\x1d\x1d\x1c\x0e‹ËØÞYÝÚ[‹˜ÛÛKÜ\x1c›Ø›\x19[\Ëš\x1d^[[\x03B‘TNˆ\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\x1a\x1d\x1d\x1c\x0e‹ËØÞYÝÚ[‹˜ÛÛKÙ˜\KÃB‘^[ØÝ[Y[\x18]\x1a[ÛŽˆ\b\b\b\b\b\b\b\b\x1a\x1d\x1d\x1c\x0e‹ËØÞYÝÚ[‹˜ÛÛKÙ^[ØÜËš\x1d^[[\x03B•[œÝXœØÜšX™H\x1a[™›Îˆ\b\b\b\b\b\x1a\x1d\x1d\x1c\x0e‹ËØÞYÝÚ[‹˜ÛÛKÛ[\vÈÝ[œÝXœØÜšX™K\Ú[\^[\x19CBƒB

Re: user/group mapping for NFS

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2509 bytes --]

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@cygwin.com> wrote:
> > 
> > On Jan 10 20:28, Charles Hedrick wrote:
> >> On Jan 10, 2019, at 12:57 PM, Corinna Vinschen <corinna-cygwin@cygwin.com<mailto:corinna-cygwin@cygwin.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


Corinna

(*) 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]