Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:21307
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Date: Wed, 21 Dec 2005 13:50:36 -0500
To: pierre.php@gmail.com
Cc: internals@lists.php.net
Message-ID: <20051221135036.69369f23.mba2000@ioplex.com>
In-Reply-To: <20051221140613.6e967471@localhost.localdomain>
References: <20051221005926.4c8ad254.mba2000@ioplex.com>
	<4e89b4260512202258j47f6745foe3b3f4d493b6cbba@mail.gmail.com>
	<20051221035606.18815a25.mba2000@ioplex.com>
	<20051221140613.6e967471@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Maintaining State Across Requests / An SSO Extension
From: mba2000@ioplex.com (Michael B Allen)

On Wed, 21 Dec 2005 14:06:13 +0100
Pierre <pierre.dev@gmail.com> wrote:

> On Wed, 21 Dec 2005 03:56:06 -0500
> mba2000@ioplex.com (Michael B Allen) wrote:
> 
> > On Wed, 21 Dec 2005 01:58:41 -0500
> > Wez Furlong <kingwez@gmail.com> wrote:
> > 
> > > Just curious, why aren't you writing this as an apache module?
> > > 
> > > Is this of any use; it seems a bit dated, but could save you some
> > > effort:
> > > http://meta.cesnet.cz/cms/opencms/en/docs/software/devel/negotiate.html
> > 
> > Well for one, mod_auth_gss_krb5 only does authentication. My *real*
> > product is Windows integration libraries for non-Windows environments
> > (i.e. LAMP). So, for example, this SSO module is going to include
> > Windows authorization functionality for integration with AD. Meaning
> > the developer can restrict content based on group membership of
> > groups defined in an AD domain:
> 
> There is already some NTLM modules for apache. A php version will may
> be available in PEAR. NTLM is what you are trying to achieve, or a part
> of it. Single Sign On is another problem, and can be done with various
> auth mechanisms. Are you implementing SSO as well? :)

Actually I don't think you're going to be satisfied with NTLM. Here's a
few reasons:

1) W2K3 requires SMB signing by default and with NTLM you don't have
the plain text equivalent password hash necessary to generate a valid
MAC key. You have to setup credentials to perform the initial connect
to the DC which is ugly because people don't want to put passwords into
config files.
2) You cannot perform delegation with NTLM. That's one of the principal
reasons why MS has moved to Kerberos. So if you want to use the negotiated
credentials to then connect to other resources like file servers it will
not work [1].
3) Prevailing security policy these days is moving away from NTLM. At
some point you're going to run into an admin that refuses to support it
in which case you must also implement NTLMv2.
4) For NTLM or NTLMv2 you must implement NTLMSSP which is not supported
by Heimdal or MIT Kerberos GSSAPI implementations (although I might fix
this soon).

Basically NTLM is depricated. NTLMv2 is still used when communicating
with non-domain members but Kerberos is a much nicer system and honestly
it's probably easier considering there are GSSAPI implementations that
can do the heavy lifting for you now.

Mike

[1] Actually you can proxy NTLM but that means you must renegotiate with
each resource you try to access.