| Author | Messages | |
amulnick
Posts:163
 | | 05/12/2007 8:59 AM |
| Thanks Ryan. That helps again :)
My guess is that in your simulations/trials that the auth portion inherent in the other methods likely caused your slowdown. I wonder if it could have been overcome though with some other optimizations?
It's off to the testing board I guess.....
On 5/12/07, Ryan Dunn wrote:
Just noticed that this did not reply to the group:I was of the same opinion until one of my co-workers asked for my help
to use FCB on a very large installation.We also tested bothLogonUser and using SSPI (either NTLM or Kerberos) in both managed andunmanaged implementations.We found that using FCB was both fasterand less resource intensive (CPU mainly) and scaled the best.I don't
have the exact numbers anymore, but it was very large and verydemanding.I think they were going for using LDAP as authentication with FCB, andthey did one heck of a job.You don't have to believe me.Just try
it with large client loads.Also, I am not including building authorization into this either -this is purely authentication.If you are looking to build a WindowsSecurity token, this is not the way to do it.You can approximate it
if your application understands IPrincipal, but it is not areplacement for full Windows authorization.On 5/11/07, Michael B Allen wrote:
> On Fri, 11 May 2007 22:37:58 -0700> "Ryan Dunn" wrote:>> > I agree with you... with one fairly large caveat.FCB is an excellent
> > auth method and in my testing is faster than SSPI, LogonUser, or any> > other authentication method.In fact, this is what is used with the> > ActiveDirectoryMembershipProvider for authentication when SSL is
> > available.> >> > For normal LDAP bind, LDAP != Authentication (assuming other> > authentication methods are not available).I agree.For FCB LDAP> > bind == Authentication however.
>> Out of curiosity I just looked up FCB so I may not be fully informed> but I don't think I would characterize it as an "excellent auth> method". Kerberos would be just as fast (faster in a cross domain
> scenario) and you get a real binding, a security token and a session key.>> FCB sounds like it's just trying to accomodate the many existing> applications that use LDAP as a make-shift authentication service.
>> Most Kerberos implementations do SPNEGO now (MIT, Heimdal, Java 6) so> I think the argument for using LDAP for auth will become less compelling.>> Mike>> > On 5/11/07, Al Mulnick <
amulnick@gmail.com> wrote:> > > For high volume apps, yes, I agree that LDAP bind might be a bit too> > > heavy.For smallish apps, this won't hurt too bad.If you have a
> > > truly high-volume app, you should look into Fast Concurrent Binding> > >with Windows 2003.> > >> > > You misunderstood my thoughts there.Let me try again.> > > I was being purposefuly vague about the issues.But I have not always been
> > > that vague.> > >> > > LDAP != authentication protocol. Although sometimes seen in the wild posing> > > as an authentication protocol, it's not.It's not a server. It's a
> > > lightweight version of DAP.It's used to access a directory.> > > Authentication is somebody else's job.> > >> > > Asking your customer to go down this route is something I never recommend.
> > > It may scale (Sun seems to make it work in some cases) but it's designed for> > > authentication.It has shortcomings that may become difficult to live with.> > >> > >
> > > Just in case there were any misunderstandings.> > >> > > -ajm> > >> > >> > > On 5/10/07, Ryan Dunn <
dunnry@gmail.com> wrote:> > > >> > > > > Right.That's likely what they're talking about when they say you don't> > > > > have the rights.It's not that you don't have the rights, it's that you
> > > > > don't have the ability.> > > >> > > > I have no doubt that anonymous binds are not allowed.However, I> > > > doubt that authenticated binds are disabled - lots of stuff wouldn't
> > > > work IMO.I might be wrong... but like I said, just bind with ldp.exe> > > > and you will know if I am wrong or not. Note, I am talking about> > > > just binding here, no other operations (
i.e. just changing the> > > > connection state to authenticated).> > > >> > > > > It's fairly common to bind using Java for applications via ldap and> > > > > sometimes even over ssl.As you read that link below, you'll have to
> > > pay> > > > > attention to the trade-offs you'd be asking your customer to make in> > > order> > > > > to do ldap bind for your authentication (I shudder when I put ldap and
> > > > > authentication in the same sentence...)> > > > >> > > > For high volume apps, yes, I agree that LDAP bind might be a bit too> > > > heavy.For smallish apps, this won't hurt too bad.If you have a
> > > > truly high-volume app, you should look into Fast Concurrent Binding> > > > with Windows 2003.> > > >> > > > > You will NOT be able to compare the password.Well, it may be possible,
> > > but> > > > > again, not by default. (reversible encryption is there for a reason,> > > > > although I have yet to see anyone use it; it MAY allow you to do what
> > > you> > > > > talk about although I'd think less of you if you did that :)> > > >> > > > Reversible encryption I know is used with Digest Authentication.I
> > > > have not seen it used much else.Even if the password is reversible> > > > encryption, I am not sure you can read the attribute in AD - I still> > > > think it is write-only here.
>List info : http://www.activedir.org/List.aspxList FAQ: http://www.activedir.org/ListFAQ.aspxList archive:
http://www.activedir.org/ma/default.aspx | | | |
| listmail
Posts:822
| | 05/12/2007 10:51 AM |
| Yep, FCB will be considerably faster and less resource intensive. It is just
plain doing less work. Primarily it doesn't have to build a token which
means it doesn't do group expansion which is a decent portion of the
time/resources for logon. It also doesn't have to write anything back to the
directory of the last auth was successful as well(i.e. last logon times).
--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm
-----Original Message-----
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Ryan Dunn
Sent: Saturday, May 12, 2007 4:49 AM
To: Michael B Allen
Cc: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] LDAP Compare for user authentication...
Just noticed that this did not reply to the group:
I was of the same opinion until one of my co-workers asked for my help
to use FCB on a very large installation. We also tested both
LogonUser and using SSPI (either NTLM or Kerberos) in both managed and
unmanaged implementations. We found that using FCB was both faster
and less resource intensive (CPU mainly) and scaled the best. I don't
have the exact numbers anymore, but it was very large and very
demanding.
I think they were going for using LDAP as authentication with FCB, and
they did one heck of a job. You don't have to believe me. Just try
it with large client loads.
Also, I am not including building authorization into this either -
this is purely authentication. If you are looking to build a Windows
Security token, this is not the way to do it. You can approximate it
if your application understands IPrincipal, but it is not a
replacement for full Windows authorization.
On 5/11/07, Michael B Allen wrote:
> On Fri, 11 May 2007 22:37:58 -0700
> "Ryan Dunn" wrote:
>
> > I agree with you... with one fairly large caveat. FCB is an excellent
> > auth method and in my testing is faster than SSPI, LogonUser, or any
> > other authentication method. In fact, this is what is used with the
> > ActiveDirectoryMembershipProvider for authentication when SSL is
> > available.
> >
> > For normal LDAP bind, LDAP != Authentication (assuming other
> > authentication methods are not available). I agree. For FCB LDAP
> > bind == Authentication however.
>
> Out of curiosity I just looked up FCB so I may not be fully informed
> but I don't think I would characterize it as an "excellent auth
> method". Kerberos would be just as fast (faster in a cross domain
> scenario) and you get a real binding, a security token and a session key.
>
> FCB sounds like it's just trying to accomodate the many existing
> applications that use LDAP as a make-shift authentication service.
>
> Most Kerberos implementations do SPNEGO now (MIT, Heimdal, Java 6) so
> I think the argument for using LDAP for auth will become less compelling.
>
> Mike
>
> > On 5/11/07, Al Mulnick wrote:
> > > For high volume apps, yes, I agree that LDAP bind might be a bit too
> > > heavy. For smallish apps, this won't hurt too bad. If you have a
> > > truly high-volume app, you should look into Fast Concurrent Binding
> > > with Windows 2003.
> > >
> > > You misunderstood my thoughts there. Let me try again.
> > > I was being purposefuly vague about the issues. But I have not always
been
> > > that vague.
> > >
> > > LDAP != authentication protocol. Although sometimes seen in the wild
posing
> > > as an authentication protocol, it's not. It's not a server. It's a
> > > lightweight version of DAP. It's used to access a directory.
> > > Authentication is somebody else's job.
> > >
> > > Asking your customer to go down this route is something I never
recommend.
> > > It may scale (Sun seems to make it work in some cases) but it's
designed for
> > > authentication. It has shortcomings that may become difficult to live
with.
> > >
> > >
> > > Just in case there were any misunderstandings.
> > >
> > > -ajm
> > >
> > >
> > > On 5/10/07, Ryan Dunn wrote:
> > > >
> > > > > Right. That's likely what they're talking about when they say you
don't
> > > > > have the rights. It's not that you don't have the rights, it's
that you
> > > > > don't have the ability.
> > > >
> > > > I have no doubt that anonymous binds are not allowed. However, I
> > > > doubt that authenticated binds are disabled - lots of stuff wouldn't
> > > > work IMO. I might be wrong... but like I said, just bind with
ldp.exe
> > > > and you will know if I am wrong or not. Note, I am talking about
> > > > just binding here, no other operations (i.e. just changing the
> > > > connection state to authenticated).
> > > >
> > > > > It's fairly common to bind using Java for applications via ldap
and
> > > > > sometimes even over ssl. As you read that link below, you'll have
to
> > > pay
> > > > > attention to the trade-offs you'd be asking your customer to make
in
> > > order
> > > > > to do ldap bind for your authentication (I shudder when I put ldap
and
> > > > > authentication in the same sentence...)
> > > > >
> > > > For high volume apps, yes, I agree that LDAP bind might be a bit too
> > > > heavy. For smallish apps, this won't hurt too bad. If you have a
> > > > truly high-volume app, you should look into Fast Concurrent Binding
> > > > with Windows 2003.
> > > >
> > > > > You will NOT be able to compare the password. Well, it may be
possible,
> > > but
> > > > > again, not by default. (reversible encryption is there for a
reason,
> > > > > although I have yet to see anyone use it; it MAY allow you to do
what
> > > you
> > > > > talk about although I'd think less of you if you did that :)
> > > >
> > > > Reversible encryption I know is used with Digest Authentication. I
> > > > have not seen it used much else. Even if the password is reversible
> > > > encryption, I am not sure you can read the attribute in AD - I still
> > > > think it is write-only here.
>
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx | | | |
| listmail
Posts:822
| | 05/12/2007 11:17 AM |
| Well if you could have versions of the other auth
mechanisms that didn't put a token together they would be faster as well... And
they do have that for logonuser, it is called a network auth. No token is built,
specifically designed just to do fast auth. Still I expect FCB will be faster
but I haven't tested those two side by side.
--
O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Al
MulnickSent: Saturday, May 12, 2007 8:59 AMTo:
ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] LDAP Compare for
user authentication...
Thanks Ryan. That helps again :)
My guess is that in your simulations/trials that the auth portion inherent
in the other methods likely caused your slowdown. I wonder if it could have been
overcome though with some other optimizations?
It's off to the testing board I guess.....
On 5/12/07, Ryan Dunn
wrote:
Just
noticed that this did not reply to the group:I was of the same opinion
until one of my co-workers asked for my help to use FCB on a very large
installation.We also tested bothLogonUser and using SSPI
(either NTLM or Kerberos) in both managed andunmanaged
implementations.We found that using FCB was both fasterand
less resource intensive (CPU mainly) and scaled the best.I don't
have the exact numbers anymore, but it was very large and
verydemanding.I think they were going for using LDAP as
authentication with FCB, andthey did one heck of a job.You
don't have to believe me.Just try it with large client
loads.Also, I am not including building authorization into this either
-this is purely authentication.If you are looking to build a
WindowsSecurity token, this is not the way to do it.You can
approximate it if your application understands IPrincipal, but it is not
areplacement for full Windows authorization.On 5/11/07, Michael B
Allen
wrote:> On Fri, 11 May 2007 22:37:58 -0700> "Ryan Dunn" wrote:>>
> I agree with you... with one fairly large caveat.FCB is an
excellent > > auth method and in my testing is faster than SSPI,
LogonUser, or any> > other authentication method.In
fact, this is what is used with the> >
ActiveDirectoryMembershipProvider for authentication when SSL is > >
available.> >> > For normal LDAP bind, LDAP !=
Authentication (assuming other> > authentication methods are not
available).I agree.For FCB LDAP> > bind ==
Authentication however. >> Out of curiosity I just looked up FCB
so I may not be fully informed> but I don't think I would characterize
it as an "excellent auth> method". Kerberos would be just as fast
(faster in a cross domain > scenario) and you get a real binding, a
security token and a session key.>> FCB sounds like it's just
trying to accomodate the many existing> applications that use LDAP as a
make-shift authentication service. >> Most Kerberos
implementations do SPNEGO now (MIT, Heimdal, Java 6) so> I think the
argument for using LDAP for auth will become less compelling.>>
Mike>> > On 5/11/07, Al Mulnick < amulnick@gmail.com> wrote:>
> > For high volume apps, yes, I agree that LDAP bind might be a bit
too> > > heavy.For smallish apps, this won't hurt too
bad.If you have a > > > truly high-volume app, you
should look into Fast Concurrent Binding> > >with
Windows 2003.> > >> > > You misunderstood my
thoughts there.Let me try again.> > > I was being
purposefuly vague about the issues.But I have not always been
> > > that vague.> > >> > > LDAP !=
authentication protocol. Although sometimes seen in the wild posing>
> > as an authentication protocol, it's not.It's not a
server. It's a > > > lightweight version of DAP.It's
used to access a directory.> > > Authentication is somebody
else's job.> > >> > > Asking your customer to go
down this route is something I never recommend. > > > It may
scale (Sun seems to make it work in some cases) but it's designed for>
> > authentication.It has shortcomings that may become
difficult to live with.> > >> > > > > >
Just in case there were any misunderstandings.> > >> >
> -ajm> > >> > >> > > On 5/10/07,
Ryan Dunn < dunnry@gmail.com>
wrote:> > > >> > > > >
Right.That's likely what they're talking about when they say you
don't> > > > > have the rights.It's not that
you don't have the rights, it's that you > > > > > don't
have the ability.> > > >> > > > I have no
doubt that anonymous binds are not allowed.However, I> >
> > doubt that authenticated binds are disabled - lots of stuff wouldn't
> > > > work IMO.I might be wrong... but like I
said, just bind with ldp.exe> > > > and you will know if I am
wrong or not. Note, I am talking about> > > > just
binding here, no other operations ( i.e. just changing the> > >
> connection state to authenticated).> > > >> >
> > > It's fairly common to bind using Java for applications via ldap
and> > > > > sometimes even over ssl.As you
read that link below, you'll have to > > > pay> > >
> > attention to the trade-offs you'd be asking your customer to make
in> > > order> > > > > to do ldap bind for
your authentication (I shudder when I put ldap and > > > >
> authentication in the same sentence...)> > > >
>> > > > For high volume apps, yes, I agree that LDAP bind
might be a bit too> > > > heavy.For smallish apps,
this won't hurt too bad.If you have a > > > >
truly high-volume app, you should look into Fast Concurrent Binding>
> > > with Windows 2003.> > > >> > >
> > You will NOT be able to compare the password.Well, it
may be possible, > > > but> > > > > again, not
by default. (reversible encryption is there for a reason,> > >
> > although I have yet to see anyone use it; it MAY allow you to do
what> > > you> > > > > talk about although I'd
think less of you if you did that :)> > > >> > >
> Reversible encryption I know is used with Digest
Authentication.I > > > > have not seen it used
much else.Even if the password is reversible> > >
> encryption, I am not sure you can read the attribute in AD - I
still> > > > think it is write-only here. >List
info : http://www.activedir.org/List.aspxList
FAQ: http://www.activedir.org/ListFAQ.aspxList
archive: http://www.activedir.org/ma/default.aspx | | | |
| AD000001730
Posts:0
| | 05/12/2007 12:16 PM |
| Kerberos auth does not require any communication between the application
server and the domain controller. The fully expanded groups are in
the PAC in the ticket and the logon time is not updated for a kerberos
auth. So if the app server is on a different host from the DC, then in
theory Kerberos should actually, in theory, be *faster* because FCB would
require network communication with the DC whereas Kerberos does not at
all. FCB multiplexes binds over the same transport but it's still gotta
send out electrons over a wire.
So I'm a little shocked to hear your results but I've never tried the
scenario you describe so ...
Mike
On Sat, 12 May 2007 01:49:24 -0700
"Ryan Dunn" wrote:
> Just noticed that this did not reply to the group:
>
> I was of the same opinion until one of my co-workers asked for my help
> to use FCB on a very large installation. We also tested both
> LogonUser and using SSPI (either NTLM or Kerberos) in both managed and
> unmanaged implementations. We found that using FCB was both faster
> and less resource intensive (CPU mainly) and scaled the best. I don't
> have the exact numbers anymore, but it was very large and very
> demanding.
>
> I think they were going for using LDAP as authentication with FCB, and
> they did one heck of a job. You don't have to believe me. Just try
> it with large client loads.
>
> Also, I am not including building authorization into this either -
> this is purely authentication. If you are looking to build a Windows
> Security token, this is not the way to do it. You can approximate it
> if your application understands IPrincipal, but it is not a
> replacement for full Windows authorization.
>
> On 5/11/07, Michael B Allen wrote:
> > On Fri, 11 May 2007 22:37:58 -0700
> > "Ryan Dunn" wrote:
> >
> > > I agree with you... with one fairly large caveat. FCB is an excellent
> > > auth method and in my testing is faster than SSPI, LogonUser, or any
> > > other authentication method. In fact, this is what is used with the
> > > ActiveDirectoryMembershipProvider for authentication when SSL is
> > > available.
> > >
> > > For normal LDAP bind, LDAP != Authentication (assuming other
> > > authentication methods are not available). I agree. For FCB LDAP
> > > bind == Authentication however.
> >
> > Out of curiosity I just looked up FCB so I may not be fully informed
> > but I don't think I would characterize it as an "excellent auth
> > method". Kerberos would be just as fast (faster in a cross domain
> > scenario) and you get a real binding, a security token and a session key.
> >
> > FCB sounds like it's just trying to accomodate the many existing
> > applications that use LDAP as a make-shift authentication service.
> >
> > Most Kerberos implementations do SPNEGO now (MIT, Heimdal, Java 6) so
> > I think the argument for using LDAP for auth will become less compelling.
> >
> > Mike
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx | | | |
| listmail
Posts:822
| | 05/12/2007 12:33 PM |
| This assumes kerberized clients doing the auth prior to talking to the app
server in which case the auth isn't faster but is distributed so couldn't
really be measured as part of the app speed. The domain auth is part of the
TGT process and the app server would only be involved in the TGS process
which means the client is already auth'ed. This may or may not be an
assumption you can make, on an internal network where the client pool is
completely controlled or you just refuse any clients that don't come
knocking with a kerb cert, you probably can make this assumption. In larger
environments it gets tough to assume this as you could have multiple
untrusted forests, people using machines that aren't joined to any domain
(this is my standard running method), folks coming in through various
reverse proxies, etc.
Straight Kerberos auth up against the FCB is going to be slower as it has
more work to do; including updating the logon time. I think what you were
referring to when you mention that logon time isn't updated with Kerb auth
is that it isn't updated for TGS requests. Certainly the TGT request pops it
or else the attribute would have no value unless you did a lot of NTLM auth.
joe
--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm
-----Original Message-----
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Michael B Allen
Sent: Saturday, May 12, 2007 12:16 PM
To: ActiveDir@mail.activedir.org
Cc: Ryan Dunn
Subject: Re: [ActiveDir] LDAP Compare for user authentication...
Kerberos auth does not require any communication between the application
server and the domain controller. The fully expanded groups are in
the PAC in the ticket and the logon time is not updated for a kerberos
auth. So if the app server is on a different host from the DC, then in
theory Kerberos should actually, in theory, be *faster* because FCB would
require network communication with the DC whereas Kerberos does not at
all. FCB multiplexes binds over the same transport but it's still gotta
send out electrons over a wire.
So I'm a little shocked to hear your results but I've never tried the
scenario you describe so ...
Mike
On Sat, 12 May 2007 01:49:24 -0700
"Ryan Dunn" wrote:
> Just noticed that this did not reply to the group:
>
> I was of the same opinion until one of my co-workers asked for my help
> to use FCB on a very large installation. We also tested both
> LogonUser and using SSPI (either NTLM or Kerberos) in both managed and
> unmanaged implementations. We found that using FCB was both faster
> and less resource intensive (CPU mainly) and scaled the best. I don't
> have the exact numbers anymore, but it was very large and very
> demanding.
>
> I think they were going for using LDAP as authentication with FCB, and
> they did one heck of a job. You don't have to believe me. Just try
> it with large client loads.
>
> Also, I am not including building authorization into this either -
> this is purely authentication. If you are looking to build a Windows
> Security token, this is not the way to do it. You can approximate it
> if your application understands IPrincipal, but it is not a
> replacement for full Windows authorization.
>
> On 5/11/07, Michael B Allen wrote:
> > On Fri, 11 May 2007 22:37:58 -0700
> > "Ryan Dunn" wrote:
> >
> > > I agree with you... with one fairly large caveat. FCB is an excellent
> > > auth method and in my testing is faster than SSPI, LogonUser, or any
> > > other authentication method. In fact, this is what is used with the
> > > ActiveDirectoryMembershipProvider for authentication when SSL is
> > > available.
> > >
> > > For normal LDAP bind, LDAP != Authentication (assuming other
> > > authentication methods are not available). I agree. For FCB LDAP
> > > bind == Authentication however.
> >
> > Out of curiosity I just looked up FCB so I may not be fully informed
> > but I don't think I would characterize it as an "excellent auth
> > method". Kerberos would be just as fast (faster in a cross domain
> > scenario) and you get a real binding, a security token and a session
key.
> >
> > FCB sounds like it's just trying to accomodate the many existing
> > applications that use LDAP as a make-shift authentication service.
> >
> > Most Kerberos implementations do SPNEGO now (MIT, Heimdal, Java 6) so
> > I think the argument for using LDAP for auth will become less
compelling.
> >
> > Mike
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx | | | |
| tech4steve
Posts:17
| | 05/14/2007 1:11 AM |
| Maybe a little OT - but this isnt exactly 100% true..
See http://blogs.msdn.com/spatdsg/archive/2007/03/07/pac-validation.aspx
steve
-------------- Original message -------------- From: Michael B Allen > Kerberos auth does not require any communication between the application > server and the domain controller. The fully expanded groups are in > the PAC in the ticket and the logon time is not updated for a kerberos > auth. So if the app server is on a different host from the DC, then in > theory Kerberos should actually, in theory, be *faster* because FCB would > require network communication with the DC whereas Kerberos does not at > all. FCB multiplexes binds over the same transport but it's still gotta > send out electrons over a wire. > > So I'm a little shocked to hear your results but I've never tried the > scenario you describe so ... > > Mike > > > On Sat, 12 May 2007 01:49
:24 -0700 > "Ryan Dunn" wrote: > > > Just noticed that this did not reply to the group: > > > > I was of the same opinion until one of my co-workers asked for my help > > to use FCB on a very large installation. We also tested both > > LogonUser and using SSPI (either NTLM or Kerberos) in both managed and > > unmanaged implementations. We found that using FCB was both faster > > and less resource intensive (CPU mainly) and scaled the best. I don't > > have the exact numbers anymore, but it was very large and very > > demanding. > > > > I think they were going for using LDAP as authentication with FCB, and > > they did one heck of a job. You don't have to believe me. Just try > > it with large client loads. > > > > Also, I am not including building authorization into this either - > > this is p
urely authentication. If you are looking to build a Windows > > Security token, this is not the way to do it. You can approximate it > > if your application understands IPrincipal, but it is not a > > replacement for full Windows authorization. > > > > On 5/11/07, Michael B Allen wrote: > > > On Fri, 11 May 2007 22:37:58 -0700 > > > "Ryan Dunn" wrote: > > > > > > > I agree with you... with one fairly large caveat. FCB is an excellent > > > > auth method and in my testing is faster than SSPI, LogonUser, or any > > > > other authentication method. In fact, this is what is used with the > > > > ActiveDirectoryMembershipProvider for authentication when SSL is > > > > available. > > > > > > > > For normal LDAP bind, LDAP != Authentication (assuming oth
er > > > > authentication methods are not available). I agree. For FCB LDAP > > > > bind == Authentication however. > > > > > > Out of curiosity I just looked up FCB so I may not be fully informed > > > but I don't think I would characterize it as an "excellent auth > > > method". Kerberos would be just as fast (faster in a cross domain > > > scenario) and you get a real binding, a security token and a session key. > > > > > > FCB sounds like it's just trying to accomodate the many existing > > > applications that use LDAP as a make-shift authentication service. > > > > > > Most Kerberos implementations do SPNEGO now (MIT, Heimdal, Java 6) so > > > I think the argument for using LDAP for auth will become less compelling. > > > > > > Mike > List info : http://www.activedir.org/L
ist.aspx > List FAQ : http://www.activedir.org/ListFAQ.aspx > List archive: http://www.activedir.org/ma/default.aspx | | | |
| AD000001730
Posts:0
| | 05/14/2007 8:31 AM |
| Hi Steve,
Interesting link. I was curious enough to look into this a little.
That communication is the PAC_PRIVSVR_CHECKSUM validation. From
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnkerb/html/msdn_pac.asp
it seems this check prevents an exploit scenario that can occur under
certain conditions:
"Validation of the PAC_PRIVSVR_CHECKSUM is OPTIONAL. It is used to
verify that the PAC was issued from the KDC and not placed in the
ticket by someone other than the KDC with access to the service key."
So if your server does not completely protect the service key from other
processes on the same host (e.g. a compromised httpd worker), the might be
able to create their own PAC and change their privileges.
But for someone who favors speed they can probably disable the
PAC_PRIVSVR_CHECKSUM validation.
Mike
On Mon, 14 May 2007 17:11:23 +0000
tech4steve@comcast.net wrote:
> Maybe a little OT - but this isnt exactly 100% true..
>
> See http://blogs.msdn.com/spatdsg/archive/2007/03/07/pac-validation.aspx
>
> steve
>
>
> -------------- Original message --------------
> From: Michael B Allen
>
> > Kerberos auth does not require any communication between the application
> > server and the domain controller. The fully expanded groups are in
> > the PAC in the ticket and the logon time is not updated for a kerberos
> > auth. So if the app server is on a different host from the DC, then in
> > theory Kerberos should actually, in theory, be *faster* because FCB would
> > require network communication with the DC whereas Kerberos does not at
> > all. FCB multiplexes binds over the same transport but it's still gotta
> > send out electrons over a wire.
> >
> > So I'm a little shocked to hear your results but I've never tried the
> > scenario you describe so ...
> >
> > Mike
> >
> >
> > On Sat, 12 May 2007 01:49:24 -0700
> > "Ryan Dunn" wrote:
> >
> > > Just noticed that this did not reply to the group:
> > >
> > > I was of the same opinion until one of my co-workers asked for my help
> > > to use FCB on a very large installation. We also tested both
> > > LogonUser and using SSPI (either NTLM or Kerberos) in both managed and
> > > unmanaged implementations. We found that using FCB was both faster
> > > and less resource intensive (CPU mainly) and scaled the best. I don't
> > > have the exact numbers anymore, but it was very large and very
> > > demanding.
> > >
> > > I think they were going for using LDAP as authentication with FCB, and
> > > they did one heck of a job. You don't have to believe me. Just try
> > > it with large client loads.
> > >
> > > Also, I am not including building authorization into this either -
> > > this is purely authentication. If you are looking to build a Windows
> > > Security token, this is not the way to do it. You can approximate it
> > > if your application understands IPrincipal, but it is not a
> > > replacement for full Windows authorization.
> > >
> > > On 5/11/07, Michael B Allen wrote:
> > > > On Fri, 11 May 2007 22:37:58 -0700
> > > > "Ryan Dunn" wrote:
> > > >
> > > > > I agree with you... with one fairly large caveat. FCB is an excellent
> > > > > auth method and in my testing is faster than SSPI, LogonUser, or any
> > > > > other authentication method. In fact, this is what is used with the
> > > > > ActiveDirectoryMembershipProvider for authentication when SSL is
> > > > > available.
> > > > >
> > > > > For normal LDAP bind, LDAP != Authentication (assuming other
> > > > > authentication methods are not available). I agree. For FCB LDAP
> > > > > bind == Authentication however.
> > > >
> > > > Out of curiosity I just looked up FCB so I may not be fully informed
> > > > but I don't think I would characterize it as an "excellent auth
> > > > method". Kerberos would be just as fast (faster in a cross domain
> > > > scenario) and you get a real binding, a security token and a session key.
> > > >
> > > > FCB sounds like it's just trying to accomodate the many existing
> > > > applications that use LDAP as a make-shift authentication service.
> > > >
> > > > Most Kerberos implementations do SPNEGO now (MIT, Heimdal, Java 6) so
> > > > I think the argument for using LDAP for auth will become less compelling.
> > > >
> > > > Mike
> > List info : http://www.activedir.org/List.aspx
> > List FAQ : http://www.activedir.org/ListFAQ.aspx
> > List archive: http://www.activedir.org/ma/default.aspx
--
Michael B Allen
PHP Active Directory Kerberos SSO
http://www.ioplex.com/
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ma/default.aspx | | | |
|
|