Well, after much searching and testing (and LEARNING) I was able to accomplish that task.
At the benefit of future posters/seekers, here’s what I found:
-
make ABSOLUTELY sure the DNS you’re using is able to perform a direct and reverse lookup of the hosts involved in the scenario
-
you can perform LDAP queries over the SSL channel by connecting to the AD server at port 636; first, grab (export in Base64) the AD Root certificate and store it on the Linux box (eg, under /tmp/adir/adroot_b64.cer).
Then, configure the /etc/openldap/ldap.conf file as follows:
HOST win2003r2.my.domain.it
PORT 636
TLS_CACERT /tmp/adir/adroot_b64.cer
TLS_REQCERT demand
Last, issue the query:
ldapsearch -x -D “Administrator@my.domain.it”
-b “cn=Users,dc=my,dc=domain,dc=it”
-H ldaps://win2003r2.my.domain.it
-W sAMAccountName=myuser
Please notice that:
. binding is still required (-D and -W)
. -H ldaps://… (connects to port 636)
- another method is to connect to port 389 and issue the Start_TLS command; in fact AD is able to use the same “unencrypted” port (389) to start a TLS tunnel and thus encrypt the pieces of info being exchanged.
The ldap.conf file does not change but the ldapsearch syntax does:
ldapsearch -x -D “Administrator@my.domain.it”
-b “cn=Users,dc=my,dc=domain,dc=it”
-H ldap://win2003r2.my.domain.it
-Z -W sAMAccountName=myuser
Please notice the use of the “-Z” flag and the connection to ldap:// (port 389)
- You can finally use the external SASL authentication which relies (among other things) over a kerberos configuration; thus making, once you get a valid ticked from the KDC, you’re not required to authenticate to the AD server over the command line.
Make sure clocks on both servers are in synch using NTP or whatever you have.
Make sure you have the following packages installed:
libgssapi-0.6-13.7
cyrus-sasl-gssapi-2.1.21-18.4
libgssapi-32bit-0.6-13.7
Also, check for the following ones:
krb5
krb5-clients
Create the /etc/krb5.conf file as follows (192.168.68.1 is the IP of the AD server):
[libdefaults]
default_realm = MY.DOMAIN.IT
clockskew = 300
[realms]
ZEN.STRHOLD.IT = {
kdc = 192.168.68.1
default_domain = my.domain.it
admin_server = 192.168.68.1
}
[logging]
kdc = FILE:/var/log/krb5/krb5kdc.log
admin_server = FILE:/var/log/krb5/kadmind.log
default = SYSLOG:NOTICE:DAEMON
[domain_realm]
.MY = MY.DOMAIN.IT
.my.domain.it = MY.DOMAIN.IT
[appdefaults]
pam = {
ticket_lifetime = 1d
renew_lifetime = 1d
forwardable = true
proxiable = false
retain_after_close = false
minimum_uid = 1
try_first_pass = true
}
Get you kerberos ticket using the
kinit Administrator
or
kinit <valid_ad_user>
Type your password and verify your ticket using “klist”:
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: Administrator@MY.DOMAIN.IT
Valid starting Expires Service principal
12/15/08 16:00:12 12/16/08 02:00:14 krbtgt/MY.DOMAIN.IT@MY.DOMAIN.IT
renew until 12/16/08 16:00:12
Kerberos 4 ticket cache: /tmp/tkt0
klist: You have no tickets cached
Last, perform your LDAP search using this syntax:
ldapsearch -Hldap://win2003r2.my.domain.it -b “” -s base -Omaxssf=0
As you can see, we’re still connecting to LDAP (389); the flag “-Omaxssf=0” disables the SASL security layers (and it seems it’s required when you perform LDAP queries against AD).
If you want to have BOTH SASL + TLS authentication:
ldapsearch -Hldap://win2003r2.zen.strhold.it -b “” -s base -Omaxssf=0 -ZZ
Please notice the use of “-ZZ”.
Well, hope this helps!
Best,
Rob