LDAP versus NIS implementation with Unix/Linux flavor systems

first_imgWhat are the benefits and complications between using NIS and/or integrating *NIX accounts with LDAP for your *NIX flavored systems? In many cases, *NIX administrators lean towards keeping to *NIX systems in order to manage their environment. There tends to be a division line between none *NIX based and *NIX in most environments. However, most application/DB users are required to make changes on both types of OS. Depending on your sites security policies around passwords, this could cause some issues for application users, as well as causing overhead in maintaining the policies your site implements. It really depends on users’ activity levels on each type of system.  Example: an LDAP compliant none *NIX based system runs the front end of an application while the DB is located on a *NIX system. The DBA user will only need to access the *NIX system once every 6 months. As a result, the DBA may find their account inactive or removed due to policies that require users to actively login to an account every some odd days to keep the account active.When looking at designing your account model, you will need to keep in mind how you would like to enforce security around your accounts, and how important is the data accessible from this system. NIS inherently does not have a method to lock accounts or to notify as security policies may dictate. NIS will manage accounts and groups without security policies. However, wrapper scripts and other programs can allow NIS to support your site’s polices. Maintaining home-grown scripts can cause extra overhead as well as introducing potential human error to enforcement policies. While NIS is simple to setup and maintain, over the years I have seen typos and character limitation sizes that cause NIS to break with little notification. Overall NIS is simple to use and configure, but there are some inherent short comings in its inability to control security policies.There are advantages in integrating *NIX accounts within LDAP, which you may think brings new complications, but it is more like putting your NIS structure within LDAP. There is a learning curve and thought process in achieving this. There is an initial design time required, as well as a one-time installation of Unix extensions within LDAP. The real question is, what is the ROI to make the change? There is added security in that the password hash and user accounts for the *NIX system will now be kept within the LDAP compatible structure, rather than on the *NIX system where it may be used to compromise the system.What about using Access Control Lists (ACL)? ACL’s only allow certain commands depending on each user’s group role within your company. Sudo is typically the standard for most *NIX shops as it is inherently built within all *NIX type OS’s. How would you set up ACL’s to deny all access and only grant what is needed? It all depends on your site’s security model. As far as controlling group IDs for ACL, it is always a good idea to give all users a base GID that is not used on any system, and only add the users to other groups as needed. This will help block users from gaining access to stale accounts as they change job roles, also as a user is removed from other groups.From my years of dealing with *NIX accounts and enforcing policies, on average, there seems to be around a 60% time reduction when using LDAP compatible authentication processes over using NIS. This is primarily due to all the manual checking and validating created wrapper processes, as well as all the overhead locking and reestablishing accounts due to inactive users or, my favorite, “I forgot my password”. The time savings seems to not change based on whether you have 200 users or 2000 users. The biggest time spent is setting up your model.last_img

About the author

Leave a Reply

Your email address will not be published. Required fields are marked *