-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael MacIsaac wrote: > > We did document a "travelling /home" using NFS+LDAP+automount in the books > "z/VM and Linux on IBM System z The Virtualization Cookbook for <SLES 10 > SP2> or <RHEL 5.2>" on the Web at > http://www.redbooks.ibm.com/abstracts/sg247493.html > or > http://www.redbooks.ibm.com/abstracts/sg247492.html > > See the "Miscellaneous Recipes" chapter. Hope this helps. >
This is what we're doing: LDAP authentication + NFSv3 home directories + Home dir automount maps in ldap. Here's a couple of tweaks we found useful in our environment. NFSv3 is not known for it's security. Consider the use of the NFS option 'root_squash', along with limiting the list of hosts who can connect to your home share. Only export home dirs to hosts which you control, remember that anyone who has root on their box (e.g. a dev workstation) can impersonate any user to NFS. Here's the relevant /etc/exports line we use (sorry for the line wrap): /export/unixdata/homedirs \ @hgrp_autohome_admin(rw,no_root_squash,insecure,sync) \ @hgrp_autohome_hosts(rw,root_squash,insecure,sync) I look forward to going to NFSv4 with kerberos authentication, but we're not there yet. Regarding automount maps in LDAP, this works very well for us with one exception. The problem is that there's a significant number of automount map schemas out there, and different OS's (and different revisions of OS's) use different ones. As we are a fairly heterogeneous environment, I found it near impossible to keep a master map in LDAP. Right now we're just keeping a /etc/auto.master or /etc/auto_master on each host. In order to make the individual map entries work heterogeneously, I had to add several object classes and a few redundant attributes to each entry. Here's what my home dir automount map entry looks like (again sorry for the line wrap): # ap00375, auto_home, unix.mayo.edu dn: automountKey=ap00375,automountMapName=auto_home,dc=unix,dc=mayo,dc=edu automountInformation: rchnas05n1.mayo.edu:/vol/vol2/unixhomes-5gb/75/ap00375 cn: ap00375 automountKey: ap00375 objectClass: automount objectClass: nisNetId objectClass: top Regarding heterogeneous clients, we found AIX in particular to be the hardest of our clients to configure, and linux the easiest. Insure on AIX that you have the latest available LDAP client package from IBM. Also be aware that AIX wants to use it's extended LDAP schema rather than RFC2307, and wants full write access to the LDAP servers from every AIX client. Despite that, it will work with RFC2307 and read only access. Solaris, like linux, has an option to not use an LDAP proxy account at all via anonymous binding, but I never got Solaris anonymous binding to work. I recommend making LDAP use TLS or SSL on the wire, in order to keep cleartext passwords from flying about. Both AIX and Solaris require the server public SSL certs to be loaded on every client to do LDAP over TLS or SSL. Linux can be configured to ignore authenticating the LDAP servers' certs and proceed with TLS/SSL anyway - this is convenient, but does open the possibility of man in the middle attacks. In our environment this isn't a big deal, but it might be in yours. We've found posix group membership management to be one of our more challenging issues overall. Some older systems (e.g. solaris <= 8 or 9) enforce the old posix limit of no more than 16 secondary groups. Further, the primary group concept is annoying - conceptually, in any organization with modest member mobility, which primary group do they get? If one assumes that the primary group is meaningful, e.g. reflective of someone's function, role, or job, what about people who do two or more things (E.g. student *and* employee) or people who transfer, but will have a transitional period? Our not so great compromise was to first use nis style netgroups via LDAP for anything we can. In particular, we use a mutation of netgroups to control individual's authorization to log in via the use of service search descriptors, and also for sudo privileges. Second in our environment all meaningful posix groups are secondary groups. For primary groups we adopt the linux convention of creating a separate posix group for each individual: e.g. userA gets a group userA as her primary group. This has the problem of a huge proliferation of groups, though, and several LDAP clients, in particular AIX, have issues with that. Anyway, apologies for the long ramble, but I hope this has some helpful info: - -- Pat -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksz19cACgkQNObCqA8uBswzQQCeNdKtNyPomTzLtD7DkFN5vpCq VmoAnAsc9n7CfpdcOHZrItE+/y4FwsAC =kG6c -----END PGP SIGNATURE----- ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
