In the message dated: Mon, 29 Dec 2008 11:57:08 MST,
The pithy ruminations from Neil Neely on
<[lopsa-tech] AD integration with Unix> were:
=> We're looking at integrating our *nix machines with our AD servers and
=> are trying to find the "Best" way to do this. In this case I'm
Propitious timing for this thread! I'm considering the same issue at $WORK.
Reading all the responses (and re-re-re-reading Samba docs & recipies) is very
helpful.
=> finding my google-fu isn't working in my favor... there is no shortage
=> of information. Every time I think I have a complete grasp of ways
=> this can be done I find one more. So there are plenty of resources
=> for how to do this using technique X, what I really need is some
=> feedback from people who are further along in this evolution that can
=> give some perspective on which approach they think is the best.
Exactly! There are so many different ways of doing "almost" the same thing
(with important distinctions) that I feel I could spend weeks setting up test
environments to find the "right" way...if I had weeks...
=>
=> Relevant background details:
=> ~50 production servers that are centrally managed (unified UID and
=> passwords) using homegrown syncing - we would like to move these to AD
Somewhat similar in my case...about 35 production servers (legacy stuff, new
systems are standardizing around CentOS) using NIS to share UID and
authentication data.
There are about 50 user accounts.
=> Already have AD infrastructure in place authenticating staff work
=> stations (~50 workstations)
Here's a big difference, which may be common to many other *nix admins...in
my $WORK there's a substantial AD infrastructure (about 3~4K user accounts)
which is managed by a separate group. There is very limited interaction with
the AD administrators, and little or no chance of getting any changes to the AD
schema or getting SFU installed on the AD servers. The AD admins have too
little exposure to integrating Windows and *nix to offer any direction.
=> * primary concern is not securing these machines against it's
=> legitimate users (so NIS may be acceptable in this environment).
=> This economy stinks and doing this without any capital expenses is
=> very important.
Same here, on both counts.
My goal is limited:
I want to allow Unix (Linux) users to login to the Linux (Unix)
servers with their AD password. SSO is not a goal--existing login
mechanisms (ssh, primarily) will continue, and creditials or domain
membership on the user's desktop machine are irrelevent.
Only people with local *nix accounts will have login privileges. The
other members of the AD population will not be able to login to the
*nix servers.
Legitimate logins will be authenticated against the AD password data,
thereby gaiing the advantage of using a single set of password strength
rules, unified expiration timing, and reducing the number of passwords
that users must remember (write down on yellow sticky pads).
Account names on our *nix servers are already identical to the account
names within AD, but there is no unification of UID or GIDs. Since there is no
requirement for sharing directories between the AD and *nix worlds, I don't
need to query the AD for a user's UID or GID, so I don't think that the
separate UID and GIDs is a problem--there doesn't need to be any mapping.
The interaction with AD would be solely as a source of authentication data.
Users would be "authorized" to login to a *nix server by virtue of having a
local /etc/passwd (or NIS passwd map) entry, not by their AD membership or
attributes.
My current plan is to configure the servers with Samba as domain clients (not
PDC or BDCs), and use the NSS and LDAP (the PADL tools?) and PAM to issue
authentication queries against the LD.
That looks so nice when I put it in print, but does this explanation make
any sense?
Does anyone have any suggested configurations?
[SNIP!]
=> Neil Neely
=> http://neil-neely.blogspot.com
Thanks again for this thread. Your clear explanation of the environment and
goals seems to have helped get this off to a productive start.
Mark
-----
Mark Bergman
http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=bergman%40merctech.com
_______________________________________________
Tech mailing list
[email protected]
http://lopsa.org/cgi-bin/mailman/listinfo/tech
This list provided by the League of Professional System Administrators
http://lopsa.org/
