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.
--
Les Mikesell
lesmikesell@xxxxxxxxx
