by danang.wijanarko@gmail.com

 

---

General Update:

I have build the one bundle solution this on my project case DCA, if you might have some interest to look on and developing this DCA further, please just contact.

---

Copyright, Desclaimer, and Feedback:

- No specific copyright, just give respect on me by supplying the original author credit.
- No claim about this howto, all is your responsibilities to use or not use in production or non-production activities.
- I'm happy about feedback, just contact me about changes, ideas, corrections, or anything help you might think that i could help you with.
- This doc is built on 2004 so some other stuff might need to be update.

The first thing is that i use Debian. This is a howto intended for an advance system administrator, and involving many major services in a *nix system.

FAST BUILD (Impatient Expert)

Installing the Kerberos KDC.

# apt-get -u install krb5-kdc krb5-admin-server
      Kerberos Realm: ITS.AC.ID
      Kerberos4 mode: none
      Kerberos-cfg server: 202.154.63.60
      "      "  kadmin server: 202.154.63.60

Then create the database.

# krb5_newrealm
      This script should be run on the master KDC/admin server to initialize
      a Kerberos realm.  It will ask you to type in a master key password.
      This password will be used to generate a key that is stored in
      /etc/krb5kdc/stash.  You should try to remember this password, but it
      is much more important that it be a strong password than that it be
      remembered.  However, if you lose the password and /etc/krb5kdc/stash,
      you cannot decrypt your Kerberos database.
      Loading random data
      Initializing database '/var/lib/krb5kdc/principal' for realm 'ITS.AC.ID',
      master key name 'K/M@ITS.AC.ID'
      You will be prompted for the database Master Password.
      It is important that you NOT FORGET this password.
      Enter KDC database master key: [rahasiakerberos]
      Re-enter KDC database master key to verify: [rahasiakerberos]
      Starting Kerberos KDC: krb5kdc krb524d.
    

Then create the kadmind keytab, and start the kerberos admin server.

      # kadmin.local
      Authenticating as principal krb5-admin/admin@ITS.AC.ID with password.
      kadmin.local:  ktadd -k /etc/krb5kdc/kadm5.keytab kadmin/admin kadmin/changepw
      Entry for principal kadmin/admin with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab   WRFILE:/etc/krb5kdc/kadm5.keytab.
      Entry for principal kadmin/admin with kvno 3, encryption type DES cbc mode with CRC-32 added to keytab  WRFILE:/etc/krb5kdc/kadm5.keytab.
      Entry for principal kadmin/changepw with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab  WRFILE:/etc/krb5kdc/kadm5.keytab.
      Entry for principal kadmin/changepw with kvno 3, encryption type DES cbc mode with CRC-32 added to keytab WRFILE:/etc/krb5kdc/kadm5.keytab.
      kadmin.local:  quit

      # /etc/init.d/krb5-admin-server start
      Starting Kerberos Administration Servers: kadmind.

Create a kerberos admin principals, and then edit /etc/krb5kdc/kadm5.acl to enable */admin *.

      # This file Is the access control list for krb5 administration.
      # When this file is edited run /etc/init.d/krb5-admin-server restart to activate
      # One common way to set up Kerberos administration is to allow any principal
      # ending in /admin  is given full administrative rights.
      # To enable this, uncomment the following line:
      */admin *

Then restart the kerberos admin server.

      # /etc/init.d/krb5-admin-server restart
    

Create the first administrative principal.

      # kadmin.local
      Authenticating as principal root/admin@COMPANY.COM with password.
      kadmin.local:  addprinc krb5-admin/admin@ITS.AC.ID
      WARNING: no policy specified for krb5-admin/admin@ITS.AC.ID; defaulting to no policy
      Enter password for principal "krb5-admin/admin@ITS.AC.ID": [rahasiakerberosadmin]
      Re-enter password for principal "krb5-admin/admin@ITS.AC.ID": [rahasiakerberosadmin]
      Principal "krb5-admin/admin@ITS.AC.ID" created. 
      kadmin.local:  quit

Install OpenLDAP.

      # apt-get -u install slapd ldap-utils db4.2-util

      Domain name: its.ac.id
      Organization name: ITSNet
      Admin password: rahasialdap
      Allow LDAPv2 for compatibity

Securing LDAP comunications - SASL version.

      # apt-get install libsasl2-gssapi-mit sasl2-bin

Create a kerberos principal for the service and host.

      # kadmin -p krb5-admin/admin
      Authenticating as principal krb5-admin/admin@ITS.AC.iD with password.
      Password for krb5-admin/admin@ITS.AC.ID: [rahasiakerberosadmin]
      kadmin:  addprinc -randkey ldap/nermus.its.ac.id
      WARNING: no policy specified for ldap/nermus.its.ac.id@ITS.AC.ID; defaulting to no policy
      Principal "ldap/nermus.its.ac.id@ITS.AC.ID" created.
      kadmin:  ktadd -k /etc/krb5.keytab ldap/nermus.its.ac.id
      Entry for principal ldap/nermus.its.ac.id with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to  keytab WRFILE:/etc/krb5.keytab.
      Entry for principal ldap/nermus.its.ac.id with kvno 3, encryption type DES cbc mode with CRC-32 added to keytab WRFILE:/etc/krb5.keytab
      kadmin:  addprinc -randkey host/nermus.its.ac.id
      WARNING: no policy specified for host/nermus.its.ac.id@ITS.AC.ID; defaulting to no policy
      Principal "host/nermus.its.ac.id@ITS.AC.ID" created.
      kadmin:  ktadd -k /etc/krb5.keytab host/nermus.its.ac.id
      Entry for principal ldap/nermus.its.ac.id with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to  keytab WRFILE:/etc/krb5.keytab.
      Entry for principal ldap/nermus.its.ac.id with kvno 3, encryption type DES cbc mode with CRC-32 added to keytab WRFILE:/etc/krb5.keytab.
      kadmin:  quit

Then edit /etc/ldap/slapd.conf to add these entries.

      ...
      sasl-host nermus.its.ac.id
      sasl-realm ITS.AC.ID
      sasl-regexp uid=(.*),cn=its.ac.id,cn=gssapi,cn=auth uid=$1,ou=People,dc=its,dc=ac,dc=id
      
      # allow ldapsearch -x -s base -b "" supportedSASLMechanisms
      access to dn.base=""  attrs=supportedSASLMechanisms
              by * +rscx stop
      ...

System Migration

The Server

Install nscd in order to cache the queries to de LDAP server and also the libnss-ldap.

      # apt-get -u install nscd libnss-ldap
      
      LDAP HOST ADDRESS : 127.0.0.1 (we are installing the server)
      DN of the search base : dc=its,dc=ac,dc=id
      LDAP version: 3
      Login: No (there will be no sensitive info apart from admin)
      Readably conf files by owner : No (anon login)

Debian configuration of LDAP doesn't include the misc.schema by default, just include it now by editing /etc/ldap/slapd.conf.

      ..
      include         /etc/ldap/schema/core.schema
      include         /etc/ldap/schema/cosine.schema
      include         /etc/ldap/schema/nis.schema
      include         /etc/ldap/schema/inetorgperson.schema
      
      include         /etc/ldap/schema/misc.schema
      ..

See..., i don't include any kerberos schema even i use kerberos as my auth protocol backend. Why ? because debian not again supporting {KERBEROS}principal@realm in authenticating, but rather use SASL. SASL provide better mechanism, even using KERBEROS or other.

Then install the migration tools from padl.

      # apt-get -u install migrationtools

The migration tools doesn't work well with repeated name services you will have to normalize the /etc/services file temporaly and edit some capitalized false like nextstep.

      # mv /etc/services /etc/services.pre
      # cat /etc/services.pre | grep /tcp > /etc/services

Then edit /usr/share/migrationtools/migrate_common.pl.

       # Default DNS domain
       $DEFAULT_MAIL_DOMAIN = "its.ac.id";
       
       # Default base
       $DEFAULT_BASE = "dc=its,dc=ac,dc=id"

The continue by adding online to ldap database or creating ldif first then add the ldif entry.

      /usr/share/migrationtools# ./migrate_all_online.sh
      Enter the X.500 naming context you wish to import into: [dc=its,dc=ac,dc=id]
      Enter the hostname of your LDAP server [ldap]: 127.0.0.1
      Enter the manager DN: [cn=admin,dc=its,dc=ac,dc=id]:
      Enter the credentials to bind with:
      Do you wish to generate a DUAConfigProfile [yes|no]? no

Then give back the original /etc/services.

      # rm /etc/services
      # mv /etc/services.pre /etc/services

Edit libnss-ldap configuration file in /etc/libnss-ldap.conf, you should leave commented the binddn and rootdn as we are conecting as the anonymous user. Then configure /etc/nsswitch.conf to use the ldap module.

      passwd:         files ldap
      group:          files ldap
      shadow:         files ldap
      
      netgroup:      ldap

Basically this choice depends on your customization, whether migrate all or some of your system configuration in the ldap. I won't be using ldap for hosts as we will use a DNS server with a LDAP backend.

Just restart nscd in order to clean the database.

      # /etc/init.d/nscd restart

NOTE: Setting {KERBEROS}prinicipal@REALM in the userPassword attribute in ldap database will not work on Debian because the openldap package is not compiled with --enable-kpasswd anymore. Use {SASL}principal@REALM instead. For this to work some things need to be done. Well this stuff makes me SICK for a while.

Edit /etc/default/saslauthd.

      # This needs to be uncommented before saslauthd will be run automatically
      START=yes
      # You must specify the authentication mechanisms you wish to use.
      # This defaults to "pam" for PAM support, but may also include
      # "shadow" or "sasldb", like this:
      # MECHANISMS="pam shadow"
      MECHANISMS="kerberos5"

I can't say no more about this strange configuration in Debian, i hope the maintainer give some explanation about this, but i can't find any note about this. This is about /usr/lib/sasl2/slapd.conf, :-) it's a kind of a joke or what, how come the configuration file is placed in the /usr/lib/sasl2/ dir ? hmmmm... this kind of configuration is similiar with the postfix stuff when using sasl to get the system more secure, but in the postfix bla...bla...bla, it is placed in the right place (IMHO). Any way, just roll it up honey... :-) this howto is preety stright forward and the most easy tune for debian user (i hope and think).

Create new file /usr/lib/sasl2/slapd.conf.

      pwcheck_method:saslauthd
      saslauthd_path:/var/run/saslauthd/mux

Then restart the slapd daemon.

      # /etc/init.d/saslauthd start
    

The next is a test.

      # kadmin -p krb5-admin/admin
      Authenticating as principal krb5-admin/admin@ITS.AC.iD with password.
      Password for krb5-admin/admin@ITS.AC.ID: [rahasiakerberosadmin]
      kadmin:  addprinc dd@ITS.AC.ID
      WARNING: no policy specified for dd@ITS.AC.ID; defaulting to no policy
      Enter password for principal "dd@ITS.AC.ID": [rahasiadd]
      Re-enter password for principal "dd@ITS.AC.ID": [rahasiadd]
      Principal "dd@ITS.AC.ID" created.
      kadmin: quit
      
      # testsaslauthd -u dd -p rahasiadd -r ITS.AC.ID
      0: OK "Success."

If you have return 0: NO "authentication failed" then you have to review again your step and do some litle hack on your configuration, maybe we miss something :-). I hope not.

Now test if the authentication with LDAP is passed to SASL by doing.

      # ldapwhoami -x -W -D 'uid=dd,ou=People,dc=its,dc=ac,dc=id'
      Enter LDAP Password:
      dn:uid=dd,ou=People,dc=its,dc=ac,dc=id

If you get "ldap_bind: Invalid credentials (49)" it could mean SASL is not properly configured (meaning you have to review). Make sure that the "sasl-regexp" entry is in "/etc/ldap/slapd.conf".

The Client

We are going to use pam, here they are:

      # apt-get install libpam-krb5 libpam-ldap libnss-ldap nscd
      
      (For caches libc-issued requests to the Name Service) nscd - GNU C Library: Name Service Cache Daemon
      (For authentication using kerberos) libpam-krb5 - PAM module for MIT Kerberos
      (For authentication using ldap) libpam-ldap - Pluggable Authentication Module allowing LDAP interfaces
      (For distributing configuration nss) libnss-ldap - NSS module for using LDAP as a naming service

libpam-ldap for authentication over ldap database and libpam-ldap for authentication over kerberos. Here is the possible way of the authentiacation:

      login → PAM → PAM/LDAP → SSL/TLS → SASL → LDAP → SSL/TLS → SASL → LDAP → Kerberos
      login → NSS → NSS/LDAP → SSL/TLS → SASL → LDAP

      (This is preety confusing but it's good, i'am already paranoid now, :-), we want to achieve this by next hardening the servers)

But you might want a simple like this, is up to you.

      login → PAM → PAM/KERBEROS → Kerberos    

All is done using PAM. So just edit the config that you might interest on.

The Building (HARDENING THE SERVERS)

Core packages: OpenSSL, MIT Kerberos V, OpenLDAP, Cyrus SASL

Miscellaneous packages: LibNSS-LDAP/LibPAM-LDAP, OpenAFS, PAM/Kerberos migration module

 

Reason of why and why ??? Why SSL/TLS ?

    -- All communication between the master and slave database ldap, 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.
    -- The replication DN and password (options replica and bindmethod) have to be stored in clear text in the configuration file.
    -- libpam-ldap is doing the authentication in clear text as well.

    Figure it:
      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.

Why Kerberos ?

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! but LDAP on the other hand, is designed to be a database for distributed, public information.

Why SASL ?

When using the combination SASL and KerberosV (SASL can use other means of storing password, Kerberos is just a choice), we can use a KerberosV keytab to authenticate the service to the database. This case is also happen when we want to replicate the ldap database. Thus, no need for any passwords etc in the slapd configuration file.

SASL is designed as a middle-layer. It sits between the LDAP server and the authentication system (in this case, Kerberos). 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), even use a LDAP database (which might be a little redundant, and difficult do obtain, without creating authentication loops), etc. 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.

Why LDAP

Distributing public information database. Emmm... and for the future. :-)

-- So the keyword is public, distribution, centerized, and secure. --

DNS Context.

      nermus                          IN      A       202.154.63.60
      doraemon                     IN      A       202.154.63.26
      ldap                            IN      CNAME   nermus
      ldap-1                          IN      CNAME   doraemon
      kerberos                        IN      CNAME   nermus
      kerberos-1                      IN      CNAME   doraemon
      
      ; Master setup
      _kerberos                       TXT     "ITS.AC.ID"
      _kerberos-master._udp           SRV     0 0 88 	nermus
      _kerberos-adm._tcp              SRV     0 0 749 	nermus
      _kpasswd._udp                   SRV     0 0 464 	nermus
      
      ; Round-robin setup
      _kerberos._udp                  SRV     0 0 88	kerberos
                                      SRV     0 0 88 	kerberos-1
      _ldap._tcp.its.ac.id	      IN      SRV     0 0 389 ldap
      				      IN      SRV     0 0 389 ldap-1
    

Set the revers look-up too. Much of my problems where that the KDC couldn't (wouldn't?) find my FQDN for the IP address, or the other way around. What is SRV stuff in this configuration ? A DNS RR for specifying the location of services (DNS SRV). Look here (rfc2052) for the detail.

Core packages

OpenSSL

Install it !!!

      # apt-get install openssl

Then create certificate !!!

First: Self Signed Certificate

The first way to create a server certificate is to use OpenSSL and create a self signed server certificate.

      # mkdir -p /etc/myCA/CASelfSignedCertificate
      # openssl req -newkey rsa:1024 -x509 -nodes -out server.pem -keyout server.pem -days 365
      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]:ID
      State or Province Name (full name) [Some-State]:Jawa TImur
      Locality Name (eg, city) []:Surabaya
      Organization Name (eg, company) [Internet Widgits Pty Ltd]:ITSNet
      Organizational Unit Name (eg, section) []:ITSNet
      Common Name (eg, YOUR name) []:nermus.its.ac.id
      Email Address []:dd@its.ac.id

Second: CA Issued Certificate

If you have access to a trusted Certificate Authority (CA), then step through the CA process to get a CA certificate, server certificate and server private key.

      # cd /usr/lib/ssl/misc ← change dir to ssl automated script
      # ./CA.sh -newca ← create the CA
      CA certificate filename (or enter to create)

      Making CA certificate ...
      Generating a 1024 bit RSA private key
      ................................++++++
      ......................................++++++
      writing new private key to './demoCA/private/./cakey.pem'
      Enter PEM pass phrase:
      Verifying - Enter PEM pass phrase:
      -----
      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]:ID
      State or Province Name (full name) [Some-State]:Jawa Timur
      Locality Name (eg, city) []:Surabaya
      Organization Name (eg, company) [Internet Widgits Pty Ltd]:ITSNet
      Organizational Unit Name (eg, section) []:ITSNet
      Common Name (eg, YOUR name) []:nermus.its.ac.id
      Email Address []:dd@its.ac.id
      
      # openssl req -newkey rsa:1024 -nodes -keyout newreq.pem -out newreq.pem ← create the Server Key
      Generating a 1024 bit RSA private key
      .............................................................++++++
      .....++++++
      writing new private key to 'newreq.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]:ID
      State or Province Name (full name) [Some-State]:Jawa Timur
      Locality Name (eg, city) []:Surabaya
      Organization Name (eg, company) [Internet Widgits Pty Ltd]:ITSNet
      Organizational Unit Name (eg, section) []:ITSNet
      Common Name (eg, YOUR name) []:nermus.its.ac.id
      Email Address []:dd@its.ac.id

      Please enter the following 'extra' attributes
      to be sent with your certificate request
      A challenge password []:
      An optional company name []:

      root@nermus:/usr/lib/ssl/misc# ./CA.sh -sign
      Using configuration from /usr/lib/ssl/openssl.cnf
      Enter pass phrase for ./demoCA/private/cakey.pem:
      Check that the request matches the signature
      Signature ok
      Certificate Details:
              Serial Number: 1 (0x1)
	      Validity
	      	Not Before: Sep 23 07:00:06 2005 GMT
	      	Not After : Sep 23 07:00:06 2006 GMT
	      Subject:
	      	countryName               = ID
	      	stateOrProvinceName       = Jawa Timur
	      	localityName              = Surabaya
	      	organizationName          = ITSNet
	      	organizationalUnitName    = ITSNet
	      	commonName                = nermus.its.ac.id
	      	emailAddress              = dd@its.ac.id
	      X509v3 extensions:
	      	X509v3 Basic Constraints:
			CA:FALSE
	      Netscape Comment:
	      	OpenSSL Generated Certificate
	      X509v3 Subject Key Identifier:
	      	E6:76:91:0A:F8:90:DA:4E:13:A6:10:E9:97:26:9C:B8:23:20:6F:BD
	      X509v3 Authority Key Identifier:
	      	keyid:4B:C1:EE:AE:99:9C:43:F5:02:F2:5A:50:2E:F2:E3:B9:B7:BA:AB:61
		DirName:/C=ID/ST=Jawa Timur/L=Surabaya/O=ITSNet/OU=ITSNet/CN=nermus.its.ac.id/emailAddress=dd@its.ac.id
		serial:DE:31:01:46:8D:CF:D0:11
		
      Certificate is to be certified until Sep 23 07:00:06 2006 GMT (365 days)
      Sign the certificate? [y/n]:y
            
      1 out of 1 certificate requests certified, commit? [y/n]y
      Write out database with 1 new entries
      Data Base Updated
      Certificate:
      	Data:
		Version: 3 (0x2)
		Serial Number: 1 (0x1)
		Signature Algorithm: md5WithRSAEncryption
		Issuer: C=ID, ST=Jawa Timur, L=Surabaya, O=ITSNet, OU=ITSNet, CN=nermus.its.ac.id/emailAddress=dd@its.ac.id
		Validity
			Not Before: Sep 23 07:00:06 2005 GMT
			Not After : Sep 23 07:00:06 2006 GMT
		Subject: C=ID, ST=Jawa Timur, L=Surabaya, O=ITSNet, OU=ITSNet, CN=nermus.its.ac.id/emailAddress=dd@its.ac.id
		Subject Public Key Info:
			Public Key Algorithm: rsaEncryption
			RSA Public Key: (1024 bit)
				Modulus (1024 bit):
					00:e4:56:52:43:66:c0:b0:26:fc:8b:a4:0f:1a:4c:
					84:1b:db:54:81:f0:7a:61:1f:b2:8a:8c:9a:63:2e:
					2e:65:73:2a:71:5c:e4:a4:3e:b4:35:1d:79:64:c8:
					4b:cc:b8:20:f2:eb:65:8f:26:57:05:35:41:03:33:
					34:05:59:4d:20:da:13:2a:0a:f5:72:ad:58:84:04:
					7d:ba:42:d0:e9:11:e8:d9:2f:35:ea:cb:c6:9c:08:
					c3:1a:ab:e0:1a:bb:71:49:bb:50:29:eb:aa:2e:fa:
					f5:53:e1:75:07:8f:d1:de:40:54:94:11:18:91:71:
					8c:9b:14:65:67:6b:ad:e9:d5
				Exponent: 65537 (0x10001)
		X509v3 extensions:
			X509v3 Basic Constraints:
				CA:FALSE
			Netscape Comment:
				OpenSSL Generated Certificate
			X509v3 Subject Key Identifier:
				E6:76:91:0A:F8:90:DA:4E:13:A6:10:E9:97:26:9C:B8:23:20:6F:BD
			X509v3 Authority Key Identifier:
				keyid:4B:C1:EE:AE:99:9C:43:F5:02:F2:5A:50:2E:F2:E3:B9:B7:BA:AB:61
				DirName:/C=ID/ST=Jawa Timur/L=Surabaya/O=ITSNet/OU=ITSNet/CN=nermus.its.ac.id/emailAddress=dd@its.ac.id
				serial:DE:31:01:46:8D:CF:D0:11
			
	Signature Algorithm: md5WithRSAEncryption
		b5:0b:6c:3e:91:b7:97:53:25:4a:59:84:92:28:eb:3a:87:68:
		69:46:6b:d7:b3:8b:1d:65:0a:dd:14:73:b6:ef:d4:9a:05:7e:
		97:d2:a9:63:27:b5:05:7a:c0:28:5d:e5:51:43:1a:95:4b:81:
		6a:89:19:2e:e4:07:26:34:0d:da:1d:de:c5:2c:1d:9c:34:00:
		ce:13:d2:f0:a6:bd:55:50:c5:b7:c8:15:79:ce:23:03:f7:16:
		5e:6a:71:f9:32:2d:90:cb:f4:09:53:63:4f:b8:e8:dc:71:b2:
		f1:b8:38:9f:38:18:17:34:93:ad:4a:07:e9:70:9b:a9:af:ce:
		ef:3a
      -----BEGIN CERTIFICATE-----
      MIIDuzCCAySgAwIBAgIBATANBgkqhkiG9w0BAQQFADCBjzELMAkGA1UEBhMCSUQx
      EzARBgNVBAgTCkphd2EgVGltdXIxETAPBgNVBAcTCFN1cmFiYXlhMQ8wDQYDVQQK
      EwZJVFNOZXQxDzANBgNVBAsTBklUU05ldDEZMBcGA1UEAxMQbmVybXVzLml0cy5h
      Yy5pZDEbMBkGCSqGSIb3DQEJARYMZGRAaXRzLmFjLmlkMB4XDTA1MDkyMzA3MDAw
      NloXDTA2MDkyMzA3MDAwNlowgY8xCzAJBgNVBAYTAklEMRMwEQYDVQQIEwpKYXdh
      IFRpbXVyMREwDwYDVQQHEwhTdXJhYmF5YTEPMA0GA1UEChMGSVRTTmV0MQ8wDQYD
      VQQLEwZJVFNOZXQxGTAXBgNVBAMTEG5lcm11cy5pdHMuYWMuaWQxGzAZBgkqhkiG
      9w0BCQEWDGRkQGl0cy5hYy5pZDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
      5FZSQ2bAsCb8i6QPGkyEG9tUgfB6YR+yioyaYy4uZXMqcVzkpD60NR15ZMhLzLgg
      8utljyZXBTVBAzM0BVlNINoTKgr1cq1YhAR9ukLQ6RHo2S816svGnAjDGqvgGrtx
      SbtQKeuqLvr1U+F1B4/R3kBUlBEYkXGMmxRlZ2ut6dUCAwEAAaOCASMwggEfMAkG
      A1UdEwQCMAAwLAYJYIZIAYb4QgENBB8WHU9wZW5TU0wgR2VuZXJhdGVkIENlcnRp
      ZmljYXRlMB0GA1UdDgQWBBTmdpEK+JDaThOmEOmXJpy4IyBvvTCBxAYDVR0jBIG8
      
      MIG5gBRLwe6umZxD9QLyWlAu8uO5t7qrYaGBlaSBkjCBjzELMAkGA1UEBhMCSUQx
      EzARBgNVBAgTCkphd2EgVGltdXIxETAPBgNVBAcTCFN1cmFiYXlhMQ8wDQYDVQQK
      EwZJVFNOZXQxDzANBgNVBAsTBklUU05ldDEZMBcGA1UEAxMQbmVybXVzLml0cy5h
      Yy5pZDEbMBkGCSqGSIb3DQEJARYMZGRAaXRzLmFjLmlkggkA3jEBRo3P0BEwDQYJ
      KoZIhvcNAQEEBQADgYEAtQtsPpG3l1MlSlmEkijrOodoaUZr17OLHWUK3RRztu/U
      mgV+l9KpYye1BXrAKF3lUUMalUuBaokZLuQHJjQN2h3exSwdnDQAzhPS8Ka9VVDF
      t8gVec4jA/cWXmpx+TItkMv0CVNjT7jo3HGy8bg4nzgYFzSTrUoH6XCbqa/O7zo=
      -----END CERTIFICATE-----
      Signed certificate is in newcert.pem
      
      # mkdir -p /etc/myCA/CAIssuedCertificate
      # mv demoCA /etc/myCA/CAIssuedCertificate
      # mv newcert.pem  /etc/myCA/CAIssuedCertificate/servercrt.pem
      # mv newreq.pem /etc/myCA/CAIssuedCertificate/serverkey.pem
      # chmod 600  /etc/myCA/CAIssuedCertificate/serverkey.pem

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.

OpenLDAP only works with unencrypted keys and the '-nodes' argument prevents encryption of the private key.

MIT Kerberos V

I suggest you to read my docs first about kerberos Kerberos Howto For Sarge.

      # apt-get install krb5-kdc krb5-admin-server

And this is my /etc/krb5.conf.

      [libdefaults]
        default_realm = ITS.AC.ID
	krb4_config = /etc/krb.conf
	krb4_realms = /etc/krb.realms
	kdc_timesync = 1
	ccache_type = 4
	forwardable = true
	proxiable = true
	v4_instance_resolve = false
	v4_name_convert = {
		host = {
			rcmd = host
			ftp = ftp
		}
		plain = {
			something = something-else
		}
	}
      
      [realms]
        ITS.AC.ID = {
		kdc = 202.154.63.60		← see this, i prefer using IP address rather than fqdn, i hope you know the reason.
		kdc = 202.154.63.26
		admin_server = 202.154.63.60
	}
      
      [domain_realm]
	.its.ac.id = ITS.AC.ID
	its.ac.id = ITS.AC.ID

      [logging]
        kdc = FILE:/var/log/krb/krb5kdc.log
	admin_server = FILE:/var/log/krb/kadmin.log
	default = FILE:/var/log/krb/krb5lib.log

      [login]
	krb4_convert = true
	krb4_get_tickets = true

And this is my /etc/krb5kdc/kdc.conf.

      [kdcdefaults]
        kdc_ports = 750,88
	
      [realms]
        ITS.AC.ID = {
	  database_name = /var/lib/krb5kdc/principal
	  admin_keytab = FILE:/etc/krb5kdc/kadm5.keytab
	  acl_file = /etc/krb5kdc/kadm5.acl
	  key_stash_file = /etc/krb5kdc/stash
	  kdc_ports = 750,88
	  max_life = 10h 0m 0s
	  max_renewable_life = 7d 0h 0m 0s
	  master_key_type = des3-hmac-sha1
	  supported_enctypes = des3-hmac-sha1:normal des-cbc-crc:normal des:normal des:v4 des:norealm des:onlyrealm des:afs3
	  default_principal_flags = +preauth
        }

And running krb5_newrealm on debian will create the stash file for you, and also create some service key and principals. Next you have to add host and other required principals or the optional one, (see above the Impatient Expert Chapter). Don't forget to add the keytab for each service principals. About keytab ? see my docs about kerberos in more detail.

We want it all by Kerberos right ? So add the principal for ldap administrator.

      # kadmin -p krb5-admin/admin
      Authenticating as principal krb5-admin/admin with password.
      Password for krb5-admin/admin@ITS.AC.ID: [rahasiakerberosadmin]
      kadmin:  addprinc ldap-admin/admin@ITS.AC.ID
      WARNING: no policy specified for ldap-admin/admin@ITS.AC.ID; defaulting to no policy
      Enter password for principal "ldap-admin/admin@ITS.AC.ID": [rahasialdapadmin]
      Re-enter password for principal "ldap-admin/admin@ITS.AC.ID": [rahasialdapadmin]
      Principal "ldap-admin/admin@ITS.AC.ID" created.
      kadmin:  quit

Then change the /etc/krb5kdc/kadm5.acl to allow only krb5-admin/admin@ITS.AC.ID.

      # This file Is the access control list for krb5 administration.
      # When this file is edited run /etc/init.d/krb5-admin-server restart to activate
      # One common way to set up Kerberos administration is to allow any principal
      # ending in /admin  is given full administrative rights.
      # To enable this, uncomment the following line:
      # */admin *
      krb5-admin/admin *

Dont forget to restart the KDC by:

      # /etc/init.d/krb5-kdc restart
      Restarting Kerberos KDC:  krb524dkrb5kdc.

Cyrus SASL

      # apt-get install libsasl2 libsasl2-modules libsasl2-gssapi-mit

      Note:
        libsasl2		: Providing base authentication abstraction library
	libsasl2-modules	: Providing Pluggable Authentication Modules for SASL
				  This package provides the following SASL modules: LOGIN, PLAIN, ANONYMOUS, OTP, CRAM-MD5, and DIGEST-MD5 (with DES support).
	libsasl2-gssapi-mit	: Providing GSSAPI  module for SASL using MIT Kerberos
				  This package provides the GSSAPI module compiled against the MIT implementation of Kerberos.

OpenLDAP

I suggest you to read tldp howto docs about ldap. Do it sequentially. First LDAP-HOWTO. Then LDAP-Implementation-HOWTO.

Basically you would only execute this in Debian.

        apt-get install slapd db4.2-util

What else could i say, ??? debian defauting to support BDB backend, cute, nice... hmmm. Just try it by yourself.
Next thing you got to know is prepare to create LDAP database to migrate the common information about the migrated client. And fortunately again debian provide it nicefully.

      Install supporting package
        # apt-get install migrationtools phpldapadmin
      
      Configure migrationtools
        # cd /usr/share/migrationtools/

	Edit migrate_common.ph to add:
	  # Default DNS domain
	  $DEFAULT_MAIL_DOMAIN = "its.ac.id";

	  # Default base
	  $DEFAULT_BASE = "dc=its,dc=ac,dc=id";

	  # Uncomment these to exclude Debian-managed system users and groups
	  $IGNORE_UID_BELOW = 1000;
	  $IGNORE_GID_BELOW = 100;

	  # And here's the opposite for completeness
	  $IGNORE_UID_ABOVE = 9999;
	  $IGNORE_GID_ABOVE = 9999;
	
	  Then create the relevant migrated ldif, it depends on you what you would like to migrate, and don't forget to set the local configuration file related.
	  In case of me, i just want to migrate /etc/passwd /etc/group.
	  Why i'm not including /etc/shadow ? (well, i use kerberos you know ? so kerberos that make it readable security setting)
	  so i'm going to do this:
	  
	  # mkdir ldif
	  # ./migrate_passwd.pl /etc/passwd ldif/passwd.ldif
	  # ./migrate_group.pl /etc/group ldif/group.ldif

	  If i want to migrate all my system configuration and distributed all of them with LDAP database backend + Kerberos, then i would like to do this:

	  # ./migrate_all_online.sh

You better read the doc first, i'm loosing my mood in explaining to you. Another owesome tool, phpldapadmin, live with it to manage, if you feel comfort with phpmyadmin. :-)

Configuring.

      Edit /etc/ldap/slapd.conf to add certification that we had made before:
        TLSCACertificateFile /etc/myCA/CAIssuedCertificate/cacert.pem
	TLSCertificateFile /etc/myCA/CAIssuedCertificate/servercrt.pem
	TLSCertificateKeyFile /etc/myCA/CAIssuedCertificate/serverkey.pem

      Edit /etc/ldap/ldap.conf (client stuff) to add:
        BASE    dc=its,dc=ac,dc=id
	URI     ldaps://202.154.63.60/

	TLS_CACERT /etc/myCA/CAIssuedCertificate/cacert.pem
	TLS_REQCERT  demand
	
      Edit /etc/defaul/slapd to put this:
        SLAPD_SERVICES="ldap://202.154.63.60:389/ ldaps:/// ldapi:///"	: this would enable various mode of openldap server.

Testing your ldap server.

      Testing OpenLDAP, simple/anonymous bind
        # ldapsearch -h nermus.its.ac.id -p 389 -x -b "" -s base -LLL supportedSASLMechanisms
	dn:
	supportedSASLMechanisms: GSSAPI				← see this? it's important sasl module thing that should be exist when we use kerberos.
	supportedSASLMechanisms: CRAM-MD5
	supportedSASLMechanisms: DIGEST-MD5
	supportedSASLMechanisms: NTLM
	
      Testing OpenLDAP, simple/anonymous bind, with SSL/TLS
      The first command tests TLS, and the second one SSL (notice the parameter -ZZ in the first command and ldaps://nermus.its.ac.id/ in the second?).
      
        # ldapsearch -H ldap://nermus.its.ac.id/ -x -b "" -s base -LLL -ZZ supportedSASLMechanisms
	dn:
	supportedSASLMechanisms: GSSAPI
	supportedSASLMechanisms: CRAM-MD5
	supportedSASLMechanisms: DIGEST-MD5
	supportedSASLMechanisms: LOGIN
	supportedSASLMechanisms: PLAIN
	supportedSASLMechanisms: NTL

	# ldapsearch -H ldaps://nermus.its.ac.id/ -x -b "" -s base -LLL supportedSASLMechanisms
	dn:
	supportedSASLMechanisms: GSSAPI
	supportedSASLMechanisms: CRAM-MD5
	supportedSASLMechanisms: DIGEST-MD5
	supportedSASLMechanisms: LOGIN
	supportedSASLMechanisms: PLAIN
	supportedSASLMechanisms: NTLM

      Testing OpenLDAP, using your Kerberos ticket
      Is that error ? NOPE, that's prove that it works with kerberos, trying to contact, but i haven't yet the ticket. :-)
        
	# ldapsearch -H ldaps://nermus.its.ac.id/ -I -b "" -s base -LLL supportedSASLMechanisms
	
	SASL/GSSAPI authentication started
	SASL Interaction
	Please enter your authorization name: dd
	ldap_sasl_interactive_bind_s: Local error (-2)
	        additional info: SASL(-1): generic failure: GSSAPI Error: Miscellaneous failure (No credentials cache found)
      
      Testing OpenLDAP, using your Kerberos ticket, with SSL/TLS
      If producing same output mean OK.

        # ldapsearch -H ldap://nermus.its.ac.id/ -I -b "" -s base -LLL -ZZ supportedSASLMechanisms
	SASL/GSSAPI authentication started
	SASL Interaction
	Please enter your authorization name: dd
	ldap_sasl_interactive_bind_s: Local error (-2)
	        additional info: SASL(-1): generic failure: GSSAPI Error: Miscellaneous failure (No credentials cache found)
      
      Testing OpenLDAP, simple user bind, with SSL/TLS

      # ldapsearch -x -D 'uid=dd,ou=People,dc=its,dc=ac,dc=id' -W -b "" -s base -LLL -H ldaps://nermus.its.ac.id/ supportedSASLMechanisms
      Enter LDAP Password:
      dn:
      supportedSASLMechanisms: GSSAPI
      supportedSASLMechanisms: CRAM-MD5
      supportedSASLMechanisms: DIGEST-MD5
      supportedSASLMechanisms: LOGIN
      supportedSASLMechanisms: PLAIN
      supportedSASLMechanisms: NTLM

Propagation

Kerberos

Prior before all, you must configure slave to run krb5-kdc alone, don't install krb5-admin-server. And create stash for slave. (Don't start KDC slave not yet !!!)

      # apt-get install krb5-kdc
      
      # kdb5_util create -r ITS.AC.ID -s
      Loading random data
      Initializing database '/var/lib/krb5kdc/principal' for realm 'ITS.AC.ID',
      master key name 'K/M@ITS.AC.ID'
      You will be prompted for the database Master Password.
      It is important that you NOT FORGET this password.
      Enter KDC database master key:
      Re-enter KDC database master key to verify:

You need to stop the kerberos slave KDC it it runs, first, if not you will see this message, when you kadmin -p ... thing:

      kadmin: Client not found in Kerberos database while initializing kadmin interface

      or 

      kadmin: GSS-API (or Kerberos) error while initializing kadmin interface

Then you must add principal for slave kerberos server. You can do this command in the master or slave, it's up to you.

      # kadmin -p krb5-admin/admin
      Authenticating as principal krb5-admin/admin with password.
      Password for krb5-admin/admin@ITS.AC.ID:
      kadmin:  addprinc -randkey host/doraemon.its.ac.id@ITS.AC.ID
      WARNING: no policy specified for host/doraemon.its.ac.id@ITS.AC.ID; defaulting to no policy
      Principal "host/doraemon.its.ac.id@ITS.AC.ID" created.
      kadmin:  quit

Then add the keytab of this principal in the slave kerberos database, as his key. Do this command below in slave.

      # kadmin -p krb5-admin/admin
      Authenticating as principal krb5-admin/admin with password.
      Password for krb5-admin/admin@ITS.AC.ID:
      kadmin:  ktadd -k /etc/krb5.keytab host/doraemon.its.ac.id
      Entry for principal host/doraemon.its.ac.id with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab.
      Entry for principal host/doraemon.its.ac.id with kvno 3, encryption type DES cbc mode with CRC-32 added to keytab WRFILE:/etc/krb5.keytab.
      kadmin:  quit

Then create file /etc/krb5kdc/kpropd.acl in both master and slave containing the principals for each of the KDCs.

      host/nermus.its.ac.id@ITS.AC.ID
      host/doraemon.its.ac.id@ITS.AC.ID

Now you ready to start the slave KDC to receive master database propagation.

      # /etc/init.d/krb5-kdc restart
      Restarting Kerberos KDC:  krb524dkrb5kdc.

Add something stupid in the /etc/inetd.conf like this both in the master and slave kerberos server

       krb5_prop stream tcp nowait root /usr/sbin/kpropd kpropd

Then restart the inetd.

      # /etc/init.d/inetd restart
      Restarting internet superserver: inetd.

In the master kerberos just do this to create propagated database.

      # kdb5_util dump /var/lib/krb5kdc/slave_datatrans
      
      It will result /var/lib/krb5kdc/slave_datatrans and /var/lib/krb5kdc/slave_datatrans.dump_ok

Next do the propagation from master kerberos.

      # kprop -f /var/lib/krb5kdc/slave_datatrans doraemon.its.ac.id
      Database propagation to doraemon.its.ac.id: SUCCEEDED

In the slave you will see /var/lib/krb5kdc/from_master file. This is the database that had beed propagated.

It is nice to make a script to do this job propagating the database and run in the cron. A typical interval between database replications is an hour.

      #!/bin/sh
      # Distribute KDC database to slave servers
      
      SLAVE_KDC="doraemon.its.ac.id"
      SLAVE_DATA="/var/lib/krb5kdc/slave_datatrans"
      SUCCESS="1"
      
      /usr/sbin/kdb5_util dump $SLAVE_DATA
      ERROR=$?
      
      if [ $ERROR -ne 0 ]; then
        echo "Kerberos database dump failed with exit code $ERROR. Exiting."
        exit 1
      fi
      
      for KDC in $SLAVE_KDC; do
        /usr/sbin/kprop -f $SLAVE_DATA $KDC 
        ERROR="$?"
      
        if [ "$ERROR" != "0" ]; then
          echo "Propagation of database to host $KDC failed with exit code $ERROR."
	  echo "Continuing with other slave servers."
	  SUCCESS="0"
        fi
      done
      
      if [ "$SUCCESS" = "1" ]; then
        echo "Kerberos database successfully replicated to all slaves."
      fi

LDAP

This is a little bit sensitive and complicated case.

Prior before all, you must configure slave to run slapd alone. Edit slave /etc/default/slapd to add this entry

      SLAPD_SERVICES="ldap://202.154.63.26:389/ ldaps:/// ldapi:///"

Then restart the slave slapd

      # /etc/init.d/slapd restart
      Stopping OpenLDAP: slapd.
      Starting OpenLDAP: running BDB recovery, slapd.

To be able to use GSSAPI/Kerberos V + SASL 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 ldap-replicator@ITS.AC.ID and of course i also create entry in ldap database about this account with uid=ldap-replicator,ou=People,dc=its,dc=ac,dc=id, 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 (note, that i use -randkey to put no password there instead i use keytab as the key to authentication):

      # kadmin -p krb5-admin/admin
      Authenticating as principal krb5-admin/admin with password.
      Password for krb5-admin/admin@ITS.AC.ID:
      kadmin:  addprinc -randkey ldap-replicator@ITS.AC.ID
      WARNING: no policy specified for ldap-replicator@ITS.AC.ID; defaulting to no policy
      Principal "ldap-replicator@ITS.AC.ID" created.
      kadmin:  quit

Then create the keytab for replication to master and slave ldap.

      # kadmin -p krb5-admin/admin
      Authenticating as principal krb5-admin/admin with password.
      Password for krb5-admin/admin@ITS.AC.ID:
      kadmin:  ktadd -k /etc/krb5.keytab.slurpd ldap-replicator
      Entry for principal ldap-replicator with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab.slurpd.
      Entry for principal ldap-replicator with kvno 3, encryption type DES cbc mode with CRC-32 added to keytab WRFILE:/etc/krb5.keytab.slurpd.
      kadmin:  quit

OK then add uid=ldap-replicator,ou=People,dc=its,dc=ac,dc=id in the ldap database, how to do that ? well i'm lazy to explain to you in too much detail (you'll be learn nothing if you just follow won't you ?).

Next prepare the access for ldap-replicator to write access to ldap database. Add this to your /etc/ldap/slapd.conf.

      ...
      access to attrs=userPassword
      	by dn="cn=admin,dc=its,dc=ac,dc=id" write
	by dn="uid=ldap-replicator,ou=People,dc=its,dc=ac,dc=id" write	← add this line
	by anonymous auth
	by self write
	by * none
      
      access to *
      	by dn="cn=admin,dc=its,dc=ac,dc=id" write
	by dn="uid=ldap-replicator,ou=People,dc=its,dc=ac,dc=id" write	← add this line
	by * read
      ...

In the master ldap server specifies the replica. Add again in /etc/ldap/slapd.conf.

      ...
      replogfile      /var/lib/ldap/replication.log
      replica uri=ldap://doraemon.its.ac.id:389
      	tls=yes
	bindmethod=sasl
	saslmech=GSSAPI
	authcId=ldap-replicator
	realm=ITS.AC.ID
      
      # OR THIS LINES IS EQUAL WITH ABOVE
      # replica uri=ldap://doraemon.its.ac.id:389
      #		binddn="uid=ldap-replicator,cn=its.ac.id,cn=gssapi,cn=auth"
      #         bindmethod=sasl
      #		saslmech=GSSAPI
      ...

Also the slave like this.

      ...
      updatedn        uid=ldap-replicator,ou=People,dc=its,dc=ac,dc=id
      updateref       ldap://nermus.its.ac.id
      ...

Since we are using SASL + Kerberos to do the replication authentication, we must ensure that slurpd have a Kerberos ldap-replicator@ITS.AC.ID principal ticket before starting. To do this, we use the LDAP service keytab we created above, like this in master ldap.

      # kinit -r 7d -k -t /etc/krb5.keytab.slurpd ldap-replicator@ITS.AC.ID

See !!! we don't have to put any password there becouse we use keytab. This is the main reason why we supplied -randkey when creating ldap-replicator@ITS.AC.ID principal.

Somehow when i write this howto, the option -k in debian slurpd is not working neither srvtab option in replica directive at slapd.conf. Hmm...so some of breaking code must be done here. Little hack on /etc/init.d/slapd script would be needed in debian system. This may be simple patch to do that.

	--- slapd.orig	2005-09-30 23:10:33.405418228 +0700
	+++ slapd	2005-09-30 23:13:21.034122200 +0700
	@@ -220,6 +220,11 @@
	 # Start the OpenLDAP daemons
	 start() {
		echo -n "Starting OpenLDAP:"
	+	
	+	# PATCH THIS
	+	echo -n "Getting ticket for ldap-replicator"
	+	kinit -r 7d -k -t /etc/krb5.keytab.slurpd ldap-replicator@ITS.AC.ID
	+	
		trap 'report_failure' 0
		if [ "$TRY_BDB_RECOVERY" = "yes" ]; then
			try_fix_db
	@@ -233,6 +238,11 @@
	 # Stop the OpenLDAP daemons
	 stop() {
		echo -n "Stopping OpenLDAP:"
	+
	+	# PATCH THIS
	+	echo -n "Removing ticket for ldap-replicator"
	+	kdestroy
	+	
		trap 'report_failure' 0
		stop_slurpd
		stop_slapd

The ticket is valid only in some amount of time if you don't specify other when creating the principal (see addprinc options in the kadmin:' shell !!!). If you know that your ticket only valid for some amount of time you need to refresh the ticket by issuing kinit again. Hmm...let's asume to use cron, so create script to run in cron about 10 minute, depend on your ticket lifetime. To find that out, we issue the command:

      # klist
      
      Ticket cache: FILE:/tmp/krb5cc_0
      Default principal: ldap-replicator@ITS.AC.ID

      Valid starting     Expires            Service principal
      09/30/05 23:29:23  10/01/05 09:29:23  krbtgt/ITS.AC.ID@ITS.AC.ID
              renew until 10/07/05 23:29:23

      Kerberos 4 ticket cache: /tmp/tkt0
      klist: You have no tickets cached

Now we ready to run slurpd. But a little note about TLS first.

      Above i'm already explain about creating Self Signed Certificate and CA Issued Certificate.
      I would like to note that slurpd is an ldap client binary code, so it would respect /etc/ldap/ldap.conf rather than /etc/ldap/slapd.conf in manner.
      
      :: When we use TLS, slurp only respecting TLS_CACERT directive, not TLS_CACERTDIR
      
      About: CA Issued Certificate
      -- CA that used by slurpd is CA that had been generated by replica, not by master
      -- So you must copy the replica's CA (slave ldap's CA) and specify TLS_CACERT to point this CA
      -- It is need to be done or you will see this error, and this is A FATAL ERROR:
      		TLS certificate verification: Error, unable to get local issuer certificate
      
      About: Self Signed Certificate
      -- CA that used by slurpd is CA that had been generated by master, not by replica (reverse by CA Issued Certificate)
      -- TLS_CACERT need to point this CA
      -- This is still error for slurpd but NOT A FATAL ERROR (slurpd can still continue)

I, myself prefer to use About: Self Signed Certificate when i don't have any CA authoritative server.

Now all have already complete to run slurpd. In the first time we need to see the debug on.

      # slurpd -f /etc/ldap/slapd.conf -d 4 -r /var/lib/ldap/replication.log
      
      @(#) $OpenLDAP: slurpd 2.2.23 (May 30 2005 08:57:10) $
              @pulsar:/home/torsten/packages/openldap/openldap2.2-2.2.23/debian/build/servers/slurpd
      Retrieved state information for doraemon.its.ac.id:389 (timestamp 1128096343.0)
      Warning: unknown replica 202.154.63.26:0 found in replication log
      begin replication thread for doraemon.its.ac.id:389
      Warning: unknown replica nirmaladewi.its.ac.id:389 found in replication log
      Warning: unknown replica 202.154.63.12:389 found in replication log

Then when we change the master database something we'll see.

      Initializing session to ldap://doraemon.its.ac.id:389
      bind to doraemon.its.ac.id as ldap-replicator via GSSAPI (SASL)
      request 1 done
      request 2 done
      request 3 done
      replica doraemon.its.ac.id:389 - modify dn "uid=crd,ou=People,dc=its,dc=ac,dc=id"	← this is dn that has been modified
      request 4 done

Some note again we'll also meet an error when using TLS.

      Initializing session to ldap://doraemon.its.ac.id:389
      request 1 done
      TLS certificate verification: Error, self signed certificate	← see, this is a self signed certificate's error
      TLS: can't connect.
      Warning: ldap_start_tls failed: Connect error (-11)

We won't find this error when we point to the right CA. Which is the right CA ? It is the replica's CA.

After we find no error again we are ready to go. I have ldap error code LDAP Eror Codes. Hope that would help to determine the error generated by slapd.

That's it !!! DAMN 2 DAYS WAY TO RUN ON SARGE !!!

Miscellaneous packages

LibNSS-LDAP

      # apt-get -u install nscd libnss-ldap

      LDAP HOST ADDRESS : 202.154.63.60 (we are installing the server / you may specify the slave)
      DN of the search base : dc=its,dc=ac,dc=id
      LDAP version: 3
      Login: No (there will be no sensitive info apart from admin)
      Readably conf files by owner : No (anon login)

Then tune the /etc/libnss-ldap.conf.

      ...
      ldap_version 3
      base dc=its,dc=ac,dc=id
      
      host 202.154.63.60
      # Or using uri like this in supporting TLS/SSL like this
      #uri 	ldaps://202.154.63.60/
      
      # You must also consider these directive if you like to use TSL/SSL when PAM communicate with LDAP
      # OpenLDAP SSL mechanism
      # start_tls mechanism uses the normal LDAP port, LDAPS typically 636
      #ssl start_tls
      #ssl on
      
      # OpenLDAP SSL options
      # Require and verify server certificate (yes/no)
      # Default is to use libldap's default behavior, which can be configured in
      # /etc/openldap/ldap.conf using the TLS_REQCERT setting.  The default for
      # OpenLDAP 2.0 and earlier is "no", for 2.1 and later is "yes".
      #tls_checkpeer yes
      
      # CA certificates for server certificate verification
      # At least one of these are required if tls_checkpeer is "yes"
      #tls_cacertfile /etc/ssl/ca.cert
      #tls_cacertdir /etc/ssl/certs
      
      # SSL cipher suite
      # See man ssl for syntax
      #tls_ciphers TLSv1
      
      # Client certificate and key
      # Use these, if your server requires client authentication.
      #tls_cert
      #tls_key
      
      # Or you even want to disable sasl like this
      #sasl_secprops maxssf=0
      ...

Configure /etc/nsswitch.conf to use the ldap module.

      passwd:         files ldap
      group:          files ldap
      shadow:         files ldap
      
      netgroup:      ldap

or like this.

      passwd:      files ldap
      shadow:      files
      group:       files ldap

We only access LDAP to obtain passwd (uid, uidNumber, gidNumber, homeDirectory, ...) and group (gidNumber, memberUid,...) information. The shadow information is not used, as the password policy is now controlled by Kerberos.

or this complex one.

      # the following two lines obviate the "+" entry in /etc/passwd and /etc/group.
      passwd:         files ldap
      group:          files ldap

      # consult DNS first, we will need it to resolve the LDAP host. (If we
      # can't resolve it, we're in infinite recursion, because libldap calls
      # gethostbyname(). Careful!)
      hosts:          dns ldap

      # LDAP is nominally authoritative for the following maps.
      services:   ldap [NOTFOUND=return] files
      networks:   ldap [NOTFOUND=return] files
      protocols:  ldap [NOTFOUND=return] files
      rpc:        ldap [NOTFOUND=return] files
      ethers:     ldap [NOTFOUND=return] files

      # no support for netmasks, bootparams, publickey yet.
      netmasks:   files
      bootparams: files
      publickey:  files
      automount:  files

      # I'm pretty sure nsswitch.conf is consulted directly by sendmail,
      # here, so we can't do much here. Instead, use bbense's LDAP
      # rules ofr sendmail.
      aliases:    files
      sendmailvars:   files

      netgroup:   ldap [NOTFOUND=return] files

The information need to export depends on your need.

Then restart nscd in order to clean the database.

      # /etc/init.d/nscd restart

Then test our nsswitch and ldap. Create user in ldap database just like other user, let's assume uid=test,ou=People,dc=its,dc=ac,dc=id, then test it with this command.

      # id test
      uid=1006(test) gid=1006(test) groups=1006(test)

Hmm... that what we want it right ??? :-)

LibPAM-LDAP

This is a choice to use ldap as the backend of PAM. In my case i use this libpam. The flow might be like this.

      First choice (the paranoid one with kerberos and full SASL)
      login → PAM → PAM/LDAP → SSL/TLS → SASL → LDAP → SSL/TLS → SASL → LDAP → Kerberos

      or
      
      First choice (the relax one without kerberos with full SASL)
      login → NSS → NSS/LDAP → SSL/TLS → SASL → LDAP

This is how to install it.

      # apt-get install libpam-ldap

Then configure /etc/pam_ldap.conf.

      ...
      ldap_version	3
      base	dc=its,dc=ac,dc=id
      
      host	202.154.63.60
      # Or using uri like this in supporting TLS/SSL like this
      #uri 	ldaps://202.154.63.60/
      
      # You must also consider these directive if you like to use TSL/SSL when PAM communicate with LDAP
      # OpenLDAP SSL mechanism
      # start_tls mechanism uses the normal LDAP port, LDAPS typically 636
      #ssl start_tls
      #ssl on
      
      # OpenLDAP SSL options
      # Require and verify server certificate (yes/no)
      # Default is to use libldap's default behavior, which can be configured in
      # /etc/openldap/ldap.conf using the TLS_REQCERT setting.  The default for
      # OpenLDAP 2.0 and earlier is "no", for 2.1 and later is "yes".
      #tls_checkpeer yes
      
      # CA certificates for server certificate verification
      # At least one of these are required if tls_checkpeer is "yes"
      #tls_cacertfile /etc/ssl/ca.cert
      #tls_cacertdir /etc/ssl/certs
      
      # SSL cipher suite
      # See man ssl for syntax
      #tls_ciphers TLSv1
      
      # Client certificate and key
      # Use these, if your server requires client authentication.
      #tls_cert
      #tls_key
      
      # Or you even want to disable sasl like this
      #sasl_secprops maxssf=0
      ...

Other line just give it commented. Well JUST WET YOUR FEED RIGHT NOW OK !!!

LibPAM-KRB5

This option might be your choice, or other's choice for simple authentication using kerberos. The flow might be like this.

      login → PAM → PAM/KERBEROS → Kerberos    

Installing this libpam-krb5 is simple.

      # apt-get install libpam-krb5

Then edit the related /etc/pam.d/* entries to use this libpam-krb5. Some of them might look like this.

      auth       sufficient   /lib/security/pam_krb5.so
      auth       sufficient   /lib/security/pam_unix.so use_first_pass
      auth       required     /lib/security/pam_env.so
      auth       required     /lib/security/pam_nologin.so
      auth       required     /lib/security/pam_deny.so

      account    sufficient   /lib/security/pam_krb5.so
      account    required     /lib/security/pam_unix.so
      account    required     /lib/security/pam_unix_acct.so

      password   sufficient   /lib/security/pam_krb5.so
      password   required     /lib/security/pam_pwdb.so use_first_pass
      password   required     /lib/security/pam_cracklib.so retry=3
      password   sufficient   /lib/security/pam_unix.so use_authtok md5 shadow nullok
      password   required     /lib/security/pam_deny.so

      session    required     /lib/security/pam_limits.so
      session    optional     /lib/security/pam_krb5.so
      session    required     /lib/security/pam_unix.so
      session    required     /lib/security/pam_unix_session.so
      session	 required     /lib/security/pam_mkhomedir.so skel=/etc/skel/ umask=0022

NOT FINISHED YET !!!! TIRED (but it's pretty enough i think)

 

- d