On Fri, 2005-07-15 at 16:27 -0500, Les Mikesell wrote: > I don't want separate smbpasswd files. Even in the old days, it was transparent. You can configure NIS-Samba to synchronize passwords so when you change it via [yp]passwd, the Samba password changes and via NT password change, the NIS password changes. In Samba 3.0, there are new backends which radically improve this. There have always been a lot of NIS, NIS+, LDAP and/or Kerberos integration options. > The part I wasn't sure about was whether NIS could supply the > unix account info (uid, gid, home dir) while allowing > the password check to be via smb, and whether that combination > would work with samba as well. You can check _always_ use whatever information/services however you configure it on the _client_. By default on just about every UNIX system, when you setup NIS and bind a client to the NIS domain, you do *0* else (even on NSSwitch clients, which typically default to an NIS check). Changing PAM or the relevant UNIX service to authenticate via NTLM (to a Windows or Samba server) is the _non-standard_ step. It doesn't matter whether you are using local files or NIS, this does _not_ change because you've added NIS. NIS is just a simple mechanism to "NIS domain-wide" your passwd, group, hosts, etc... files. > The solaris/freebsd versions I used didn't have an obvious way to use > smb authentication for ssh/ftp logins. Solaris _should_ have PAM as of 2.6 onward. Not sure about FreeBSD (been awhile for me). Again, _nothing_changes_ if you use NIS in this regard, period. NIS just augments your local files with maps, not replaces any settings. I know this is difficult to understand, largely because people are used to working with Microsoft or Novell where you are "forced" to do naming X, authentication Y and file service Z -- but in UNIX, you can piecemeal as much as you want. When it comes to NIS, all it's doing is _augmenting_ your local files with NIS domain-wide maps. Everything else is the same. So if you're already configured NTLM for authentication, just make sure that is used in PAM or your other configuration files _first_, before local/nis. > Today these are NT domain controllers actually still running NT. Then consider _not_ going to MS ADS. Is there any reason you have to? The "key turning point" in an organization is _before_ they go MS ADS. After they do, your network is ADS' bitch -- and I use that exact phrase because that's what it is. Interoperability becomes increasingly difficult after that step. At worst, your ADS is in charge of everything. Microsoft quickly had to add NIS to Services for UNIX (SFU) largely because organizations did have a lot of legacy systems. But at least with DNS and NIS, you can setup true UNIX secondary/slave servers for when ADS self-destructs. The better option is to segment your ADS tree off from your UNIX, be you have NIS, NIS+ or LDAP with or without Kerberos. That's what most 10,000+ node enterprise networks do. A few even make ADS "submissive" to their formal LDAP tree -- typically those are established NsDS trees with 8+ years of production (before ADS was even introduced). >From the sounds of your arrogant and oblivious IT management, you probably want to choose the latter. > The replacement is going to be an AD, but run by a group at another > location that doesn't like unix. That right there is the problem. Any IT organization that "doesn't like unix" is not about "servicing users" but "mandating arrogance." 9 times out of 10 when I come into a shop, it's that arrogant, oblivious attitude that causes _all_ the problems. > We will probably have an AD server at this location with AD replication. > Can it do SFU if the master doesn't? Yes. DCs are peers. In fact, I highly recommend you setup _true_ UNIX/Linux secondary DNS and slave NIS servers to the ADS-integrated primary DNS (I assume they made your DNS ADS' bitch with ADS-integrated DNS) and ADS SFU master NIS server. That way if your ADS DC with SFU tanks (which it most certainly will), your UNIX/Linux clients are SOL until it comes back up. > I would have done that eons ago if someone else hadn't been > managing the Windows boxes. But by the time samba was capable, > the worst of the windows bugs were resolved - and you never knew > when a windows update was going to break authentication against > samba again... My recent favorite "Samba issue" was when Windows Server 2003 / Windows XP Pro re-introduced an old, _broken_ handshake. In a nutshell, 2003/XP skipped a step in the handshake. Because this violates the security protocol, Samba refused to allow access. But 2003/XP went right through the handshake. It made Samba "look bad," but in actuality, Microsoft violated their own security protocols! > No, nobody cares if my job is hard or easy - or how many places I > have to copy a file to make things work. And if the UNIX/Linux network goes down? I feel for you dude. I've come in several times and seen people just like you in your position. It took me only 1 day before I had the Windows admins and their managers realizing how much their business relies on the UNIX/Linux services. >From that point on, the Windows admins at least _notified_ the UNIX/Linux admins when things changed, if not asked for input before they did. At this point, considering your issues, I'd _segment_ myself away from the CIFS PDC/BDCs and, eventual, ADS DCs. There are solutions the synchronize passwords and other things, some of which do not have to run on the ADS DCs (although that's clearly the easiest to support). > It's no longer my choice, and this is basically why I've always > considered it worth the trouble to keep separate logins on the > oddball boxes. Not just for the Microsoft issue, but to be able > to replace services with any better alternatives that might come > along without regard to whether they understood NIS, LDAP, SMB > or whatever. There aren't so many people that it is a problem > to set up the accounts. It would be annoying, but not impossible > to maintain passwords separately - the scheme I use will accept > either local passwords or a match with the windows domain so I > won't be locked out regardless. Well, NIS is old and well understood, just like old Netware Bindery. It's just like for Netware, ADS' LDAP can support Bindery, but not eDirectory (largely because eDirectory is a superset X.500 DAP implementation, long story ;-). So for UNIX, ADS' LDAP can support NIS, but not fully NIS+ or typical UNIX LDAP schema. But at least it's something. > I'll probably attempt to set up the RH directory server to pull > info from AD eventually. That might be best, although if you don't have control of the ADS DCs, or their admins are not open to running services on the ADS DCs, then it makes it extremely difficult for you (but not impossible). > I've always thought that the worst possible thing you could do is to > have someone come in and set up something you don't understand yourself. Then you haven't been hiring the right type of architects/consultants. A _good_ architect/consultant spends the _majority_ of his/her time doing "knowledge transfer," giving you options, feedback and then explaining what options are available to you, how they work, etc... And after he/she helps you implement them, you have a full set of documentation of _your_ operations to follow in case you forget something. That's _exactly_ what I do. In addition to my capabilities, I easily average 200 pages/month in technical documentation (as anyone can attest on this list, I crank out extensive verbage in no time). I typically leave a company after 3-4 months with their entire enterprise documented far better than every before, from the standpoint of _their_ operations and needs. Not "another manual to read," but a sectional document on how to conduct all IT operations that are key. Clients call me back again and again because of it, not because I've setup something only I understand -- quite the opposite! As every client has said, "we like consultants like you who document yourself out of a job!" > In this case the most trouble it would save is editing a few files > once in a while, something I've never considered to be a problem. I > started this thread only because the system tools crapped out on a > duplicate entry - something that might happen with any system. NIS (originally called Yellow Pages, a British Telecom trademark) was invented in the very early '80s by Sun Microsystems. All it does is replicate typical, local files over the network as "maps," which pretty much all UNIX/Linux flavors support without issue in their standard C libraries (i.e., every major C function call in any application can typically lookup NIS as well as local files). > I can assure you that no one thinks that Windows is easier. However > it also isn't going away and new things are going to require AD. Well, as I put it weeks ago, enterprises have had to deal with this "issue" since the '90s and the NT infestation. Most enterprises went with NsDS, and even Sun licensed it as its LDAP backend in its Sun One architecture. Now Red Hat has (finally!) chucked OpenLDAP, bought NsDS from AOL-Netscape, and its now GPL (after the negotiated period/dollar amount -- whichever came first (the period did) -- where Red Hat kept it a commercial product, per AOL's terms). Luckily, even for the most heavily infested ADS networks, Microsoft offers several capabilities: 1. Legacy NTLM authentication, WINS emulation, PDC/SAM distribution 2. One-way Kerberos Trusts to UNIX Kerberos Realms/KDCs 3. Services for UNIX (SFU) NIS, NFS and other services > But, regardless of any global scheme, the set of valid logins on each > of these boxes is unique so specifying it in some network setup is > going to be just about the same amount of work as doing it directly > on each one. I think Netgroups would be a "fire and forget" setup on each system. You do it just once on each system, and then you only have to change the Netgroup membership on the NIS master from then on. Even if your NIS master is an ADS DC with the SFU NIS server. -- Bryan J. Smith b.j.smith at ieee.org --------------------------------------------------------------------- It is mathematically impossible for someone who makes more than you to be anything but richer than you. Any tax rate that penalizes them will also penalize you similarly (to those below you, and then below them). Linear algebra, let alone differential calculus or even ele- mentary concepts of limits, is mutually exclusive with US journalism. So forget even attempting to explain how tax cuts work. ;->