Re: LDAP Authentication for Single Sign On

Joe Kaplan wrote:
However, some applications and services that do programmatic authentication
against LDAP directories do more than a bind operation as part of the
authentication. Some will also perform LDAP searches to do things like
verifying that the user exists or reading some attributes on the user. I
was trying to suggest that this is not really necessary and isn't really
part of the authentication itself, as the bind operation is the actual
authentication.

Mainly LDAP-enabled applications will search for a unique user ID (like
'uid', 'mail' or for AD 'samAccountName') to find the accompanying bind
DN needed for the simple bind request. Yes, Joe is partially correct: AD
directly accepts the UPN in simple bind operation. But that's not LDAPv3
compliant.

Relevant excerpts from RFC 4511 (LDAPv3), continue yourself
with RFC 4514:

------------------------------- snip -------------------------------
[..]
An LDAPDN is defined to be the representation of a Distinguished Name
(DN) after encoding according to the specification in [RFC4514].

LDAPDN ::= LDAPString
-- Constrained to <distinguishedName> [RFC4514]
[..]
BindRequest ::= [APPLICATION 0] SEQUENCE {
version INTEGER (1 .. 127),
name LDAPDN,
authentication AuthenticationChoice }
AuthenticationChoice ::= CHOICE {
simple [0] OCTET STRING,
-- 1 and 2 reserved
sasl [3] SaslCredentials,
... }
[..]
------------------------------- snip -------------------------------

So if the 3rd-party ISV wants his application to accept a user ID from
the user and send a LDAPv3 compliant bind request he SHOULD implement a
search for mapping the user ID entered to a bind DN. For all LDAP
directories which disallow anonymous searches (e.g. AD) he has to use a
service account for that search.
Doing SASL binds (e.g. with DIGEST-MD5) is a completely different story.

I support Joe's statement about security: You have to fully trust the
applications not to compromise the password and not do any harm on
behalf of the user (on the LDAP connection he was impersonated).

BTW: In one project I suggested to use this user impersonation as a
privacy feature to read a certain private attribute of the user which
was only readable by 'self' (ACL was set but this was not AD).

BTW: For achieving good performance especially when deploying SSL I'd
keep two persistent LDAP connections (with automatic reconnecting):
1. for doing the searches (after having bound as service account once!),
2. for sending the bind requests for validating the end user's passwords.

Ciao, Michael.
.

Relevant Pages

  • Re: passwd_compat: ldap?
    ... but doesn't implement doing an actual bind ... operation to perform authentication. ... support a bind for authentication either (or doesn't support returning a ... with PADL's) to perform authentication against LDAP in that environment. ...
    (Fedora)
  • Re: LDAP Authentication for Single Sign On
    ... Co-author of "The .NET Developer's Guide to Directory Services Programming" ... the bind operation IS the authentication. ...
    (microsoft.public.windows.server.active_directory)
  • Re: How do I bind to LDAP with a username/password
    ... Authentication against LDAP normally works by attempting to bind with the ... Failure to bind indicates a failure to authenticate. ... The only other way to do it would be to bind with some master credentials ...
    (comp.lang.java.programmer)
  • Re: LDAP Authentication from Linux
    ... I'm trying to implement a secure authentication from an apache2 server ... I've configured LDAP in apache, and if I bind using a Domain Admin ...
    (microsoft.public.windows.server.sbs)
  • Re: Query AD from DMZ via LDAP?
    ... You don't really need ADAM for this unless you need LDAP simple bind, ... authentication to apps on the public internet, ...
    (microsoft.public.windows.server.active_directory)
Quantcast