[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: GSSAPI+kerberos5+TLS to Active Directory

To: "Leila Lappin" <galaxylappin@comcast.net>, "Dr. Arul Veda Manickam" <avmanickam@yahoo.com>
Subject: Re: GSSAPI+kerberos5+TLS to Active Directory
From: "Andrew Hall" <temp01@bluereef.com.au>
Date: Tue, 12 Mar 2002 12:03:08 +1100
Cc: <openldap-software@OpenLDAP.org>
References: <003b01c1c67c$0f69f090$2e01010a@bluereef.local> <004c01c1c6bf$875ae9e0$600b2644@verona01.nj.comcast.net>

For those that asked, please find attached text file on building
SASL/GSSAPI/KERBEROS/Openldap Client for connecting to Microsoft Active
Directory.

Please understand that this information is offered 'AS IS' with no implied
warranties. It worked for me and hopefully others will find it useful too.
I'll try to answer any queries you may have if anybody gets stuck.

Kind regards,

Andrew Hall.
----- Original Message -----
From: "Leila Lappin" <galaxylappin@comcast.net>
To: "andrew hall" <temp01@bluereef.com.au>
Sent: Saturday, March 09, 2002 3:37 AM
Subject: Re: GSSAPI+kerberos5+TLS to Active Directory


> Hello Andrew,
>
> I'd like to repeat the request that Arul Veda made.  If you have the time
> and patience I would also like to benefit from your experiments.
>
> Thanks
> Leila
>
>
> ----- Original Message -----
> From: "andrew hall" <temp01@bluereef.com.au>
> To: <openldap-software@OpenLDAP.org>
> Sent: Friday, March 08, 2002 12:34 AM
> Subject: GSSAPI+kerberos5+TLS to Active Directory
>
>
> > Hello,
> >
> > I have been playing with openldap and MS active directory over the past
> > couple of days trying to figure out what will and won't work when
> connecting
> > SASL and TLS connections from a unix client such as ldapsearch to active
> > directory. I have successfully compiled the Openldap 2.0.23 libraries
with
> > openSSL 0.96c, MIT kerb5 1.2.3, Cyrus SASL 1.5 and tested connecting
> against
> > AD to see what comes back.
> >
> > I successfully get a GSSAPI/kerb5 connection working to AD after I use
> Kinit
> > to get the TGT, however I now have a few questions that I hope someone
can
> > enlighten me with answers to:
> >
> > 1. I made a user account on AD for my unix host, used a utility called
> > Ktutil and generated a keytab file from the account information. This I
> > loaded onto my unix host and used KTutil to load the keytab file into
> > /etc/keytab. After playing for a while I deleted this file, issued a
> > Kdestroy and tried to reconnect again to AD and was still able. It seems
> > this file isn't important for client SASL connections? Is this true or
is
> > something being cached elsewhere on my unix host that holds the
> credentials?
> >
> > 2. Now loading a server side certificate authority on AD and attempting
a
> > TLS start I observe the following:
> >     a. SASL auth doesn't work in this mode I assume because AD doesn't
> > support an EXTERNAL SASL mechanism?
> >     b. TLS with simple auth seems to work although I get a "decode
error"
> > when the ldapsearch query returns, even though it connects on port 636,
> > authenticates and dumps my query successfully. I have NOT loaded the
> server
> > side CA cert PEM onto my client even though the debug seems to correctly
> > find and accept the CA cert anyway, is this correct? Do I need this cert
> for
> > server side auth only?
> >     c. Am I REQUIRED to have a client side cert for TLS to work with AD?
> If
> > I do a ZZ with ldapsearch the query fails, why?
> >
> > Thanks alot!
> >
> > Kind regards,
> >
> > Andrew.
> >
>
>

Getting Kerberos/SASL/GSSAPI and Active Directory LDAP to work together.

1. Get and extract:
* OpenSSL 0.9.6c from http://www.openssl.org
* MIT's Kerberos version 1.2.3 from
* Cyrus'SASL libraries version 1.5.27 from http://asg.web.cmu.edu/sasl/
* Openldap source version 2.0.23 from www.openldap.org
* I compiled on Redhat 6.2

2. Extract Openldap tar file and put other sources into this same directory
3. Extract OpenSSL and enter directory
4. ./configure
5. make
6. make install
7. Extract kerberos and enter directory
8. ./configure -- enable-shared
9. make
10. make install
11. Extract SASL and enter directory
12. ./configure
13. make sure it picks up libraries and headers for kerberos and openSSL
14. make
15. look back through make output and make sure there are no complaints - ignore warning about not finding DES libraries as shared libraries
16. make install
17. put ln -s /usr/local/lib/sasl /usr/lib/sasl symbolic link in
18. run ldconfig to cache library directories
19. go back to openldap directory
20. run ./configure -prefix=/opt/openldap \
--with-cyrus-sasl \
--enable-slapd=no \
--enable-slurpd=no
21. make depend
22. make
23. make install

24. Edit /etc/krb5.conf to the following:

[root@52 openldap-2.0.23]# more /etc/krb5.conf

[libdefaults]
ticket_lifetime = 24000
default_realm = TESTDOMAIN.LOCAL

[realms]
TESTDOMAIN = {
kdc = 10.1.1.5:88
admin_server = 10.1.1.5:749
default_domain = TESTDOMAIN.LOCAL
}

[domain_realm]
.bluereef.local = TESTDOMAIN.LOCAL
bluereef.local = TESTDOMAIN.LOCAL

25. Type: 'Kinit testuser' (testuser = any valid user on Active Directory server)
26. enter password

You have now authenticated against AD using Kerberos 5

LDAPsearch test to prove it works:

(SASL bind using GSSAPI as mech)

Comments: For this to work, you must first get a valid TGT from the AD server using Kinit as above. If you don't do this you will always get a "local error" when attempting to search.

Command:

ldapsearch -H ldap://testbox.testdomain.local -b "dc=testdomain,dc=local" cn=a*

Now we try SSL.

27. Get onto AD domain controller and install a "certificate authority" on this machine. This can be done by "adding windows components" under control panel. If you don't already have it installed, it will ask you what type of Certification authority you want installed - select the enterprise (AD domain based) version. Fill in the various authority details and select okay. This will install a server certificate onto this domain controller in the root directory of the primary hard disk.
28. Now try an SSL connect using simple username/password:

(SSL Bind on port 636 using simple username/password)

Comments: For this to work the search request must have the host name that matches the CN in the server certificate. As long as this applies, it seems the client libraries don't require you to have the CA authority certificate installed on your client. Don't try client-side certification checking as AD doesn't support this yet (to the best of my knowledge).

Command:

Ldapsearch -H ldaps://testbox.testdomain.local - b "dc=testdomain,dc=local" -D "cn=test user, ou=testou, dc=testdomain, dc=local" -w testpassword cn=a*

Use a debug (-d 1) in the command line if you have problems connecting over SSL.

Lastly we try SASL authentication over SSL

(SASL authentication with GSSAPI mechanism over SSL, with SASL privacy and integrity protection disabled.)

Comments: This effectively allows a secure kerberos authentication, while using SSL as the transport layer encryption.

First you need a TGT : Kinit testuser

Command:

Ldapsearch -H ldaps://testbox.testdomain.local - b "dc=testdomain,dc=local" -O maxssf=0 cn=a*

References:
- GSSAPI+kerberos5+TLS to Active Directory
  - From: "andrew hall" <temp01@bluereef.com.au>

Prev by Date: checking for Berkeley DB thread support... no
Next by Date: authentication
Index(es):
- Chronological
- Thread