|
- Author - |
-
- - LDAPv3 - |
-
- Last - updated - |
-
|
- Turbo Fredriksson - |
-
-
|
-
- |
-
-
Over the last year (around May, 2001) I have tried to rewrite this -HOWTO into a book, and get it published. So far my attempts have not -been that successful. No one want's to publish it. My language seems -to be lacking. The major concerns (it seems) is that it's not -"professional" enough. Maybe so, but this is the way I -want to read about something that's difficult.
-Is -there any need for a book about this? Have a look at Implementing -LDAPv3 for the parts I have decided to show in public. It -contains the the Contents at A glance, Table of contents, and chapter -one and three. It is color encoded, to show what's done and what's -not... I'd appreciate -comments. This example is a little old now, I can't be bothered -to update it (it is after all an EXAMPLE :). However, I also managed -to create a -PDF of the first seventeen (17) pages, which includes the title -page, Contents at a glance and Table of contents as it would look -like if it was printed. This I'll try to update every now and then. -Watch the bottom on the title page for date of PDF creation. It's -updated automatically.
-
-
Quite a number of people (4000 unique web accesses in the first -three months it was up) have had help from this book. There's a -number of companies that got helped with this HOWTO. A lot of them -software companies. How about thanking me (if it actually helped and -saved time/money that is) by sending me something you/your company -makes? One successful company makes a Linux desktop distribution. I -would have liked a copy of that, it would have been nice :). No -requirenments though!
-
-
These -are my notes about how I got OpenLDAP (v2.0.7), OpenSSL -(v0.9.5a), SASL (v1.5.24) and MIT KerberosV (v1.2.2) to -work together. This combination (according to some RFC I can't -remember the number of) is what's called LDAPv3.
-I -have since I initially wrote this HOWTO, upgraded some packages. The -information about this can be found in the Updates -section. At the time of this writing (Sunday, August 19, 2001) I have -not successfully compiled and installed OpenLDAP v2.0.11! I'm still -working heavily on this, it is at the top of my todo list, since I -really (!!) need to upgrade because of a resent security alert.
-You -might want to read the section LDAPv3, -why bother to see the reasoning for this quite complicated issue. -It deals with all the discussed systems, such as SSL/TLS, SASL, LDAP -and Kerberos, and why we should run such a complicated system in the -first place.
-Reading -and following this documentation will require a knowledge of LDAP in -general, knowing how to create and install software 'from scratch' -(i.e. building from source/tar balls) and also how to configure -OpenLDAP and also how to administer it... This issue (LDAPv3) is not -for the beginner, and I will usually not -answer any questions in the format of 'I get this when i try to -configure/make/install this-or-that-software'! In short, you will be -required to 'read between the lines' of this document, and draw you -own (correct! :) conclutions. That being said, it's not as difficult -as it might seem. If you belong to the group of people that I here -call 'beginner', I recommend installing the software while reading -the OpenLDAP web page on OpenLDAP administration.
-I'm -running Debian -GNU/Linux on all my machines, both on the -Intel platform and the Sun SPARC, -and prefer to use the Debian package system as much as I can. Since -I'm also a Debian developer, I have a fairly good know-how about -making a Debian package. In my pursuit of getting this to work, I had -to modify some of the default packages since they lacked some -features that is necessary. I will try to guide you through the -process of rebuilding you package, if you to are running Debian -GNU/Linux. If you are not, I will at least tell you which parameters -to configure etc. the Debian package are using, giving you at least -SOME hint on getting all this software compiled and installed :). -Also, the progress and fast moving target that the Internet and the -OpenSource movement are, the versions I have described here are most -likely already out of date. Two weeks after I started with this -HOWTO, Cyrus-SASL had released version 1.5.26, that fixed the problem -described in the section Bugs -in Cyrus SASL, v1.5.24. But I'm deploying this any day now -on a live server, so I won't be able to test if it indeed fixes the -problem.
-Wherever you see -the <> (in bold) part, -it means that that's where you input your own information. So for -example, when you see -
-<YOUR KERBEROS REALM>
-It means that you should put your realm in there, like this:
-BAYOUR.COM
-Note, that you should NOT -include the characters < and >!.
-Also, I assume -in this document that the configuration for OpenLDAP2 is installed -into /etc./ldap. If you -haven't installed it there, please remember to exchange that path to -your path.
-Please -don't send any 'please help me' mails directly to me. Direct it to -the appropriate mailing -lists for help instead, you stand a much better chance of getting -a reply if you do. I just don't have the time (or knowledge) to help -anyone/everyone in private.
--Any mails sent to -me about any of this will -be replied to on a public list.
--BerkeleyDB from -SleepyCAT is, from what I have read/tried a better database back-end -than gdbm, ndbm and db. It is used by OpenLDAP to store the database -on disk. Your call, you don't have to use it, but I like it and have -been using it all the time.
-Building -and installing Berkeley DB
--This is the software -that will give us TLS and SSL enabled LDAP (secure and encrypted -communication). It have nothing to do with AUTHENTICATING a user, it -just gives us a way to encrypt traffic to/from the LDAP server.
- - --This -is what we will use to store password in. It will, as a bonus, also -give us a 'single-sign-on' system (that is, you enter your -passphrase/password once, and the 'ticket' that is returned, will be -used for login authentication).
- -Bugs -in MIT Kerberos V, v1.2.1
-Bugs -in MIT Kerberos V, v1.2.2
- - -Preparing -the DNS for KerberosV
- - -Setting -up KerberosV access rights
- --This is the layer -between OpenLDAP and -Kerberos. It gives you a secure way of AUTHENTICATING access to the -LDAP server. It will not encrypt the actual traffic (even though the -authentication session is encrypted).
- - -Build -the Cyrus SASL packages
- - --Well, we all know -what this is, don't we? It's a free LDAP server. A very (VERY) -good one to, in my opinion (even though I don't have much experience -in other LDAP server :).
- - - - -Configure -OpenLDAP to use the new SSL certificate
-Changes -to the OpenLDAP config file
-Changes -to the OpenLDAP startup script
- - - -Populate -the database to allow simple bind as user
-Modify -the LDAP database to allow simple bind as user.
-Notes -about 'userPassword: {KERBEROS}'
- -Testing -OpenLDAP, simple/anonymous bind
-Testing -OpenLDAP, simple/anonymous bind, with SSL/TLS
-Testing -OpenLDAP, using your Kerberos ticket
-Testing -OpenLDAP, using your Kerberos ticket, with SSL/TLS
-Testing -OpenLDAP, simple user bind, with SSL/TLS
-Setting -up secure replication
-Replication -configuration, slave server
-Replication -configuration, master server
-Creating -a replication principal
-Automatically -getting a ticket before starting slurpd
-Keeping -replication ticket updated
-Give -the replicator access to the database
--Some -software to ease administration and migration to LDAP/Kerberos are -these softwares. I'm not going to go -in to how to get this configured and installed. That's an exercise -for the reader :). They have no real -relevance for getting LDAPv3 to work, but I thought I'd plug for them -anyway, because I have found them invaluable in using and -administrating LDAP in general.
-The LDAP name service -switch (NSS) module is an Open Source project to integrate -LDAP as a native name service under Linux, Solaris, and other -operating systems. The LDAP pluggable authentication -module (PAM) is an Open Source project to integrate LDAP -authentication into operating systems supporting the PAM API, such as -Linux, Solaris, and HP-UX.
- - - -Install -the newly made packages
-Not related with OpenLDAP really, but I'm -going to show you a little how to get CVS linked and compiled with -GSSAPI so that we can use our Kerberos key for authentication to the -cvs server.
- - - - -Quite naturally we would like the IMAP -and POP3 server to authenticate directly with SASL to the Kerberos -database as well.
-Building -Cyrus IMAP and POP3 server
-Configure -Cyrus IMAP and POP3 server
-Creating -a IMAP/POP3 service key
-From the project page:
-AFS is a distributed filesystem product, -pioneered at Carnegie Mellon University and supported and developed -as a product by Transarc Corporation (now IBM Pittsburgh Labs). It -offers a client-server architecture for file sharing, providing -location independence, scalability and transparent migration -capabilities for data.
-Kind'a like NFS with Kerberos -authentication. Although AFS is a (network) file system and have -don't have anything to do with LDAPv3, it is 'essential' for a -distributed (and load balanced) server cluster.
- - - - -OpenAFS -KerberosV support software
-Building -OpenAFS KerberosV support software
-Installing -OpenAFS KerberosV support software
-Configure -OpenAFS KerberosV support software
- -Building -and Installing the OpenAFS PAM module
- - - -Putting -the AFS service key into the AFS KeyFile
- - -Setup -the cell configuration files
-Getting -a Kerberos ticket and a AFS token
- -Testing -the OpenAFS softwares
-Testing -OpenAFS KerberosV support software
- -The idea here is to make a Windows 2000 -server out of our Linux/UNIX box. In theory (at least from what I -have understood from mails on the openldap-software list) this should -be possible if using Krb5, SASL, LDAP and Samba. I'm currently -investigating this issue.
-Check back every now and then to see how -far I have got with this.
- - - -From the project page:
-Designed with the only focus of being a -tool to easily manage UNIX users and groups in an LDAP directory, -corporate information, access controls, and LDAP mail routing.
-I'm currently writing a patch for this, -to allow it to add the principal to the KDC as well as adding the -user stuff in the LDAP server. Also in progress are SASL and SSL/TLS -binds to the LDAP server.
-I haven't gotten this to work yet, but -I'm working on it. From the source code README:
-pam_krb5_migrate is a stackable -authentication module (for PAM) that takes a user name and password -from an earlier module (such as pam_ldap or pam_unix) in the stack, -and attempts to transparently add them to a Kerberos realm using the -Kerberos 5 kadmin service. The module can be used to ease the -administrative burdens of migrating a large installed user base from -pre-existing authentication methods to a Kerberos based setup.
-Looks nice to me, if I just could get it -to work!
-Have a look at Migrating -existing users for more information about migrating existing -users.
-It is possible to have QMAIL look in a -LDAP database for it's email addresses, and to have QMAIL's pop/imap -server authenticate the users from a LDAP database.
-I'm not using Sendmail, in fact, I -dislike sendmail quite heavily. In my opinion it's the most insecure -piece of software you can install on a UNIX (like) platform. But, -granted, it's the only (mail) server that can cope with hundred of -thousands (and above) of mails. I'll see if I can dig up some -information about this, and add this to this HOWTO/FAQ.
-In the mean time, have a look at the URL: -http://www.stanford.edu/~bbense/Inst.html.
-Here you can find some reference -material, and copies of my configurations discussed in this document
-Most things in the Open Source movement -change quite fast, and software naturally gets updated. Instead of -adding a 'updates' section under each software product, I have -gathered them here instead, sorted by the latest version at the time -of writing.
-| - - | -- - | -
-
|
-
-
|
-
-
|
-
-
|
-
-
|
-
-
|
-
| - - | -- - | -- - | -
-
|
-
-
|
-
-
|
-
-
|
-
-
|
-
| - - | -- - | -- - | -- - | -- - | -- - | -- - | -- - | -
| - - | -- - | -
-
|
-
-
|
-
-
|
-
-
|
-
-
|
-
-
|
-
| - - | -- - | -
-
|
-
-
|
-
-
|
-
-
|
-
-
|
-
-
|
-
These are copies on all my configuration -files. They are documented here in the document, but just a -preventive measure, I thought that I'd include the actual files as -well.
- - - - -This are some misc information about -where to find more information about RFC's and Internet drafts etc.
- - - - - - - - -After getting all this software -configured, compiled and installed, it will need to work independent -of the other. That is, each piece needs to work before we can start -gluing them together. There's always something that can go wrong. -Here's examples and solutions for some of (the most common?) ones.
-Problems -when the KVNO don't match up.
- - - - - - - - -For the lazy ones, why not take a look at -this section.
-No guaranties though!
- -These -are the packages that are available for installations
- - - - - - - - - - --Some notes about migrating an existing user database, be it the old -fashioned /etc/passwd -approach, NIS/NIS++ etc.
--I would like to thank the following people, in no special -order(!), for giving -me input on this document. I apologize if I forgot someone (I started -this thank you part quite late in the development :).
-|
- Johann - Botha - |
-
- For - noting that we have to start the SLAPD server on port 636 aswell - |
-
|
- Allan - Streib - |
-
- For - the patch to Cyrus SASL, v1.5.27 - |
-
|
- Jorge - Santos - |
-
- For - pointing out that Berkeley DB 3.2.9 is in Debian GNU/Linux under - the name libdb3/libdb3-dev. - Also found a missing '-exec' in a find command (in the Building - Packages subsection of the libpam-ldap and libnss-ldap section). - |
-
|
- John - Green - |
-
- Which - had a one month newer version than the file I had in my backup - when I lost the whole page because of user error :) - |
-
|
- Keith - R Lally - |
-
- For - finding the latest version of the lost document. - |
-
|
- Jasper - Möller - |
-
- For - some question and remarks about the DNS setup, migration of - existing users, SSL certificates etc. - |
-
A couple of days ago (around December 12, -2001) I lost this document. I managed to rescue a version from -August, but quite a number of things where missing.
-For those other of you that mailed me -about different versions etc, THANX! I wasn't quite sure if this -document made any difference, but it seems like it does... It's -always nice to hear from users (just not TO much :).
--Thanx -again for all the support
-This package I just installed right of the Debian -GNU/Linux non-US FTP site, using apt-get install libssl09 -libssl09-dev openssl. The -development package are needed later when building -OpenLDAP v2.
-For those of you that don't use Debian, this are the configure -command line:
-./Configure shared --prefix=/usr --openssldir=/usr/lib/ssl
-Then build the package by issuing this command:
-make -f Makefile.ssl all
To install OpenSSL after executing make, issue this command:
-make -f Makefile.ssl install.
-That's about it about OpenSSL I think, but as I said, I just -installed the Debian packages, and where done with it :)
-To create the certificate that OpenLDAP will use, we issue the -command openssl like this:
-openssl req -new -x509 -nodes -out server.pem -keyout server.pem -days 365
-This is what the command will output when I do it. The first line -might be different in your installation, and some of the wordings -might have changed if you are using a different version than me. The -important information you should input is on the last seven lines -(starting with Country Name and ending with Email Address. Parts in -bold+underline is my responses:
-Using configuration from /usr/lib/ssl/openssl.cnf -Generating a 1024 bit RSA private key -.....++++++ -.................................................++++++ -writing new private key to 'server.pem' ------ -You are about to be asked to enter information that will be incorporated -into your certificate request. -What you are about to enter is what is called a Distinguished Name or a DN. -There are quite a few fields but you can leave some blank -For some fields there will be a default value, -If you enter '.', the field will be left blank. ------ -Country Name (2 letter code) [AU]:SE -State or Province Name (full name) [Some-State]: -Locality Name (eg, city) []:Gothenburg -Organization Name (eg, company) [Internet Widgits Pty Ltd]: -Organizational Unit Name (eg, section) []: -Common Name (eg, YOUR name) []:egeria.bayour.com -Email Address []:turbo@bayour.com
-It is very important that you don't give localhost for the -Common Name. It should be your hosts FQDN (Fully Qualified Domain -Name). That is, what's your IP address, and what name does the DNS -tell you belong to this IP address?
-NOTE: I can not stress this enough! 99% of all the "SSL/TLS -don't work" mails on the openldap-software list is due to the -fact that someone have not used a correct Common Name in the SSL -certificate! An IP address won't work either. It can however be used -to get your common name from the DNS. Find your IP address and issue -the command
-host <YOUR IP ADDRESS HERE>
-The first line that reads Name: is what you should use as your common -name!
-Keep the file server.pem created here handy, we will need -it later when setting -up secure replication below.
-Also, remember that since you're specifying the host name in the -certificate (which is required), you must have -one certificate for each of your LDAP server (if you're doing -replication to other machines).
-This software don't exists as Debian packages, so I had to make -and install it my self. To do this, I just downloaded the tarball -from the sleepycat website. I got version 3.0.55, and I see that the -version on there site is now 3.2.9. I can't guarantee that that will -work, but be my guest to try it. If it shouldn't work, you can get -SleepyCAT -v3.0.55 at my site. This is how to build the software after -unpacking it in your favourite source directory.
-cd build_unix -../dist/configure -make -make install
-That's about all I have to say on the issue of installing Berkeley DB -mostly because there's not much more to it! :).
-UPDATE: With Debian GNU/Linux 2.3 (aka Woody) and later, -BerkeleyDB 3.2.9 is availible in the libdb3 and libdb3-dev -packages, so you won't really need to download and install BerkeleyDB -from source. Just execute
-apt-get install libdb3 libdb3-dev
-and off you go...
-Now, as promised I will here give you the configure parameters -that the Debian packages are using:
---prefix=/usr ---enable-shared ---with-ccopts="-g -O2 -D_REENTRANT" ---localstatedir=/etc ---mandir=/usr/share/man ---without-tcl
-Then, just make all is executed.
-NOTE1: As said above, there is a -bug in all Kerberos implementations deriving from MIT KerberosIV -(yes, that spells out 4, it's a very old bug!). The bug is that it -have a temporary files race condition. For those that have a version -lower than 1.2.2 and don't want to/can't upgrade, there's a patch to -be found at the MIT -Kerberos advisories site. For you that run Debian, please see the -Building Cyrus SASL -example how to make a Debian package with this patch.
-NOTE2: Also, there have been discovered a buffer overflow -vulnerability in the telnetd that is distributed with Kerberos 5, -v1.2.2. See the URL http://www.securityfocus.com/bid/3064 -for more information about this vulnerability. A patch for this bug -can be found at the URL -http://web.mit.edu/kerberos/www/advisories/telnetd_122_patch.txt.
-NOTE3: Debian are now distributing MIT Kerberos v1.2.2 in -it's unstable distribution, so just execute
-apt-get update && apt-get upgrade
-(if you are getting your packages from Internet, and not from CD that -is). It should be installed into the testing and then the stable tree -after a couple of weeks (if there isn't any serious bugs against the -packages)...
-NOTE1: A buffer overflow bug have been found in wu-ftpd (and -therefor gssftpd which is the origin of part of the wu-ftpd). Have a -look at the advisory at -http://web.mit.edu/Kerberos/www/advisories/ftpbuf.txt. -The patch is also located without the advisory text on the URL: -http://web.mit.edu/Kerberos/www/advisories/ftpbuf_122_patch.txt.
-To prepare the Kerberos installation, one should read the Kerberos -FAQ. This FAQ was a very good guide for me to learn (or at least -give me a rough understanding of Kerberos :). Basically nothing in -there needs to be done when using the Debian GNU/Linux packages. I -just used the default ones, even though the version I installed first -had a /tmp race condition bug. I have now upgraded to version -1.2.2-1 (the -1 is the Debian patch version). The installation is -very straight forward, just answer the questions correctly :). -However, there are some stuff that needs to be done before (or after -if you like) the installation begins. You will need a working DNS -system. And the KDC/KAdmin. server should really be on a separate -machine, but I didn't have that luxury, so I installed it on the main -system (I'll make a separate KDC/KAdmin/LDAP server later, but not -now). -
-The DNS should be setup like follows to get full Kerberos network -support. However, it seems like very few programs (OpenLDAP doesn't -seem to) actually use the SRV entries, which is 'Server Location' -entries. So if you don't want to/can't change the DNS, it is not -required...
-NOTE: I upgraded my Kerberos server (from 1.2.2 to 1.2.4) -the other day, and I got the question if my DNS was listing the -location of my KDC's (which it does) so maybe Kerberos is now using -the SRV entries. I haven't verified what's the case here, it doesn't -matter that much to me at the moment... :)
-; IP addresses to the Kerberos/LDAP servers... -kerberos IN A <IP ADDRESS OF YOUR 1st KERBEROS SERVER> -kerberos-1 IN A <IP ADDRESS OF YOUR 2nd KERBEROS SERVER> -kerberos-2 IN A <IP ADDRESS OF YOUR 3rd KERBEROS SERVER> -ldap IN A <IP ADDRESS OF YOUR 1st LDAP SERVER> -ldap-1 IN A <IP ADDRESS OF YOUR 2nd LDAP SERVER> -ldap-2 IN A <IP ADDRESS OF YOUR 3rd LDAP SERVER> -; -; Master setup -_kerberos IN TXT "<YOUR KERBEROS REALM>" -_kerberos-master._udp IN SRV 0 0 88 kerberos -_kerberos-adm._tcp IN SRV 0 0 749 kerberos -_kpasswd._udp IN SRV 0 0 464 Kerberos -; -; Round-robin setup -_kerberos._udp IN SRV 0 0 88 kerberos - IN SRV 0 0 88 kerberos-1 - IN SRV 0 0 88 kerberos-2 -_ldap._tcp.<DOMAINNAME> IN SRV 0 0 389 ldap - IN SRV 0 0 389 ldap-1 - IN SRV 0 0 389 ldap-2
-Don't forget to make sure that the revers look-up works. Much of my -problems where that the KDC couldn't (wouldn't?) find my FQDN (Fully -Qualified Domain Name => Host name + Domain name) for my IP -address, or the other way around. -
-And what's this SRV stuff doing in there? That's kind'a cool -feature in the -BIND DNS server. See the page about specifying -the location of services RFC for more about this.
-The main KerberosV packages we will have to install on the KDC -(Kerberos server), are the following packages.
-krb5-kdc -krb5-admin-server -libkrb5-dev
-To do this, all you have to do is execute (as root of course :) the -command line
-apt-get install krb5-kdc krb5-admin-server libkrb5-dev-and this will install and configure a KDC and Kerberos admin server. -We will need the development package later on when we build SASL. -Since I'm running Debian GNU/Linux, I just installed these default -Debian packages, which also configured the stuff for me. What is also -good to have is these packages (just add those you want at the end of -the apt-get line. These packages should be installed on the Kerberos -client. In my case, the KDC lives on my main server, so I installed -these packages on the same system as the packages above. This is not -recommended, but I had no choise.
-krb5-doc -krb5-user -krb5-clients
-If you like to offer Kerberos secured services like ftp, rsh, telnet -etc, these are the packages you will also need to install (I did):
-krb5-ftpd -krb5-rsh-server -krb5-telnetd
-Now, apt is so very clever that it will download and install any -packages that the above packages are dependent on. So, for example, -if you are running with an older libc6 than the krb5 packages needs, -apt will download and install (!) those for you to. -
-Now, there seems to be something -wrong in some install script or other, because sometimes when I -installed Kerberos, the file /etc/krb5.conf wasn't created -correctly. I installed, unistalled back and fourth to try to figure -out how to get this to work. I will here include the file I have, and -it should work for most cases. As said, this seems to be a random -problem, and I have not been able to successfully duplicate the -problem, so double check the file for accuracy first.
-<libdefaults>
- default_realm = <YOUR KERBEROS REALM>
- default_tgs_enctypes = des3-hmac-sha1 des-cbc-crc des-cbc-md5
- default_tkt_enctypes = des3-hmac-sha1 des-cbc-crc des-cbc-md5
- permitted_enctypes = des3-hmac-sha1 des-cbc-crc des-cbc-md5
- krb4_config = /etc/krb.conf
- krb4_realms = /etc/krb.realms
- kdc_timesync = 1
- ccache_type = 4
- forwardable = true
- proxiable = true
-
-<realms>
- <YOUR KERBEROS REALM> = {
- kdc = kerberos.<YOUR DOMAINNAME>:88
- admin_server = kerberos.<YOUR DOMAINNAME>:749
- default_domain = <YOUR DOMAINNAME>
- }
-
-<domain_realm>
- .<YOUR DOMAINNAME> = <YOUR KERBEROS REALM>
-
-<logging>
- kdc = FILE:/var/log/kerberos/krb5kdc.log
- admin_server = FILE:/var/log/kerberos/kadmin.log
- default = FILE:/var/log/kerberos/krb5lib.log
-
-<login>
- krb4_convert = false
- krb4_get_tickets = falseWhen the DNS -is prepared and the packages installed, we need to create the -realm data in the KDC. You will be notified by this by the Debian -installer scripts. The command that needs to be executed are -krb5_newrealm. It will create the stash file for you, and also -create some service keys. This is what the script does (for those of -you that aren't running Debian):
-kdb5_util create -s -kadmin.local -q "ktadd -k /etc/krb5kdc/kadm5.keytab kadmin/admin" -kadmin.local -q "ktadd -k /etc/krb5kdc/kadm5.keytab kadmin/changepw" -/etc/init.d/krb5-kdc start || true -/etc/init.d/krb5-admin-server start ||true
-The last two lines are however a little premature. We need some form -of administrator user in the KDC to, so execute this line
-kadmin.local -q "addprinc krbadm@<YOUR KERBEROS REALM>"
-Also, while we are creating administrators, we will create a LDAP -administrator principal. This principal will have full access to the -LDAP database. For those of you that are migrating from OpenLDAP1 or -OpenLDAP2 without SASL etc (or basically any other LDAP server I -guess) will recognise this as the AdminDN (or rootdn as it's called -sometimes).
-kadmin.local -q "addprinc ldapadm@<YOUR KERBEROS REALM>"
Also, some access lists should be -installed/configured. In the file /etc/krb5kdc/kadm5.acl you should -enter these lines:
-kadmin/admin@<YOUR KERBEROS REALM> * -<YOUR USERNAME>@<YOUR KERBEROS REALM> * -krbadm@<YOUR KERBEROS REALM> * -*/*@<YOUR KERBEROS REALM> i
-For me, the second line reads turbo@BAYOUR.COM -* and that gives me full access to the database as my -ordinary login. Might not be a good thing, but then you don't have to -give out the kadmin/admin password to all of those that you want to -have (full or partial) access to your kerberos system. See the -Kerberos -V5 Installation Guide:ACL file for other values you can have -besides * and i.
-As you can see in this ACL file, we have not listed the ldapadm -principal we created above, only the krbadm. That's because we will -separate the Kerberos administration from the LDAP administration. -Even if you are running this system on only one machine, and -you are alone in administrating this (and will be in a foreseeable -future), I still recommend that you to separate the functions. Have -you read the section LDAPv3, -why bother. Remember the discussion about security? Let's not -allow things to slip through the cracks in such a minor detail as two -separate principals...
-The default keytab depends on your installation, but for Debian -GNU/Linux it is /etc/krb5.keytab. This file have to be -(securely) copied to the LDAP server before -being able to authenticate with SASL. I had a number of problems with -a faulty keytab. The kvno didn't matchup for some reason. Most likely -because I'm not (or at least wasn't) very good at Kerberos -administration. See the section about Problems -when the KVNO don't match up for ways of fixing/preventing this.
-This about raps' up the Kerberos installation/configuration, now -we can (re)start the KDC and Kerberos admin server.
-[I haven't written this part yet, please contribute!]
-I can't really remember how I tested it, but if -ktelnet/kftp/krsh/ksu works to/from you machine, it works. If not, -take a look at the Kerberos -FAQ.
-This is the first package that we will have to modify, since the -default's isn't good enough (we need GSSAPI). To get the full source -code (inclusive the patches applied by the Debian maintainer etc), -there's the tool apt-get. With the parameter source, it -downloads the latest source code and unpacks it in the current -directory. So, the source package for Cyrus-SASL is, you guessed it -cyrus-sasl (Debian have lowercased package names over the -board, that eases things). To double check, the command line is:
-apt-get source cyrus-sasl
-This is the second part. This one we need to modify a little from the -default Debian GNU/Linux packages. The changes are the following, -please edit the file debian/rules.
---enable-gssapi instead of --disable-gssapi
-And all the option, for those of you that aren't running Debian -GNU/Linux, are:
---prefix=/usr ---enable-static ---enable-login ---without-des ---without-rc4 ---enable-gssapi ---disable-krb4 ---mandir=/usr/share/man ---infodir=/usr/share/info
There is a bug in the version 1.5.24 that -makes interactive bind from ldapsearch fail if trying to -connect with SSL/TLS. If you execute this command line (exchanging -the <YOUR BASE DN>) after running kinit to get a -Kerberos ticket:
-ldapsearch -I -b "<YOUR BASE DN>" -H ldaps:///
-If you then get the following error, you need the patch below.
-ldap_sasl_interactive_bind_s: Unknown authentication method
-NOTE: According to a message on the openldap-software mailing -list, this was fixed some time ago in the CVS version of Cyrus SASL. -So make sure that you need the patch before applying it! The version -of the file plugins/gssapi.c in the cyrus-sasl source -directory should be greater than 1.39, that's when it was fixed. So -if you have a version higher than 1.39 you don't need to patch -Cyrus-SASL. If you got the tarball from the FTP site, then you will -need both these patches. Another thing, if you can't find a version -number in the file noted above, then you're most likely not running -the CVS version, so the patch is needed.
-This is the patch you will have to apply:
-diff -ur cyrus-sasl-1.5.24.orig/plugins/gssapi.c cyrus-sasl-1.5.24/plugins/gssapi.c ---- cyrus-sasl-1.5.24.orig/plugins/gssapi.c.orig Wed Mar 7 19:42:31 2001 -+++ cyrus-sasl-1.5.24/plugins/gssapi.c Wed Mar 7 19:43:35 2001 -@@ -1243,7 +1243,7 @@ - - /* need bits of layer */ - allowed = secprops.max_ssf - external; -- need = secprops.min_ssf - external; -+ need = secprops.min_ssf < external ? 0 : secprops.min_ssf - external; - serverhas = ((char *)output_token->value)[0]; - - /* if client didn't set use strongest layer available */
-Also, there is a problem with the -Debian GNU/Linux (and according to information on the -OpenLDAP-Software list, in any place where you use pre-built -binaries) that makes SASL 'forget' about the realm part in the login. -The way to test this is by running slapd with options -d -1 -and try a sasl -bind. Then check the output from slapd. -To save all the output that slapd is spewing out, use the -command tee like this:
-slapd -d -1 2>&1 | tee /tmp/output.txt
-Then search in the file /tmp/output.txt for the parts that -read:
-slap_sasl_bind: username="u:[YOUR USER ID]" realm="[YOUR KERBEROS REALM]" ssf=[SOME NUMBER] -<== slap_sasl_bind: authzdn: "uid=[YOUR USER ID] + realm=[YOUR KERBEROS REALM]"
-If you have the text realm=<YOUR KERBEROS REALM> in -there, all is well, and you don't need the patch. If however, the -realm is not listed there, then please apply this patch that I got -from the mailing list:
-diff -ur cyrus-sasl-1.5.24.orig/plugins/gssapi.c cyrus-sasl-1.5.24/plugins/gssapi.c
---- cyrus-sasl-1.5.24.orig/plugins/gssapi.c.orig Fri Jul 21 04:06:52 2000
-+++ cyrus-sasl-1.5.24/plugins/gssapi.c Sun Dec 17 15:19:31 2000
-@@ -592,6 +594,7 @@
- gss_buffer_desc name_without_realm;
- gss_name_t without = NULL;
- int equal;
-+ char *realm = NULL;
-
- name_token.value = NULL;
- name_without_realm.value = NULL;
-@@ -625,7 +623,8 @@
- without the realm and see if it's the same id (i.e.
- tmartin == tmartin@ANDREW.CMU.EDU. If this is the case we just want
- to return the id (i.e. just "tmartin: */
-- if (strchr((char *)name_token.value, (int) '@')!=NULL)
-+ realm = strchr((char *)name_token.value, (int) '@');
-+ if (realm != NULL)
- {
- name_without_realm.value = (char *) params->utils->malloc(strlen(name_token.value)+1);
- if (name_without_realm.value == NULL) return SASL_NOMEM;
-@@ -687,6 +686,14 @@
- strcpy(oparams->authid, name_token.value);
- }
-
-+ if (realm != NULL)
-+ {
-+ realm++; /* skip '@' */
-+ oparams->realm = (char *) params->utils->malloc(strlen(realm)+1);
-+ if (oparams->realm == NULL) return SASL_NOMEM;
-+ strcpy(oparams->realm, realm);
-+ }
-+
- if (name_token.value)
- params->utils->free(name_token.value);
- if (name_without_realm.value)-Applying this patch(-es) can be done by using patch. For example, the -patch is saved in the file /tmp/gssapi1.patch. You would then -use the following command (in the top directory of the cyrus sasl -source).
-patch -p1 < /tmp/gssapi1.patch
-The patch can also be found at my site, GSSAPI -patch 1 and GSSAPI -patch 2. The author of the first patch comes originally from -Nalin Dahyabhai <nalin@redhat.com>. Again, only do this if your -plugins/gssapi.c version is lower than 1.39 (or if you're -trying to compile SASL from the official tarball)!
-Now you can start building the packages by executing the command -line
-debuild -uc -us -rfakeroot
-Debuild is in the package devscripts, so just install that package by -executing the command line
-apt-get install devscripts
-before building the package. To build the packages if you are not -running Debian, you just execute make to build the software.
-To make sure that the packages you just build don't get -automatically upgraded when using the command
-apt-get update && apt-get upgrade
-etc, make sure to put the packages on hold. Easiest way to do that, -is to go into dselect -and press = on the line of the package. Another way to do this -is to execute
-echo <PACKAGENAME> hold | dpkg --set-selections
-Do this after you have installed the packages :). Please also see the -section about Bumping -the Debian GNU/Linux package version on another way to avoid -automatic upgrades of the newly made packages.
-But before we install the SASL packages, you have to make sure -that some libraries etc. that these libraries depend on is installed. -To do this, first install these packages
-libgdbmg1 -libpam0g -libcomerr2 -libkrb53
-Then you can continue with installation of the SASL packages below
-libsasl7 -libsasl-modules -libsasl-bin
-You do this by executing the command
-dpkg -i libsasl7*.deb libsasl-modules*.deb libsasl-bin*.deb
-To install the software if you are not running Debian, you execute -the command make install. See the package libkrb53? Now -you know why I asked you to install the Kerberos development -packages. SASL must find krb5 on the system to allow you to use -Kerberos V!
-You will need to have a working Kerberos V system running. See the -section Testing MIT -Kerberos V for more about this. What you will have to do is get -yourself two shells. Execute kinit in both and then in shell -number one type
-su -c ./sample-server -s ldap -p /usr/lib/sasl
-And in the other one
-./sample-client -s ldap -n <FQDN> -u <USERNAME> -p /usr/lib/sasl
-Other than that, please follow the information outlined in the file -testing.txt distributed with cyrus-sasl. You can find the file -at this URL to, Testing -the CMU SASL Library with the included sample applications if you -prefer to have it through you favourite web browser.
-This package have also been slightly modified to suite my needs. -First the changes in the configure command line, please edit the file -debian/rules.
---disable-cleartext instead of --enable-cleartext ---disable-rlookups instead of --enable-rlookups ---with-tls instead of --without-tls ---enable-kpasswd
-To build against the Berkeley -DB we built before, add these two lines before the configure -line.
-CPPFLAGS="-I/usr/local/BerkeleyDB.3.0/include" \ -LDFLAGS="-L/usr/local/BerkeleyDB.3.0/lib"
-And all the options, for those of you that aren't running Debian -GNU/Linux, are the following. These are the important ones you should -have
---with-cyrus-sasl ---enable-slapd ---enable-crypt ---enable-spasswd ---with-tls ---enable-kpasswd
-These are also some (optional) values you should add. Remove the -options that you know that you definitely don't want. For example, -the enable-ipv6 might be a bad idea sometimes...
---enable-debug ---enable-syslog ---enable-proctitle ---enable-cache ---enable-referrals ---enable-ipv6 ---enable-local ---with-readline ---with-threads ---disable-cleartext ---enable-multimaster ---enable-phonetic ---disable-rlookups ---enable-wrappers ---enable-dynamic ---enable-dnssrv ---enable-ldap ---enable-ldbm ---enable-passwd ---enable-shell ---enable-sql ---enable-slurpd ---enable-shared
There might also bee needed to patch -the file libraries/libldap/open.c from the openldap2 source -directory. Read all about the reasoning behind this at the OpenLDAP -ITS, bug 889. There's also a patch there for you that don't use -Debian. If you however are using Debian, and you want the changes in -the rules file and the discussed patch, you can apply this patch -instead of doing it all by yourself. To apply this patch, see the -Cyrus SASL -bugs above or read the manual page for patch. This patch might -not be needed on the OpenLDAP source you have, so verify that you -need it before use! One way of doing this, is compile/install without -it, and if ldapsearch, ldapadd, ldapmodify -segfaults when trying to use the parameter -H, then you need -it!
-NOTE: These bugs have been fixed around 2.0.9 or so. At any -rate, the latest version (at the time of this writing, 2.0.21) have -it fixed, so there is no need to patch the files! Please have a look -at the Updates section for more -information.
-diff -urN debian.orig/patches/004_libldap-open debian/patches/004_libldap-open
---- debian.orig/patches/004_libldap-open Thu Jan 1 01:00:00 1970
-+++ debian/patches/004_libldap-open Wed Mar 14 22:13:52 2001
-@@ -0,0 +1,19 @@
-+diff -ur OPENLDAP_HEAD/libraries/libldap/open.c libraries/libldap/open.c
-+--- OPENLDAP_HEAD/libraries/libldap/open.c Wed Oct 18 11:53:53 2000
-++++ ./libraries/libldap/open.c Tue Nov 21 20:37:04 2000
-+@@ -329,8 +329,15 @@
-+ if (ld->ld_options.ldo_tls_mode == LDAP_OPT_X_TLS_HARD ||
-+ strcmp( srv->lud_scheme, "ldaps" ) == 0 )
-+ {
-++ LDAPConn *savedefconn = ld->ld_defconn;
-++ ++conn->lconn_refcnt; /* avoid premature free */
-++ ld->ld_defconn = conn;
-++
-+ rc = ldap_pvt_tls_start( ld, conn->lconn_sb,
-+ ld->ld_options.ldo_tls_ctx );
-++
-++ ld->ld_defconn = savedefconn;
-++ --conn->lconn_refcnt;
-+
-+ if (rc != LDAP_SUCCESS) {
-+ return -1;
-diff -urN debian.orig/rules debian/rules
---- debian.orig/rules Wed Mar 14 22:10:41 2001
-+++ debian/rules Wed Mar 14 22:10:33 2001
-@@ -34,11 +34,11 @@
- configure_args := --enable-debug --enable-syslog --enable-proctitle \
- --enable-cache --enable-referrals --enable-ipv6 --enable-local \
- --with-cyrus-sasl --with-readline --with-threads \
----enable-slapd --enable-cleartext --enable-crypt --enable-spasswd \
----enable-multimaster --enable-phonetic --enable-rlookups --enable-wrappers \
-+--enable-slapd --disable-cleartext --enable-crypt --enable-spasswd \
-+--enable-multimaster --enable-phonetic --disable-rlookups --enable-wrappers \
- --enable-dynamic --enable-dnssrv --enable-ldap --enable-ldbm \
- --enable-passwd --enable-shell --enable-sql --enable-slurpd --enable-shared \
----without-tls
-+--with-tls --enable-kpasswd
-
- # FHS options
- configure_args += --prefix=/usr --localstatedir=/var --sysconfdir=/etc \
-@@ -52,6 +52,8 @@
- $(STAMP_DIR)/pre-build-stamp: $(unpacked) $(patched)
- dh_testdir
- cd $(BUILD_TREE) && CFLAGS="$(CFLAGS)" \
-+ CPPFLAGS="-I/usr/local/BerkeleyDB.3.0/include" \
-+ LDFLAGS="-L/usr/local/BerkeleyDB.3.0/lib" \
- ./configure $(configure_args) --host=$(DEB_BUILD_GNU_TYPE)
- $(MAKE) depend -C $(BUILD_TREE)
- touch $(STAMP_DIR)/pre-build-stamp-You can also get the OpenLDAP -v2 patch on papadoc.
-When the possible patching is done, we will build the packages. Do -this by executing the command
-debuild -uc -us -rfakeroot
-For those that aren't running Debian, execute the commands
-make depend -make
The packages you should install are the following:
-libldap2 -ldap-utils -slapd
-You do this by executing the command
-dpkg -i libldap2*.deb ldap-utils*.deb slapd*.deb
-But before you can do this, you have to make sure that some libraries -etc. that these libraries depend on is installed. To do this, execute -the line
-apt-get install libiodbc2
-To install the software if you are not running Debian, you just -execute the command
-make install
-For more information (in case of trouble building and installing -OpenLDAP2 etc.), please see the OpenLDAP -web site and/or the OpenLDAP -FAQ-O-Matic:Quick Start Guide.
-The Debian GNU/Linux installation script will guide you through -most of the scripts and will also create the administration DN -referred to in these files. This DN is mostly for backward -compatibility with older clients, than can't do SASL/Kerberos binds.
-Then it's just a matter of copying this file, server.pem to -/etc/ldap and modify The -OpenLDAP config file with these options:
-TLSCertificateFile /etc/ldap/server.pem -TLSCertificateKeyFile /etc/ldap/server.pem -TLSCACertificateFile /etc/ldap/server.pem
We have to make sure that slapd (the actual LDAP -daemon/server) listens to port 636 which is the actual LDAP over -SSL/TLS port. In the Debian GNU/Linux original startup script, we -make this change:
---- slapd.orig Fri Jul 27 08:53:39 2001 -+++ slapd Fri Jul 27 08:53:11 2001 -@@ -21,7 +21,7 @@ - echo -n "Starting ldap server(s):" - echo -n " slapd" - start-stop-daemon --start --quiet --pidfile "$pidfile" \ -- --exec $DAEMON -+ --exec $DAEMON -- -h "ldap://0.0.0.0:$PORT/ ldaps://0.0.0.0/" - replicas=`grep ^replica /etc/ldap/slapd.conf` - test -z "$replicas" || (echo -n " slurpd" && start-stop-daemon --start \ - --quiet --name slurpd --exec $SLURPD)
-That is, we have to make sure that SLAPD listens to ldaps (which is -port 636). The PORT variable is set earlier in the script (at least -in the Debian GNU/Linux version).You should have a line that read -something like:
-PORT=389
-If you don't have this, either replace the $PORT part above -with 389, or add the PORT=389 line above the slapd -start lines...
-This could be a FAQ all on it's own, -let's just include my config file, shall we?
-# This is the main ldapd configuration file. See slapd.conf(5) for more -# info on the configuration options. - -# Schema and objectClass definitions -include /etc/ldap/schema/core.schema -include /etc/ldap/schema/cosine.schema -include /etc/ldap/schema/inetorgperson.schema -include /etc/ldap/schema/nis.schema -include /etc/ldap/schema/krb5-kdc.schema -include /etc/ldap/schema/qmail.schema -include /etc/ldap/schema/qmailControl.schema -include /etc/ldap/schema/netscape-profile.schema -include /etc/ldap/schema/trust.schema -include /etc/ldap/schema/turbo.schema -# Some are extra schema's that I found on the 'Net... -# Want them? They can be found at http://www.bayour.com/openldap/schemas/ - -# Schema check allows for forcing entries to -# match schemas for their objectClasses's -schemacheck on - -# Where the pid file is put. The init.d script -# will not stop the server if you change this. -pidfile /var/run/slapd.pid - -# List of arguments that were passed to the server -argsfile /var/run/slapd.args - -# Read slapd.conf(5) for possible values -loglevel 2048 # Only entry parsing errors - -sasl-realm <YOUR KERBEROS REALM> -sasl-host <FQDN OF LDAP SERVER> -#sasl-secprops none - -####################################################################### -# ldbm database definitions -####################################################################### - -# The backend type, ldbm, is the default standard -database ldbm - -# The base of your directory -suffix "<YOUR BASEDN>" - -# Where the database file are physically stored -directory "/var/lib/ldap" - -# Save the time that the entry gets modified -lastmod on - -# Indexes -index default pres,eq -index objectClass,uid,uidnumber,gidnumber,cn -index mail,mailalternateaddress,mailforwardingaddress eq - -# Include the access lists -include /etc/ldap/slapd.access - -# End of ldapd configuration file
-In this file you will notice the option sasl-host. Remember -the DNS -setup? This is the host name and domain name of the host that -your LDAP server is running on. It is not the FQDN of the kerberos -server as I've stated in previous versions of this document. Sorry -about that. In my case, this is egeria.bayour.com, because that was -what I was entering into the SSL certificate. Don't forget the -SSL/TLS certificate file options, which I showed you in Creating -SSL certificate.
-I have all my access lists (ACL's) -in a separate file (/etc/ldap/slapd.access). I'm still working -on getting this to work properly so it's not perfect, but there you -go...
-# For Netscape Roaming support, each user gets a roaming profile for
-# which they have write access to
-access to dn=".*,ou=Roaming,dc=.*"
- by dn="<YOUR ADMIN DN>" write
- by dn="uid=ldapadm.+\+realm=<YOUR KERBEROS REALM>" write
- by dnattr=owner write
- by * none
-
-# Some things should be editable by the owner, and viewable by anyone...
-access to attr=cn,givenName,sn,krbName,krb5PrincipalName,gecos
- by dn="<YOUR ADMIN DN>" write
- by dn="uid=ldapadm.+\+realm=<YOUR KERBEROS REALM>" write
- by self write
- by users read
-
-access to attr=loginShell,gecos
- by dn="<YOUR ADMIN DN>" write
- by dn="uid=ldapadm.+\+realm=<<YOUR KERBEROS REALM>" write
- by self write
- by * read
-
-# Since we're using {KERBEROS}<PRINCIPAL>, we can't allow the user
-# to change the password. They have to use the Kerberos 'kpasswd' to
-# do this... But the admin can change (if need be).
-# Please see krb5 userPassword attribute
-access to attr=userPassword
- by dn="cn=admin,ou=People,dc=papadoc,dc=bayour,dc=com" write
- by dn="uid=ldapadm.+\+realm=<YOUR KERBEROS REALM>" write
- by anonymous auth
- by * none
-
-# The mail and mailAlternateAddress should only be readable if you
-# authenticate!
-access to attr=mail,mailAlternateAddress,mailHost
- by dn="<YOUR ADMIN DN>" write
- by dn="uid=ldapadm.+\+realm=<YOUR KERBEROS REALM>" write
- by users read
- by * none
-
-# Should not be readable to anyone, and only editable by admin...
-access to attr=mailQuota,trustModel,accessTo
- by dn="<YOUR ADMIN DN>" write
- by dn="uid=ldapadm.+\+realm=<YOUR KERBEROS REALM>" write
- by self read
- by * none
-
-# The admin dn has full write access
-access to *
- by dn="<YOUR ADMIN DN>" write
- by dn="uid=ldapadm.+\+realm=<YOUR KERBEROS REALM>" write
- by * read-Notice the
-by dn="uid=ldapadm.+\+realm=<YOUR REALM>" write
-That's the Kerberos principal you want write access to the database -as. This principal was created in the Create -KerberosV realm section.
-But there seems to be another bug in the Debian SASL packages. -According to information on the openldap-software mailing list, the -problem don't exist in the tarball from Cyrus home page. See the -section about the SASL patch - Realm -for more about this.
-To let OpenLDAP/SASL connect to -the KDC, we need to add a LDAP service key into the KDC. To do this, -use the command kadmin or kadmin.local like this:
-kadmin.local -q "addprinc -randkey ldap/<FQDN>@<YOUR KERBEROS REALM>" -kadmin.local -q "ktadd ldap/<FQDN>"
If you starting out fresh with this project, you will have to read -up on how to create a database on the openldap database -creation and maintenance tools page. When you understand this, -it's time to specify the special object classes and attributes that -makes this whole LDAPv3 thing tick. The object class krb5Principal -specify that the attribute krb5PrincipalName is a must -and that the cn and krb5PrincipalRealm attributes is -optional. What this means, is that we use the following LDIF snippet -on each of our users:
-objectClass: krb5Principal -krb5PrincipalName: turbo@<MY KERBEROS REALM> -cn: Turbo Fredriksson
-The cn means Common Name, and in this case it's my full name -(yes, my name really IS turbo! :).
-These attributes and object classes are defined in the -krb5-kdc.schema file distributed with OpenLDAP2. The other -object classes (krb5KDCEntry and krb5Realm) are not -used in this context, so ignore them :).
-If you already have a database, but are using some other means of -storing the passwords, you will have to do some minor modifications -to the database. For example, my production server, which is a -version 1.2.11 have the passwords in the LDAP database as -'{crypt}CRYPTEDPW', and is using libpam-ldap (and for migration -purposes libpam-krb5 which is NOT to recommend in a shared network -environment since it binds in clear text) to authenticate the users -on all services (ssh/imap/pop/ftp etc). Now, Quite naturally I wanted -to use that database, so I first did a dump of the original database -with ldbmcat (to convert it into an LDIF file) and then on the -new server, slapadd to create the database. This was a big -problem, since OpenLDAP2 is much more strict about the existence of a -proper schema for the objectClasses etc. See LDAP -schemas on Papadoc for the schema's that I have (I found most of -them on the Internet so don't blame me if they are a little out of -date :).
-Before loading the database -into the new server, I had to change all the userPassword -attributes. This is where the --enable-kpasswd comes into -play. The password should be {KERBEROS}<USERS PRINCIPAL> -like this (my entry):
-dn: uid=turbo,ou=People,<MY BASEDN>
-replace: userPassword
-userPassword: {KERBEROS}turbo@<MY KERBEROS REALM>-This have to be done for all the users to allow them to authenticate! -This only works if you have compiled OpenLDAP2 with the configure -option --with-kpasswd, and what that do is making slapd -ask the Kerberos server if the password corresponds with the password -for the Kerberos principal turbo@<MY KERBEROS REALM>. -What this do, is it's telling the OpenLDAP2 server (slapd) to -check the password in the Kerberos server. Since there is no password -in the LDAP database any more, we have to make sure that the user -can't change there password with either ldappasswd or via PAM. -Therer for, please have a look at the The -OpenLDAP access file again (especially the 'access to -attr=userPassword' section.
-Now, just to clarify some things (because it will look a little -strange). If you do the modifications above, and then do a search -(ie, retrieving) the userPassword value from the database, it -will look a little garbled:
-userPassword:: e2NyeXB0fUlNRDR0cmxiaUdFVVU=
-This is nothing to worry about. It's simply base 64 encoded (this -reads {KERBEROS}turbo@BAYOUR.COM after decoding).
-The reason for using userPassword: {KERBEROS}PRINCIPAL -is so that we can allow simple binds with the password in the -Kerberos database. This should not really be done, since if we do a -simple bind without SSL/TLS, we're opening up the Kerberos database. -We're using Kerberos so that we get a secure system, remember?!.
-So -simple binds would only be allow if -it's protected with SSL or TLS. If you have no interest in allowing -simple binds (note, this is not SASL bind!), then don't use the -userPassword -entry at all. If you only have interest in allowing SASL binds, this -entry can be left out completely. If, for some reason, you have -clients that can't do SASL binds (Qmail-LDAP comes to mind), then -don't have the password in the Kerberos database, but in LDAP with -either {CRYPT} or even better {SSHA}. -Using the command slappasswd, -you can create a scheme to be inserted into the database. This way, -you won't accidentally compromise your Kerberos database security.
-In the ldapsearch commands below, I use localhost -for the name of the LDAP server. I got one mail from Will Day on the -OpenLDAP-Software mailing list, saying that this didn't work for him. -He had to exchange localhost to the FQDN of the LDAP -server instead. The reason for this is most likely because it can't -get a ticket for ldap/localhost@<KERBEROS REALM>. -To avoid that, just enter a ldap/localhost@<KERBEROS REALM> -service key as well as the ldap/<FQDN>@<KERBEROS -REALM>. Have a look at Creating -a LDAP service key below how to do that. So, if the commands -don't work as shown here, please try that.
-Also, I'm specifying port 389 here. You might not need that at -all, since that's the default port of the LDAP server. I only list -that here, because while setting all this up for the very first time, -I ran a OpenLDAP1 server on port 389, and my new OpenLDAP2 server on -port 3389. This server is now my main LDAP database.
-The first thing is probably to check if -a non SASL/SSL/TLS (that is, a simple bind) works
-ldapsearch -h localhost -p 389 -x -b "" -s base -LLL supportedSASLMechanisms
-You should get something like this
-supportedSASLMechanisms: PLAIN -supportedSASLMechanisms: LOGIN -supportedSASLMechanisms: ANONYMOUS -supportedSASLMechanisms: GSSAPI
-The important stuff here is the last line! If you don't have GSSAPI -listed, something is wrong, and you should go back to Building -OpenLDAP v2 (or maybe you need to go back to Building -Cyrus SASL) and do it right this time. On my production server, I -have now disabled some of these mechanisms, so the only one I -get is GSSAPI. This is perfectly ok, since I only want/need SASL -(GSSAPI) binds.
-If the search for supported SASL mechanisms went well, let's - -continue with the next step. Let's try to do a simple bind, but with -SSL and TLS. The first command tests TLS, and the second one SSL -(notice the parameter -ZZ in the second and ldaps:/// -in the first?).
-ldapsearch -H ldap://<FQDN OF LDAP SERVER>/ -p 389 -x -b "" -s base -LLL -ZZ supportedSASLMechanisms -ldapsearch -H ldaps://<FQDN OF LDAP SERVER>/ -x -b "" -s base -LLL supportedSASLMechanisms
-You should get the same stuff as above back, only this time it is -sent to you encrypted from the LDAP server. You can double check this -by using a packet sniffer. The reason we have to enter the full name -of our LDAP server for these two commands (instead of just ldap:/// -or ldaps:///) is because in newer OpenLDAP, the certificate -verifications is much stronger. It requires the FQDN -one connects to matches the one in the certificate. In my example -(see the section about Creating -SSL certificate) the commands would look like:
-ldapsearch -H ldap://egeria.bayour.com/ -p 389 -x -b "" -s base -LLL -ZZ supportedSASLMechanisms -ldapsearch -H ldaps://egeria.bayour.com/ -x -b "" -s base -LLL supportedSASLMechanisms
Now let's try out a SASL bind. Exchange -the -x above to -I (uppercase i) like below. Just press -enter when you get the prompt Please enter your authorisation -name:.
-ldapsearch -H ldaps:/// -I -b "" -s base -LLL supportedSASLMechanisms
-Anything? Nope, you should get back:
-ldap_sasl_interactive_bind_s: Local error
-This is a bug (or maybe more correctly, 'missing feature' :) in SASL -(it doesn't return the correct error codes). There is no known fix -for this yet. To get around it, execute the command kinit and -try again. The lines above, with -x replaced with -I -should return something like:
-SASL SSF: 56 -SASL installing layers -dn: -supportedSASLMechanisms: PLAIN -supportedSASLMechanisms: LOGIN -supportedSASLMechanisms: ANONYMOUS -supportedSASLMechanisms: GSSAPI
-Here DES (56 bit key lengh for symmetric cryptography) is used to -encrypt the data stream. That is, the transfer of the -information to you isn't encrypted, but the actual bind (the password -and user/authorisation name) is. Hmm, wonder if this is true... I've -heard 'rumors' on some lists that SASL actually ARE encrypting all -communication between you and the LDAP server. Ah, well. Better safe -than sorry, use -H or -Z.
-Please verify that a SSL and TLS works with SASL to by using -ZZ -and -H parameters to the above ldapsearch command line. -The difference between -Z and -ZZ is that the later -requires the operation to be successful.
-Now, if all the changes to the -database (see how to populate -the database and/or modify -the LDAP database) have been done and all the above tests work, -let's try to search the database as yourself again, but this time -doing it with a simple bind (-x to ldapsearch). To make -absolutely sure that it doesn't try to use the Kerberos ticket you -got with kinit above, execute kdestroy. Just to be on -the safe side when testing here, mind you :). Here we go, all in one -line:
-ldapsearch -x -D 'uid=turbo,ou=People,<MY BASEDN>' -W -b "" -s base -LLL -H ldaps://<FQDN OF LDAP SERVER>/ supportedSASLMechanisms
-Enter the password when prompted. This command should return the same -thing as the previous commands. Remember, you should enter the -password for your KerberosV principal. If it didn't take the Kerberos -password, you would get this back:
-Enter LDAP Password: -ldap_bind: Invalid credentials
-I worked for quite some time (about 4-5 days) to get this part to -work. I had no luck. Then, all of a sudden it worked, and I'm not -quite sure why. I am however quite sure that it have -something to do with the order the ACL's for userPassword is -arranged. OpenLDAP v2.0 is a LOT more picky about the order of the -ACL's than the 1.3 version(s) where (where my config/access file -originates from). See my OpenLDAP -access file of how it looks when it works. Take a extra look at -the section that starts with:
-access to attr=userPassword
-NOTE: The parameters -D, -W and -w is not -used when using SASL (unless you want a simple bind, which you -normally wouldn't). You use -I (uppercase i), -U and -X -to use SASL bind. For anonymous and/or simple binds, one have to use -the option -x.
-If all the above searches work, you might want to try searching -for data under your base DN, and also do modifications etc, just to -double check that everything works as it's supposed to. The biggest -problems I had with all this, must be the ACL's! Have a second look -at The OpenLDAP -access file.
-One of the main points (for me at least) by using SASL, Kerberos -and SSL/TLS is so that we can have a secure/encrypted authentication -and communication between the master and slave LDAP server(s). To try -this out, I will demonstrate how you can (and should?) have a slave -server running on localhost. The reason we want to do this, is so -that when doing backups of the LDAP database, we don't need to take -down the master database, only the read-only replica, which means -that we don't have any downtime on the LDAP server.
-The first thing we do, is we -create the config file for the slave server. This is basically the -exact same config file as The -OpenLDAP config file. The differences though, is that the -database is located in another directory. Preferably we should set -the database to read only, but it doesn't seem to work. We will -instead use ACL's to limit the access (as much as I can, with the -limited knowledge of OpenLDAP2's ACL structure :).
-directory "/var/lib/ldap.backup" -updatedn "uid=replicator.\+realm=<YOUR REALM>" -include /etc/ldap/slapd.access.backup
-Other than that, we will run the slave server on other ports than the -master. That's since we are running both on the same machine, and we -can't bind both of them on the same port (unless you make it bind to -different IP addresses, but that's nothing I will go into here). -There for we add some more options to the command line. You can use -the master's start script, modify it by running slapd like -this:
-PORT=3391 /usr/sbin/slapd \ - -h "ldap://0.0.0.0:$PORT/ ldaps://0.0.0.0:`expr $PORT + 1`/" \ - -f /etc/ldap/slapd.conf.backup
-That will start the non-SSL/TLS -port on 3391, and the SSL/TLS port on 3392.
-The modifications to the master database's configuration, is the -location of the slave. This is what we will add to the database -definition in The -OpenLDAP config file:
-replica host=localhost:3391 - tls=yes - bindmethod=sasl - saslmech=GSSAPI -replogfile /var/lib/ldap/replog
-Please see the OpenLDAP -2.0 Administrator's Guide:Replication and the manual page for -slapd.conf for more about this.
-To be able to use -GSSAPI/Kerberos V with replication, we will need to create a service -key that we will use for authentication and extract that into a -keyfile. The principal I have chosen here is replicator, but you can -essentially choose any principal you like, as long as use use the -same principal in the access list on both the master and the slave -server. To create such a principal, we execute the following -commands:
-kadmin.local -q "addprinc -randkey replicator@<YOUR KERBEROS REALM>" -kadmin.local -q "ktadd -k /etc/krb5.keytab.slurpd replicator"
-Make sure that the keytab file (/etc/krb5.keytab.slurpd in -this example) is secure. That is, transfer it safely -to the slave and master LDAP server (using for example scp or -kscp). Also make sure it is not readable for anyone else than -the user slapd is running as.
-If this file is compromised (obtained by any arbitrary -user), then your whole LDAP database will have to be considered -compromised!-
Since we are using SASL/KerberosV to do the replication -authentication, we must ensure that slurpd have a Kerberos -ticket before starting. We must also 'remember' the location of the -ticket file, so that it can be removed when shutting down slurpd. -To do this, we use the LDAP -service key we created above, like this:
-kinit -r 7d -k -t /etc/krb5.keytab.slurpd replicator@<YOUR KERBEROS REALM>
-This line will have to be inserted into the slapd/slurpd -start script, just before slurpd is started. To make sure that -the ticket gets removed/destroyed when no longer needed (ie, when -slurpd is shutdown), we issue the command kdestroy just -after slurpd have been stopped.
-This results in the following start scripts (for starting slurpd):
-replicas=`grep ^replica /etc/ldap/slapd.conf` -if [ ! -z "$replicas" ]; then - KRB5CCNAME=FILE:/var/run/slapd.krbenv - echo -n "Getting ticket for replicator: " - kinit -k -t /etc/krb5.keytab.slurpd replicator@<YOUR KERBEROS REALM> - echo "done." - - echo -n "Starting LDAP replication daemon: " - /usr/sbin/slurpd - echo "done." -fi
-This is the stopping part:
-replicas=`grep ^replica /etc/ldap/slapd.conf` -if [ ! -z "$replicas" ]; then - echo -n "Stopping LDAP replication daemon: " - killall slurpd > /dev/null 2>&1 - echo "done." - - KRB5CCNAME=FILE:/var/run/slapd.krbenv - echo -n "Removing Kerberos ticket: " - kdestroy && rm /var/run/slapd.krbenv - echo "done." -fi
To make sure that there always is a ticket for the replicator, we -will have to execute the kinit line above every now and then -from cron. How often this should happen, depends on how -long-lived the ticket is. To find that out, we issue the command -kadmin (or kadmin.local) like this:
-kadmin.local -q "getprinc replicator" | grep "^Maximum ticket life:"
-In my case, it will return:
-Maximum ticket life: 0 days 10:00:00
-So I will have to renew the ticket at least every ten hours. To be on -the safe side, I'll do it every nine hours. The entry we will put -into /etc/crontab is:
-# Making sure that the LDAP replication have a valid ticket - -KRB5CCNAME=FILE:/var/run/slapd.krbenv -0 */9 * * * root test -e /var/run/slapd.krbenv && kinit -R
-You can read more about running and getting tickets in shell scripts -untended at the Kerberos -FAQ:Shell scripts.
-There is a way to specify a longer life time when creating the -principal (-maxlife) but I haven't figured out exactly how to -specify the time. I keep getting Invalid date specification -all the time.
-UPDATE: The maximum lifetime of a ticket can, in kadmin -or kadmin.local be -specified like
--maxlife "4 days" --maxlife "4 hours"
-etc...
-We must give the replicator principal access to write to the -database. To do this, we create this access file instead of The -OpenLDAP access file we had for the master server (this file is -named /etc/ldap/slapd.access.backup in the slave -server replication configuration above). The reason it's much -simpler is because it's read-only, and should contain a online backup -of the database, therefor there is no need for anyone else than -replicator to be able to read/write to the slave.
-access to attr=cn,givenName,sn,krbName,krb5PrincipalName,loginShell,gecos,mail,mailAlternateAddress,mailHost,mailQuota,uidNumber,gidNumber,homeDirectory - by dn="uid=replicator.+\+realm=<YOUR KERBEROS REALM>" write - by users read - by * none - -access to attr=userPassword,ldapPassword,clearTextPassword - by dn="uid=replicator.+\+realm=<YOUR KERBEROS REALM>" write - by * none - -access to * - by dn="uid=replicator.+\+realm=<YOUR KERBEROS REALM>" write - by * read
-We should really not have read access at all (by users read -and by * read), but for some reason (which elude me) it -doesn't work otherwise...
-The version I did this with was v1.11-0.1. One can now -authenticate and encrypt using the GSSAPI network security interface. -For details, see the -Cederqvist's description of specifying :gserver: in -CVSROOT, and the -a global option.
-To do this, we need to build with the following options to -configure:
---with-gssapi=value GSSAPI directory ---enable-encryption enable encryption support
-For non-Debian systems, these are the full configure opions:
---prefix=/usr ---mandir=/usr/share/man ---infodir=/usr/share/info ---with-gssapi ---enable-encryption
-How to build and install? Haven't you paid attention? :) Please go -back to the Building -Cyrus SASL section again...
-There's the --with-krb4=value to configure in this case, -but as you can see that is for Kerberos IV, and that isn't fully -compatible with MIT Kerberos V. There is however a krb524d -daemon that takes care of converting a Kerberos IV request to a -Kerberos V. But that's quite pointless, since we are already using -GSSAPI with our Kerberos V server. From what I can tell, you should -only run the krb534d daemon if you don't have any other -choice. That is, if there weren't any --with-gssapi option -here, we'd go for the --with-krb4, and made sure that our -converter daemon was running.
-To be able to use GSSAPI/Kerberos V -with CVS, you will have to add the appropriate service key into the -Kerberos database:
-kadmin.local -q "addprinc -randkey cvs/<FQDN>@<YOUR KERBEROS REALM>" -kadmin.local -q "ktadd cvs/<FQDN>"
-As you can see, the service name for CVS, are... Right, cvs!
-This is currently unverified by me, but -this is supposed to be the way it's done...
-To -have the Cyrus IMAP and POP3 server use GSSAPI (SASL) to authenticate -the user, we need the source of the Cyrus IMAPd/POP3d package -(apt-get source cyrus-imapd). And to build, these are the -options to configure:
-[I'm currently trying this out, come back in a few days]
-For non-Debian systems, these are the full configure options:
-[I'm currently trying this out, come back in a few days]
See Cyrus -IMAP/POP Howto:Cyrus IMAP Configuration and imapd.conf(5) for -more about this.
-To -be able to use GSSAPI/Kerberos V with IMAPd/POP3d, you will have to -add the appropriate service keys into the Kerberos database:
-kadmin.local -q "addprinc -randkey imap/<FQDN>@<YOUR KERBEROS REALM>" -kadmin.local -q "addprinc -randkey pop/<FQDN>@<YOUR KERBEROS REALM>" -kadmin.local -q "ktadd -k /etc/krb5.keytab.cyrus imap/<FQDN>" -kadmin.local -q "ktadd -k /etc/krb5.keytab.cyrus pop/<FQDN>" -chown cyrus /etc/krb5.keytab.cyrus
-The keytab above is used in the wrapper needed for GSSAPI/KerberosV -support:
-#!/bin/sh - -KRB5_KTNAME=/etc/krb5.keytab.cyrus -export KRB5_KTNAME -exec /usr/sbin/imapd.real $@
Basicly the only thing that needs to be done with these two -packages are rebuilding (ie, configure and make) them, -to get SSL/TLS support. For those of you that are running Debian -GNU/Linux, execute this command
-apt-get source libpam-ldap libnss-ldap
-and the source of the two packages will be downloaded and unpacked in -the current directory.
-To create the two Debian GNU/Linux packages, execute this command -(we only have to rebuild them to have them recognize that we have the -installed OpenSSL development package files)
-find -maxdepth 1 -type d -name 'lib*ldap-*' -exec sh -c 'cd {} && debuild -rfakeroot -uc -us' \;Now it's just a matter of executing the following command to -install them:
-dpkg -i lib*ldap_*.deb
This is currently unverified by me, but -this is supposed to be the way it's done...
-Have compiled samba-2.2.0.final with the following options. I'm -currently trying to configure samba. Using 'security = user' -and 'encrypt passwords = no' don't work at all, and using -encrypted password don't either (it bypasses the auth mechanisms).
---with-krb5 ---with-ssl ---with-sslinc=/usr/include/openssl
-According on a mail on the kerberos mailinglist, Microsofts -Step-by-Step -Guide to Kerberos 5 (krb5 1.0) Interoperability should be -interesting to read... You be the judge, I haven't bothered to read -it fully yet :).
-It seems that the LDAP support in samba 2.2 isn't working at all. -Have downloaded samba -TNG via CVS, hopefully that will work...
---with-fhs ---prefix=/usr ---sysconfdir=/etc ---with-privatedir=/etc/samba ---with-lockdir=/var/state/samba ---localstatedir=/var ---with-netatalk ---with-smbmount ---with-pam ---with-syslog ---with-sambabook ---with-utmp ---with-readline ---with-krb5 ---with-ssl ---with-sslinc=/usr/include/openssl ---with-ldap ---with-utmp
make SMBLOGFILE=/var/log/smb NMBLOGFILE=/var/log/nmb all smbtorture rpctorture debug2html
I have this working just fine on my live server, and it have been -working great (better than expected!) for about three months now. -From the occasional glitch when I started to understand what exactly -AFS is, I now have all my users, my web directory and whole of my FTP -support directory on AFS.
-There's many good things about AFS, and one that I've started to -like more and more, is that root is no longer almighty! Root have (at -least default) absolutely NO rights in AFS space! It's all about -tickets (Kerberos V) and tokens. The ACL (Access Control List) of the -directory decide who have access to what, not the system UID (User -Identification Number).
-AFS also come with 'replication support' as standard, so adding -more servers is a good thing. And easy to, from what it seems.
-To get OpenAFS up and running with Kerberos V (OpenAFS only works -with Kerberos IV as standard), there is some additional software's -necessary besides the OpenAFS sources. These are the OpenAFS PAM -module and the the special OpenAFS/KerberosV support software's.
-Getting OpenAFS and the associated PAM/KRB5 softwares to compile -under Debian GNU/Linux 2.2 (code name Potato) have been proven to be -very difficult. There's a lot of build dependencies that have to be -fulfilled and very few of the packages required exists for Potato. I -have therefor left out the building of all these packages. If you -really want to build for Potato, you will have to figure out how to -build those yourself.
- - - - -OpenAFS -KerberosV support software
-Building -OpenAFS KerberosV support software
-Installing -OpenAFS KerberosV support software
-Configure -OpenAFS KerberosV support software
- -Building -and Installing the OpenAFS PAM module
- - - -Putting -the AFS service key into the AFS KeyFile
- - -Setup -the cell configuration files
-Getting -a Kerberos ticket and a AFS token
- -Testing -the OpenAFS softwares
-Testing -OpenAFS KerberosV support software
- -The source package for OpenAFS is just simply called 'openafs' -so download the source, using the command
-apt-get source openafs
-I have not needed to make any modifications to these packages, they -are fine as is. These are the options that the Debian GNU/Linux -package is using to configure the OpenAFS sources:
-afslogsdir=/var/log/openafs ---with-afs-sysname=$(SYS_NAME) ---disable-kernel-module ---prefix=/usr ---sysconfdir=/etc ---libexecdir=/usr/lib ---localstatedir=/var/lib
-The variable SYS_NAME is delivered from the output of the /bin/arch -command (in the util-linux package). For my Sun SPARC Station -4, this will equal sparc_linux22. Strangely enough, this seems -to be the system name even if I use a 2.4 kernel. I think I must look -into this more...
-To build the package on a Debian GNU/Linux box, the command
-debuild -uc -us -rfakeroot
-is used. If not running a Debian GNU/Linux box, execute the command
-make dest
When the build of the sofware is done, there will be a -openafs-modules-source package (in my example, for the version -I built, this file will be called -openafs-modules-source_1.2.3final2-3_all.deb). -This is the source to the kernel module, which is needed to give -OpenAFS support to the kernel. The module for the kernel is built by -unpacking the file openafs.tar.gz which gets installed into -/usr/src when installing this package. This file have to be -unpacked from the /usr/src tree for the make-kpkg -command (which is in the kernel-package package.
-To create a Debian GNU/Linux package for the kernel and for the -OpenAFS module, issue the following command inside the kernel -source tree of your choice.
-make-kpkg -uc -us configure buildpackage modules_image
-You will have to have the kernel configured using either make -config, make -menuconfig or make xconfig depending on favorite -choice. My personal favorite is the second one, make menuconfig. -Graphically enough for me :)
-The buildpackage option creates the kernel packages, so -that can be lefout if you don't want/need a package for your kernel.
-When the modules_image have finished, it will leave a
-openafs-module-KERNELVERSION_OPENAFSVERSION_SPECIALVERSION_ARCH.deb
-file in /usr/src. For my Sun SPARC Station 4, trying to build -my first 2.4 kernel on this architecture, this file will be named:
-openafs-modules-2.4.18_1.2.3final2-5+10.00.Custom_sparc.deb
-and that is installed using dpkg (with the option -i). -If not using Debian GNU/Linux, the package is installed when you -issued the command make dest.
-The packages that have to be installed are:
-|
- All hosts - |
-
- Development Host - |
-
- Server Host(s) - |
-
|---|---|---|
|
- openafs-client - |
-
- libopenafs-dev - |
-
- openafs-dbserver - |
-
|
- openafs-modules-XX-YY - |
-
- openafs-modules-source - |
-
- openafs-fileserver - |
-
|
-
|
-
-
|
-
- openafs-kpasswd - |
-
The development packages only have to be installed on the host -where all the packages are built, not on the client/server hosts -themselves. The libopenafs-dev package is needed by all -software's that is going to be compiled to use some functionality -that OpenAFS provides. That include the OpenAFS -KerberosV support software and the OpenAFS -PAM module below.
-Before we continue with configuring OpenAFS, we need some -supplementary commands since we're using Kerberos V. So these have to -be built first.
-OpenAFS only comes with Kerberos IV (four) support. We need this -software to be able to use the Kerberos V (five) database, which was -the very first thing we did, and not have to have two -databases (the Transarc KA server which comes with OpenAFS and the -Kerberos V server) for user authentication/authorization.
-The source package for this is called openafs-krb5, and are -configured using the following configure options:
---prefix=/usr ---with-krb5=/usr/ ---with-afs=/usr
-Building the openafs-krb5 package is done with debuild -as always (see above for more information). The software is built -using make on a non Debian GNU/Linux box...
-The build process will create the openafs-krb5 package, and -is installed using dpkg. On a non Debian GNU/Linux box, issue -the command make install.
-No configuration of the OpenAFS Kerberos V migration kit have to -be done. Instead of using klog to get a AFS token, one uses -aklog instead. This is (usually) done by the OpenAFS PAM -module, but not always, so use aklog after getting a Kerberos -V ticket.
-This package is intended to be used by PAM aware programs getting -a AFS token, and requires aklog which is in the OpenAFS -KerberosV support software. Use it as any other PAM module.
-The source for this is called libpam-openafs-session, so a
-apt-get source libpam-openafs-session
-is needed to get source for the package. Using the same command as -when we were building OpenAFS, we will end up with the package -libpam-openafs-session. This package is installed using the -command dpkg -i (as ANY package is installed on a Debian -GNU/Linux box is :).
-Building and installing this software on a non Debian GNU/Linux -box, issue the command make and then make install.
-The installation of this software will result in a file called
-/lib/security/pam_openafs_session.so
-on a Debian GNU/Linux box, and
-/lib/security/pam_openafs-krb5.so
-on a non Debian GNU/Linux machine. Why the files are named -differently, is something you will have to ask the maintainer for the -Debian GNU/Linux package about. I have not bothered with this, so be -my guest asking him :)
-The is no configuration that needs to be done for this package, -it's just a matter of using it. This is done in the service file, -located under /etc/pam.d. For example, using the pam_openafs_session -module with ssh, this is what my /etc/pam.d/ssh file looks like (use -as directed :)
-auth required pam_nologin.so -auth required pam_env.so -auth sufficient pam_krb5.so forwardable -auth required pam_unix.so try_first_pass shadow -auth required pam_issue.so issue=/etc/issue.net - -account sufficient pam_krb5.so forwardable -account required pam_unix.so try_first_pass shadow - -password required pam_krb5.so forwardable - -session sufficient pam_krb5.so forwardable -session optional pam_openafs_session.so -session required pam_unix.so -session optional pam_lastlog.so -session optional pam_motd.so
-How much of this that's actually needed, is up to you to decide and -verify, but this works for me. What this file do, is verify the -password against the Kerberos V database, OR if that fails, against -the /etc/shadow file (the shadow option). When that is -done, it will obtain a AFS token when the session starts.
-We should really only add this module to services that have an -interactive session, such as ssh, login, ftp -etc. NOT something like the IMAP and POP services (unless you deliver -mail to the users home directory that is).
-There is some things that needs to be setup before we can use AFS. -One such thing is to create a service principal for AFS. This is in -the form afs@REALM. Usually your AFS cell is the same as your -Kerberos realm, just in lower case. So since my Kerberos realm is -BAYOUR.COM, I decided to use -the AFS cell name of bayour.com. -If your AFS cell name don't match your Kerberos realm like this, you -will have to use the AFS principal form afs/CELL@REALM (like: -afs/google.com@BAYOUR.COM). Creating the service principal, -and putting it in a keytab is done like this:
-kadmin.local -q "ank -randkey afs" -kadmin.local -q "ktadd -k /etc/krb5.keytab.afs afs"
We need AFS to recognize the service principal, and that is done -by putting the service key into the AFS KeyFile. This is done with -the command asetkey like -this:
-asetkey add 4 /etc/krb5.keytab.afs afs
-The number 4 here is the -keynumber that got created in Creating -a AFS service key so make sure you took note about this. If you -forgot which number it is, you can use the following command line to -find that out:
-kadmin.local -q 'getprinc afs' | grep ^Key
AFS uses a special directory and file structure, very different -from the ordinary UN*X way of storing files. We need a special -partition to be mounted on /vicepX -where X is a letter from a to z (and from aa to zz – see the -OpenAFS -documentation for more about this). There have been indications -that this partition can not be on a journaling file system (such as -JFS, XFS and Ext3) on Linux.
-If you don't have a free partition, -you can settle for a file that is mounted using the loop -module. Create such a file like this:
-dd if=/dev/zero of=/var/lib/openafs/vicepa bs=1024k count=32 -mke2fs /var/lib/openafs/vicepa -mount -oloop /var/lib/openafs/vicepa /vicepa
We need to have our IP address and cell name in both the file -server cell configuration file and -in the Client configuration file. If this is to be both a client and -server, that is. Usually the very first machine is both, but does not -need to be. In Debian GNU/Linux, the configuration files is -/etc/openafs/server/CellServDB -for the file server, and /etc/openafs/CellServDB -for the client. Make sure our IP address and cell name is located at -the top of these files. The -format of this file is:
->CELLNAME -IPADDRESS
-So for my test environment, these files begin like this:
->bayour.com -192.168.1.4 # tuzjfi.bayour.com
-We also need to specify which cell this is and the configuration file -for this is /etc/openafs/ThisCell. -In my example, my AFS cell name is bayour.com, -so I enter this into this file.
-When this is done, we can start the fileserver with the command
-/etc/init.d/openafs-fileserver start
-Now it's time to setup and start the other services that we need for -this to be a proper file and database server for AFS. I will only -list them right of, no explanation.
-bos addhost tuzjfi tuzjfi -localauth ||true -bos adduser tuzjfi turbo -localauth -bos create tuzjfi ptserver simple /usr/lib/openafs/ptserver -localauth -bos create tuzjfi vlserver simple /usr/lib/openafs/vlserver -localauth -bos create tuzjfi fs fs -cmd /usr/lib/openafs/fileserver -cmd /usr/lib/openafs/volserver -cmd /usr/lib/openafs/salvager -localauth -vos create tuzjfi a root.afs -localauth
-In these examples, I have specified tuzjfi -which is my test platform's hostname. Replace with your -hostname! Also, the paths to the commands (/usr/lib/openafs/) -might differ from your installation, so take note!
-Also, turbo in these commands -is my principal name which is to be the administration user for my -AFS cell. Exchange with your principal name!
-When this is done, we can start the -AFS client which mounts the /afs tree which is where we access -our AFS file system. This is done with the command
-/etc/init.d/openafs-client force-start
-Do not under any any circumstances access anything under /vicepX! -It is in special AFS format, and any changes might render your AFS -system unusable!-
To be able to create volumes (which can roughly be translated to -partitions – storage space in AFS), we need a token for the -administration user (which we created above). This is done by issuing -the command (exchange with your -principal name):
-kinit turbo && aklog
The following command sequences will create the necessary volumes -with the proper access control. Don't forget to change all -occurrences of 'tuzjfi' to -your hostname, and all references to 'bayour.com' -to your cell name. The 'bayour' -entries is quick access links to the cell mount point, and it's up to -you if you want/need them...
-fs sa /afs system:anyuser rl -vos create tuzjfi a root.cell -localauth -fs sa /afs/bayour.com system:anyuser rl -fs mkm /afs/.bayour.com root.cell -cell bayour.com -rw -fs mkm /afs/.root.afs root.afs -rw -ln -s /afs/bayour.com /afs/bayour -ln -s /afs/.bayour.com /afs/.bayour -vos addsite tuzjfi a root.afs -localauth -vos addsite tuzjfi a root.cell -localauth -vos release root.afs -localauth -vos release root.cell -localauth
To verify that it is possible to get a AFS token from the OpenAFS -server(s), you must have a Kerberos V ticket. This is done using the -command kinit. If kinit where successful in getting a -ticket, it will look something like this when looking at the ticket. -Viewing what tickets you have is done with the command klist -without parameters, like this:
-[papadoc.pts/1]$ kinit -Password for turbo@<MY_KERBEROS_REALM>: -[papadoc.pts/1]$ klist -Ticket cache: FILE:/tmp/krb5cc_turbo -Default principal: turbo@<MY_KERBEROS_REALM> - -Valid starting Expires Service principal -05/31/02 09:59:23 05/31/02 19:59:19 krbtgt/<MY_KERBEROS_REALM>@<MY_KERBEROS_REALM> - - -Kerberos 4 ticket cache: /tmp/tkt1000 -klist: You have no tickets cached -[papadoc.pts/1]$
-Now it's time to get the AFS token:
-[papadoc.pts/1]$ aklog -[papadoc.pts/1]$ tokens - -Tokens held by the Cache Manager: - -User's (AFS ID 1) tokens for afs@<MY_AFS_CELL> [Expires May 31 19:59] - --End of list-- -[papadoc.pts/1]$
-As you can see, if everything goes well, aklog won't output -anything. This is in good old UNIX style. If it's okay, why say -anything :)
-When the Testing -OpenAFS KerberosV support software have been successful, it is -time to verify that the PAM module works. This is done by trying to -login with a service that is OpenAFS aware. In Configure -OpenAFS PAM module we enabled the ssh service to use -OpenAFS, so we try to login through ssh.
-For those that are converting an existing setup (be it users -located in /etc/passwd, -NIS/NIS++, NDS etc) it would be nice if there -where a 'execute and continue' solution to on the fly convert the -current database while keeping the users passwords. But there is no -such thing, and never will (in most cases anyway). This is because -most, if ALL 'password storage systems' have some means of encrypting -the password. And most of them is a one-way encryption, meaning that -it's not possible to decrypt it (only force a check, trying out -random password to see if it's a match).
-It is therefor necessary to either write a program that inserts -the users password into Kerberos (after a successful authorization) -or you can ask each and every user to come to you to receive/change -their password. On a big system, this is just not possible, so there -you have to go with option one.
-There is however a third alternative, although in my eyes not the -perfect one... It is to only include the NEW users in this new -system, and slowly migrate (forcing a password change) the existing -ones.
-I went for the first alternative, because my users are very spread -geographically, so it was not possible for them to come to me for a -new password, and I don't like to talk passwords over the phone. Some -of my users I never meet. So what I did was I modified the pam_ldap -module to insert the users clear text password into the -clearTextPassword attribute in the LDAP database, then after three -months I did a search for users with a clearTextPassword -entry, and use that when changing the users password in the Kerberos -server. Something like this:
-ldapsearch -LLL 'cleartextpassword=*' clearTextPassword krb5PrincipalName
-This will give us something like this
-dn: uid=turbo,ou=People,dc=papadoc,dc=bayour,dc=com -krb5PrincipalName: turbo@<MY KERBEROS REALM> -clearTextPassword: ThisIsMySecretPasswordInClearTextFormat
-This will however also give us the passwords that are set to 0 or *. -We must initially set it to some value, because OpenLDAP does not -allow us to insert a NULL value. You either use an attribute (which -requires a value) or you don't. So you'll have to write a script that -parses the information, filtering out those that don't make sense.
-Then, for each value retrieved, modify the krb5PrincipalName -with the value of clearTextPassword. If you're paranoid, or -don't want this information in the database, just modify each LDAP -object, removing the clearTextPassword attribute and -the corresponding object class.
-To change a password in the Kerberos database in a script, this is -how to do it
-kadmin.local -q "cpw -pw <USER PASSWORD> <USER PRINCIPAL>"
-The magic here is the -pw option.
-Instead of putting the packages on hold, one can increase the -version number in a 'secure' way. That is, one makes the version -number such that it will always be higher than the default Debian -package number, that way it won't be upgraded/overwritten by a -default Debian version. To do this, one edits the file -debian/changelog. If we take the entry I made for the -cyrus-sasl packages as an example, the top of the changes file will -look like this:
-cyrus-sasl (2:1.5.24-5.TF.3) unstable; urgency=low - * --without-des. It seems that's part of the Krb4 packages, not Krb5... - - -- Turbo Fredriksson <turbo@debian.org> Sun, 1 Apr 2001 19:10:58 +0200 - -cyrus-sasl (2:1.5.24-5.TF.1) unstable; urgency=low - * Can't do search with '-H ldaps:///', but to the non-ssl works. - Norbert Klasen <klasen@zdv.uni-tuebingen.de> say: - Seems to be some signend/unsigned arithmetic mismatch. - => Patched plugins/gssapi.c - - -- Turbo Fredriksson <turbo@debian.org> Wed, 7 Mar 2001 15:30:00 +0100 - -cyrus-sasl (2:1.5.24-5.TF) unstable; urgency=low - * Build with the following parameters to configure: - --enable-gssapi Needed to have kerberos auth - --with-des Even better to have I guess - - -- Turbo Fredriksson <turbo@debian.org> Tue, 27 Feb 2001 17:34:33 +0100
-The important number here is 2: before the actual number -(1.5.24-5). This number will not be seen when doing a
-dpkg -l libsasl-modules
-but only when doing
-dpkg -s libsasl-modules | grep '^Version: '
-The .TF is added just to make sure that I remember that it's a -home made packages. It will however work just fine without it. If I -remove the 2: and just have .TF, the package will be -upgraded by any package with a version number higher than 1.5.24-5. -That can be, for example 1.5.24-5.1 -which would indicate the first Non Maintainer upload. A fix for this -package, by the maintainer, would have the number 1.5.24-6 -which would also overwrite my package (if I didn't have the 2:). -By setting myself (the Turbo Fredriksson <turbo@debian.org> -entry) I will be listed as the maintainer when viewing the status of -the package (dpkg -s libsasl7 for example). That is also a -indication that it is a home made package. To make this a 'fully -fledged Debian package', instead of issuing the command debuild --uc -us -rfakeroot i will remove the -uc -us (which is -unsigned source and changelog. Without those two parameters, the -package will be signed with my PGP (or GPG) signature. In emacs, -there's the debian-changelog-mode command, that will give you -a proper editing mode for changelogs. The mode is in the emacs -package.
-Nothing works right out of the box. Sad to say, but that's the way -it is. I have tried to list as many of the most common problems here, -but I'm still working on this, so please contribute!
-Problems -when the KVNO don't match up.
- - - - - - - - -
-
If you can't have pam_ldap to -authenticate you, this is most likely a problems -with ACL's
-A problem with the kvno can be verified by executing the klist --k command. If I do it on my machine, I will get this output:
-Keytab name: FILE:/etc/krb5.keytab -KVNO Principal ----- -------------------------------------------------------------------------- - 4 kadmin/admin@<MY KERBEROS REALM> - 4 kadmin/admin@<MY KERBEROS REALM> - 4 kadmin/changepw@<MY KERBEROS REALM> - 4 kadmin/changepw@<MY KERBEROS REALM> - 5 ftp/<MY FQDN>@<MY KERBEROS REALM> - 3 host/<MY FQDN>@<MY KERBEROS REALM> - 3 host/<MY FQDN>@<MY KERBEROS REALM> - 4 ldap/<MY FQDN>@<MY KERBEROS REALM> - 5 ftp/<MY FQDN>@<MY KERBEROS REALM> - 4 ldap/<MY FQDN>@<MY KERBEROS REALM>
-The reason there are two of a kind, is because they use different -crypto algorithms. To check this, use the command
-klist -keK | grep ldap
-(we're only interested in the ldap service key at this point), it -will return something like this:
-4 ldap/<MY FQDN>@<MY KERBEROS REALM> (DES cbc mode with CRC-32) (0x<A HEX NUMBER>) - 4 ldap/<MY FQDN>@<MY KERBEROS REALM> (Triple DES cbc mode with HMAC/sha1) (0x<A HEX NUMBER>)
-To verify that the kvno for the ldap service key is correct, issue -the command
-kvno ldap/<MY FQDN>@<MY KERBEROS REALM>
-This is what I get back:
-ldap/<MY FQDN>@<MY KERBEROS REALM>: kvno = 4
-As you can see, they match up now. However, I wasted two whole days -on looking for a problem with OpenLDAP/SASL, when it was in fact a -problem with this number.
-If the number received from kvno -is lower than the number received from klist, one have -to remove all the service keys and principal of that service and then -add them again. I doubt that this is the correct/best way to do it, -but it works for me (probably since this is a fresh install, without -a big DB etc.).
-kadmin.local -q "ktrem ldap/<FQDN> all" -kadmin.local -q "delprinc ldap/<FQDN>" -kadmin.local -q "addprinc -randkey ldap/<FQDN>" -kadmin.local -q "ktadd -k /etc/krb5.keytab ldap/<FQDN>"
-If the number from kvno is -higher than the one from klist, just add the service -key to the keytab, removing (?) all the old ones. Use ktadd -below until the numbers from both klist and kvno match -up.
-kadmin.local -q "ktadd -k /etc/krb5.keytab ldap/<FQDN>" -kadmin.local -q "ktrem ldap/<FQDN> old"
-Update,
The company have three machines, dns1, dns2 and -kattla (the dragon from Astrid Lindgren's Lionheart). Kattla -is the LDAP/Kerberos server, and dns1 and dns2 is the -DNS servers.
-I added the host/<FQDN> principals for the three -machines in kattla's keytab. When trying krsh/ktelnet -to dns1, the machine complained about 'no such file'. Using -strace I found that kshd/ktelnetd where looking -for the keyfile /etc/krb5.keytab. I had hoped that I wouldn't -need that (since I thought/had hoped that all that would be in the -KDC). Now, I wouldn't want to copy the whole keytab from kattla -(since that included ALL server's host keys). So I executed
-ktadd -k /etc/krb5.keytab.dns1
-on kattla and copied that file to dns1 as file -/etc/krb5.keytab. Logical conclusion? I thought so. But that's -where I got the same problem as before. The keytab on dns1 had -version 4, but I had tried connecting and got version 3 in my ticket -(that is, doing kvno host/dns1.DOMAINNAME on my own -server, revealed version 3). This was a real nuisance. I couldn't -figure out a way to have the same version in the two files.
-Doing some testing, I tried executing kdestroy and then -kinit again. That helped!
-Now, I'm not sure if I really need all the host keys in kattla -but as said, I'm not very good at Kerberos administration yet...
-You get this error when SASL isn't configured/working properly. -Please see the simple bind examples on -when to know if SASL works or not.
-This is most likely because you are trying to do a -simple/anonymous -bind, but aren't using the correct parameters to -ldapsearch/ldapadd/ldapmodify. Try adding -x -to the command line. If you are using -x, but still get this -error, it might be that your ACL's don't allow viewing the base dn -(where the supportedSASLMechanisms attributes are). -
-This error messages will look like this
-# ldapsearch -h localhost -p 389 -I -b "" -s base -LLL supportedSASLMechanisms -SASL/GSSAPI authentication started -SASL Interaction -Please enter your authorization name: -ldap_sasl_interactive_bind_s: Local error
-This is because you don't have a Kerberos TGT (Ticket Granting -Ticket). Just execute kinit to get a ticket.
-Will Day (on the OpenLDAP-Software list) also reported that he got -this problem because he hadn't specified the FQDN host name of the -LDAP server, which led it to default to localhost, for which it -couldn't get a Kerberos ticket.
-I migrated from OpenLDAP1 to OpenLDAP2. Having used OpenLDAP1 for -over a year on a number of production servers, going to OpenLDAP2 was -quite a nuisance. The first problem I got was that the old database -wouldn't load at all (which was a problem with the non-existence of -proper schemas). The other, and the one that gave me the most grief -was the ACL's. It seems like OpenLDAP2 is much more strict about the -correctness and order of the ACL's. So it's important to have all the -stuff in the right order and in the right place. By a lot of trial -and error, I came up with The -OpenLDAP access file you see in this document. It might be the -most perfect, but at least it works. If all other fails, try my ACL -and see if that work. If it does, start modifying that to get the -restrictions you want. I'm still working on perfecting this list, so -come back every now and then to see if I have any updates... -
-Otherwise, don't hesitate to ask on the OpenLDAP-Software -mailing list or if you need to make your own schemas, have a look -at the OpenLDAP2 -Admin Guide:Schema Specification.
-slapadd: could not parse entry (line=<SOME LINE NR>)
-This (usually ?) means that one (or more) of the attribute you are -trying to use, don't exist in any schema. For example, I kept getting -this when trying to use the objectclass krb5Principal. The -attribute I meant to use where krb5PrincipalName -but a typo slipped in the LDIF, so it was named krb5Principal -instead...
-NOTE: The line it complains about, is the first empty line -after the object (that is, the empty line between -the two adjacent objects) in the LDIF file. There is no problem on -the line itself, but the object above the empty line. To find -exactly what attribute it complains about, copy the whole (and ONLY -the) troublesome object to a separate LDIF file, and try to just add -that object. Then use -d -1 when executing slapadd.
-Solution: Correct attribute name
-slapadd: dn="<SOME DN>" (line=<SOME LINE NR>): attribute not allowed
-This (usually ?) means that you have attribute which is not a MUST -or MAY attribute in the objectclasses you are using.
-Solution: Find the objectclass this -attribute belong to, and add that to the LDIF.
-slapadd: dn="<SOME DN>" (line=<SOME LINE NR>): missing required attribute
-This should be quite obvious. You are trying to use a objectclass, -but you have not specified one (or more) of the MUST -attributes. For example, when trying to modify my old DB (replacing -the attribute userPassword), I wrote a perl script that parsed -the old LDIF, and replaced all the userPassword: {crypt}... -values with userPassword: {KERBEROS}user@<MY KERBEROS REALM>. -Some of the objects (especially the AdminDN object) should not be -replaced, it should retain the crypted value. But my script was -buggy, so the attribute where totaly removed. Those DN's used the -objectclass simpleSecurityObject which MUST have the -attribute userPassword.
-Solution: Add the missing REQUIRED (MUST) -attributes to the LDIF.
-For those of you running Debian GNU/Linux which thinks all this -about making your own package are daunting, or if you're just to lazy -to do it your self, you can always get the pre-compiled binaries from -me. I make no promises to keeping them up to -date, I'm deploying this on a live server, without access to a -development platform. Because of this, it's difficult to keep -downloading packages, remake them and then doing a install. IF -something breaks, it will break my live server!
-HOWEVER, if you thing it's about time I upgraded (ie, these -packages are WAY out of date) don't hesitate to send me a simple -and friendly 'nudge' mail, telling me to get my acts together! :)
-If you use Debian GNU/Linux and would like to use the packages -I've created, here's the line you should add one of the following -lines to the /etc/apt/sources.list file, and run the command -apt-get update to update the list of available packages.
-deb ftp://ftp.bayour.com/pub/debian local . -deb-src ftp://ftp.bayour.com/pub/debian local .
-These packages have such a higher version number, that they won't be -upgraded by the packages from the official Debian GNU/Linux FTP -sites. See the section about Bumping -the Debian GNU/Linux package version section of what I mean.
-Packages are available for the Intel processors and for Sun SPARC -only. Unfortunately I don't have any Alpha, PPC, m68k machines, so I -can't currently support these architectures. Using my source -packages, all you have to do is download them yourself, and compile -using debuild as directed elsewhere in this document...
--Table 1: Packages to install. Packages in italic is for -development only...
-The PAM/NSS modules above will come with SSL -and TLS enabled, if downloaded from me. CVS, SSH, sudo and -PostgreSQL is compiled with GSSAPI/Kerberos support (which the -original packages are not).
-| - - | -- - | -- - | -- - | -
| - - | -- - | -- - | -
-
|
-
|
- Berkeley DB - |
- - - | -- - | -
-
|
-
Kerberos -replacement software
- -Why should we use so much encryption -and such a complicated setup, when user information (inclusive the -password) works so great together with libpam-ldap? Well, basicly the -keyword here is growth (and maybe security, even though many isn't -that paranoid as me :). To illustrate what I mean by growth, I will -show you the system I use, and the (small) differences to a system I -did for the company I worked for.
-I only have one machine -(called papadoc for 'historical' reasons). This system 'only' hosts -five domains, with about 50 users (most of them family and friends). -Having users (and all there relevant information, such as UID/GID -number, home directory, passwords, mail address, mail aliases etc, -etc) in an LDAP database, using libpam-ldap to help authentication, -was my main reason for LDAP. Be able to structure users in a -tree-like fashion, with the possibility to have a fail-over system -(an extra LDAP database, a so called 'replica') is a very nice -feature. But I'm not going to tell you much about the reasoning for -LDAP in the first place, there are other, better HOWTOs/FAQs etc out -there.
-At my previous job, we had -the exact same system, but with a lot more domains, a lot more users -and finally, a lot more machines. Since this was an ISP, redundancy -is vital. So a replica was quickly setup (so that we could have an -online backup of the user/mail database). Using round-robin (poor -mans load-balancer) reduced the load of the master database.
-Here came (and comes for me to when, not -if, I add a second DB or a second machine, be it shell, mail server -or other type of system) the first big gripe I had with OpenLDAP1 (at -the time of this writing, I'm still running OpenLDAP v1.2.11 on my -system, but are slowly migrating to OpenLDAP2 according to this -document). Since OpenLDAP1 don't have built in support for SSL/TLS -(or any other secure authentication mechanism), all communication -between the master and slave (or by any of the other servers on the -network, about 50 or so at last count) is done in clear text! It's -quite easy for someone on the same network segment (yes, EVEN if it's -a switched network!) to listen on the communication and retrieving -all the passwords etc. This can be avoided to some extent by using -external programs to do the SSL tunnelling, such as stunnel. -My experience with this is that it isn't that reliable. Stunnel dies -every now and then, and it's difficult to automate the process. -Another big gripe I had, was the fact that the replication DN and -password (options replica and bindmethod) have to be -stored in clear text in the configuration file. And the third thing -is that libpam-ldap is doing the authentication in clear text as -well. This isn't true any more (latest version, v99), since it can be -compiled with SSL support. -
-Using only PAM/LDAP, an -authentication happens something like this:
-login -> PAM -> PAM/LDAP -> LDAPServer
-Everything between login and the LDAP server is clear text -communication.
-Also imagine adding a second system, or putting the LDAP serveri -on it's own machine. All logins (be it login/imap/pop/ssh/ftp etc) is -verified in clear text between the system and the machine where the -LDAP database is residing. Now we have tree machines, the actual -server, the master LDAP database and the slave database (or a second -login system). Login in this text does refer to a software -that does some kind of user authentication, not the program -login. All communication back and forth is done in clear text, -giving anyone (basically) the chance to discover any password.
-But why store the user passwords in the -Kerberos database in the first place? Why not just use it for/when we -need a replica (or replicas)? We only really need Kerberos to have a -service key, right? Nope, not quite true. The answer is quite simple -actually. Kerberos is designed solely as a secure password storage -database (with a secure authentication protocol) on an insecure -network. And contrary to popular belief, a local network IS NOT -to be considered a secure environment! LDAP, on the other hand, is -designed to be a database for distributed, public information. -
-Put simply, passwords are more -secure in a Kerberos database, than in a LDAP ditto. Besides, with at -least MIT Kerberos, there are special, kerberised binaries that -replace the original ones. This will give you a more secure way of -authentication (you don't have to go through PAM etc). The software -to let this be possible, is libnss-ldap. It will get all the -public information (such as UID/GID numbers, home directory etc, etc) -from LDAP, but look at the Kerberos server fo the password. Thus, all -sensitive information is encrypted, even before leaving the binary. -The binaries/services that can be replaced right-out-of-the-box is -login, ftpd, ftp, rlogind, rlogin, -rshd, rsh, telnetd, telnet and passwd.
-Oki, I guess I have convinced you why it is -imperative to use SSL/TLS, and we have discussed some of the nice -things about Kerberos. But why use SASL? Where does that come into -play? Well, when using the combination SASL and KerberosV (SASL can -use other means of storing password, Kerberos is just my choice), we -can use a KerberosV keytab to authenticate the master database with -the slave with. Thus, no need for any passwords etc in the slapd -configuration file. See Creating -a replication principal for more about this. The reason we use -SASL, is because SASL is designed as a middle-layer. That is, -it sits between the LDAP server and the authentication system (in -this case, Kerberos). As mentioned, SASL could just as well use any -other authentication system, such as the default UNIX way -(/etc/passwd, /etc/group etc), it's own database file (usually -/etc/sasldb) etc. In theory, it can even use a LDAP database (which -might be a little redundant, and difficult do obtain, with out -creating authentication loops). With a little code writing, it's even -possible to use a KerberosIV server. Some use libpam-smb to -look-up the user/password on a Windows PDC. Simply, SASL is -designed as a modular authentication protocol, and it's usage is as a -middle-layer. The difference between SASL and PAM (which in many -ways resembles each other) is that SASL have integrity and -confidentiality protection, while PAM don't have anything like that.
-With all this stuff we have -discussed (LDAP, SSL/TLS, SASL and Kerberos), we get this flow of -authentication (remember the flow, -libpam_ldap?):
-login -> PAM -> PAM/LDAP -> SSL/TLS -> SASL -> LDAP -> KerberosV
-If we only want the UID/GID number etc (like when doing ls -l -etc), the communication stops at the LDAP server, and don't continue -with SASL/Kerberos.
-There are still many hops the -information have to travel, many of them not that very secure (like -PAM). So to minimise that, we could replace many (preferably all) of -the programs with proper Kerberised binaries, see the section about -Kerberos -replacement software. That will create the following -authentication flow.
-For public information:
-login -> NSS -> NSS/LDAP -> LDAP
-and for password authentication:
-login -> Kerberos
-Much cleaner, don't you think? A nice feature would be to have -SSL/TLS to the libnss-ldap software, but I'm not quite that -paranoid yet :). It might already have that option, I just haven't -bothered to check...
-UPDATE: I just recompiled the libnss-ldap package, -and if the OpenSSL development package are installed, libnss-ldap -will come with SSL/TLS.
-In the package listings below, the package names in bold is -the one you need if installing the rest of my packages (ie, just -using the packages, not building anyting yourself) and the ones in -italic is needed for building you own packages of the other -software. If you are very daring, have a look at the Shortcuts -section.
-15/8 2001: Build and install exactly like you did on -Building -and installing Berkeley DB.
-Unfortunately, Sleepycat have changed some of the interface, so -that OpenLDAP will have to be rewritten slightly to use the new -version of BerkeleyDB.
-THAT IS, OPENLDAP WILL NOT WORK WITH THIS VERSION OF -BERKELEYDB!-
28/5 2001: Built v0.9.6a from the Debian GNU/Linux -sources. See OpenSSL.
-These are the packages that got built:
-openssl -libssl0.9.6 -libssl-dev -ssleay
15/8 2001: Built v0.9.6b from the Debian GNU/Linux -sources. See OpenSSL.
-28/5 2001: According to a mail on the -OpenLDAP-Software mailinglist:
-At 05:17 PM 5/22/01, Mark Whitehouse wrote: -I am experiencing some database corruption problems with back-ldbm using -Berkeley DB 3.2.9. Any advances over this configuration would especially -interest me.-
This means that I will wait a while longer to upgrade...
-Also, OpenLDAP2 v2.0.10 and .11 depends on libdb3 (which is - only availible in unstable). Unfortunatly, many packages depend on - libdb2, and they have to be upgraded as well...
-12/8 2001: I'm currently testing this version, and -it works fine in a CHROOT jail.
-I'll try to upgrade my machine the next couple of hours/days and -let you know...
-What I can say right away is, that I tried to compile this - yesterday, and when I installed the package, I got segfault from - slapd. My thoughts is that it linked against TWO different versions - of OpenSSL. I've been fiddling with upgrading OpenSSL due to some - security alerts, and somehow the old developer packages was left - behind.
-This is what dpkg show me now:
-[papadoc.pts/4]$ dpkg -l | grep ssl -ii libssl0.9.6 0.9.6b-1 SSL shared libraries -ii libssl09 0.9.4-5 SSL shared libraries -ii libssl09-dev 0.9.4-5 SSL development libraries -ii libssl095a 0.9.5a-5 SSL shared libraries -ii openssl 0.9.6b-1 Secure Socket Layer (SSL) binary and related-
The troublesome package where:
-[papadoc.pts/4]$ dpkg -l | grep ssl -ii libssl-dev 0.9.6b-1 SSL shared libraries-
So after I replaced the libssl-dev package with libssl09-dev, it - seems to work (at least OpenSSL isn't compiled in twice as before).
-16/8 2001: I just don't seem to get this to work. I'm still -working on it though, since I REALLY need it!
-21/11 2001: I finally got this version to work! You -will have to patch servers/slurpd/config.c. -This is what it looks like:
-diff -urN openldap-2.0.10/servers/slurpd/slurp.h openldap-2.0.10.new/servers/slurpd/slurp.h ---- openldap-2.0.10/servers/slurpd/config.c Mon Sep 18 18:08:08 2000 -+++ openldap-2.0.10.new/servers/slurpd/config.c Thu May 24 15:29:17 2001 -@@ -34,7 +34,7 @@ - #include "slurp.h" - #include "globals.h" - --#define MAXARGS 100 -+#define MAXARGS 500 - - /* Forward declarations */ - static void add_replica LDAP_P(( char **, int ));
-The patches you see in the Bugs -in OpenLDAP, v2.0.7 section is NOT needed -with this version. The only patch necessary is the one above -(servers/slurpd/config.c). Also, this patch is NOT -needed with OpenLDAP v2.0.18 -and later! I'm currently trying to install that, I'll let you know...
-21/11 2001: This worked right out of the box! Weird! -No patches had to be applied, I just compiled it according to the -section Building OpenLDAP v2.
-24/01 2002: This worked out perfectly! No need for -any patches etc. Just compile and install!
-Note that you should really install this, and not -anything earlier. There is a bug in version 2.0.19 (and earlier I -assume).-
06/02 2002: This worked out perfectly! No need for -any patches etc. Just compile and install!
-Just for the record, these are the changed files in the Debian -GNU/Linux package. Other than this, I made no changes...
-The debian/rules-
The debian/changelog-
26/03 2003: Same as previous version. Works great! -Same modifications as v2.0.22.
-The debian/rules-
The debian/changelog-
20/11 2001: Thanx to Allan Streib, I got some -updates on the new CurysSASL software:
-There is a potential security vulnerability in cyrus-sasl versions prior to 1.5.27. It is described at: http://xforce.iss.net/static/7443.php-
To close the vulnerability above, I downloaded version 1.5.27 from the cyrus FTP site. I found that the problem corrected by your patch 1 has been corrected in this version of gssapi.c. However the second problem (REALM being dropped in a GSSAPI SASL bind) is still there. But your second patch file could not be applied, as there are enough other changes to gssapi.c that patch(1) could not resolve the context. I created the attached patch which corrects the problem in the 1.5.27 release. To apply it, change to the plugins directory and enter:-
$ patch < cyrus-sasl-1.5.27-gssapi.patch-
26/03 2002: Rein Tollevik found a problem with -chain-crashing postfix-tls using SASL LDAP authentication. Without -this patch, all applications that both link to OpenLDAP and use SASL -(maybe through PAM) will segfault. Apply this patch by issuing the -command:
-patch -p1 < cyrus-sasl-1.5.27-sasl_allocation_locked.patch
04/03 2002: I'm currently looking into compiling this. These are -the changes between the 1.2.2 and 1.2.4 releases:
-Changes between 1.2.2 and 1.2.3 -Changes between 1.2.3 and 1.2.4
Just to make sure that there are no typos or that you haven't -misunderstood etc anything in my configuration examples, these are my -configuration files (they are however censored). With these files, -everything works like a charm. Replication, Secure searches and -updates, simple binds etc, etc... They might not be absolutely -optimised, but they work...
-|
- Start script - |
- - - | -
|
- Configuration file - |
- - - | -
|
- Access Control Lists file - |
- - - | -
|
- Start script - |
- - - | -
|
- Configuration file - |
- - - | -
|
- Access Control Lists file - |
- - - | -
|
- Name Service Switch configuration file - |
- - - | -
|
- Configuration file for LDAP NSS library - |
- - - | -
|
- Configuration file for LDAP PAM library - |
- - - | -
|
- LDAP configuration file - |
- - - | -
|
- KerberosV configuration file - |
- - - | -
|
- Tables for driving cron - |
- - - | -
| - - | -
|
- RFC1777 - |
- - - | -
|
- RFC1778 - |
- - - | -
|
- RFC1779 - |
- - - | -
|
- RFC1959 - |
- - - | -
|
- RFC1960 - |
- - - | -
|
- RFC1823 - |
- - - | -
|
- RFC 2596 - |
- - - | -
|
- RFC 2251 - |
- - - | -
|
- RFC 2252 - |
- - - | -
|
- RFC 2253 - |
- - - | -
|
- RFC 2254 - |
- - - | -
|
- RFC 2255 - |
- - - | -
|
- RFC 2256 - |
-
- A - summary of the X.500(96) User Schema for use with LDAPv3 - |
-
|
- RFC 2830 - |
- - - | -
|
-
|
-
-
|
-
|
- Readme - |
- - - | -
|
- RFC 2222 - |
- - - | -
|
- RFC 2245 - |
- - - | -
|
- RFC 2444 - |
- - - | -
|
- RFC 2829 - |
- - - | -
|
-
|
-
-
|
-
|
- Draft - |
- - - | -
|
- Draft - |
- - - | -
|
- Draft - |
- - - | -
|
- Draft - |
- - - | -
|
- Draft - |
- - - | -
|
- Draft - |
- - - | -
|
- Draft - |
- - - | -
|
- Draft - |
- - - | -
|
- Draft - |
- - - | -
|
- Draft - |
-
- Salted - Challenge Response Authentication Mechanism (SCRAM) - |
-
|
-
|
-
-
|
-
|
- Documentation - |
- - - | -
|
- Documentation - |
- - - | -
|
- Documentation - |
- - - | -
|
- RFC 1510 - |
- - - | -
|
-
|
-
-
|
-
|
- HOWTO - |
- - - | -
|
- HOWTO - |
- - - | -
|
- Readme - |
-
- Designing - an Authentication System: a Dialogue in Four Scenes - |
-
|
- RFC 1321 - |
- - - | -
|
- RFC 2052 - |
-
- A - DNS RR for specifying the location of services (DNS SRV) - |
-
|
- RFC 2104 - |
- - - | -
|
- RFC 2247 - |
- - - | -
|
- RFC 2849 - |
- - - | -
|
-
|
-
-
|
-
|
- IBM Redbook - |
- - - | -
©
Total number of access: -
- \ No newline at end of file diff --git a/lam/docs/ldap-linux.htm b/lam/docs/ldap-linux.htm deleted file mode 100644 index 10417b23..00000000 --- a/lam/docs/ldap-linux.htm +++ /dev/null @@ -1,280 +0,0 @@ - - - - --LDAP is a directory server technology that allows information such -as usernames and passwords for an entire site to be stored on a central -server. -This whitepapers describes how to set up a Linux workstation -to use an LDAP server for user information and authentication. -
- --Before proceeding, you will need a working LDAP server which can -provide you with user information. If you need to set one up, -consult our OpenLDAP whitepaper for -instructions. -
- --User information consists of such data as mappings between user id numbers -and user names (used, for example, by ls -l), or home directory -locations (used, for example, by cd ~). Lookups of such information -are handled by the name service subsystem, configured in the file -/etc/nsswitch.conf. - -Authentication (password checking), on the other hand, is handled by the -PAM (plugable authentication module) subsystem, configured in the -/etc/pam.d/ directory. - -While these two subsystems can (in fact must) be configured seperately, -you will likely want both to use LDAP. -
- --Begin by installing the shared library code necessary for the -name service to use ldap. - -
-# apt-get install libnss-ldap
--Next, open the /etc/nsswitch.conf file, and tell the -name service subsystem to use LDAP to obtain user information. - -
-passwd: files ldap -group: files ldap -shadow: files ldap --
-Finally, you need to tell then name service subsystem how to talk -to your LDAP server. This is done in the file -/etc/libnss-ldap.conf. - -
-uri ldap://ldap.example.com/ ldap://ldap-backup.example.com/ -base dc=example, dc=org --
-nss-ldap expects accounts to be objects with the following attributes: uid, -uidNumber, gidNumber, homeDirectory, and loginShell. These attributes are -allowed by the objectClass posixAccount. -
- --There is a simple way to verify that your name service subsystem is using -your LDAP server as instructed. Assign a file to be owned by a user that -exists only in the LDAP database, not in /etc/passwd. If -an ls -l correctly shows the username, then the name service -subsystem is consulting the LDAP database; if it just shows the user number, -something is wrong. - -For example, if the user john, with user number 1001, exists only in -LDAP, we can try - -
-# touch /tmp/test -# chown 1001 /tmp/test -# ls -l /tmp/test --rw-r----- 1 john users 0 Jan 1 12:00 test -
-Next we configure the PAM subsystem to use LDAP for passwords. Begin by -installing the necessary PAM module. - -
-# apt-get install libpam-ldap
--uri ldaps://ldap.example.com/ -base dc=example,dc=com -pam_password exop --
-pam-ldap assumes accounts to be ojbects with the following attributes: -uid and userPassword. The attributes are allowed by the objectClass -posixAccount. -
- --We are now ready to configure individual services to use the LDAP server -for password checking. Each service that uses PAM for authentication has -its own configuration file /etc/pam.d/service. -To configure a service to use LDAP for password-checking, you must modify -its PAM configuration file. -
- --To avoid an in-depth explanation of PAM, we will -content ourselves with a few examples. Consider first the login program, -which handles logins from the text console. A typical PAM stack which -checks passwords both in /etc/passwd and in the LDAP database -follows. - -
-auth required pam_nologin.so -auth sufficient pam_ldap.so -auth sufficient pam_unix.so shadow use_first_pass -auth required pam_deny.so --
-account sufficient pam_unix.so -account sufficient pam_ldap.so -account required pam_deny.so --
-Some applications not only authenticate passwords, but can also be used -to change them. The prototypical example is of course passwd, -the standard password-changing utility. Such programs can be configured to -use LDAP by modifying their password stack. - -
-password required pam_cracklib.so -password sufficient pam_ldap.so -password sufficient pam_unix.so -password required pam_deny.so --
-One convienient application of pam-ldap is to set up "black box" servers -that can authenticate users for a particular service without having an -account on the machine at all. Services such as netatalk, (Cyrus) imap, -and (Postfix) smtp use PAM. By configuring their PAM stacks to use LDAP, -while leaving LDAP out of the PAM stacks of services such as login and ssh, -you can easily create a "black box" server. -
- --To keep your computers from pounding your LDAP server every time -a command such as ls -l /home is issued on a computer in your -organization, it is a good idea to configure your workstations to -cache some user data. As long as the data in the cache is sufficiently -fresh, the workstations use in instead of asking your LDAP server again. -The name server caching daemon (nscd) accomplishes exactly -this task. -
- --To install nscd on Debian, just - -
-# apt-get install nscd
--The configuration file for nscd is /etc/nscd.conf. - -
-enable-cache passwd yes -positive-time-to-live passwd 600 -negative-time-to-live passwd 20 -suggested-size passwd 211 -check-files passwd yes --