Netgroups with LDAP for NFS authorization

Since the success of our LDAP implementation for centralized user/password naming services, we have started to utilize LDAP for many more naming services such as hosts, netgroups, Sun Desktop Manager, and user authorization for various applications that support it. Netgroups have proven to be a simple, handy solution to authorizing access to systems and NFS shares, something that we really couldn't live without after transitioning from NIS+ to LDAP.

Here is an example implementation of utilizing a netgroup "nfs-clients" for authorization to NFS shares. Very simple and effective in only allowing those servers that you trust to mount up NFS shares from central fileservers. I'm quite sure there is some spoofing methods (including DNS cache poisoning) that could drastically affect the effectiveness of this method, but it's better and leaving an NFS share open to the [internal] world to mount up.

As most of my postings, the context of this setup is Sun Java Directory Server 6.x with Solaris-based LDAP clients performing queries against the directory. Small modifications can make this work on other *nix/LDAP platforms.

• If you don't already have it, create a new OU called ou=netgroup,dc=your,dc=domain.
• Create a new object under this new OU, with objectclasses of: top and nisNetgroup
• Configure the attributes of this nisNetgroup object with similar attributes as below, remembering that the nisNetgroupTriple attribute is multi-valued and will hold an entry for each host (must be listed as FQDNs!!!) that will be allowed to mount NFS shares that specify this netgroup in /etc/dfs/dfstab
  

  nisNetgroupTriple: (nfsclient1.domain.net,,)
  nisNetgroupTriple: (nfsclient2.domain.net,,)
  objectClass: nisNetgroup
  objectClass: top
  cn: nfs-clients

• 
  
• Modify the DUA profile that the LDAP clients are configured with to include a ServiceSearchDescriptor such as the following, to ensure that nsswitch looking in the right branch of the directory tree for the netgroup information:
  

  netgroup:ou=netgroup,dc=your,dc=domain?sub

• Now, modify your dfstab entry to specify options for the share(s) to reference netgroups to allow ro/rw access and mapping of the root user:
  

  share -F nfs -o ro=nfs-clients,root=nfs-clients /export/home

• Of course, run the shareall command to reshare this NFS export with the updated options, and it would probably be a good idea to restart nscd (name service cache daemon) as well.
• On your NFS/LDAP clients, make sure that the value for the netgroup lookup is set to LDAP:
  

  # grep netgroup /etc/nsswitch.conf
  netgroup: ldap
  

• Mount it up on one of the servers specified in the netgroup, nfs-clients, and attempt to mount it on a server not listed in that netgroup to validate that authorization control is working properly.
  

I'll make another post that is VERY similar to this one explaining how to set up host lookups in LDAP also. This is handy if you want to store some host/ip address mapping records in LDAP versus DNS (believe me, there are situations that call for this). I would suggest sticking with DNS for this purpose as much as possible, as it is optimized for host lookups, but like I said there are situations where this is helpful.

Common tuning tips and pitfalls to avoid

One major aspect of setting up systems that is very much neglected in the practice of system administration is testing and tuning (and testing again and tuning more...). It is a shame that I don't get the chance to test as much as I would like to before deploying a system to the production environment, but I have learned a few things through reactive actions that I would like to share to hopefully prevent myself and others from running into such issues after a system is deployed.
If you're in a similar situation as me, without the abundance of human resources that are allocated to specific roles (i.e. architecture, capacity planning, engineering, lab/testing, etc.) and have to handle all of these necessary capacities yourself, take the following into consideration when going through your "checklist" to ensure you've "dotted your i's and crossed your t's."

• Make sure that your network interfaces are set to full duplex and the link speed that you intended to be set at. This sounds so simple, but is one of those configurations that seems to come back to bite me every once in a while. In Solaris (10+) this can be quickly checked by running: dladm showdev or kstat bge:0 (example)
  
• Check the max file descriptors per process (and total) setting for the user that your services run under. This is an OS level tuning parameter that defines how many files/ports/pipes/etc. a given process can open and usually defaults at 256, but should probably be increased. At some point, this has an impact on the system by increasing memory utilization, so caution should be taken when setting this high. A safe value to stay under is 65535. I've seen this the root cause of far too many service impacting outages and should be prevented as much as possible.
• Validate that your database has enough tablespace to grow as needed and make sure it is set to auto-extend if desired. Also, make sure that archive log files are handled effectively by removing them after backing them up (with RMAN in the Oracle world) and do not utilize more local disk space than you feel they should.
• Choose the right processor architecture for the software that will run on it, and load test as much (and as brutal) as possible to ensure stability at higher than expected production loads. As an example, there are software packages that are highly multi-threaded, but choke on a extremely multi-threaded processors (such as the Sun Niagra [T1/T2] series) due to lack of highly-depended on resources such as FPUs.
• more to come in future posts...