Re: NIS and shadow passwords

Chao Y. Din wrote: > > > Just because NIS/NIS+ is free with Solaris, does not mean NIS/NIS+ should > be implemented. When discussing NIS/NIS+, I assume there is a requirement > Absolutely. The problem is that NIS/NIS+ are trying to give you a secure method of implementing one passwd one account in a UNIX environment. The problem is that NIS/NIS+ can be broken and NIS+ is not an easy thing to set up. Even experienced administrators have problems implementing it. > The project I worked before utilized NIS+ to meet a requirement -- using > single account and single password to log into all database servers (more > than 10). Do you have a more "cost-effective" way than NIS/NIS+? I can > come up two alternatives: (1) using unicenter and (2) writing our own code > Skip unicenter. I haven't held CA in high regard. NIS/NIS+ are a cost effective way to meet this requirement, however, there is a cost in lessening the security of the system. IBM does node authentication with Kerberos. Now on an SP2 running 3.2.5 or 4.1.4 (The last OS I have worked on) Each node had to be rebooted once a month to receive new keys for kerberos. Can we say that this blows in a 24 x 7 environment. :-) Now I understand the Kerberos keys last for a max of one year. The problem exists because the gods who wrote UNIX and enhanced UNIX were not paranoid enough. (That's why NIS+ was introduced over NIS :-) The point being that unless you need to have access to a network of servers with one login, don't do it. I realize that I am being overly paranoid, but the problem is in designing systems which contain a lot of personal information one must be paranoid. HTH -Mikey -- #include <std_disclaimer.h> /* Mike Segel (MS385) */ #include <No_Spam.h> #ifdef OFFENDED_BY_CONTENT The author takes no responsibility for this post. Any resemblence to a coherent rational thought is purely coincidence. -The Management. #endif ***************************** Due to AGIS's Refusal to Act Responsibly We are blocking all of their domains at the packet level. This block will exist until AGIS modifies their policies to conform to existing RFCs and net community standards. We encourage all ISPs and domain holders to do the same. *****************************