Re: LDAP Authentication for Single Sign On

Joe - Thanks for the rapid and comprehensive response. Of course it spurs a
couple more questions...

Please keep in mind that I am an AD/LDAP novice (read:clueless)

1.) So no authentication is required when performing bind operations only
against AD?

2.) My users are distributed in a number of OU's that all live under a self
created Users & User Groups OU. (Again excuse my ignorance here) Can the bind
operation work in this configuration?

3.) If I do find that I have to create a service account can you steer me
towards somewhere I might look for details on limiting said service account
so that it only has access to read from the OU in question?

4.) If the (non-Windows) client doesn't support anything other than a simple
bind and I use a self assigned certificate isn't it just a case of
configuring the client performing the bind to trust it?

5.) You mention not needing transport security if IPSEC is in place in the
VPN. But isn't the password still sent in plaintext and therefore subject to
exposure?

Thanks in advance for your help,

Jeremy

"Joe Kaplan" wrote:

Microsoft generally recommends against using LDAP for authentication against
AD, so you won't tend to find a lot of guidance out there on it. It is done
A LOT though and can be done well or poorly.

My first comment would be why you need to do a search in the first place.
If your only goal is to authenticate the user with credentials the user
provided, then a bind operation is all that's needed. You don't need to do
any search unless unless you need to discover additional information about
the user. That isn't really necessarily part of the authentication though.

That said, it is a very common pattern to see LDAP authentication schemes
use some sort of a service account to do searches to get information about
the user. If you really need that, then you'll need to provision some sort
of a service account. Restricting information from service accounts (or any
account) in AD can be a bit painful as the default design of the directory
is to make most data available for read by authenticated users. It can be
done, but is extra work for sure.

Regarding PKI, the first thing I would suggest is that AD provides a variety
of binding mechanisms using SASL that are secure and do not require
transport encryption. If the client can do a Windows "secure" bind
"GSS-SPNEGO" SASL mechanism in LDAP), then that will actually use Kerberos
or NTLM to do the authentication. If the client can do DIGEST
authentication, then you can use that with AD as well. Only if you need to
do an LDAP simple bind do you need transport encryption, as that is the only
method that sends the user's credentials in plaintext. Unfortunately, this
is default way that people do this type of thing when using non-Windows
clients.

I highly recommend you avoid using a self-signed cert for any of your DCs,
but you can do that. The problem with self-signed certs is that no one
trusts them by default, so every client that will attempt to connect via SSL
will need to have a copy of the certificate available so they can configure
the client machine to trust it. I think you are much better off with real
externally issued third-party SSL certs or an enterprise CA.

You can also use IPSEC as transport security and may already have that in
place with a VPN tunnel, so you might not really need transport security at
the LDAP level.

I also highly recommend you look at Active Directory Federation Services
(ADFS) for implementing this type of architecture. ADFS allows your AD to
act as an account store to other applications and organizations and
establish trust using standard protocols and techniques. You don't poke
holes in your firewall to support this type of scenario. It is more work to
do in the short run but it gives you a reusable asset that allows you to use
your directory in a more flexible way with other third-party relationships
in the future, so it is more strategic than tactical.

Best of luck!

Joe K.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--
"Jeremy Revitch" <JeremyRevitch@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:58DB0D4C-C5CB-4E38-B4D4-3C4C99CE0F51@xxxxxxxxxxxxxxxx
I am working with a third party ISV to enable their application to
authenticate using LDAP over an existing VPN tunnel and have a few
questions:

1.) Is there a guide or documentation to such an implementation?
2.) Is there a simple way to create a user account for the queries to run
under that only has read access to the minimum require resources?
3.) Without a PKI is there a simple way to implement SSL for LDAP with a
self signed certificate?



.

Relevant Pages

  • RE: How to Authenticate to WCF Service Via VPN
    ... \par Microsoft MSDN Online Support Lead ... He launches Cisco Systems VPN Client and authenticates as ... \par> includes the service account identity as a user principal name. ... \par> mutual authentication is assumed. ...
    (microsoft.public.dotnet.framework.webservices)
  • RE: How to Authenticate to WCF Service Via VPN
    ... \par From your description, you're encountering some problem when calling a WCF service from a client which use a VPN connection to the server's domain environment, correct? ... The client endpoint ... \par includes the service account identity as a user principal name. ... \par mutual authentication is assumed. ...
    (microsoft.public.dotnet.framework.webservices)
  • Re: LDAP Authentication for Single Sign On
    ... Microsoft generally recommends against using LDAP for authentication against ... That isn't really necessarily part of the authentication though. ... use some sort of a service account to do searches to get information about ... If the client can do DIGEST ...
    (microsoft.public.windows.server.active_directory)
  • Re: Security logging ldap Authentication in Active Directory
    ... authentication to AD because of default policy which prevents ... I would have guessed that NetAPP would keep it to ... This setup required a service account that the NetCache ... uses to bind to AD. ...
    (microsoft.public.windows.server.active_directory)
  • Re: Windows Authentication, Single sign on and Active Directory
    ... service proxy client fails to connect due to authentication failure and then ... Co-author of "The .NET Developer's Guide to Directory Services Programming" ... The server is always in the domain. ...
    (microsoft.public.dotnet.framework.aspnet.security)