public class LdapSearch
extends java.lang.Object
implements java.security.PrivilegedExceptionAction
The LdapSearch commandline syntax is defined as follows:
Usage: LdapSearch [-f <propfile>] [-v <level>] [-d ADS|RFC] [-x] [-t] [-a <authtype>] [-u <username> -p <password>] ldap://host/base?attrs?scope?filter
The following table describes each option in detail:
| Parameter | Description |
|---|---|
| -f <propfile> |
Specifies a properties file.
See the LdapSecurityProvider API documentation for a detailed table of possible properties.
In practice, the most likely properties to be used with this utility class are the dns.servers and dns.site properties which in fact should be specified so that the implementation can properly locate a suitable LDAP server given only a domain name in the LDAP URL.
Other properties that might be used are ldap.disposition, service.acctname and service.password (although these can also be specified on the commandline using the -d, -u and -p parameters) and perhaps ldap.search.maxcount and others.
|
| -v <level> | Indicates the log level for "verbose" output. An ideal value for debugging usage issues is 4. |
| -d ADS|RFC | Specifies the "disposition" of the target server. With respect to this utility, this parameter controls attributes definitions and authentication behavior. The default value is "ADS" but if the server is not Active Directory or ADAM, a value that starts with "RFC" will need to be specified (see examples below). To be more specific about the server disposition, values such as ADS2008, RFC2251, RFC2307 and so on might be used but currently this implementation does not utilize information other than the first three characters. |
| -x | Disable integrity and confidentiality. This is useful for debugging network communication with packet capture software. This options should otherwise probably not be used. Note that if this option is not supplied, the server may not negotiate confidentiality or integrity. |
| -t |
Use TLS confidentiality.
This option requires a trust store containing the PKI certificate exported from the LDAP server.
The trust store file can be specified using the a commandline parameter like -Djavax.net.ssl.trustStore=dc1.keystore.
|
| -a <authtype> |
Specifies the JNDI Context.SECURITY_AUTHENTICATION such as "simple", "GSSAPI", etc.
The default authentication type depends on the LDAP disposition of the server (specified with the -d option).
If the disposition starts with "ADS", the default authentication behavior is to use the Jespa NTLM apparatus which provides NTLMv2 authentication and 128 bit session security.
If the disposition starts with "RFC", the default authentication type is "simple".
In this case, the plaintext password and communication should be secured with TLS confidentiality using the -t option (although it may not be required by the server).
|
| -u <username> |
The username used to authenticate with the target server.
If this parameter is not specified, the service.acctname property from a the properties file will be used.
|
| -p <password> |
The password corresponding to the above username used to authenticate with the target server.
If this parameter is not specified, the service.password property from a the properties file will be used.
|
For a detailed description of RFC2255 style LDAP URLs with many examples, see the LdapSecurityProvider API documentation.
base because the default scope of sub would require a non-anonymous bind.
C:\>java -cp jespa-1.2.5.jar jespa.ldap.LdapSearch 'ldap://192.168.2.110/??base'
The following example illustrates how to query a User account in Active Directory.
This query will use NTLMv2 authentication with 128 bit transport encryption.
This example uses the special 'DefaultNamingContext' base identifier (which only works with Active Directory servers).
This example also shows how to use a properties file which ideally should contain dns.servers and dns.site properties so that a suitable domain controller can be properly located.
Also, if a properties file is used, the credentials can alternatively be supplied with the service.acctname and service.password properties instead of with the -u and -p parameters.
The output of this example illustrates how attribute definitions assist in rendering attributes like single valued attributes as opposed to multi-valued (shown with square brackets) and attributes like times and the objectSid attribute which would otherwise not be easily interpreted by the user.
C:\>java -cp jespa-1.2.5.jar jespa.ldap.LdapSearch 'ldap://busicorp.local/DefaultNamingContext??sub?(&(objectCategory=person)(sAMAccountName=hmuller))' CN=Hans Müller,CN=Users,DC=busicorp,DC=local: displayName: Hans Müller givenName: Hans sAMAccountType: 805306368 mobile: 9083777833 primaryGroupID: 513 objectClass: [top,person,organizationalPerson,user] badPasswordTime: 2008-12-16 02:24:22 objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=busicorp,DC=local cn: Hans Müller userAccountControl: 590336 userPrincipalName: hmuller@busicorp.local dSCorePropagationData: [2009-09-17 13:47:25,2007-05-10 22:42:52,1600-12-31 19:04:17] codePage: 0 distinguishedName: CN=Hans Müller,CN=Users,DC=busicorp,DC=local whenChanged: 2010-04-19 19:37:21 whenCreated: 2007-05-02 13:51:19 pwdLastSet: 2007-12-11 12:11:17 logonCount: 309 accountExpires: <never> lastLogoff: 1600-12-31 19:00:00 lastLogonTimestamp: 2010-04-19 19:37:21 objectGUID: bWYA2RAjQUeXz34GLCvGTg== sn: Müller lastLogon: 2009-09-21 13:27:16 uSNChanged: 2896697 uSNCreated: 15617 objectSid: S-1-5-21-2779991297-2625803212-4394051119-1431 countryCode: 0 sAMAccountName: hmuller instanceType: 4 memberOf: ["CN=Engineers,CN=Users,DC=busicorp,DC=local","CN=Group598,CN=Users,DC=busicorp,DC=local",...,"CN=Remote Desktop Users,CN=Builtin,DC=busicorp,DC=local"] badPwdCount: 0 name: Hans Müller
The following example uses the same query as the first example but uses Kerberos authentication.
This example assumes a TGT is present in the user's Kerberos ticket cache.
Alternatively, credentials may be supplied explicitly using the -u and -p parameters although the username must be in a principal name form with the domain in UPPERCASE like -u bcarter@BUSICORP.LOCAL.
C:\>java -cp jespa-1.2.5.jar jespa.ldap.LdapSearch -a GSSAPI 'ldap://dc1.busicorp.local/DefaultNamingContext??sub?(sAMAccountName=hmuller)'
The following example illustrates how to query a user account in an RFC based LDAP server like OpenLDAP.
The first major difference is that the server "disposition" is set using the -d parameter.
This is used as a hint by the Jespa LDAP SecurityProvider that authentication and attribute definitions suitable for RFC based servers should be used.
Because the default authentication method for RFC based servers is a "simple" bind, the username must be a full DN.
Also, TLS encryption should be used however this assumes a certificate has been generated on the server, exported and then imported into a suitable Java trustStore file (see the -t parameter description above).
An IP address is used in this example because a hostname would require DNS SRV records for LDAP.
Alternatively if a properties file were used with authority.dns.names.resolve = false set to disable SRV lookups, an FQDN hostname could be used.
$ java -cp jespa-1.2.5.jar jespa.ldap.LdapSearch -d RFC2251 -u 'CN=Alice Baker,OU=Research,DC=openbook,DC=edu' -p 'opensaysme' 'ldap://192.168.44.110/OU=Research,DC=openbook,DC=edu??sub?(uid=cdavis)'
createLdapContext: {bindstr.url=ldap://192.168.44.110/OU=Research,DC=openbook,DC=edu??sub?(uid=cdavis), ldap.attributes.definitions={18 entries}, bindstr=ldap://192.168.44.110/OU=Research,DC=openbook,DC=edu??sub?(uid=cdavis), service.password.encrypted=tBuh2l11VwXeKhOAeBrfMJ1kyvCSXt64VTVQ7SprJS60WyD3hulSBQ==, service.acctname=CN=Alice Baker,OU=Research,DC=openbook,DC=edu, ldap.disposition=RFC2251}
securityAuthentication: simple
cn=Chris Davis,ou=Research,dc=openbook,dc=edu:
givenName: Chris
sn: Davis
userPassword: e01ENX1cJldvYkcvaTF63JNEZp2RcHJtNXpRPT0=
uidNumber: 1003
gidNumber: 5000
objectClass: [inetOrgPerson,posixAccount,top]
uid: cdavis
cn: Chris Davis
homeDirectory: /home/users/Research/cdavis
The following example illustrates how to query the RootDSE of an OpenLDAP server using the special + attribute to retrive otherwise hidden attributes.
$ java -cp jespa-1.2.5.jar jespa.ldap.LdapSearch -d RFC2251 'ldap://192.168.44.110/?*,+'
For other examples of LDAP URLs, see the LdapSecurityProvider API documentation.
| Modifier and Type | Method and Description |
|---|---|
static void |
main(java.lang.String[] args) |
java.lang.Object |
run() |