Re: Sun Java System Directory Server Authentication

"Jon Skeet [C# MVP]" <skeet@xxxxxxxxx> wrote in message news:MPG.1febb6edce12413098d6e9@xxxxxxxxxxxxxxxxxxxxxxx
Willy Denoyette [MVP] <willy.denoyette@xxxxxxxxxx> wrote:
> I'd expect it to handle HTTP requests though - and that's closer to
> what's being requested, I believe.
Note that I'm not picking on you, I largely following your reasoning and that I don't agree
with Chan's answer at all, I'm only discussing the part I don't follow your reasoning.
A client sending an HTTP request to a Webserver will not get the *expected* answer when the
request is meant to be handled by a ASP, ASP.NET ....you name it ... service. At the core,
each Webserver is handling the HTTP protocol (say http v1 and/v1.1), but that doesn't mean
that each of them can/will handle the services requested. Also, HTTP is a session layer
protocol nothing more.
The same goes for LDAP, at the core each LDAP server handles the LDAP protocol, but that
doesn't mean each is handling all possible *service* requests, for instance don't expect
Solaris LDAP to handle NTLM authentication.

Certainly - I agree there. I think part of the problem is that "Active
Directory" is more often than not primarily used for things *other*
than what I tend to think of as directory services.


Well, that's exactly my point, people tend to use AD only as an authentication service, but it isn't an authentication service, it just a service which (optionally) needs to "authorize" accesses to it's DB (the directory). but before it can "authorize" it has to "authenticate". The actual authentication isn't done by AD itself, it's done by the one and only authenticator in Windows - the LSA. It's far more easier to authenticate using regular authentication API's than to bind against a Directory server which at it's turn needs to set-up an authentication handshake with the LSA of the logon domain of the user specified by the credentials, just to get an access token which is not used any further!.
And that's exactly why large corporation and Financial organizations don't allow (all of) their users to access the Active Directory, just by putting a deny ACL on the root of their domain they prevent people to use if solely for "authentication". When this DACL is applied, "authentication" will fail not because of invalid credentials but because of a lack of access privs.
We had the exact same issue a while ago, people running IIS on their desktop authenticating like mad against the AD, result overloaded AD servers (LDAP Bind requests) overloaded Logon servers (not run on Windows but on VAX VMS at that time) and excessive of network traffic.

Which is not the same thing, authentication is meant to "validate user credentials",
network "authentication" as used when binding against an LDAP server is meant to 1) validate
user's credentials, and 2) check access privileges to the LDAP server. Note also that the
LDAP server doesn't handle 1), it relies on another (authentication) system service for
this, on Windows it's relying on the LSA (Local Security Authority) service. Therefore it's
plain wrong to use LDAP for *authentication*, it's not guaranteed to correctly answer the
question *are these credentials correct ?*, simply because it was not designed to answer
such question.
It's quite possible that a bind fails specifying correct credentials, just because of a lack
of access privileges. For the same reason you won't connect to MSSQL or ORACLE, only to
*authenticate* a user do you? When I ask the same question to customers who are using LDAP
for authentication, they answer, sure not!! SQL server is a RDBMS and then I answer and LDAP
server is a Directory Service....

That's certainly true - but if you have all your users in the
directory, and they all have access appropriately set up, it seems
reasonable to use that for an authentication check.

Not really see above.

It's not entirely uncommon to want to authenticate using an LDAP server
- it's sufficiently common that there's an Apache module for the
purpose, for instance.


That's true if you have a secured webserver, for which you don't want to open the corporate firewall to have access to your most precious directory servers (and or Domain Controller(s) on Windows) from the internet. . In this case you can set-up a "private" LDAP server (or a simple DB server) on the Webserver machine just to authenticate external clients, but here we aren't talking about a Directory Server right?


Willy.

.

Relevant Pages

  • Re: [opensuse] LDAP served network
    ... One LDAP server and one LDAP client. ... I use pam to configure the various services to perform ... an ldap authentication. ...
    (SuSE)
  • Re: Directory Services, LDAP or similar
    ... In other projects, we managed the user authentication by creating tables that define all users and its allowed capacities, then the application queryies that data to verify if a user has access to some feature or not. ... The above ID and password are sent to the service at login time. ... They are using Novell eDirectory at the enterprise level; yes it's LDAP. ... We already do that for three different DB servers; ...
    (borland.public.delphi.non-technical)
  • Re: Directory Services, LDAP or similar
    ... we managed the user authentication by creating tables ... The above ID and password are sent to the service at login ... Novell eDirectory at the enterprise level; yes it's LDAP. ... servers; ...
    (borland.public.delphi.non-technical)
  • Re: [opensuse] LDAP served network
    ... One LDAP server and one LDAP client. ... Server_1 is file a group file server with several shares with common ... I think so, I've all my server performing an ssh ldap authentication, ... I use pam to configure the various services to perform ...
    (SuSE)
  • Re: Windows 2003/IIS 6.0 + IE 6.0 - random authentication dialog
    ... NetMon can be found in Add/Remove Programs under Network ... Proper Integrated Authentication functionality requires strict adherence to ... authentication and runnning under Windows 2003 Server Standard ... It happens when the UI requests dynamic content from ...
    (microsoft.public.inetserver.iis.security)