That primer says that it is using LDAP Auth[1]. LDAP
is not an Auth protocol as much as some would like it to force it to try and be.
It is just a guess but I expect, this, which is the usual in the *nix world, is
a simple LDAP bind that is redirected. They are not using SSL[2] but they could
be using TLS but the lack of any mention of TLS or SSL or certs would tend to
make me expect to see clear text passwords zipping across the
network.
I really dislike steps 9 & 10. It looks like they have
a hardcoded userid requirement. I always hate when companies do that crap. That
should be configurable. Other than that, as Al mentioned this looks like a pain
to use.
If you
are using AD as a backend auth store for anything, you should use kerberos to do
it. Unlike LDAP, kerberos *IS* an authentication protocol.
As
Alan mentioned, you can do this without purchasing any third party tools.
HOWEVER, expect to have a kerberos Dev/Troubleshooting team especially if you
have anything other than one or two basic *nix platforms or multiple domains in
the forest (multirealm in kerberos parlance). Basic MIT Kerberos really doesn't
work well in a multirealm environment that is handled so easily and
transparently by Windows. You will tend to have to write custom code if you want
to do multirealm which will be a pain to maintain. Also the whole management of
*nix computer objects in AD can be a pain through the default mechanisms and I
have seen special perl services written to handle the whole keytab and account
management portion of the integration running on Windows machines that
talk to the *nix boxes through sockets.
This
is where products from Centrify and Vintela really help out. It makes it so you
don't have to do any of that dev work. You simply load up the products and the
*nix boxes integrate with AD. This includes auth, authorization, group policies,
etc. Additionally you get to deal with one product across all your *nix
platforms versus having custom versions of MIT for Solaris, RH Linux, SUSE
Linux, HPUX, etc etc etc. Again, if you have to deal with multirealm, you
probably don't want to do this with the default kerberos packages.
joe
[1]
The other option is to create
and register an authentication module which specifically performs LDAP
authentication against the Active Directory.
[2]
See step 3, port 389.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Douglas M. Long
Sent: Monday, May 02, 2005 10:26 PM
To: [email protected]
Subject: Solaris authentication
Anyone know if this is passed in plain text? If so, i
dont see any advantage to this versus the NIS server in SFU. Seems that the *nix
community is making no progress in the secure authentication arena if this is
the case. Any ideas or thoughts?
