From: Les Mikesell <lesmikesell at gmail.com> > The problem is that nearly all of the people are windows users > that need samba accounts to work in addition to ftp/ssh. So? I've been authenticating Samba against NIS servers since the mid-'90s. I've even used NIS to distribute my smbpasswd files. See "Samba Unleashed," Appendix A (Solaris). ;-> [ NOTE: The book is 5 years old now, Samba 2.0 was latest. ] I wanted to put in more, but the main author (and my largest professional critic) wanted me to keep the NIS/NFS compatibility down because the rest of the book didn't address it. > Some maintain web content, some are customer support that need > write access to the ftp server and another set does some > development and testing on a different box. At various times > in the past, some of the boxes were solaris and freebsd. So? NIS is _universal_ to just about any UNIX flavor. Almost every UNIX C Library supports checking against it. Some include more modular options, like NSSwitch for telling it whether or not to check against NIS maps. > Now they are all Linux and I'm using smb authentication against > a windows domain controller but still create the accounts for each > permitted user manually. Dude ... 1) I specifically asked you if you had an true MS ADS DC. 2) I mentioned MS Services for UNIX (SFU) Dude, if you had a true MS ADS DC and were already authenticating Samba against it, you _should_also_ use SFU to share out NIS from the same. Now you just control your netgroups at your MS ADS DC. Furthermore, you can even setup true UNIX/Linux NIS "slave" servers to SFU, just like you can setup UNIX/Linux BIND "secondary" DNS servers to MS ADS-integrated DNS. That way if your MS ADS DC tanks, you're not down, because you still have UNIX/Linux DNS/NIS. > Can NIS/netgroups mesh with samba authentication against a > windows domain or would I have to use LDAP for better > integration? Think of NIS as "flat file" like old CIFS (except without the broadcast non-sense). Whereas CIFS moved the Reigstry-SAM password DB network-wide, used NT LAN Manager authentication and introduced WINS as a name resolution service, NIS basically does the same for _any_ UNIX files. You don't even need DNS. You can even use pGINA to replace your NT/200x/XP login to authenticate against other servers. I used to do similar with NISGINA back in the '90s (before MS ADS was even an option for Windows networks). GINA is NT's graphical login/authentication system when you logon. Now that MS has gotten serious, you can just use SFU on your MS ADS DC _directly_! Now you're hosting maps, and ensuring ADS objects _match_ those of NIS maps. Alternatively, if you're worried about security, you can use Kerberos for your password store (instead of NIS hashes in passwd). Now that gets a little more client-specific, but you _can_ use MS ADS' Kerberos to provide a "one-way trust" down to a Keberos realm. > Actually, I guess the next integration will be with Active Directory. Wait! Are you CIFS PDC/BDCs or ADS DCs? If you are the former, you _can_ switch _away_ from CIFS altogether! Not only does Samba 2.2+ provide _full_ CIFS replacement, but you can setup Samba 3.0+ as a BDC, mirror the existing, native CIFS PDC, and then _easily_ promote it to a PDC! Once your PDC is Samba, then it's cake to do NIS. If you already made your Network ADS' bitch, then just get MS SFU. Trust me on this, it makes life 100x easier! I wouldn't be surprised if management thinks UNIX/Linux "sucks" because the UNIX/Linux network is setup like crap, and not because it's not capable. > This company has been acquired and the corporate parent is in the > process of converting their domains now and will be including the > users at this location. Just FYI ... Once you ADS, you're _always_ going to be Microsoft-controlled. Samba will _never_ reverse engineer all of Microsoft's LDAP schema. I know MS ADS is required for a lot of new services. In such case, consider segmenting, maintaining and sychronizing the MS ADS to Red Hat Directory Server (fka Netscape Directory Server, NsDS). Florida Institute of Technology's (FIT's) "acctsync" is a ADS DC-side service designed to retrieves any changes or sends any updates (like password) back to their "master" NsDS tree (acctsync also now supports OpenLDAP, although limitedly). FIT did this because back in 1999, when Windows 2000 starting infiltrating their network, they did _not_ want to put UNIX/Linux reliability at the mercy of MS ADS. They were already running a full LDAP tree with NsDS, and even if they were still using legacy NIS, SFU 1.0 didn't offer a good NIS/NFS service yet (that wasn't really until 3.0 -- current version is 3.5 and _free_). You better decide soon whether or not you're going to put your entire network at the mercy of MS ADS, or if you want to maintain some anonymous control. You really need an independent architect to come in and make your life easier. Because it seems your department isn't aware of all your interoperability options. I'm sure your management must think that Windows is 100x easier to support than UNIX/Linux because of your current setup. I mean, NIS is circa 1982 (yes, _82_) UNIX design, and it would solve your problem quite nicely. -- Bryan J. Smith mailto:b.j.smith at ieee.org