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@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 -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba