[lopsa-tech] AD integration with Unix

[Neil Neely]

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
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.

Disclaimer: I am in the process of learning how these bits fit
together, and if I've said something truly bizarre it is likely out of
ignorance not arrogance so I really would appreciate being pointed in
the right direction.

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
Already have AD infrastructure in place authenticating staff work
stations (~50 workstations)
The servers exist to support our customers (not staff in general)
These servers do not require shared home directories for staff.
Staff accessing these servers are all performing some task relating to
"administration", though at different levels (tech support through sys
admin).
* 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.

Combinations we are seriously considering (in no particular order):

NIS w/Kerberos (via SFU)

Winbind

Likewise Open

We've found various bits and pieces that seemed promising with each of
these approaches. This is our short list of best fit for the problems
we've got, but perhaps we've overlooked something. I would really
appreciate any pro's/con's from the trenches on this topic. "Likewise
Open" seems to be the easiest to install at this point, so is slightly
ahead in our evaluation.

Thanks for your time,

(sidenote: AD is being chosen because it is existing established
infrastructure here that looks like it will do the job we need,
nothing at all against openldap, this is just using the tool that
we've got so we can focus on solving other challenges.)

Neil Neely
http://neil-neely.blogspot.com

[apostolos pantazis]

For Unified Login, security and auditing I would recommend you take a
look at Centrify. In other arenas I am not very well versed yet but I
will be watching this thread as I am interested as well.

On Mon, Dec 29, 2008 at 10:57 AM, Neil Neely <***@neely.cx> wrote:
> 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
> 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.
>
> Disclaimer: I am in the process of learning how these bits fit
> together, and if I've said something truly bizarre it is likely out of
> ignorance not arrogance so I really would appreciate being pointed in
> the right direction.
>
> 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
> Already have AD infrastructure in place authenticating staff work
> stations (~50 workstations)
> The servers exist to support our customers (not staff in general)
> These servers do not require shared home directories for staff.
> Staff accessing these servers are all performing some task relating to
> "administration", though at different levels (tech support through sys
> admin).
> * 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.
>
> Combinations we are seriously considering (in no particular order):
>
> NIS w/Kerberos (via SFU)
>
> Winbind
>
> Likewise Open
>
> We've found various bits and pieces that seemed promising with each of
> these approaches. This is our short list of best fit for the problems
> we've got, but perhaps we've overlooked something. I would really
> appreciate any pro's/con's from the trenches on this topic. "Likewise
> Open" seems to be the easiest to install at this point, so is slightly
> ahead in our evaluation.
>
> Thanks for your time,
>
> (sidenote: AD is being chosen because it is existing established
> infrastructure here that looks like it will do the job we need,
> nothing at all against openldap, this is just using the tool that
> we've got so we can focus on solving other challenges.)
>
> Neil Neely
> http://neil-neely.blogspot.com
>
>
>
>
> _______________________________________________
> Tech mailing list
> ***@lopsa.org
> http://lopsa.org/cgi-bin/mailman/listinfo/tech
> This list provided by the League of Professional System Administrators
> http://lopsa.org/
>



--
Paul

[John Reddy]

I'm running Centrify in a pretty mixed environment. It's a bit pricey, but
worth it. Weighing the cost of developing in-house AD/Kerb/Ldap integration
plus the cost of software development for AIX, Solaris, Mac OS X, every
flavor of linux, and a few others that I forgot.

Centrify's pretty simple and doesnt require any schema changes in the AD,
just a container to work in. Install the agent software on the Unix machine
in question and it joins to the active directory. You can then get modules
for tying Samba, Apache auth, or other software in to the AD auth as well.

They also provide a kerberized putty that will pass Kerb tix for SSO.

I know it's not the "make your network sit up and beg" solution, but it
makes my life easier when I've got 10 different jobs to do.

-John Reddy

On Mon, Dec 29, 2008 at 2:55 PM, apostolos pantazis <
***@gmail.com> wrote:

> For Unified Login, security and auditing I would recommend you take a
> look at Centrify. In other arenas I am not very well versed yet but I
> will be watching this thread as I am interested as well.
>
>

[Atom Powers]

You should also take a look at:

OpenLdap w/ Kerberos

Since Active Directory is, at it's heart, LDAP with Kerberos this /should/
be a fairly straight forward implementation. ( I haven't actually done this
yet, but I've been looking into it for a while. I currently run an OpenLdap
infrastructure. )

On Mon, Dec 29, 2008 at 10:57 AM, Neil Neely <***@neely.cx> wrote:

> 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
>
> Combinations we are seriously considering (in no particular order):
>
> NIS w/Kerberos (via SFU)
>
> Winbind
>
> Likewise Open
>
>

--
Perfection is just a word I use occasionally with mustard.
--Atom Powers--

[John Jasen]

Neil Neely wrote:

> 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

You would need to install the Services for UNIX extensions on your Win2K
server, where Win2k >= Windows 2003. Note: R2 and Win2K8 have them already.

You'll also need to install the NIS server (and DON'T run it!) to get
the tab under AD Users and Computers to manipulate UNIX attributes via a
GUI.

> Already have AD infrastructure in place authenticating staff work
> stations (~50 workstations)
> The servers exist to support our customers (not staff in general)
> These servers do not require shared home directories for staff.
> Staff accessing these servers are all performing some task relating to
> "administration", though at different levels (tech support through sys
> admin).
> * 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.

Are you looking for any sort of single sign on, are you just looking at
centralizing account information and passwords, or are you looking at
something else that requires kerberos?

Single sign on will be entertaining with UNIX systems, as AD doesn't
understand service principal names in the expected way. Centralizing
user info in AD can be done with tools that come relatively native with
solaris (10), Redhat (4 and 5), and Ubuntu (at least the last three
versions).

What are you aiming for? I'll be happy to pass along my notes and/or my
adventures in AD versus UNIX versus NFS.

> Combinations we are seriously considering (in no particular order):
>
> NIS w/Kerberos (via SFU)

Yuck ....

> Winbind

UIDs and GIDS may stop matching up.

> (sidenote: AD is being chosen because it is existing established
> infrastructure here that looks like it will do the job we need,
> nothing at all against openldap, this is just using the tool that
> we've got so we can focus on solving other challenges.)

I pushed for using AD because the alternative here was Sun's
Iplanet^WOne^WJava^WNewName2009 Directory Server, and getting it to use
kerberos as a password repository seemed sub-optimal.

--
-- John E. Jasen (***@realityfailure.org)
-- No one will sorrow for me when I die, because those who would
-- are dead already. -- Lan Mandragoran, The Wheel of Time, New Spring

[Neil Neely]

On Dec 29, 2008, at 5:33 PM, John Jasen wrote:
> Are you looking for any sort of single sign on, are you just looking
> at

> centralizing account information and passwords, or are you looking at
> something else that requires kerberos?

Really just centralizing account information. SSO would be a plus,
but is not a requirement.

> Single sign on will be entertaining with UNIX systems, as AD doesn't
> understand service principal names in the expected way. Centralizing
> user info in AD can be done with tools that come relatively native
> with
> solaris (10), Redhat (4 and 5), and Ubuntu (at least the last three
> versions).
>
> What are you aiming for? I'll be happy to pass along my notes and/or
> my
> adventures in AD versus UNIX versus NFS.

This is mainly for CentOS servers so it should have the RHEL goodies
you refer to. As I mentioned above - SSO is not a requirement for
this environment.
I'd love to see your notes and adventures.

I'd really like a solution that is relatively painless to install/
configure so I can train puppet how to take care of this for me (Still
learning puppet). Failing that I'm looking for a recipe that I can
hand to a junior admin. We've virtualized our environment here and
our number of 'servers' is going to be exploding over the next year
and I want to do everything I can to make building and maintaining
large numbers of servers take less time. Total # of (virtual) servers
doubling this year is likely.

While shared home directories are not a requirement if we can
accomplish this relatively painlessly it would not be a bad thing.
The bulk of my staff all accesses a single admin server that they do
their work from, so the few of us that need to roam around a lot more
can handle using scp to move our own files around.

Thanks,


Neil Neely
http://neil-neely.blogspot.com

[Edward Ned Harvey]

> I'd really like a solution that is relatively painless to install/
> configure so I can train puppet how to take care of this for me (Still
> learning puppet). Failing that I'm looking for a recipe that I can
> hand to a junior admin.

In that case, your best solution is probably the MS built-in UNIX services and NIS. Nothing else is as simple and straight-forward. Just read my comments in the email one minute ago ...

Also, I'd recommend enabling the services on more than one server. NIS clients perform very well switching from one NIS server to another, in the event one server becomes unavailable. But of course, only if there's more than one server available, and only if you told the clients about it.

[unix_fan]

--- On Mon, 12/29/08, Neil Neely <***@neely.cx> wrote:
> We're looking at integrating our *nix machines with our
> AD servers and are trying to find the "Best" way to do this.

You might benefit from looking at how Neil Waybright described it working in this recent talk at UUASC-LA.
http://www.waybright.org/neil/presentations/Authenticating_with_AD/Auth_with_AD.pdf

It's similar to what we have in multiple isolated networks.

[]
> This economy stinks and doing this without any capital
> expenses is very important.

I see one person has already mentioned Centrify. We have that at one site at $WORK and I'm sure it works. However, the "server" pricing is very high (4 figures). While we were recently told that we could define what constitutes a server, I am very uneasy when subjective language goes into a licensing agreement.

[Richard Chycoski]

Neil Neely wrote:
> 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
> 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.
>
> Disclaimer: I am in the process of learning how these bits fit
> together, and if I've said something truly bizarre it is likely out of
> ignorance not arrogance so I really would appreciate being pointed in
> the right direction.
>
> 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
> Already have AD infrastructure in place authenticating staff work
> stations (~50 workstations)
> The servers exist to support our customers (not staff in general)
> These servers do not require shared home directories for staff.
> Staff accessing these servers are all performing some task relating to
> "administration", though at different levels (tech support through sys
> admin).
> * 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.
>
> Combinations we are seriously considering (in no particular order):
>
> NIS w/Kerberos (via SFU)
>
> Winbind
>
> Likewise Open
>
> We've found various bits and pieces that seemed promising with each of
> these approaches. This is our short list of best fit for the problems
> we've got, but perhaps we've overlooked something. I would really
> appreciate any pro's/con's from the trenches on this topic. "Likewise
> Open" seems to be the easiest to install at this point, so is slightly
> ahead in our evaluation.
>
> Thanks for your time,
>
> (sidenote: AD is being chosen because it is existing established
> infrastructure here that looks like it will do the job we need,
> nothing at all against openldap, this is just using the tool that
> we've got so we can focus on solving other challenges.)
>
> Neil Neely
> http://neil-neely.blogspot.com
>
For Open packages, look at Luke Howard's PADL products
<http://www.padl.com>. When I was last working on this (a couple of
years ago), PADL didn't have caching, but I believe that this has been
done since then. Luke is very dedicated to the work, and is responsible
for creating the standard (RFC2307) that is accepted as 'the standard'
for Unix to AD connectivity. His company also offers commercial support
if that is important to your organisation.

The two commercial packages that I've seen that are built to to this are
Quest(Vintela) and Centrify.

Microsoft's SFU is underpowered, but if you have only a few users and
machines, you might be able to get away with it for now. I can't
recommend it for any sizable organisation.

SFU does not scale well as all lookups are done directly to AD - it's
meant for a large Windows site that has a very small Unix
infrastructure. Try doing an 'ls -l' in a directory with files owned by
hundreds (or thousands) of different users - and be prepared to wait....

Quest and Centrify have local caching of AD data, so the load on your AD
servers is minimal most of the time, and there is no latency on
obtaining user data.

For 'future-proofing' look for RFC2307bis compatibility (unfortunately,
this RFC was never brought through for ratification, but it does
describe Kerberised LDAP compatibility with functionality that scales to
large infrastructures).

All of the products (including SFU) require extensions to the AD schema,
and since AD schema changes are irreversible once installled, experiment
with whichever product(s) that you are interested in on a test domain
before committing yourself. VMware is your friend - I did a lot of
playing around with Win2K3 servers running under VMware, using snapshots
to play 'Groundhog Day' with the AD data (instant schema change reversal
:-).

AD is a solid back end service. I hammered AD servers during testing,
and the only way that I could make them crash was to do a nasty DOS
attack (by accident :-) - I hammered Kerberos authentication requests
without closing the TCP connections, and eventually ran out of sockets
on the server... For every other load test that I performed, AD degraded
'gracefully', i.e., it came up to a maximum number of transactions per
second, and held it - regardless of additional load applied. Further
load did not cause it to 'crowbar' (it didn't drop off in the number of
transactions per second as more load was applied). I was not expecting
this kind of solid performance from a Windows server (having heard the
horror stories about IIE and Exchange). AD on Win2K3 also expands nicely
when you add replicas. It was also 5-6 times faster than the Solaris
NIS+ servers that we were running at the time when retrieving individual
results. Where AD (and every other LDAP server that I've seen) falls
down (compared to NIS+) is when you 'walk a map', since the NIS+
protocol is built to deliver the entire map in large chunks, and LDAP
returns each entry individually. This is why you want caching in the
client - map walks become 'free', and the load on your AD (or other LDAP
server) is greatly reduced.

OTOH, I'm an 'OS gourmand' - I eat them all! While I admit to a little
bias, I'm do try to use the OS/platform/application that does the best
job for a given service (which also must take into account local
expertise for maintaining the system). If you have competent Windows
admins taking care of your AD infrastructure (as my $WORK does), I would
have no qualms about basing your Unix authentication and authorisation
on AD. Having dealt with Sun and their NIS+ fiascos for a number of
years (they didn't really get their act *mostly* together until Solaris
10), AD on Win2K3 was a pleasant change! (AD on older versions of
Windows has some performance and configuration limitations that were
corrected in 2K3.)

- Richard

[d***@lang.hm]

On Mon, 29 Dec 2008, Richard Chycoski wrote:

> For Open packages, look at Luke Howard's PADL products
> <http://www.padl.com>. When I was last working on this (a couple of
> years ago), PADL didn't have caching, but I believe that this has been
> done since then. Luke is very dedicated to the work, and is responsible
> for creating the standard (RFC2307) that is accepted as 'the standard'
> for Unix to AD connectivity. His company also offers commercial support
> if that is important to your organisation.
>
> The two commercial packages that I've seen that are built to to this are
> Quest(Vintela) and Centrify.

Symark software sells Power Advantage, which seems to be a similar product
(price and checklist functionality seem to be similar to Quest). I haven't
used it, but have looked at it a bit.

David Lang

[Leon Towns-von Stauber]

On Dec 29, 2008, at 10:57 AM, Neil Neely wrote:

> 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
> 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.


I wouldn't claim it's necessarily the "best", but I've done it with
Samba winbindd. The procedures I used are documented here:

http://www.occam.com/tools/ad_auth.html

which includes a pointer to a tool I wrote to keep UIDs and GIDs in
sync on the UNIX side, important if you have NFS in your environment.
Not real pretty, but it works.

--------------------------------------------------------------------
Leon Towns-von Stauber http://www.occam.com/leonvs/
"We have not come to save you, but you will not die in vain!"

[Christoph Maser]

Am Dienstag, den 30.12.2008, 03:28 +0100 schrieb Leon Towns-von Stauber:
> On Dec 29, 2008, at 10:57 AM, Neil Neely wrote:
>
> > 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
> > 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.
>
>
> I wouldn't claim it's necessarily the "best", but I've done it with
> Samba winbindd.
>
Why not? It works like a charm for me. It gives you SSO via kerberos.
Also service principals work perfectly for me with an easy keytab
frontend (net ads keytab). It is free, it is open source. It even
supports logon caching (for laptops like Windows does).

For me it was the perfect choice. The only drawback i can think of is
the non-syncronized uid, wich for me have nerver been an issue.


Chris


financial.com AG

Munich head office/Hauptsitz München: Maria-Probst-Str. 19 | 80939 München | Germany
Frankfurt branch office/Niederlassung Frankfurt: Messeturm | Friedrich-Ebert-Anlage 49 | 60327 Frankfurt | Germany
Management board/Vorstand: Dr. Steffen Boehnert (CEO/Vorsitzender) | Dr. Alexis Eisenhofer | Dr. Yann Samson | Matthias Wiederwach
Supervisory board/Aufsichtsrat: Dr. Dr. Ernst zur Linden (chairman/Vorsitzender)
Register court/Handelsregister: Munich – HRB 128 972 | Sales tax ID number/St.Nr.: DE205 370 553

[Brandon S. Allbery KF8NH]

On 2008 Dec 30, at 5:48, Christoph Maser wrote:
> Why not? It works like a charm for me. It gives you SSO via kerberos.
> Also service principals work perfectly for me with an easy keytab
> frontend (net ads keytab). It is free, it is open source. It even
> supports logon caching (for laptops like Windows does).

I'm using it on one system which needs both unix and windows logins to
work. I find it has to be restarted periodically or it chokes.

--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] ***@kf8nh.com
system administrator [openafs,heimdal,too many hats] ***@ece.cmu.edu
electrical and computer engineering, carnegie mellon university KF8NH

[Christoph Maser]

Am Dienstag, den 30.12.2008, 23:40 +0100 schrieb Brandon S. Allbery
KF8NH:
> On 2008 Dec 30, at 5:48, Christoph Maser wrote:
> > Why not? It works like a charm for me. It gives you SSO via kerberos.
> > Also service principals work perfectly for me with an easy keytab
> > frontend (net ads keytab). It is free, it is open source. It even
> > supports logon caching (for laptops like Windows does).
>
> I'm using it on one system which needs both unix and windows logins to
> work. I find it has to be restarted periodically or it chokes.
>
I had some similiar problems. In all cases i could find network issues
as reason for those. You might want to analyse the logfiles of winbindd
and maybe increase the loglevel.

One feature i missed to point out, with winbindd you can also easily
limit who is allowed access to which system. There is a config directive
which accepts AD group membership as required for login.

It is also possible to use winbindd _and_ kerberos.

Chris


financial.com AG

Munich head office/Hauptsitz München: Maria-Probst-Str. 19 | 80939 München | Germany
Frankfurt branch office/Niederlassung Frankfurt: Messeturm | Friedrich-Ebert-Anlage 49 | 60327 Frankfurt | Germany
Management board/Vorstand: Dr. Steffen Boehnert (CEO/Vorsitzender) | Dr. Alexis Eisenhofer | Dr. Yann Samson | Matthias Wiederwach
Supervisory board/Aufsichtsrat: Dr. Dr. Ernst zur Linden (chairman/Vorsitzender)
Register court/Handelsregister: Munich – HRB 128 972 | Sales tax ID number/St.Nr.: DE205 370 553

[Edward Ned Harvey]

Oh boy - you've touched on a fun topic. One that I've worked on a lot (and I'm sure a lot of other people here have as well.)

There are several options available - Each one has its strengths and weaknesses. What I describe here is by no means a complete list. Just a list of what I can talk about.

--- Option 1:
The easiest one to set up is Unix services in Windows Server. Just add "Identity Management for UNIX" to your server, and voila - you now have extra tabs available for each user and group inside of AD. You should know - This stores the unix passwords on the server in a different format than the standard active directory password store, and since the original password store is non-reversible encryption, installation of UNIX services doesn't work instantly. Each user must reset their password once after the service is installed, before their password will work for UNIX. If you enable the NIS server, that's the absolute simplest way to get things working.

There are a couple of downsides to the above solution - (a) If you want to follow the redhat user-private-group convention, then you run into a barrier. In AD, you cannot have a username and a group of the same name. The simplest solution is simply create "eharvey" and "eharveygroup" - but it is recommended to keep object names to 8 characters or less. Just a small obstacle. (b) Many people will tell you NIS is not the most secure protocol in the world. It does use encryption, but it's a weak form of encryption. Make your decision based on your organization's requirements. (c) There are a lot of advanced features available in things like LDAP, or standard unix NIS, which are not available in MS NIS. The MS NIS is only usable for basic functionality - pure posix - username,password,UID,GID,FullName, and shell.

--- Option 2:
LDAP. This is very good, very powerful and extensible, reliable, and secure. If you can figure out how to get it working. Your first-time setup will not be easy, I promise you that. I think people normally take a class or two, read a couple of books, and google around for a while before they can get this working between unix & ad for the first time. After you're an expert it isn't hard anymore. Perhaps somebody has a recipe? There is always a risk that some AD schema change could mess something up - for example if you upgrade your server from 2003 to 2008 or whatever. The risk should be minimal, so don't be scared - just be cautious and use backups liberally.

You need to store posix information somewhere. I believe another person mentioned you can store it in AD as long as you install the UNIX services and NIS, but simply disable NIS.

--- Option 3:
Kerberos. Same pros/cons as ldap, just another protocol. Has the advantage of single sign on support. I'm guessing that the LDAP setup will be slightly easier than the Kerberos setup. But I'm not really sure.

--- Option 4:
Winbind. This is a clever little component of samba. It allows your linux client to join the windows domain just like another windows client. It has some snags with password synchronization (but with a little massaging you can get it to work). The main problem is - Each client has no authoritative source for UID/GID posix unification, so each client autogenerates the UID/GID's for each user account. As long as you're on a standalone machine, no problem. But if you have a bunch of clients all using NFS, then there's a problem. You need to ensure "eharvey" has the same UID on all the machines, or else the permissions on the NFS server will get screwed up. There are solutions to this problem - I believe another user posted a response to this effect.



> -----Original Message-----
> From: tech-***@lopsa.org [mailto:tech-***@lopsa.org] On Behalf
> Of Neil Neely
> Sent: Monday, December 29, 2008 1:57 PM
> To: LOPSA Technical Discussions
> Subject: [lopsa-tech] AD integration with Unix
>
> 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
> 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.
>
> Disclaimer: I am in the process of learning how these bits fit
> together, and if I've said something truly bizarre it is likely out of
> ignorance not arrogance so I really would appreciate being pointed in
> the right direction.
>
> 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
> Already have AD infrastructure in place authenticating staff work
> stations (~50 workstations)
> The servers exist to support our customers (not staff in general)
> These servers do not require shared home directories for staff.
> Staff accessing these servers are all performing some task relating to
> "administration", though at different levels (tech support through sys
> admin).
> * 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.
>
> Combinations we are seriously considering (in no particular order):
>
> NIS w/Kerberos (via SFU)
>
> Winbind
>
> Likewise Open
>
> We've found various bits and pieces that seemed promising with each of
> these approaches. This is our short list of best fit for the problems
> we've got, but perhaps we've overlooked something. I would really
> appreciate any pro's/con's from the trenches on this topic. "Likewise
> Open" seems to be the easiest to install at this point, so is slightly
> ahead in our evaluation.
>
> Thanks for your time,
>
> (sidenote: AD is being chosen because it is existing established
> infrastructure here that looks like it will do the job we need,
> nothing at all against openldap, this is just using the tool that
> we've got so we can focus on solving other challenges.)
>
> Neil Neely
> http://neil-neely.blogspot.com
>
>
>
>
> _______________________________________________
> Tech mailing list
> ***@lopsa.org
> http://lopsa.org/cgi-bin/mailman/listinfo/tech
> This list provided by the League of Professional System Administrators
> http://lopsa.org/

[Richard Chycoski]

Edward Ned Harvey wrote:
> Oh boy - you've touched on a fun topic. One that I've worked on a lot (and I'm sure a lot of other people here have as well.)
>
> There are several options available - Each one has its strengths and weaknesses. What I describe here is by no means a complete list. Just a list of what I can talk about.
>
> --- Option 1:
> The easiest one to set up is Unix services in Windows Server. Just add "Identity Management for UNIX" to your server, and voila - you now have extra tabs available for each user and group inside of AD. You should know - This stores the unix passwords on the server in a different format than the standard active directory password store, and since the original password store is non-reversible encryption, installation of UNIX services doesn't work instantly. Each user must reset their password once after the service is installed, before their password will work for UNIX. If you enable the NIS server, that's the absolute simplest way to get things working.
>
> There are a couple of downsides to the above solution - (a) If you want to follow the redhat user-private-group convention, then you run into a barrier. In AD, you cannot have a username and a group of the same name. The simplest solution is simply create "eharvey" and "eharveygroup" - but it is recommended to keep object names to 8 characters or less. Just a small obstacle. (b) Many people will tell you NIS is not the most secure protocol in the world. It does use encryption, but it's a weak form of encryption. Make your decision based on your organization's requirements. (c) There are a lot of advanced features available in things like LDAP, or standard unix NIS, which are not available in MS NIS. The MS NIS is only usable for basic functionality - pure posix - username,password,UID,GID,FullName, and shell.
This is actually more dangerous (security-wise) because with NIS you are exposing the encrypted passwords via NIS, which can then be used to crack the passwords. NIS passwords are also limited to eight characters, and if you sync (or allow your users to sync) their NIS and AD passwords, you are exposing both your Windows and Unix accounts. AD passwords can be much longer than eight characters and the encrypted format is not exposed to the world (unless you do something really bad to your AD config :-).

I would only (barely) consider installing NIS in a very well controlled, trusted environment - and even then, I'd probably skip it.

(I've spent a lot (too much!) of the last 20 years managing NIS and NIS+ environments - PLEASE move on to more current technology!)

If (after all my protestations against it :-) you do choose to use NIS via AD, take Clif's advice and use the AD server as a master with Linux replicas to handle the actual load - AD's NIS does not do well under load. NIS clients also don't like switching between replicas (slaves), they take their time switching and you can lose processes in the meantime, so keep your NIS slaves close to the clients (network-wise) and put them on stable, unloaded machines to prevent timeout. I would not put them on virtual machines, or machines shared with other services other than something lightweight like DNS. For a small number of client machines (which sounds like your situation) a single NIS slave might seem like enough, but two is a better idea. The slaves go away for a period of time when being updated. I would also put only the slaves into the 'ypservers' table on the slaves to prevent the clients from attaching themselves to the AD 'master' NIS server.


> --- Option 2:
> LDAP. This is very good, very powerful and extensible, reliable, and secure. If you can figure out how to get it working. Your first-time setup will not be easy, I promise you that. I think people normally take a class or two, read a couple of books, and google around for a while before they can get this working between unix & ad for the first time. After you're an expert it isn't hard anymore. Perhaps somebody has a recipe? There is always a risk that some AD schema change could mess something up - for example if you upgrade your server from 2003 to 2008 or whatever. The risk should be minimal, so don't be scared - just be cautious and use backups liberally.
>
> You need to store posix information somewhere. I believe another person mentioned you can store it in AD as long as you install the UNIX services and NIS, but simply disable NIS.
>
IIRC there are some issues with using LDAP for such authentication (if
your machines are not in the AD domain they don't have 'machine
accounts'), but I believe that they can be worked around - if your
machine administrators permit it, which may be a challenge since it does
reduce the security of the AD infrastructure.
> --- Option 3:
> Kerberos. Same pros/cons as ldap, just another protocol. Has the advantage of single sign on support. I'm guessing that the LDAP setup will be slightly easier than the Kerberos setup. But I'm not really sure.
>

Kerberos brings more complexity with it - tickets and their management.
Tickets time out - or you can set the timeout very long and expose your
accounts to nefarious ticket reuse. The AD clients for Unix that I've
seen have strategies for managing ticket timeout. If you're considering
Kerberos, you might as well go to full-blown AD, and get the advantages
of full integration.
> --- Option 4:
> Winbind. This is a clever little component of samba. It allows your linux client to join the windows domain just like another windows client. It has some snags with password synchronization (but with a little massaging you can get it to work). The main problem is - Each client has no authoritative source for UID/GID posix unification, so each client autogenerates the UID/GID's for each user account. As long as you're on a standalone machine, no problem. But if you have a bunch of clients all using NFS, then there's a problem. You need to ensure "eharvey" has the same UID on all the machines, or else the permissions on the NFS server will get screwed up. There are solutions to this problem - I believe another user posted a response to this effect.
>
>
>
I haven't tried this, but would only consider such solutions for a small
lab environment or other non-production application. It is far too
unregulated, and you will have issues when files on the server (or
attached NFS filesystem) can't be properly 'owned' until each user signs
on to each client machine.

It does sound like a useful trick for private one-offs, though... Try
this at home! :-)

- Richard

[Christophe Kalt]

On Wed, Dec 31, 2008 at 3:16 PM, Richard Chycoski
<***@chycoski.com> wrote:
> This is actually more dangerous (security-wise) because with NIS you are exposing the encrypted passwords via NIS, which can then be used to crack the passwords. NIS passwords are also limited to eight characters, and if you sync (or allow your users to sync) their NIS and AD passwords, you are exposing both your Windows and Unix accounts. AD passwords can be much longer than eight characters and the encrypted format is not exposed to the world (unless you do something really bad to your AD config :-).

Which OS still limits NIS passwords to 8 characters and/or weak encryption?

[John Stoffel]

This has been a great discussion about Unix/AD integration, esp the
part where the unix and AD admins need to coordinate well. I've got a
related, but different issue.

We have distributed engineering sites, and each site has it's own NIS
domain, so that if/when the WAN links go down, they can continue to
work.

I spent a bunch of time cleaning up the various UIDs, usernames, GIDs,
groupnames, etc to bring them more closely in sync. But now I'd like
to really bind them all into one LDAP domain, possibly with NIS slaves
at each site.

We support RHEL3, RHEL4, some RHEL5, Solaris 8, 9 & 10 (very little
any more) and some ancient RH7.3 boxes. Most boxes are compute
cluster boxes and they only allow login access via LSF (moving to
rtda.com's NC) to our users.

I'd like to have it so that all usernames/passwords are synced between
sites, and that I can create new user accounts from one master and
have it goto all the others. Yes, I could do some hackery and copy
data from the master NIS domain to the sub-domains, but it just sucks
to manage. And when a user changes their password in a remote NIS
domain, I then need to push that change back to the master. Blech.

So to me, it looks like LDAP, with multiple slaves and possibly even
NIS slaves binding to LDAP, is the way to go. Esp if I can be
tolerant of WAN failures.

I just don't want to have to support LDAP on Solaris 8 if I can avoid
it, though I guess it could be ok. Esp if we can easily tweak and
restrict access in various ways.

Should I look at the Padl.com stuff again? I looked at it a while
ago, but they wanted alot of money at the time. Maybe it's
changed... goes and looks.

Hmm... looks like I can/should use either the nss_ldap, or the
pam_ldap modules. Anyone have comments on using these on Solaris 8-10
systems? Any issues?

Thanks,
John

[Leon Towns-von Stauber]

On Jan 2, 2009, at 10:24 AM, John Stoffel wrote:

> I just don't want to have to support LDAP on Solaris 8 if I can avoid
> it, though I guess it could be ok. Esp if we can easily tweak and
> restrict access in various ways.
>
> Should I look at the Padl.com stuff again? I looked at it a while
> ago, but they wanted alot of money at the time. Maybe it's
> changed... goes and looks.
>
> Hmm... looks like I can/should use either the nss_ldap, or the
> pam_ldap modules. Anyone have comments on using these on Solaris 8-10
> systems? Any issues?


I used both on Solaris 8 several years ago (2001), and they worked
well as a YP replacement. I thought I had the documentation on what
I did, but can't find it now. I could probably dig up some config
files if you need them, though.

The one thing I couldn't get working on Solaris 8 for some reason
was TLS encryption for the LDAP sessions. I ended up using IPSec
between hosts, which was surprisingly easy using the bundled Solaris 8
tools (which have since changed). I do have details on that here:

http://www.occam.com/security/

--------------------------------------------------------------------
Leon Towns-von Stauber http://www.occam.com/leonvs/
"We have not come to save you, but you will not die in vain!"

[John Stoffel]

Leon> On Jan 2, 2009, at 10:24 AM, John Stoffel wrote:

>> I just don't want to have to support LDAP on Solaris 8 if I can
>> avoid it, though I guess it could be ok. Esp if we can easily
>> tweak and restrict access in various ways.
>>
>> Should I look at the Padl.com stuff again? I looked at it a while
>> ago, but they wanted alot of money at the time. Maybe it's
>> changed... goes and looks.
>>
>> Hmm... looks like I can/should use either the nss_ldap, or the
>> pam_ldap modules. Anyone have comments on using these on Solaris 8-10
>> systems? Any issues?

Leon> I used both on Solaris 8 several years ago (2001), and they
Leon> worked well as a YP replacement. I thought I had the
Leon> documentation on what I did, but can't find it now. I could
Leon> probably dig up some config files if you need them, though.

That would be helpful if you can send them on. In my site, I'll be
using LDAP to unify multiple domains, while still providing redundancy
and tolerance to network outages.

Leon> The one thing I couldn't get working on Solaris 8 for some
Leon> reason was TLS encryption for the LDAP sessions. I ended up
Leon> using IPSec between hosts, which was surprisingly easy using the
Leon> bundled Solaris 8 tools (which have since changed). I do have
Leon> details on that here:

Leon> http://www.occam.com/security/

Thanks for the pointer. I'm not going to worry as much about the TLS
stuff, since I'm still stuck with NIS and it's known issues too, along
with NFSv3 as well. Heck, some users are still using telnet and ftp
for stuff. So no, we're not very secure internally. We do need to
work better towards that state though.

Thanks for the pointers, reading the docs shows me that I'll need
*both* pam_ldap and nss_ldap in my setup, which isn't too bad at all.

Thanks,
John

[Ryan Dorman]

The instructions here:

http://blog.scottlowe.org/2007/01/15/linux-ad-integration-version-4/

Have been very helpful to me... obviously they are Linux specific but are a
good jumping off point for Samba/Kerberos

Watch how the pam files are setup on your distribution/flavor as there could
be other things (like a system-operators file) or some such.

-rd

-----Original Message-----
From: tech-***@lopsa.org [mailto:tech-***@lopsa.org] On Behalf Of
John Stoffel
Sent: Saturday, January 03, 2009 4:13 PM
To: Leon Towns-von Stauber
Cc: LOPSA Technical Discussions
Subject: Re: [lopsa-tech] AD integration with Unix


Leon> On Jan 2, 2009, at 10:24 AM, John Stoffel wrote:

>> I just don't want to have to support LDAP on Solaris 8 if I can
>> avoid it, though I guess it could be ok. Esp if we can easily
>> tweak and restrict access in various ways.
>>
>> Should I look at the Padl.com stuff again? I looked at it a while
>> ago, but they wanted alot of money at the time. Maybe it's
>> changed... goes and looks.
>>
>> Hmm... looks like I can/should use either the nss_ldap, or the
>> pam_ldap modules. Anyone have comments on using these on Solaris 8-10
>> systems? Any issues?

Leon> I used both on Solaris 8 several years ago (2001), and they
Leon> worked well as a YP replacement. I thought I had the
Leon> documentation on what I did, but can't find it now. I could
Leon> probably dig up some config files if you need them, though.

That would be helpful if you can send them on. In my site, I'll be
using LDAP to unify multiple domains, while still providing redundancy
and tolerance to network outages.

Leon> The one thing I couldn't get working on Solaris 8 for some
Leon> reason was TLS encryption for the LDAP sessions. I ended up
Leon> using IPSec between hosts, which was surprisingly easy using the
Leon> bundled Solaris 8 tools (which have since changed). I do have
Leon> details on that here:

Leon> http://www.occam.com/security/

Thanks for the pointer. I'm not going to worry as much about the TLS
stuff, since I'm still stuck with NIS and it's known issues too, along
with NFSv3 as well. Heck, some users are still using telnet and ftp
for stuff. So no, we're not very secure internally. We do need to
work better towards that state though.

Thanks for the pointers, reading the docs shows me that I'll need
*both* pam_ldap and nss_ldap in my setup, which isn't too bad at all.

Thanks,
John

_______________________________________________
Tech mailing list
***@lopsa.org
http://lopsa.org/cgi-bin/mailman/listinfo/tech
This list provided by the League of Professional System Administrators
http://lopsa.org/

[John Jasen]

Ryan Dorman wrote:
> The instructions here:
>
> http://blog.scottlowe.org/2007/01/15/linux-ad-integration-version-4/
>
> Have been very helpful to me... obviously they are Linux specific but are a
> good jumping off point for Samba/Kerberos
>
> Watch how the pam files are setup on your distribution/flavor as there could
> be other things (like a system-operators file) or some such.

Scott Lowe also has a solaris guide that is pretty useful.

Be forewarned -- if you start trying to use service principals, AD
doesn't exactly support them.

A lot of the recommendations floating around will tell you to create
user accounts and us AD's ktpass.exe to map the principal name to that.
You can map a principal name to a computer account, but the magic is
that you need to ensure that the userprincipalname attribute is mapped
to the service you want to kerberize. (Which is what ktpass does, and
forgets to tell you .... )

--
-- John E. Jasen (***@realityfailure.org)
-- No one will sorrow for me when I die, because those who would
-- are dead already. -- Lan Mandragoran, The Wheel of Time, New Spring

[Edward Ned Harvey]

Call me crazy, but I do all of what you've described below as follows:

NIS Master in US.
NIS Slaves scattered about the world.
(No LDAP.)
(No AD, although it might be a possibility)

WAN goes down, nobody cares. (Well, all the systems stay up and usable.)
No separation of which-password-where.
Create a user here, it appears everywhere.

The only problem I've ever had was - One time, one nis slave got out of sync with the server. So I had to re- ypinit the slave, and that was the end of that.

This is for a multinational company, but only for about 50 users within that company. Up for about 18 months now.





> -----Original Message-----
> From: tech-***@lopsa.org [mailto:tech-***@lopsa.org] On Behalf
> Of John Stoffel
> Sent: Friday, January 02, 2009 1:24 PM
> To: Christophe Kalt
> Cc: LOPSA Technical Discussions
> Subject: Re: [lopsa-tech] AD integration with Unix
>
>
> This has been a great discussion about Unix/AD integration, esp the
> part where the unix and AD admins need to coordinate well. I've got a
> related, but different issue.
>
> We have distributed engineering sites, and each site has it's own NIS
> domain, so that if/when the WAN links go down, they can continue to
> work.
>
> I spent a bunch of time cleaning up the various UIDs, usernames, GIDs,
> groupnames, etc to bring them more closely in sync. But now I'd like
> to really bind them all into one LDAP domain, possibly with NIS slaves
> at each site.
>
> We support RHEL3, RHEL4, some RHEL5, Solaris 8, 9 & 10 (very little
> any more) and some ancient RH7.3 boxes. Most boxes are compute
> cluster boxes and they only allow login access via LSF (moving to
> rtda.com's NC) to our users.
>
> I'd like to have it so that all usernames/passwords are synced between
> sites, and that I can create new user accounts from one master and
> have it goto all the others. Yes, I could do some hackery and copy
> data from the master NIS domain to the sub-domains, but it just sucks
> to manage. And when a user changes their password in a remote NIS
> domain, I then need to push that change back to the master. Blech.
>
> So to me, it looks like LDAP, with multiple slaves and possibly even
> NIS slaves binding to LDAP, is the way to go. Esp if I can be
> tolerant of WAN failures.
>
> I just don't want to have to support LDAP on Solaris 8 if I can avoid
> it, though I guess it could be ok. Esp if we can easily tweak and
> restrict access in various ways.
>
> Should I look at the Padl.com stuff again? I looked at it a while
> ago, but they wanted alot of money at the time. Maybe it's
> changed... goes and looks.
>
> Hmm... looks like I can/should use either the nss_ldap, or the
> pam_ldap modules. Anyone have comments on using these on Solaris 8-10
> systems? Any issues?
>
> Thanks,
> John
>
>
> _______________________________________________
> Tech mailing list
> ***@lopsa.org
> http://lopsa.org/cgi-bin/mailman/listinfo/tech
> This list provided by the League of Professional System Administrators
> http://lopsa.org/

[Yves Dorfsman]

Edward Ned Harvey wrote:
> Call me crazy, but I do all of what you've described below as follows:
>
> NIS Master in US.
> NIS Slaves scattered about the world.
> (No LDAP.)
> (No AD, although it might be a possibility)
>
> WAN goes down, nobody cares. (Well, all the systems stay up and usable.)
> No separation of which-password-where.
> Create a user here, it appears everywhere.

?

For the two last points, I am assuming that's only true in the UNIX
environment, if your users use MS Windows systems, they have different
passwords there (or have to keep them in sync manually themselves) ?

Right ?

--
Yves.
http://www.sollers.ca/blog/

[Edward Ned Harvey]

> > NIS Master in US.
> > NIS Slaves scattered about the world.
> > (No LDAP.)
> > (No AD, although it might be a possibility)
> >
> > WAN goes down, nobody cares. (Well, all the systems stay up and
> usable.)
> > No separation of which-password-where.
> > Create a user here, it appears everywhere.
>
> ?
>
> For the two last points, I am assuming that's only true in the UNIX
> environment, if your users use MS Windows systems, they have different
> passwords there (or have to keep them in sync manually themselves) ?
>
> Right ?

Correct you are. I could have worded it more clearly from the start. I meant to say:

I don't have separate NIS domains just because there are separate offices in different countries. Let there be a NIS master somewhere, and each of the other offices has a slave or two.

Perhaps the master could even be AD, in which case, you really could have unified AD/Linux passwords, create the user once, and it's always in sync everywhere. I have used AD NIS before, but only on a single server. Never did any sort of NIS replication that way before. I'm venturing a guess that it would be a pretty good solution, if you are ok with the limitations of the MS version of NIS.

[John Stoffel]

Edward> Call me crazy, but I do all of what you've described below as follows:

Edward> NIS Master in US.
Edward> NIS Slaves scattered about the world.
Edward> (No LDAP.)
Edward> (No AD, although it might be a possibility)

I sorta have this now, but it's hacky and prone to breakage.
Basically, it was setup before we had fast(ish) WAN links, so each
site was pretty much on it's own.

Now that I've spent the time finding conflicts, moving usernames/uids,
merging groups, etc, it's time to update it.

Home directories are the problem. We have site specific home dirs for
the same user account (new solution to fix this in the works) and some
users have seperate homedirs at seperate sites. Merging *those* is
going to be painful, but doable.

Again, we're an engineering shop and the users move lots of data
around, so NFS sucks over the WAN, though it's honestly tolerable for
home dirs.

We're about 200+ live accounts, lots more dead account whcih need to
be cleaned out, but bosses are nervous. It's the nature of the ASIC
design business that old projects come back from the dead at times.

Edward> WAN goes down, nobody cares. (Well, all the systems stay up
Edward> and usable.)

That's my goal.

Edward> No separation of which-password-where.

What happens when someone changes their password on a remote site
without connection to the master? Duh... stupid question. It means
they can't change it. Sorry, low of sleep...

Edward> Create a user here, it appears everywhere.

My goal for sure.

Edward> The only problem I've ever had was - One time, one nis slave
Edward> got out of sync with the server. So I had to re- ypinit the
Edward> slave, and that was the end of that.

Edward> This is for a multinational company, but only for about 50
Edward> users within that company. Up for about 18 months now.

I guess my goal is to start moving to LDAP and possibly AD integration
down the line sometime, so I figure taking the baby steps with the
pam_ldap and pam_nss modules might be the way to go. But you're
making me think I should really just bite the bullet and finish the
NIS map merge and cleanup home dirs so that things aren't seperated
by NIS domain.

John




>> -----Original Message-----
>> From: tech-***@lopsa.org [mailto:tech-***@lopsa.org] On Behalf
>> Of John Stoffel
>> Sent: Friday, January 02, 2009 1:24 PM
>> To: Christophe Kalt
>> Cc: LOPSA Technical Discussions
>> Subject: Re: [lopsa-tech] AD integration with Unix
>>
>>
>> This has been a great discussion about Unix/AD integration, esp the
>> part where the unix and AD admins need to coordinate well. I've got a
>> related, but different issue.
>>
>> We have distributed engineering sites, and each site has it's own NIS
>> domain, so that if/when the WAN links go down, they can continue to
>> work.
>>
>> I spent a bunch of time cleaning up the various UIDs, usernames, GIDs,
>> groupnames, etc to bring them more closely in sync. But now I'd like
>> to really bind them all into one LDAP domain, possibly with NIS slaves
>> at each site.
>>
>> We support RHEL3, RHEL4, some RHEL5, Solaris 8, 9 & 10 (very little
>> any more) and some ancient RH7.3 boxes. Most boxes are compute
>> cluster boxes and they only allow login access via LSF (moving to
>> rtda.com's NC) to our users.
>>
>> I'd like to have it so that all usernames/passwords are synced between
>> sites, and that I can create new user accounts from one master and
>> have it goto all the others. Yes, I could do some hackery and copy
>> data from the master NIS domain to the sub-domains, but it just sucks
>> to manage. And when a user changes their password in a remote NIS
>> domain, I then need to push that change back to the master. Blech.
>>
>> So to me, it looks like LDAP, with multiple slaves and possibly even
>> NIS slaves binding to LDAP, is the way to go. Esp if I can be
>> tolerant of WAN failures.
>>
>> I just don't want to have to support LDAP on Solaris 8 if I can avoid
>> it, though I guess it could be ok. Esp if we can easily tweak and
>> restrict access in various ways.
>>
>> Should I look at the Padl.com stuff again? I looked at it a while
>> ago, but they wanted alot of money at the time. Maybe it's
>> changed... goes and looks.
>>
>> Hmm... looks like I can/should use either the nss_ldap, or the
>> pam_ldap modules. Anyone have comments on using these on Solaris 8-10
>> systems? Any issues?
>>
>> Thanks,
>> John
>>
>>
>> _______________________________________________
>> Tech mailing list
>> ***@lopsa.org
>> http://lopsa.org/cgi-bin/mailman/listinfo/tech
>> This list provided by the League of Professional System Administrators
>> http://lopsa.org/

[Edward Ned Harvey]

> Again, we're an engineering shop and the users move lots of data
> around, so NFS sucks over the WAN, though it's honestly tolerable for
> home dirs.
>

OOooohhh... I would caution against that idea. You might not know how much your home dir gets used. Every new shell runs another .bashrc, every little X movement reads another dot-file of various sorts ... etc. The main thing about the WAN is that it's very high latency, even for tiny little files, it'll take another 1 second delay ... over and over and over and over ...

In the setup where I use the international NIS setup, the users have separate home directories in each country, but the path is always the same. So they're always /path/to/home but coming from a low-latency server.


> What happens when someone changes their password on a remote site
> without connection to the master? Duh... stupid question. It means
> they can't change it. Sorry, low of sleep...

Heheh. Right.


> I guess my goal is to start moving to LDAP and possibly AD integration
> down the line sometime, so I figure taking the baby steps with the
> pam_ldap and pam_nss modules might be the way to go. But you're
> making me think I should really just bite the bullet and finish the
> NIS map merge and cleanup home dirs so that things aren't seperated
> by NIS domain.

No matter what, you're going to have to unify all the UID/GID/username mappings anyway.

[Richard Chycoski]

>
>> Again, we're an engineering shop and the users move lots of data
>> around, so NFS sucks over the WAN, though it's honestly tolerable for
>> home dirs.
>>
>>
>
> OOooohhh... I would caution against that idea. You might not know how much your home dir gets used. Every new shell runs another .bashrc, every little X movement reads another dot-file of various sorts ... etc. The main thing about the WAN is that it's very high latency, even for tiny little files, it'll take another 1 second delay ... over and over and over and over ...
>
> In the setup where I use the international NIS setup, the users have separate home directories in each country, but the path is always the same. So they're always /path/to/home but coming from a low-latency server.
>
>
We still have NIS+ installed across the globe, with most data for
*everyone* (150K+ user accounts) replicated into the domain at every
location. The exception is home directory information where we have a
NIS+ automounter map for the home directories.

Most users have a single home directory in the location where they do
most of the work (usually local to where they live). However, for users
who do work in multiple theatres we can create separate home directories
in each of those theatres. This usually happens only after someone
complains about the speed (mounting a US-based home directory in Europe
or India is painful!) and when authorised by management.Others just put
up with the latency for occasional use 'across the pond'.

- Richard

[Robert Hajime Lanning]

On Wed, 2009-01-07 at 16:59 -0500, Edward Ned Harvey wrote:

> Call me crazy, but I do all of what you've described below as follows:
>
> NIS Master in US.
> NIS Slaves scattered about the world.
> (No LDAP.)
> (No AD, although it might be a possibility)
>
> WAN goes down, nobody cares. (Well, all the systems stay up and usable.)
> No separation of which-password-where.
> Create a user here, it appears everywhere.
>
> The only problem I've ever had was - One time, one nis slave got out of sync with the server. So I had to re- ypinit the slave, and that was the end of that.
>
> This is for a multinational company, but only for about 50 users within that company. Up for about 18 months now.


The big sell for AD in these environments (that I have seen) is the
multimaster capabilities.
WAN goes down, people can still modify/add/remove accounts.

--
END OF LINE
--MCP

[Richard Chycoski]

Christophe Kalt wrote:
> On Wed, Dec 31, 2008 at 3:16 PM, Richard Chycoski
> <***@chycoski.com> wrote:
>
>> This is actually more dangerous (security-wise) because with NIS you are exposing the encrypted passwords via NIS, which can then be used to crack the passwords. NIS passwords are also limited to eight characters, and if you sync (or allow your users to sync) their NIS and AD passwords, you are exposing both your Windows and Unix accounts. AD passwords can be much longer than eight characters and the encrypted format is not exposed to the world (unless you do something really bad to your AD config :-).
>>
>
> Which OS still limits NIS passwords to 8 characters and/or weak encryption?
>
Any system that uses the old standard 'crypt' password encoder. Solaris
8 was certainly this way (the man pages specifically indicate that only
the first 8 characters of the password are significant). Solariis 10 can
be altered by specifying a different algorithm.

- Richard

[Leon Towns-von Stauber]

>> Which OS still limits NIS passwords to 8 characters and/or weak
>> encryption?
>>
> Any system that uses the old standard 'crypt' password encoder.
> Solaris
> 8 was certainly this way (the man pages specifically indicate that
> only
> the first 8 characters of the password are significant). Solariis 10
> can
> be altered by specifying a different algorithm.


So can Solaris 9. But you're right, Solaris 8 and before, you're stuck
with crypt.

--------------------------------------------------------------------
Leon Towns-von Stauber http://www.occam.com/leonvs/
"We have not come to save you, but you will not die in vain!"

[Clif Smith]

I've used MS' UNIX services and NIS and for the most part it worked as
advertised. My one recommendation would be to front end it with a number of
Linux NIS slave servers. As my environment grew the MS NIS service would
frequently crash. After adding the Linux slaves, it was mostly stable.

My other gripes with the setup was:
- AD propagation throughout all sites only worked once ALL AD servers were
2003 R2. I wasn't in IT so I couldn't mandate it and it took some time for
them to catch up.
- Keeping Windows groups and UNIX groups in sync for users was a hassle.

I'm currently looking at a third party solution to solve the above as well
as implementing a more secure setup vs. NIS. I've toyed with Samba,
Winbind, etc. but being that I also have to account for AIX, HPUX and
Solaris, I've grown tired of trying to keep up with the various recipes and
headaches.

cjs


On Tuesday, 12/30/08 9:57 AM, "Edward Ned Harvey" <***@nedharvey.com>
wrote:

>> I'd really like a solution that is relatively painless to install/
>> configure so I can train puppet how to take care of this for me (Still
>> learning puppet). Failing that I'm looking for a recipe that I can
>> hand to a junior admin.
>
> In that case, your best solution is probably the MS built-in UNIX services and
> NIS. Nothing else is as simple and straight-forward. Just read my comments
> in the email one minute ago ...
>
> Also, I'd recommend enabling the services on more than one server. NIS
> clients perform very well switching from one NIS server to another, in the
> event one server becomes unavailable. But of course, only if there's more
> than one server available, and only if you told the clients about it.
>
>
>
> _______________________________________________
> Tech mailing list
> ***@lopsa.org
> http://lopsa.org/cgi-bin/mailman/listinfo/tech
> This list provided by the League of Professional System Administrators
> http://lopsa.org/

[b***@merctech.com]

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

[Christophe Kalt]

On Tue, Dec 30, 2008 at 6:32 PM, <***@merctech.com> wrote:
> 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.
[...]
> 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?

There used to be a small piece of SFU which allowed password
synchronization towards UNIX (or both ways possibly). I've always
hacked the source on the UNIX side to make it behave a bit better, but
it's a nice/simple setup: daemon on the DC and on the NIS master.

Of course, that's only useful as long as SSO isn't your goal :-)

[John Jasen]

***@merctech.com wrote:

<snipped for brevity: how do I get UNIX auth with AD passwords?>

Easy. Comfigure your UNIX systems as kerberos clients, and point your
krb5.conf files at the AD PDC and BDC(s).

Depending on your UNIX, you may have to muck around to get it to support
kerberos for login credentials (solaris and mlinux require PAM
modifications)

--
-- John E. Jasen (***@realityfailure.org)
-- No one will sorrow for me when I die, because those who would
-- are dead already. -- Lan Mandragoran, The Wheel of Time, New Spring

[John Jasen]

Various notes on configuring RHEL5, Solaris 10 and OSX 10.5 clients for
AD kerberos authentication and LDAP lookup.

RHEL5:


first attempt at an /etc/krb5.conf:
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log

[libdefaults]
default_realm = TRANSLAB.FQDN.XXX
dns_lookup_realm = false
dns_lookup_kdc = false
ticket_lifetime = 24h
forwardable = yes
# you may need to set _enctypes depending on your application.
# depending on your kerberos client, you may need to apply the
des-cbc-crc hotfix to your AD servers

[realms]
TRANSLAB.FQDN.XXX = {
kdc = translabpdc1.translab.fqdn.xxx:88
admin_server = translabpdc1.translab.fqdn.xxx:749
# you can add more kdcs. Depending on your setup, you can try DNS
resolution of DCs
# I think I later removed the :749 from admin_server
default_domain = translab.fqdn.xxx
}

[domain_realm]
.translab.stsci.edu = TRANSLAB.FQDN.XXX
translab.stsci.edu = TRANSLAB.FQDN.XXX

[appdefaults]
pam = {
debug = true
ticket_lifetime = 36000
renew_lifetime = 36000
forwardable = true
krb4_convert = false
}

first attempt at /etc/ldap.conf

# to use SSL/TLS with AD, I believe you need to get the PDC to spit out
#client certificates and install them on all the LDAP clients. I've not
#investigated this fully.

host AAA.BBB.CCC.4
bind_timelimit 120
bind_policy soft
# change to hard when working??
idle_timelimit 3600

# you may need to add this, and add in any other local users installed
by default:
#nss_initgroups_ignoreusers
root,ldap,named,avahi,haldaemon,messagebus,dbus,vcsa


base dc=translab,dc=fqdn,dc=XXX
uri ldap://translabpdc1.translab.fqdn.XXX/
binddn ***@translab.fqdn.XXX
bindpw pickagoodone!
scope sub
ssl no
nss_base_passwd dc=translab,dc=fqdn,dc=XXX?sub
nss_base_shadow dc=translab,dc=fqdn,dc=XXX?sub
nss_base_group dc=translab,dc=fqdn,dc=XXX?sub?
&(objectCategory=group)(gidnumber=*)
nss_map_objectclass posixAccount user
nss_map_objectclass shadowAccount user
nss_map_objectclass posixGroup group
nss_map_attribute gecos cn
nss_map_attribute homeDirectory unixHomeDirectory
nss_map_attribute uniqueMember member

pam modifications:

#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth sufficient pam_unix.so nullok try_first_pass
auth sufficient pam_krb5.so
# added for kerberos
auth requisite pam_succeed_if.so uid >= 500 quiet
auth required pam_deny.so

account required pam_unix.so
account sufficient pam_krb5.so
# added for kerberos
account sufficient pam_succeed_if.so uid < 500 quiet
account required pam_permit.so


Don't forget to modify /etc/nsswitch.conf to reflect files ldap for
passwd and group.

Solaris 10 Configuration:

/etc/krb5.conf is /etc/krb5/krb5.conf, but otherwise identical.

Use ldapclient to change solaris:

ldapclient manual \
-a credentialLevel=proxy \
-a authenticationMethod=simple \
-a proxyDN="cn=LDAP UNIX Binder,cn=Users,dc=translab,dc=fqdn,dc=xxx" \
-a proxyPassword=pickagoodone \
-a defaultSearchBase=dc=translab,dc=fqdn,dc=xxx \
-a domainName=translab.fqdn.xxx \
-a defaultServerList=AAA.BBB.CCC.4 \
-a attributeMap=group:userpassword=userPassword \
-a attributeMap=group:memberuid=memberUid \
-a attributeMap=group:gidnumber=gidNumber \
-a attributeMap=passwd:gecos=cn \
-a attributeMap=passwd:gidnumber=gidNumber \
-a attributeMap=passwd:uidnumber=uidNumber \
-a attributeMap=passwd:homedirectory=unixHomeDirectory \
-a attributeMap=passwd:loginshell=loginShell \
-a attributeMap=shadow:shadowflag=shadowFlag \
-a attributeMap=shadow:userpassword=userPassword \
-a objectClassMap=group:posixGroup=group \
-a objectClassMap=passwd:posixAccount=user \
-a objectClassMap=shadow:shadowAccount=user \
-a serviceSearchDescriptor=passwd:dc=translab,dc=fqdn,dc=xxx?sub \
-a serviceSearchDescriptor=group:dc=translab,dc=fqdn,dc=xxx?sub

ldapclient will copy over a new nsswitch.conf file, which you may want
to edit, depending on your configuration needs. If my memory serves, it
changes everything to using LDAP first.



Solaris PAM configuration: /etc/pam.conf

#
#ident "@(#)pam.conf 1.31 07/12/07 SMI"
#
# Copyright 2007 Sun Microsystems, Inc. All rights reserved.
# Use is subject to license terms.
#
# PAM configuration
#
# Unless explicitly defined, all services use the modules
# defined in the "other" section.
#
# Modules are defined with relative pathnames, i.e., they are
# relative to /usr/lib/security/$ISA. Absolute path names, as
# present in this file in previous releases are still acceptable.
#
# Authentication management
#
# login service (explicit because of pam_dial_auth)
#
login auth requisite pam_authtok_get.so.1
login auth required pam_dhkeys.so.1
login auth sufficient pam_krb5.so.1
login auth required pam_unix_cred.so.1
login auth required pam_unix_auth.so.1
login auth required pam_dial_auth.so.1
#
# rlogin service (explicit because of pam_rhost_auth)
#
rlogin auth sufficient pam_rhosts_auth.so.1
rlogin auth requisite pam_authtok_get.so.1
rlogin auth required pam_dhkeys.so.1
rlogin auth required pam_unix_cred.so.1
rlogin auth required pam_unix_auth.so.1
#
# Kerberized rlogin service
#
krlogin auth required pam_unix_cred.so.1
krlogin auth required pam_krb5.so.1
#
# rsh service (explicit because of pam_rhost_auth,
# and pam_unix_auth for meaningful pam_setcred)
#
rsh auth sufficient pam_rhosts_auth.so.1
rsh auth required pam_unix_cred.so.1
#
# Kerberized rsh service
#
krsh auth required pam_unix_cred.so.1
krsh auth required pam_krb5.so.1
#
# Kerberized telnet service
#
ktelnet auth required pam_unix_cred.so.1
ktelnet auth required pam_krb5.so.1
#
# PPP service (explicit because of pam_dial_auth)
#
ppp auth requisite pam_authtok_get.so.1
ppp auth required pam_dhkeys.so.1
ppp auth required pam_unix_cred.so.1
ppp auth required pam_unix_auth.so.1
ppp auth required pam_dial_auth.so.1
#
# Default definitions for Authentication management
# Used when service name is not explicitly mentioned for authentication
#
other auth requisite pam_authtok_get.so.1
other auth required pam_dhkeys.so.1
other auth sufficient pam_krb5.so.1
other auth required pam_unix_cred.so.1
other auth required pam_unix_auth.so.1
#
# passwd command (explicit because of a different authentication module)
#
passwd auth required pam_passwd_auth.so.1
#
# cron service (explicit because of non-usage of pam_roles.so.1)
#
cron account required pam_unix_account.so.1
#
# Default definition for Account management
# Used when service name is not explicitly mentioned for account management
#
other account requisite pam_roles.so.1
other account required pam_unix_account.so.1
other account required pam_krb5.so.1
#
# Default definition for Session management
# Used when service name is not explicitly mentioned for session management
#
other session required pam_unix_session.so.1
#
# Default definition for Password management
# Used when service name is not explicitly mentioned for password management
#
other password required pam_dhkeys.so.1
other password requisite pam_authtok_get.so.1
other password requisite pam_authtok_check.so.1
other password required pam_authtok_store.so.1
other password sufficient pam_krb5.so.1
#
# Support for Kerberos V5 authentication and example configurations can
# be found in the pam_krb5(5) man page under the "EXAMPLES" section.
#

For completeness: OS X

Try this script, based around Apple's dsconfigad:

http://patgmac.blogspot.com/2007/09/bind-to-ad-using-apple-remote-desktop.html

--
-- John E. Jasen (***@realityfailure.org)
-- No one will sorrow for me when I die, because those who would
-- are dead already. -- Lan Mandragoran, The Wheel of Time, New Spring

[Edward Ned Harvey]

> 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
>
> ...
>
> My current plan is to configure the servers with Samba as domain
> clients

I do have a word of caution for you here - because I have the same trouble myself. If AD is managed by some other group, without obsessive communication, I'll discourage the winbind/samba approach. Because it's very easy to change something in AD which causes the non-windows clients to cease functioning. And then you've got no alternative. It's a very real danger.

As a real life example - I do normally join linux clients onto the domain and share the "root /" just so I can browse the filesystem using native CIFS client in windows. I'll tell users about it, but for years I've continually called it "experimental" and tell them the supported tool is WinSCP (sftp client) instead. Then I repeated my procedure at a new customer's site, and couldn't join the domain. For no apparent reason; simply something in their schema makes it incompatible, can't be done without a real-life AD/Kerberos/Whatever super genius expert guru priest. I mean - I know this stuff pretty well - but I'm no genius expert - and I spent hours examining and repeating everything. Eventually gave up.