I also had issues installing a replica under 7.4. Here are my notes. krb4 is the new replica, krb1 and 2 the existing ones.

However a few things set up on krb4 didn't replicate to the krb1 and krb2. There were enough issues that I did a full comparison of dumps from krb1 and krb4. Use "/sbin/ipa-backup --online --data" to dump the data, untar the tar file, and look at CS-RUTGERS-EDU-userRoot.ldif. I used ldifsort.pl and ldifdiff.pl to compare the versions from krb1 and krb4, together with an awk script that normalizes entries. So I did a full comparison of ldif files (from a backup). I found three things:
dn: cn=krb4.cs.rutgers.edu,cn=masters,cn=ipa,cn=etc,dc=cs,dc=rutgers,dc=edu
changetype:modify
add:objectclass
objectClass: nsContainer
objectClass: ipaReplTopoManagedServer
objectClass: ipaConfigObject
objectClass: ipaSupportedDomainLevelConfig
-
add:ipaReplTopoManagedSuffix
ipaReplTopoManagedSuffix: dc=cs,dc=rutgers,dc=edu
-
add:ipaMinDomainLevel
ipaMinDomainLevel: 0
-
add:ipaMaxDomainLevel
ipaMaxDomainLevel: 1


dn: cn=ipa-http-delegation,cn=s4u2proxy,cn=etc,dc=cs,dc=rutgers,dc=edu
changetype:modify
add:memberprincipal
memberPrincipal: HTTP/krb4.cs.rutgers.edu@CS.RUTGERS.EDU


dn: cn=ipa-ldap-delegation-targets,cn=s4u2proxy,cn=etc,dc=cs,dc=rutgers,dc=edu
changetype:modify
add:memberprincipal
memberPrincipal: ldap/krb4.cs.rutgers.edu@CS.RUTGERS.EDU

Perhaps a cleaner solution would have been to reinit the other two from krb4, but I wasn't sure that was safe.
In addition to this, "ipa topologysegment-find domain" showed that the link to krb4 was one-way. I later realized that the repliction agreement was actually there, so it was just the topology property that was wrong. I could have fixed it to changing the attribute from left-to-right to both, using ldapmodify. What I did was to delete the topology segement and put it back. But that ended up with two replication agreements from krb2 to krb4. So I deleted the topology segment, then manually deleted "cn=meTokrb4.cs.rutgers.edu,cn=replica,cn=dc\3Dcs\2Cdc\3Drutgers\2Cdc\3Dedu,cn=mapping tree,cn=config changetype:delete" and added back the topology segment.
It's worth noting that reiniting ldap won't fix issues with replication, because only the user database is synced. Replication agreements are in cn=config. In theory deleting the topology segment and putting it back will fix a lot of issues, but not all of them.

[edit]Diagnosing permission failures

First, make sure the directory server principals are recognized by the others. E.g. on krb3
kinit -k -t /etc/dirsrv/ds.keytab ldap/krb3.cs.rutgers.edu@CS.RUTGERS.EDU
Now do
ldapsearch -Y GSSAPI -h krb1.cs.rutgers.edu uid=hedrick
for both krb1 and 2, to make sure authentiction works. I'd do that on all servers to all servers. If it's working, then the other thing to check is that the principals are in the group "cn=replication managers,cn=sysaccounts,cn=etc,dc=cs,dc=rutgers,dc=edu".
ldapsearch -Y GSSAPI cn="replication managers"
If the data isn't syncing you may want to do that on all servers.