Академический Документы
Профессиональный Документы
Культура Документы
LDAP Authentication
LDAP authentication is a loaded term which simply means to issue the LDAP BIND
operation. Since the LDAP BIND operation is very flexible, this means there are a
variety of forms this authentication might take. These forms include extremes such as:
as well as more traditional forms where a name (username) and password are used,
and the password is encrypted on the wire or a private/public key algorithm used to
protect the password.
Active Directory supports all the LDAP standard authentication mechanisms, as well as
a few more, but many of these more extreme forms are not supported by UWWI, usually
because they violate computing standards.
The LDAP standard introduces the various forms of authentication by first categorizing
them as authentication methods, with various authentication mechanisms underlying
each method. This document follows that organizational precedent.
Authentication Methods
There are two primary authentication methods that must be supported by RFC
standard:
Other authentication methods *may* be supported, but are not part of the LDAP
standard and so are likely to be less widely used by LDAP applications.
Each method has many authentication mechanisms, and the RFC standards specify
that a number of these mechanisms must be supported.
Active Directory may accept a number of additional methods, but because of lack of
good Microsoft documentation, these additional methods can't be covered here at all.
However, this lack of documentation also means that applications won't know how to
use them either, so Active Directory might as well not provide these undocumented
methods at all.
Which method/mechanism you choose, will likely be dependent on which method and
mechanism is supported by your operating system and application. Since passwords
are sensitive data, you should choose the strongest method and mechanism available.
The strongest possible method and mechanism is SASL using Kerberos and employing
session-level encryption.
From strongest to least, the possible combinations are:
Reference Documents
LDAP Directories Explained
LDAP: Authentication Methods and Security Mechanisms
Understanding LDAP whitepaper
MSDN: Binding to an LDAP Server
MSDN: Using LDAP for Password Authentication
JNDI, Active Directory, and Authentication
Oracle Directory Server LDAP Authentication Mechanisms
Oracle SASL Authenication
1. Overview
2.
2. Steps to Complete
1.
2.
3.
4.
3.
3. Related
1.
1. Overview
2.
2. Steps to Complete
1.
2.
3.
4.
3.
3. Related
Overview
Sugar can be configured to accept Lightweight Directory Access Protocol (LDAP) authentication
if your organization has implemented LDAP or Active Directory authentication. When users in
your system attempt to log into Sugar, the application will authenticate them against your LDAP
directory or Active Directory. If authentication is successful, the user is allowed to log into
Sugar. If the authentication is unsuccessful, Sugar will then attempt to verify the provided
credentials against its own database of valid usernames and passwords.
You will need to add a user to your active directory for the purpose of authenticating from your
SugarCRM to your active directory to read the LDAP. The user should be a service account that
needs read-only access to Active Directory. Configuring Active Directory to support LDAP is
beyond the scope of this document.
Steps to Complete
Enabling LDAP for the Instance
1. Log into Sugar as an administrator and navigate to Admin > Password Management
2. Scroll down to the 'LDAP Support' section at the bottom of the page.
3. Select the 'Enable LDAP Authentication' option. Sugar will then display additional fields
for entering the necessary information.
4. Enter in the appropriate information and then click the 'Save' button.
Explanation of Settings
Here is a better explanation of the above settings:
Port enter 389 (This is the default port enter it unless you have some custom
configuration for LDAP)
Bind Attribute enter userPrincipalName (This is what is used for Active Directory and
is case sensitive.)
Login Attribute enter sAMAccountName (This is what is used for Active Directory and
is case sensitive.)
Authenticated Password enter the password of the authenticated user you created.
Auto Create Users (Leave this option unchecked. When you create an AD user you
dont have to create their account in SugarCRM you just have them log in and
SugarCRM will create the account automatically.)
Once this is selected, Sugar will synchronize their Active Directory user name and present the
password on the LDAP port. When the User Logs in they will use their active directory username
and password.
If the Active Directory Authentication server is behind a corporate firewall and your instance of
Sugar is hosted in our On-Demand environment, then please visit the following article to ensure
the appropriate IP range is open on your firewall to allow communication with the Active
Directory server. A rule will need to be created allowing the LDAP bi-directional communication
for the necessary IP range. This can be the standard LDAP port 389 or you can use LDAP over
SSL.
Using LDAP for Password Authentication
Concurrent bind, also known as fast bind, enables an application to determine if multiple users
have valid IDs and passwords and if their accounts are enabled. By using concurrent binding, the
application can request multiple bind operations by way of a single LDAP connection.
Unlike a normal LDAP bind, a concurrent bind does not determine a user group association or
build a security token; it only determines if the user has a valid ID and password. This enables
the concurrent bind to complete in a fraction of the time of a normal bind.
To enable concurrent bind on an LDAP connection, the application sets the
LDAP_OPT_FAST_CONCURRENT_BIND session option after the LDAP connection has been
initialized, but before any binds are performed. When concurrent binding is enabled for a
particular LDAP session, it cannot be disabled without closing the session connection.
Concurrent bind cannot be enabled on an LDAP session if signing or data encryption are
enabled. Attempting to enable concurrent bind on sessions with signing or data encryption will
fail the ldap_set_option call and return an LDAP_UNWILLING_TO_PERFORM error code.
When concurrent bind is enabled on an LDAP session, only simple bind operations may be
performed in that session and all simple binds are fast binds. As a result all subsequent bind
requests will not be serialized internally by the LDAP client and the binds will not generate a
security token. Any binds performed in this session are performed as anonymous, and because
data encryption is not allowed any data sent through this session will appear on the network in an
unencrypted form. If the application attempts to use a non-simple bind on a session with
concurrent bind enabled, the call will fail and return an LDAP_UNWILLING_TO_PERFORM
error code.
The following example code shows how to create an LDAP session with concurrent bind
enabled.
C++
Copy
ULONG ldap_open_fast_bind_session(LPTSTR pHostName, PLDAP pSession)
Users & Computers snap-in, it doesn't matter what the givenName, Surname, Display names are, but the
User Logon (pre-Windows 2000) name in thus example is set to "linux" (without the quotes of course !)
Also remember to have created a user object to represent the user that you will log in as. (Hopefully not
root !)
Step 2.
Create the keytab from Active Directory. In this example, my Linux host is called "linux", it's fully qualified
dns name is linux.antipodes.com, my Active Directory domain is called antipodes.com, the password I
have used for the host account is "password", and the resultant keytab is named linux.keytab. (Note that
the Active Directory domain, or kerberos realm, must be uppercased, this will make sense later on in the
krb5.conf description)
c:> ktpass -princ host/linux.antipodes.com@ANTIPODES.COM -mapuser linux
-pass password -out linux.keytab
Note that if you look at the Users & Computer snap-in, the "linux" account will now have a Login name of
the form:
"host/linux.antipodes.com@ANTIPODES.COM"
Step 3.
Securely transfer the linux.keytab file to the Linux host, and install it using ktutil.
# ktutil
ktutil: read_kt linux.keytab
ktutil: write_kt /etc/krb5.keytab
ktutil: quit
To check that the keytab has been merged, use the ktutil list command.
# ktutil
ktutil: list
slot KVNO Principal
----- ---- ---------------------------------------1 1 host/linux.antipodes.com@ANTIPODES.COM
Step 4.
Configure Kerberos on the linux host. My /etc/krb5.conf file looks like this.
[libdefaults]
default_realm = ANTIPODES.COM
default_tgs_enctypes = des-cbc-crc
default_tkt_enctypes = des-cbc-crc
[realms]
ANTIPODES.COM = {
kdc = mydc.antipodes.com:88
admin_server = mydc.antipodes.com:88
kpasswd_server = mydc.antipodes.com:464
default_domain = ANTIPODES.COM
}
Note that this is using a really old version of the MIT Kerberos V that used DES as the common
encryption algorithm supported by both Active Directory & the MIT release. Newer MIT releases support
stronger encryption algorithms that may or may not be supported by Active Directory such as 3DES or
RC4-HMAC. (RC4-HMAC is the default encryption algorithm used by Active Directory & Windows clients)
Step 5.
Test that Kerberos actually works.
# kinit
Password for steven@ANTIPODES.COM
# klist
Ticket cache: /tmp/krb5cc_0
Default principal: steven@ANTIPODES.COM
Valid Starting Expires Service Principal
12/15/2004 09:26:02 12/15/2004 19:24:04 krbtgt/ANTIPODES.COM
You could also configure PAM to use Kerberos as the authentication mechanism.
One common gotcha, the time needs to be synchronized between the Linux client and Active Directory
domain controller so that it does not exceed the Kerberos Clock Skew (default 5 minutes).
Step 6.
The application. As I said, a simple modification of the Sun sample code:
/**
* SearchWithAuth.java
*
10 July 2001
import javax.naming.*;
import javax.naming.directory.*;
import javax.security.auth.login.*;
import javax.security.auth.Subject;
import java.util.Hashtable;
class SearchWithAuth {
LoginContext lc = null;
try {
lc = new LoginContext(SearchWithAuth.class.getName(),
new SampleCallbackHandler());
lc.login();
public LDAPSearch() {
env.put(Context.INITIAL_CONTEXT_FACTORY,
"com.sun.jndi.ldap.LdapCtxFactory");
try {
// Create the initial directory context
DirContext ctx = new InitialDirContext(env);
totalResults++;
System.out.println(">>>" + sr.getName());
ctx.close();
} catch (NamingException e) {
// e.printStackTrace();
}
}
}
And the corresponding Callback handler. (Question: how does one create a password entry reader, which
echos * instead of the password charcters ?)
/**
* SampleCallbackHandler.java
*
10 July 2001
}
String pw = getProtectedInput(cb.getPrompt());
char[] passwd = new char[pw.length()];
pw.getChars(0, passwd.length, passwd, 0);
cb.setPassword(passwd);
} else {
throw new UnsupportedCallbackException(callbacks[i]);
}
}
}
// Test handler
ch.handle(callbacks);
NameCallback ncb = (NameCallback)callbacks[0];
System.out.println("Debug: " + ncb.getName());
}
}
Step 8.
You can avoid steps 1-4 with the Vintela software. It simplifies the
integration of Unix & Linux clients with the Active Directory.
It extends the schema with Unix GID, UID attributes, enhances the Active
Directory Users & Computers snap-in with additional property pages to
enable editing of Unix UID, GID, shell script atributes and allows
Active Directory Group Policy to be applied to Unix & Linux clients
(including password policy)
There is also a Linux/Unix command line utility that "joins" the machine
to the domain (essentially automates the creation of computer account,
generation, transfer and import of the keytab, configuration of the
kr5.conf ) and extends the crypto libraries to support RC4-HMAC.
854 Views
* 5 July 2001
* December 2004 - noted that ldaps url now supported on JSDK 1.5.0
* Sample JNDI application to perform a search for against the Active
Directory
* over SSL (port 636)
*/
import java.util.Hashtable;
import javax.naming.ldap.*;
import javax.naming.directory.*;
import javax.naming.*;
String adminName =
"CN=Administrator,CN=Users,DC=ANTIPODES,DC=COM";
String adminPassword = "XXXXXXX";
String ldapURL = "ldap://mydc.antipodes.com:636";
env.put(Context.INITIAL_CONTEXT_FACTORY,"com.sun.jndi.ldap.LdapCtxFactory
");
totalResults++;
System.out.println(">>>" + sr.getName());
surname: " +
attrs.get("sn").get());
System.out.println("
attrs.get("givenName").get());
System.out.println("
firstname: " +
mail: " +
attrs.get("mail").get());
}
catch (NullPointerException e)
+ e);
}
}
}
catch (NamingException e) {
System.err.println("Problem searching directory: " + e);
}
}
}
Step 2. Establish trust with the Active Directory domain PKI certificates.
I have installed an Enterprise CA, with the distinguished name of cn=Antipodes
Root,dc=antipodes,dc=com"
By default, domain controllers automatically enroll for domain controller certificates once an Enterprise CA
has been installed. The root certificate can be found in the root of the system drive (Eg. if the operating
system has been installed in c:\windows, the cert will be found in c:\)
By default the certificate file is named <dns name of ca>_<name of cert>.crt
#keytool -import -alias antipodes -file "mydc.antipodes.com_Antipodes Root.crt" -keystore
/usr/java/j2sdk1.4.0/jre/lib/securitycacerts
There is no need to publish the root certificates in the Active Directory or to add them via Group Policy as
an Enterprise CA will automagically publish the root certs and Domain Controllers will automagically enroll
for Domain Controller certificates.
An alternative mechanism to obtain the root cert is via the Certicate Authority Web Enrollment tool.
Assuming the Certificate Authority is installed on myca.antipodes.com (and that the CA Web Interface is
also running on the same server), via a browser connect to http://myca.antipodes.com/certsrv. From the
page, go to "Download a CA Certificate" and then select "Download CA Certificate". Leave the encoding
method as Distinguished Encoding Rules (DER). .
import java.util.Hashtable;
import javax.naming.ldap.*;
import javax.naming.directory.*;
import javax.naming.*;
env.put(Context.INITIAL_CONTEXT_FACTORY,"com.sun.jndi.ldap.LdapCtxFactory
");
try {
attrs.get("mail").get());
mail: " +
}
catch (NullPointerException e)
System.out.println();
}
catch (NamingException e) {
System.err.println("Problem searching directory: " +
e);
}
}
}
Note that there are two major gotchas.
1. In the application, only NT Domain names (DOMAIN\username) or userPrincipal names
(username@domain.com) can be used. Distinguished names are not supported.
2. The user's password must be configured to be stored using reversible encryption (Performed either
from the Active Directory Users & Computers tool, or by modifying the user's userAccountControl attribute
with a JNDI, LDAP, ADSI or LDAP application). Also after the reversible encryption option has been set,
the user must change their password for the password to be stored using this format