[Samba] samba 4 and nfs permissions

[Bernd Markgraf]

Hi Steve,

I'll cc to the samba list so other's get the details as well.

> > Mapping user ids seems to be a problem in various places. I run Samba4
> > as AD for a bunch of (virtual) Windows 7 machines and as Kerberos/LDAP
> > server for some Solaris and Linux boxes and Samba3 on the fileserver. I
> > extended the original LDAP schema on the S4 side to include the posix
> > UID/GID bits (rfc 2307 iirc) - not sure if this has made it into the
> > current tree yet.
> Hi Bernd.
> 
> Does that mean it will eventually be part of Samba 4? Window clients are 
> fine. Samba 4 seems to have forgotten about Linux clients.
I think I filed a RFE for this. Haven't checked the latest sources
though. I'm still running a snapshot from over a year ago.
I'm not sure if the real AD comes with this schema per default or if you
have to install that later to make use of UNIX/Posix bits.

> > In my case I create new users with the Windows Management Console (give
> > the fellow admins an easy start). That sets up the Windows related
> > things. Second step ist to user ldapmodify to add the needed Unix bits
> > to that account. Wrapped in a litte script to fetch the next free
> > UIDNUMBER, add and create the user's home directory, chown and chmod as
> > required etc. The last bit which seems to be important to make things
> > work nicely is to add a hard UID:SID mapping on the fileserver running
> > the Samba fileserver:
> > /opt/samba/bin/wbinfo --set-uid-mapping=$UIDN,`/opt/samba/bin/wbinfo -n $UID`
> 
> OK I think I've got that bit. I can create a Samba 4 user from Windows 7 
> using dsa.msc. I can see the user using wbinfo -i user on the Samba 4 
> server. OK so far. Now, the next bit is what I need. I want to use nfs 
> on the samba 4 server to export the /home folder. Linux clients the 
> authenticate against Samba 4 and are placed in their /home folder. I 
> think you are saying I need to add UID attributes to the Samba 4 ldap no?
Ah I think I see your problem here. The machine that runs the Samba4
would need to use the Samba4 bits for nameservice. That is usually not
recommended (imagine a Unix box booting and trying to lookup a username
via LDAP when the LDAP server is not yet ready to serve requests - you
may work around this by having a replica though). In any case you would
need proper Unix user accounts for that to work reliably.
I usually check for users with getent passwd username
That way I know whether the OS can properly resolve usernames.

> > UIDN being the UNIX UIDNUMBER and UID being the user's login name. That
> > makes the job for Samba3 easier as it doesn't need to figure out the
> > mapping by itself. One could argue that it would be nice if Samba
> > checked for the existence of the posix uid number and use that for a
> > mapping but there may be cases where someone would like to have a
> > different behaviour. For us it works very well though.
> > Also I never really had the need to create unix accounts on the fly for
> > existing Samba/Windows users. Once those exist in LDAP I prefer them to
> > carry the appropriate UNIX attributes as well.
> 
> I can't see where your Samba 3 fileserver fits in. Is it doing the same 
> job as my nfs server as described above?
The fileserving bits were (are?) not ready for prime time when I set
things up. It was (is?) recommended to use Samba3 for fileserving. So I
have one Solaris10 machine running Samba4 which does LDAP and Kerberos
for all clients (Windows and Solaris and Linux). All authentication runs
against the data in Samba4. The Samba4 fileserver ONLY holds rudimentary
bits of the user profiles and th group policies. Most things in the
profile are redirected (group policy folder redirection) to the real
fileserver.
A second Solaris10 machine runs the fileserver (lots of local storage).
This is where the home directories are stored and served out via NFSv4
to the Solaris clients, via NFSv3 to the Linux clients and via Samba3 to
the windows clients. The Samba3 on this machine is joined to the Samba4
domain to fetch the users for Windows clients. The OS (Solaris10) uses
its native LDAP/Kerberos clients to authenticate and resolve the Unix
users (RFC2307 schema).
The Samba4 machine does not run an NFS server.
There was a project codenamed Franky iirc to use a mix of Samba4 and
Samba3 on the same machine. In essence Samba4 for the nameservice part
and Samba3 for the fileserver related bits. I never gave that a real try
though so I cannot comment on the chances here.

> To simplify, I have:
> 1. Samba 4 server which is also a nfs server for /home.
> 2. A Linux client with /home mounted via nfs
> 3. A Windows client
> The windows client is fine. It can create and edit files. The Linux 
> client can authenticate but cannot reach his home folder because his uid 
> is wrong.
Most certainly because the OS on the machine running the Samba4 server
doesn't know about the users you have in your Samba4 domain. I don't
know a lot on how to setup a box with pam winbind and co to fetch users.
I very much prefer LDAP+Kerberos for this.

> In your setup can both a Linux and a Windows client authenticate, see 
> and edit the same set of files?
Yes. As mentioned above I use folder redirection on the Windows clients
to store data in the 'real' home directory. I even have some folders
(semantically and physically) shared between the Unix and Windows
clients (most notably 'Desktop').

> > The Samba3 part runs on a Solaris10 box (the script to modify the
> > account and add the mapping runs on the same machine) but it should work
> > the same way on a Linux machine.
> This is where I'm lost. How does your Samba 3 box get the files to 
> serve? Aren't those files on the Samba 4 server?
The files are local to the Samba3 server, i.e. local storage. One could
NFS mount the homes from somewhere else though (of course not
recommended due to expected problems regarding file locking etc) as long
as all machines share a common namespace and userbase (in my case user
data in the LDAP directory)

Let me give an example of an LDAP entry of one of the users and comment
on the interesting parts (local domain names XXXXX'd):
dn: CN=Matlab User,CN=Users,DC=dzne,DC=XXXXXXX
        CN: Matlab User
        sn: User
        givenName: Matlab
        instanceType: 4
        whenCreated: 20100517130530.0Z
        displayName: Matlab User
        uSNCreated: 29730
        name: Matlab User
        primaryGroupID: 513
        sAMAccountName: matuser
        sAMAccountType: 805306368
        userPrincipalName: matuser at XXXXXX
        objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=dzne,...
        pwdLastSet: 129185751300000000
        userAccountControl: 512
        uid: matuser
        uidNumber: 1020
        gidNumber: 100
        homeDrive: Z:
        homeDirectory: \\niihau\matuser
        profilePath: \\kauai\profiles\matuser
        loginShell: /bin/bash
        homedirectory: /home/matuser
        msSFU30NisDomain: local
        msSFU30Name: matuser
        scriptPath: \\kauai\netlogon\people.bat
        objectClass: top
        objectClass: person
        objectClass: posixAccount
        objectClass: shadowAccount
        objectClass: organizationalPerson
        objectClass: user
        msDS-SupportedEncryptionTypes: 0
        whenChanged: 20100517131031.0Z
        uSNChanged: 29743
        distinguishedName: CN=Matlab User,CN=Users,DC=dzne,DC=XXXX
        gecos: Matlab User

Common Name is pretty obvious. sAMAccountName is the Windows logon name.
uid and following lines are the posix related parts. homedrive: Z: and
homedirectory: \\niihau\matuser is the mapping for the user's home
folder/drive on the Windows client. niihau is the fileserver running
Samba3. profilePath: \\kauai\profiles\matuser resides on the Samba4
server.
As you see the LDAP user account holds information for both Windows
clients and Unix clients (password/authentication runs via Kerberos).
So all machines regardless of the OS in use 'know' the same users with
the according UIDs as long as they are clients to the Samba4 domain.

> Thanks so much for your patience Bernd.
You're welcome.

  Bernd