Re: Fix passwd/shadow/group files?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



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



[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux