Sun Java System Directory Server Authentication

Chan Ming Man <ch*****@hotmail.comwrote:

Forgive me to say that. I did not see why VS 2005 need to put in effort for
LDAP because I do not think someone will like to run their WinApp (Windows
Application) or WebApp (ASP.NET) in Solaris.

Just because you don't run the application itself on Solaris doesn't
mean you won't need to talk to a Solaris LDAP server.

Can you imagine if the web client facilities only allowed you to fetch
pages from IIS?

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Dec 14 '06 #3

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP************************@msnews.microsoft.c om...

Chan Ming Man <ch*****@hotmail.comwrote:
>Forgive me to say that. I did not see why VS 2005 need to put in effort for
LDAP because I do not think someone will like to run their WinApp (Windows
Application) or WebApp (ASP.NET) in Solaris.

Just because you don't run the application itself on Solaris doesn't
mean you won't need to talk to a Solaris LDAP server.

Can you imagine if the web client facilities only allowed you to fetch
pages from IIS?

Jon,
This is Ok for simple HTML, all webservers will handle that, but you can't expect a Solaris
"Webserver" to handle asp or asp.net requests.
The same analogy goes for LDAP, you can't expect it to handle authentication of Windows
accounts, right? LDAP is not an authentication protocol and an LDAP server (just as an AD on
Windows) is not required to "handle" all possible authentication type requests either, nor
should you expect it to implement the AD schema.
That said, the System.DirectoryServices.Protocols namespace offers low-level access to the
LDAP V3 protocol, so this is where the OP should start with.

Willy.

Dec 14 '06 #4

<tr********@gmail.comwrote in message
news:11**********************@80g2000cwy.googlegro ups.com...

>I am new to LDAP and Directory Services, and I have a project that
requires me to authenticate users against a Sun Java System Directory
Server in order to access the application. I have found dozens of
examples of how to authenticate users against Active Directory, but AD
seems to be a different animal than Sun Java System Directory Server.

Could someone provide me with an example of how to authenticate a user
against a Directory Server other than Active Directory (specifically
Sun Java System Directory Server if you can) using C# or point me to an
online resource?

Thanks!

Take a look at the System.DirectoryServices.Protocols namespace, it contains all classes you
need to access a V3 LDAP server.
One thing which is not perfectly clear is what exactly do you mean with "authenticate a
user". The LDAP server is not an "authentication" server, you can "authenticate "a
connection with the LDAP server, but this is just meant to authenticate the user accessing
the LDAP server, this is however not a generic way to authenticate users. Note also that you
can't authenticate "Windows accounts" against a non AD server and Solaris Directory is not a
replicate of a DC (running a AD).

Willy.

Dec 14 '06 #5

Willy Denoyette [MVP] wrote:

Can you imagine if the web client facilities only allowed you to fetch
pages from IIS?

This is Ok for simple HTML, all webservers will handle that, but you can't expect a Solaris
"Webserver" to handle asp or asp.net requests.

I'd expect it to handle HTTP requests though - and that's closer to
what's being requested, I believe.

The same analogy goes for LDAP, you can't expect it to handle authentication of Windows
accounts, right? LDAP is not an authentication protocol and an LDAP server (just as an AD on
Windows) is not required to "handle" all possible authentication type requests either, nor
should you expect it to implement the AD schema.

LDAP isn't *just* an authentication protocol, but there is the concept
of "authenticate this user by trying to log into an LDAP server with
this username/password".

That said, the System.DirectoryServices.Protocols namespace offers low-level access to the
LDAP V3 protocol, so this is where the OP should start with.

Right.

Jon

Dec 14 '06 #6

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:11**********************@t46g2000cwa.googlegr oups.com...

Willy Denoyette [MVP] wrote:

Can you imagine if the web client facilities only allowed you to fetch
pages from IIS?

This is Ok for simple HTML, all webservers will handle that, but you can't expect a
Solaris
"Webserver" to handle asp or asp.net requests.

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. But, LDAP is more than a session layer protocol,
it's also an application layer protocol, that is, it exposes well defined set of application
services (version dependant) and here is where the analogy with HTTP stops, and
authentication is not one of them.

>The same analogy goes for LDAP, you can't expect it to handle authentication of Windows
accounts, right? LDAP is not an authentication protocol and an LDAP server (just as an AD
on
Windows) is not required to "handle" all possible authentication type requests either,
nor
should you expect it to implement the AD schema.

LDAP isn't *just* an authentication protocol, but there is the concept
of "authenticate this user by trying to log into an LDAP server with
this username/password".

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

Dec 14 '06 #7

Willy Denoyette [MVP] <wi*************@telenet.bewrote:

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.

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.

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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Dec 14 '06 #8

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP************************@msnews.microsoft.c om...

Willy Denoyette [MVP] <wi*************@telenet.bewrote:

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.

Dec 14 '06 #9

Willy Denoyette [MVP] <wi*************@telenet.bewrote:

<snip good stuff>

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?

Well, for whatever reason, and regardless of whether or not it's always
a good idea (which it may be in some small companies which use an LDAP
server for other purposes and don't want to have a separate service for
genuine authentication) I believe it's not uncommon to use LDAP this
way...

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Dec 14 '06 #10

We run into requirements to use LDAP for authentication all the time.
Even if LDAP wasn't designed for true authentication (and isn't
particularly developer friendly for it), it's extremely common.

Previously as a gov't contractor the majority of our applications
included LDAP authentication, usually against non-AD servers. Now in
a university marketplace many of our customers use LDAP authentication
as well, some for AD but some not. Also it's quite common for COTS
products to include LDAP as an authentication means.

So even if LDAP wasn't originally designed for authentication (and
this is the first I heard it isn't) it certainly is used for
authentication and telling clients/developers that they can't use LDAP
this way 'cause it isn't designed to be used for authentication is
foolish.

My $0.02.

Sam

------------------------------------------------------------
We're hiring! B-Line Medical is seeking Mid/Sr. .NET
Developers for exciting positions in medical product
development in MD/DC. Work with a variety of technologies
in a relaxed team environment. See ads on Dice.com.
On Thu, 14 Dec 2006 22:22:18 -0000, Jon Skeet [C# MVP]
<sk***@pobox.comwrote:

>Willy Denoyette [MVP] <wi*************@telenet.bewrote:

<snip good stuff>

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?

Well, for whatever reason, and regardless of whether or not it's always
a good idea (which it may be in some small companies which use an LDAP
server for other purposes and don't want to have a separate service for
genuine authentication) I believe it's not uncommon to use LDAP this
way...

Dec 14 '06 #11

"Samuel R. Neff" <sa********@nomail.comwrote in message
news:u2********************************@4ax.com...

>
We run into requirements to use LDAP for authentication all the time.
Even if LDAP wasn't designed for true authentication (and isn't
particularly developer friendly for it), it's extremely common.

Previously as a gov't contractor the majority of our applications
included LDAP authentication, usually against non-AD servers. Now in
a university marketplace many of our customers use LDAP authentication
as well, some for AD but some not. Also it's quite common for COTS
products to include LDAP as an authentication means.

So even if LDAP wasn't originally designed for authentication (and
this is the first I heard it isn't) it certainly is used for
authentication and telling clients/developers that they can't use LDAP
this way 'cause it isn't designed to be used for authentication is
foolish.

My $0.02.

Sam

------------------------------------------------------------
We're hiring! B-Line Medical is seeking Mid/Sr. .NET
Developers for exciting positions in medical product
development in MD/DC. Work with a variety of technologies
in a relaxed team environment. See ads on Dice.com.
On Thu, 14 Dec 2006 22:22:18 -0000, Jon Skeet [C# MVP]
<sk***@pobox.comwrote:

>>Willy Denoyette [MVP] <wi*************@telenet.bewrote:

<snip good stuff>

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

Well, for whatever reason, and regardless of whether or not it's always
a good idea (which it may be in some small companies which use an LDAP
server for other purposes and don't want to have a separate service for
genuine authentication) I believe it's not uncommon to use LDAP this
way...

Guess you are talking about something else , maybe a small company running Linux and some
open LDAP server deamon, while I'm talking about "WIndows" here, that is Windows client
needing to get authenticated , when I say LDAP I mean AD and when I say Logon server I mean
a DC. These are two different scenarios really, in the first case I would say go on no
problem, but in the Windows case I say don't do it, there is much better.

Once again the LDAP server doesn't actually do the authentication, it hands the task to an
authentication service like LSA using the authentication type as specified by the client
(NTLM, Kerberos, Digest etc..), this authentication service doesn't necessarily run on the
LDAP server box but on a Login server of the DOMAIN of the user that needs to get
authenticated.
There is nothing wrong with this kind of authentication scenario as long as the LDAP server
and the authentication authority service runs on the same box, but even then it's always
faster (10 times) to authenticate directly with the LSA, the Win32 API's are there ready
to be used so why using LDAP to authenticate is beyond me really
But say you are Binding to the LDAP server on "Jupiter" just to authenticate "Bob", which
is a member of a Windows Domain "Earth", now "Jupiter" will have send an authentication
request to the logon server on the DC of the domain "Earth", no big deal when both are on
the same local network in the same Domain realm, but what if they are separated by a few
hundred miles and a bunch of network routers and switches?

This is exactly the situation we had years back, an AD server in Reading UK (a BU in
Valbonne - France and Munich Germany), and the DC's (and GC) for our Domain in Brussels,
imagine what happened when some guy's where stressing their brand new asp application which
authenticated against the AD in Reading? A connection request to LDAP in Reading, followed
by an NTLM authentication handshake between Reading and Brussels, just to get an access
token and then bye..., no directory access no queries nothing. This is just the same as
making an authenticated connection with a RDBMS server like SQLServer without ever running a
query, no-one will ever do this, but doing the same against an LDAP server (which is juts
another DB server right?) is considered common?
Willy.

Dec 15 '06 #12

Willy Denoyette [MVP] <wi*************@telenet.bewrote:

<snip>

Guess you are talking about something else , maybe a small company
running Linux and some open LDAP server deamon, while I'm talking
about "WIndows" here, that is Windows client needing to get
authenticated , when I say LDAP I mean AD and when I say Logon server
I mean a DC. These are two different scenarios really, in the first
case I would say go on no problem, but in the Windows case I say
don't do it, there is much better.

But we know the OP is in the first category, don't we?

<quote>
I am new to LDAP and Directory Services, and I have a project that
requires me to authenticate users against a Sun Java System Directory
Server in order to access the application.
</quote>

I would be very wary of assuming that LDAP==AD in the same way that I'd
be wary of HTTP==IIS.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Dec 15 '06 #13

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP************************@msnews.microsoft.c om...

Willy Denoyette [MVP] <wi*************@telenet.bewrote:

<snip>

>Guess you are talking about something else , maybe a small company
running Linux and some open LDAP server deamon, while I'm talking
about "WIndows" here, that is Windows client needing to get
authenticated , when I say LDAP I mean AD and when I say Logon server
I mean a DC. These are two different scenarios really, in the first
case I would say go on no problem, but in the Windows case I say
don't do it, there is much better.

But we know the OP is in the first category, don't we?

Yes I do, and I dis answer his question ,didn't I? But this is a different (albeit related)
issue.
First my excuses for the long post's and the long thread, but I think it's important enough
to be somewhat explicit.
My point is about the common sense of using LDAP for authentication, more specifically using
LDAP 'bind' to authenticate which, even if "it works", is not the most appropriate way to
authenticate, even not on NON Windows systems.
Unfortunately, even on MSDN (see patterns & Practices at
http://msdn.microsoft.com/library/de...SecNetHT02.asp )
you'll find samples of asp.net using AD authentication which goes like this:

<snip
string domainAndUsername = domain + @"\" + username;
DirectoryEntry entry = new DirectoryEntry( _path,
domainAndUsername,
pwd);
try
{
// Bind to the native AdsObject to force authentication.
Object obj = entry.NativeObject;
</snip
Above code uses LDAP "bind" to authenticate the "domainAndUsername" but the code is
flawned, why?
1) It's not pure authentication request, it's an *authorization* request (authenticate +
access check), if the the _path is protected by an ACL which does not grant access for
domainAndUsername, the "authentication will fail albeit the user credentials are perfectly
legitime, bummer!
2) DirectoryEntry sit's in top of the ADSI COM client stuff (activeds.dll), part of a
successful bind is the transfer of the AD metadata (the directory schema) to be cached at
the client (per process/ApplicationDomain), this is done to speed-up consecutive requests
against the Directory. The schema is a something like ~100Kb of data, quite a bit of data
just to authenticate a client, right? Result, a scalability issue.
3) But there is more, if the bind fails for one or another reason, the client (ADSI in this
case) produces a "default" minimal schema and stores it in the cache (again per
process/ApplicationDomain), however this schema doesn't reflect the real AD schema. The
result is that successful binds following the unsuccesful bind (this is an asp.net
application right), will use the "default schema" instead of the real AD schema and will get
some weird errors (NO_SUCH_PROPERTY or NO_SUCH_OBJECT ) when trying to query the directory.
Many have been bitten by this, especially those using ADSI (and System.DirectoryServices) to
bind and query non AD servers.

The sample above continuous like :
....
DirectorySearcher search = new DirectorySearcher(entry);
search.Filter = "(SAMAccountName=" + username + ")";
search.PropertiesToLoad.Add("cn");
SearchResult result = search.FindOne();
if(null == result)
....
Great, the user whas correctly authenticated, and now we are going to perform a look up for
the same user, the authentication above was done against the LSA (the security provider on
Windows) and apparantly the author thinks it necessary to check whether the user is also
stored in this Directory. The chapter in this document is called - To develop LDAP
authentication code to look up the user in Active Directory -. English is not my first
language, but as far as I see it, this implies two different tasks "authentication" and
"Lookup". The lookup is not needed if you only want to authenticate, right?.

Now, the above code was written for V1.1 of the framework, V2 was added the LDAP low level
stuff through the System.DirectoryServices.Protocols, unfortunately above is used frequently
to authenticate from asp or asp.net, but in V2 we can solve issues 2 and 3 above, by coding
something like:

...
// Bind to an LDAP server
using (LdapConnection ldap = new LdapConnection("LdapServerName"))
{
LdapSessionOptions so = ldap.SessionOptions;
ldap.AuthType = AuthType.Basic; // or Ntlm, Kerberos etc... depending on the SSP
ldap.Bind(new NetworkCredential("userName", "UserPAwd"));
}

Look, no ADSI stuff under the cover, though this code is much closer to what we are trying
to achieve, that is *authenticating*, we still we may face issue 1, the authentication is
done against a Security Provider (using the SSPI on Windows), but the bind is done to the
root of the directory (AD or None-AD) and if this one is protected by ACL's, the Bind may
fail resulting in a false negative.
The only way to solve this is by authenticating using the SSPI and selecting Kerberos ,
Secure Channle (SSL) or a custom provider interface to authenticate against Windows or
Non-Windows Security Providers.

Willy.

Dec 15 '06 #14

Most of the time when we run into LDAP and it isn't AD then the
request is related to thousands of users authenticating against Oracle
Internet Directory. Not some open "LDAP server daemon"

Sam
------------------------------------------------------------
We're hiring! B-Line Medical is seeking Mid/Sr. .NET
Developers for exciting positions in medical product
development in MD/DC. Work with a variety of technologies
in a relaxed team environment. See ads on Dice.com.

>Guess you are talking about something else , maybe a small company running Linux and some
open LDAP server deamon, while I'm talking about "WIndows" here, that is Windows client
needing to get authenticated , when I say LDAP I mean AD and when I say Logon server I mean
a DC. These are two different scenarios really, in the first case I would say go on no
problem, but in the Windows case I say don't do it, there is much better.
Willy.

Dec 15 '06 #15

"Samuel R. Neff" <sa********@nomail.comwrote in message
news:7o********************************@4ax.com...

>
Most of the time when we run into LDAP and it isn't AD then the
request is related to thousands of users authenticating against Oracle
Internet Directory. Not some open "LDAP server daemon"

Sam

Sam,
Please define "authenticating", guess you are retrieving/checking the users credentials
against the ones stored the Oracle Directory aren't you?
If that's true, this is not my point, there is nothing wrong with that, what I'm talking
about is people calling LDAP's *Bind* API only to "authenticate", they don't query the
Directory at all. And this is what I call a screwed way of authentication, when you bind to
a Directory whatever, it's because you want to retrieve some (user?) info, right? Not that
LDAP server plays a middleman between a client and an authentication service (LSA SP on
Windows, Bind on U**X etc..) and nothing more.

Willy.

Dec 15 '06 #16

We've done bind simply to authenticate but more often we bind and then
check if the user has a particular attribute which grants access to
our application.

How do you check credentials without binding (assuming no further
lookup is needed)?

Sam

------------------------------------------------------------
We're hiring! B-Line Medical is seeking Mid/Sr. .NET
Developers for exciting positions in medical product
development in MD/DC. Work with a variety of technologies
in a relaxed team environment. See ads on Dice.com.
On Fri, 15 Dec 2006 17:47:34 +0100, "Willy Denoyette [MVP]"
<wi*************@telenet.bewrote:

>"Samuel R. Neff" <sa********@nomail.comwrote in message
news:7o********************************@4ax.com.. .
>>
Most of the time when we run into LDAP and it isn't AD then the
request is related to thousands of users authenticating against Oracle
Internet Directory. Not some open "LDAP server daemon"

Sam

Sam,
Please define "authenticating", guess you are retrieving/checking the users credentials
against the ones stored the Oracle Directory aren't you?
If that's true, this is not my point, there is nothing wrong with that, what I'm talking
about is people calling LDAP's *Bind* API only to "authenticate", they don't query the
Directory at all. And this is what I call a screwed way of authentication, when you bind to
a Directory whatever, it's because you want to retrieve some (user?) info, right? Not that
LDAP server plays a middleman between a client and an authentication service (LSA SP on
Windows, Bind on U**X etc..) and nothing more.

Willy.

Dec 15 '06 #17

"Samuel R. Neff" <sa********@nomail.comwrote in message
news:nt********************************@4ax.com...

>
We've done bind simply to authenticate but more often we bind and then
check if the user has a particular attribute which grants access to
our application.

I see, In this case it's perfectly valid to authenticate by a Bind to the Directory server,
I remember Oracle Directory has it's own Kerberos SP included in the package, and the
Directory doesn't contain much more info than user's and user attributes, right?
You don't overload a global Directory server with authentication requests and there is no
network traffic other than the client <--Directory server transfer.

How do you check credentials without binding (assuming no further
lookup is needed)?

You can't check credentials without binding to an LDAP server, but you don't need an LDAP
server to authenticate, if the purpose is only *authenticate*. All you need is a Security
Provider, like the LSA on Windows, or Bind on U**X, and select a protocol depending on your
security requirements (do you need secure channel, encryption and stuff like that).
Windows includes a number of SSP providers, which allow an application to use different
security models, using what is called the SSPI, on a local computer or over a network
whithout changing the interface to the SP. It inclues SSP's for Kerberos, NTLM, and a
number of other security packages, unfortunately the SSPI isn't publicly exposed through
some namespace classes in the framework, but the WCF uses the SSPI under the covers to
support authentication. Take a look at the SSPI info and WCF authentication info in the SDK
docs for more details, it's more than worth a read. It's not that complicated to write a
Windows client that authenticates over Kerberos with a Security provider that runs on VAX
OVMS ;-)

Willy.

Dec 15 '06 #18