| [1662] | 1 | How to migrate from SSL authentication to GSSAPI authentication | 
|---|
|  | 2 | =============================================================== | 
|---|
|  | 3 |  | 
|---|
|  | 4 | :author: Edward Z. Yang <ezyang> | 
|---|
|  | 5 | :author: Geoffrey Thomas <geofft> | 
|---|
|  | 6 |  | 
|---|
|  | 7 | NOTE: This document is strictly for HISTORICAL purposes.  It may | 
|---|
|  | 8 | come in handy if you ever need to migrate from SSL to GSSAPI on | 
|---|
|  | 9 | another LDAP setup, though!  This assumes that ldap service keytabs | 
|---|
|  | 10 | are setup properly on all hosts involved. | 
|---|
|  | 11 |  | 
|---|
|  | 12 | ---- | 
|---|
|  | 13 |  | 
|---|
|  | 14 | On $CONSUMER (e.g. real-mccoy.mit.edu) | 
|---|
|  | 15 |  | 
|---|
|  | 16 | To cn=replica,cn="dc=scripts,dc=mit,dc=edu",cn=mapping tree,cn=config: | 
|---|
|  | 17 | Add nsDS5ReplicaBindDN: uid=ldap/$PRODUCER,ou=People,dc=scripts,dc=mit,dc=edu | 
|---|
|  | 18 | This tells the CONSUMER to accept replication pushes from PRODUCER. | 
|---|
|  | 19 | However, PRODUCER is not configured yet, so you should keep | 
|---|
|  | 20 | the cn=repman,cn=config entry which is old style. | 
|---|
|  | 21 |  | 
|---|
|  | 22 | Create uid=ldap/$PRODUCER,ou=People,dc=scripts,dc=mit,dc=edu | 
|---|
|  | 23 | uid: ldap/$PRODUCER | 
|---|
|  | 24 | objectClass: account | 
|---|
|  | 25 | objectClass: top | 
|---|
|  | 26 | This creates the LDAP user entry for GSSAPI authentication via the | 
|---|
|  | 27 | service keytab of LDAP replication.  This information /is/ | 
|---|
|  | 28 | replicated, so if you felt like it you could create entries for all | 
|---|
|  | 29 | PRODUCERS (which, in full multimaster replication, is all servers.) | 
|---|
|  | 30 |  | 
|---|
|  | 31 | ---- | 
|---|
|  | 32 |  | 
|---|
|  | 33 | On $PRODUCER (e.g. cats-whiskers.mit.edu) | 
|---|
|  | 34 | You will destroy and recreate a replication agreement (well, | 
|---|
|  | 35 | actually, ldapvi will attempt to create and then destroy the old | 
|---|
|  | 36 | agreement). | 
|---|
|  | 37 |  | 
|---|
|  | 38 | To cn="SSL Replication to $CONSUMER",cn=replica,cn="dc=scripts,dc=mit,dc=edu",cn=mapping tree,cn=config | 
|---|
|  | 39 | Replace all instances of "SSL Replication" to "GSSAPI Replication" | 
|---|
|  | 40 | Replace the number on the entry with 'add'; to indicate destroy/recreate | 
|---|
|  | 41 | Replace nsDS5ReplicaBindDN: uid=ldap/cats-whiskers.mit.edu,ou=People,dc=scripts,dc=mit,dc=edu | 
|---|
|  | 42 | (instead of cn=repman,cn=config) | 
|---|
|  | 43 | Replace nsDS5ReplicaTransportInfo: LDAP | 
|---|
|  | 44 | (instead of SSL) | 
|---|
|  | 45 | Replace nsDS5ReplicaPort: 389 | 
|---|
|  | 46 | (instead of 636) | 
|---|
|  | 47 | Replace nsDS5ReplicaBindMethod: SASL/GSSAPI | 
|---|
|  | 48 | (instead of simple) | 
|---|
|  | 49 | Remove nsDS5ReplicaCredentials | 
|---|
|  | 50 |  | 
|---|
|  | 51 | Here are some search-replace lines that will probably do what you want, | 
|---|
|  | 52 | but be sure to double check how many substitutions were made. '<,'> lines | 
|---|
|  | 53 | should exclude the cn=replica section. | 
|---|
|  | 54 |  | 
|---|
|  | 55 | # n = NUMBER OF SERVERS - 1 = 4 | 
|---|
|  | 56 | # n*3 substitutions | 
|---|
|  | 57 | :%s/SSL Replication/GSSAPI Replication/g | 
|---|
|  | 58 | # n substitutions | 
|---|
|  | 59 | :'<,'>s/cn=repman,cn=config/uid=ldap\/$HOST,ou=People,dc=scripts,dc=mit,dc=edu/g | 
|---|
|  | 60 | :%s/simple/SASL\/GSSAPI/ | 
|---|
|  | 61 | :%s/nsDS5ReplicaPort: 636/nsDS5ReplicaPort: 389/ | 
|---|
|  | 62 | :%s/SSL/LDAP/g | 
|---|
|  | 63 | :%s/^nsDS5ReplicaCredentials.\+\n//g | 
|---|
|  | 64 | :'<,'>s/^nsds5replicareapactive: 0\n//g | 
|---|
|  | 65 | :%s/^[1-9] /add /g   # fix if more than 9 servers | 
|---|
|  | 66 |  | 
|---|
|  | 67 | There is some cleanup that needs to happen after these values change; | 
|---|
|  | 68 | I had luck forcibly rebooting the servers and making LDAP cleanup | 
|---|
|  | 69 | after an unclean shutdown.  You can tell if this cleanup is necessary | 
|---|
|  | 70 | if LDAP refuses to start replication sessions.  This issue is known to | 
|---|
|  | 71 | clear up after several reboots or by destroying and recreating all | 
|---|
|  | 72 | replicas. | 
|---|
|  | 73 |  | 
|---|
|  | 74 | ---- | 
|---|
|  | 75 |  | 
|---|
|  | 76 | Once everything is on the new replication and you verify it's working | 
|---|
|  | 77 | correctly, you should then clean out the SSL configuration (most | 
|---|
|  | 78 | notably, turn nsslapd-security off. Despite its ominous name, it only | 
|---|
|  | 79 | controls SSL authentication, not GSSAPI authentication.)  You will need | 
|---|
|  | 80 | to take the server offline to do that; edit | 
|---|
|  | 81 | /etc/dirsrv/slapd-scripts/dse.ldif | 
|---|
|  | 82 |  | 
|---|
|  | 83 | When that's gone, there may be some vestigial SSL configuration left. | 
|---|
|  | 84 | Scripts specifically had the following sections that needed to be | 
|---|
|  | 85 | cleaned up: | 
|---|
|  | 86 |  | 
|---|
|  | 87 | cn=RSA,cn=encryption,cn=config | 
|---|
|  | 88 | (whole thing) | 
|---|
|  | 89 | cn=encryption,cn=config | 
|---|
|  | 90 | nsSSL3: on [change to off] | 
|---|
|  | 91 | nsSSL3Ciphers: +rsa_rc4_128_md5 [delete] | 
|---|
|  | 92 | cn=config | 
|---|
|  | 93 | nsslapd-sslclientauth: on [change to off] | 
|---|