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.