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.

On Sat, 2005-07-16 at 10:40, Bryan J. Smith wrote:

...

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.

I said that to keep it short, but it is really much more complicated. In fact the people involved are all reasonable and cooperative and even if they wanted to be arrogant, everyone knows that management will insist on making things work together if it comes to that. The problem is that no one knows how to integrate different technology and it may not even be possible to know. There are hundreds of books and classes on Windows networking and about the same for at least some flavors of unix, but there is really nothing published about integrating heterogeneous systems and even if there were, it would change with every samba release and every windows service pack. The seemingly arrogant attitude comes from having to stick to what you know works and there isn't much overlap.

...

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.

The AD is being added as a new domaim with users moved over as testing proceeds. I have added slave zones to my unix dns to accomodate it.

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!

I think that's about the 4th time they have done that with service packs that you are forced to install because of other security issues. I'm sure making samba look bad was not accidental - and that it wasn't the last time either.

...

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 keep spare parts...

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.

Oh, they do understand that here - and the new management even has a good handle on how much it would save to run more things on Linux. But, everyone has their hands more than full already trying to integrate the companies without making additional infrastructure changes or re-writing apps.

...

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.

Yes, if you are lucky you might get that. But it's a snapshot of what you can do today. What you need is to understand how you should plan for a few years out, and an outsider won't know enough about a business (at least if it is an unusual business...) to do that. And in our case, nothing we could have planned two years ago would have matched our situation now, trying to integrate into a completely different company.

...

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.

The reason for unique sets of people on these machines is generally for ownership of files and stuff in their home directories, so that part of the account setup has to be done individually anyway. Other than personnel turnover the only things that change later are the passwords which are taken care of with simple SMB authentication against a PDC now. If the AD can emulate that, I may keep it the same for simplicity. The one thing that would be worth the trouble to fix would be CVS - it is about the only thing left that doesn't use PAM and the number of users is increasing. I know there are patches but there is a tradeoff in making a version that doesn't match the distribution.

On Sun, 2005-07-17 at 22:37, Bryan J. Smith wrote:

...

The seemingly arrogant attitude comes from having to stick to what you know works and there isn't much overlap.

I wasn't saying you were arrogant. Quite the opposite. I was saying your enterprise IT sounds rather arrogant.

But it's the same there - they know how to do it one way - and have a fairly large staff to support it. So even if they know it isn't the best way they tend to stick to it.

If you setup Services for UNIX (SFU), and start managing your Netgroups there, then setup slave NIS servers on your true UNIX servers. If management has an issue with supporting SFU, you should enlighten them to why Microsoft introduced it in the first place. Because Microsoft wants to control UNIX networks, and NIS is the legacy way to do it.

This sounds promising. Is there some way to transition gracefully? The AD is being added as a new domain with users moving over piecemeal. At the moment it doesn't have most of the users I would need but it should soon.

...

I keep spare parts...

Oh, I meant if the UNIX/Linux network goes down because of the Windows admins doing things without telling you, like dorking up your SFU install (assuming you go that way)?

They've done that with the AD already, but since only a few users here have been moved it didn't affect much. They are pretty careful once things get into real production - in fact, everything gets scheduled before it is touched to be sure different people aren't doing conflicting changes.

Several have already pointed out how you can _explicitly_ allow only select Netgroups login. You will define which Netgroup at the individual system, and then maintain the users, groups and netgroups at your NIS master (which can be SFU's NIS service).

So I'm still scratching my head on why you are so resistant to NIS and Netgroups?

It's mostly inertia at this point. The work is already done for local accounts so it doesn't matter for a while. But, I'm becoming convinced.

Instead of having to setup your UNIX/Linux clients to use NTLM to authenticate against a PDC or ADS DC -- which is a PITA and UNIX/Linux client-specific -- one of the ADS DCs runs SFU's NIS service, and it _generates_ the _native_ password hashes in the NIS passwd map.

No more headaches. And it's no less secure than NTLMv2 with null sessions (a commonly unknown fact).

I think long ago I avoided NIS because it had a reputation for security issues. And I played with an earlier version of SFU and wasn't impressed. The current version may be OK.

...

The one thing that would be worth the trouble to fix would be CVS - it is about the only thing left that doesn't use PAM and the number of users is increasing. I know there are patches but there is a tradeoff in making a version that doesn't match the distribution.

I don't think you understand.

With NIS, there is _no_ PAM modification required. Even on non-PAM platforms, you merely tell it to use the NIS passwd map.

And if SFU is your NIS master, it is _automatically_ synchronizing the ADS SAM database for the domain to your NIS domain password maps.

OK, if it can make CVS logins automatically track the Windows passwords, that gives me a reason to use it. The group of people needing CVS access is still growing - and soon those people will already have AD accounts.