From: Les Mikesell <lesmikesell@xxxxxxxxx>
> 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@xxxxxxxx
