Hide Forgot
+++ This bug was initially created as a clone of Bug #707793 +++ Description of problem: I have two separate machines running a set of VMs, each with their own private subnet. Machine A is in 192.168.166.0/24 and hosted on 192.168.0.26. Machine B is in 192.168.186.0/24 and hosted on 192.168.0.33. Within the context of IPA I am trying to set up a replica on a machine B VM and it is failing with a NullPointer exception due machine A rejecting authentication. The relevant log on machine A install is: [25/May/2011:17:34:14][http-9444-2]: TokenAuthentication: hostname=192.168.186.8 and givenHost=192.168.0.33 is different [25/May/2011:17:34:14][http-9444-2]: TokenAuthenticate authenticate failed, wrong hostname. 192.168.186.8 is the VM I'm trying to install the replica on. 192.168.0.33 is the host that the VM is running on. A workaround is to temporarily add 192.168.0.33 to /etc/hosts pointing to the hostname of the VM on machine B at least past the point where the serial number ranges are given out. After that it needs to be removed so that replication will succeed (a very dicey proposition). Version-Release number of selected component (if applicable): pki-ca-9.0.5-1.20110405T0320z.fc14.noarch
So - here is what is happening here. A is the master and has two interfaces IPa1 (hostA1) and IPa2 (hostA2) B is the clone and has two interfaces IPb1 (hostB1) and IPb2 (hostB2) 1. At the beginning of the installation, B contacts the security domain master A to log onto the security domain and be issued an installation token (cookie) It passes its "public" hostname hostB1 to the master. The master resolves the hostname and stores the resulting IP address (IPb1) in a hash table of installation tokens. 2. At some point, B contacts A to execute a servlet requiring token authentication. It contacts A using the natted interface (IPb2/ hostB2) and passes the authentication token (cookie). A contacts the security domain (which in this casee, turns out to be itself - and calls the servlet to authenticate the token (passing the token and the IP address of the original requester IPb2). 3. The token authentication servlet checks that the requester's IP matches the one in the hash table. In this case, IPb1 is not equal to IPb2 - and so authentication fails. So - possible solutions: 1. Enable a setting that would disable the IP match check. This is a bad idea. Right now, an installation requires knowledge of the cookie and the right IP. Removing this check would open up all kinds of security holes. 2. Add some kind of option to pkisilent so that the user could specify how B will communicate with the security domain. In this case, we could end up specifying hostB2 instead of hostB1 for the installation token. This is an intriguing notion, but I can very easily see it becoming problematic. In particular, consider a case where you have security domain A and clone C on the same NATTed network and master B on a different network. This solution is too rigid to be useful for the various network configurations out there. 3. Modify the token authentication servlet to read a configuration file that maps IP addresses. In this file, the admin could specify IPb2 -> IPb1, so that when the token authentication servlet sees an token authentication request from IPb2, it knows that the request really comes from IPb1. The file contents can then be removed post-installation. This seems to me to be the only reasonable solution - it does not compromise security - it is flexible enough to allow any network configuration The downside is that it is not automatic. The admin will have to do something in between if they know they are in a NATT-ed environment. I don't see another way forward unless there is some way for the server tofind out that IPb2 is the same a IPb1.
(In reply to comment #3) > So - here is what is happening here. > > A is the master and has two interfaces IPa1 (hostA1) and IPa2 (hostA2) > B is the clone and has two interfaces IPb1 (hostB1) and IPb2 (hostB2) > > 1. At the beginning of the installation, B contacts the security domain master > A to log onto the security domain and be issued an installation token (cookie) > It passes its "public" hostname hostB1 to the master. The master resolves the > hostname and stores the resulting IP address (IPb1) in a hash table of > installation tokens. IMO there is another option. At this stage B should in addition to its name send A the IP of the interface it is using - the locally know IP. I suspect it will be the same interface that would be used at a later step. Then A should see that is this additional data is provided it should save it as an alias for the peer. During the later step when the IP check fails it would see that there is also an alias IP and would try to match it too. In general case I would also prefer the logic to support list of IP aliases rather than just one. We do not need to implement the logic of detecting all possible aliases on B day 1 (this can be deferred) but matching logic and storage should assume that we are dealing with the list.
The host that doesn't know that its IP address is NATed and has no way (that I know of) to look up what its IP address appears to the outside world as. That i the problem, B tells A "my IP address is x" and A looks at the connection and says "um, I don't think so" and fails the install. I just wonder if this check is superfluous. A whole lot of stuff would have to get compromised to get to the point where you'd install a clone CA, right?
Can they just use a shared key established at the first connection that they can reuse on the second one to validate the peer? IPs never a reliable solution to check the peer identity.
Created attachment 516757 [details] patch to fix
6.2: [vakwetu@goofy-vm6 base]$ svn ci -m "Resolves #708075 - Clone installation does not work over NAT" Sending base/common/src/com/netscape/cms/servlet/csadmin/TokenAuthenticate.java Transmitting file data . Committed revision 2104. tip: [vakwetu@dhcp231-121 base]$ svn ci -m "Resolves #708075 - Clone installation does not work over NAT" common/src/com/netscape/cms/servlet/csadmin/TokenAuthenticate.java Sending common/src/com/netscape/cms/servlet/csadmin/TokenAuthenticate.java Transmitting file data . Committed revision 2105.
8.2: [vakwetu@goofy-vm4 base]$ svn ci -m "Resolves #708075 - Clone installation does not work over NAT" Sending base/common/src/com/netscape/cms/servlet/csadmin/TokenAuthenticate.java Transmitting file data . Committed revision 2110.
VERIFIED Version Info: ================================================== [root@x86_64d(106) ~] rpm -qi ipa-server | less Name : ipa-server Relocations: (not relocatable) Version : 2.1.3 Vendor: Red Hat, Inc. Release : 9.el6 Build Date: Mon 07 Nov 2011 12:00:54 PM PST Install Date: Tue 08 Nov 2011 01:19:54 PM PST Build Host: x86-001.build.bos.redhat.com ================================================== Setup Info: I used Yi's setup info. And here is the config. x86_64c.yzhang.redhat.com -- 192.168.122.105 -- Master x86_64d.yzhang.redhat.com -- 92.168.122.106 -- Replica 1/ Setup Master IPA server # ipa-server-install --setup-dns -N ; configure w/ DNS forwarder(same as local IP) 2/ Prepare replica info. on Master # ipa-replica-prepare x86_64d.yzhang.redhat.com --ip-address 192.168.122.106 3/ Copy the replica prepare file over to replica machine # scp /var/lib/ipa/replica-info-x86_64d.yzhang.redhat.com.gpg root.122.106:/var/lib/ipa/ 4/ Turn off the firewall on the replica machine. #service iptables stop 5/ Run the replica install command on the replica server # ipa-replica-install --setup-dns /var/lib/ipa/replica-info-x86_64d.yzhang.redhat.com.gpg --forwarder 192.168.122.105 Replica should be installed successfully -- Connection from master to replica is OK. Also, do a connection check to replica by running: On replica: ============================================================== [root@x86_64d(106) ~] ipa-replica-conncheck -m 192.168.122.105 Check connection from replica to remote master '192.168.122.105': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos KDC: TCP (88): OK Kerberos KDC: UDP (88): OK Kerberos Kpasswd: TCP (464): OK Kerberos Kpasswd: UDP (464): OK HTTP Server: port 80 (80): OK HTTP Server: port 443(https) (443): OK Connection from replica to master is OK. Start listening on required ports for remote master check Listeners are started. Use CTRL+C to terminate the listening part after the test. Please run the following command on remote master: /usr/sbin/ipa-replica-conncheck --replica x86_64d.yzhang.redhat.com ============================================================== On Master: ============================================================== [root@x86_64c(105) ~] /usr/sbin/ipa-replica-conncheck --replica x86_64d.yzhang.redhat.com Check connection from master to remote replica 'x86_64d.yzhang.redhat.com': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos KDC: TCP (88): OK Kerberos KDC: UDP (88): OK Kerberos Kpasswd: TCP (464): OK Kerberos Kpasswd: UDP (464): OK HTTP Server: port 80 (80): OK HTTP Server: port 443(https) (443): OK Connection from master to replica is OK. ==============================================================
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2011-1655.html