I am planning to move our internal servers to the latest Sametime servers which are using a different LDAP. I have constructed managed-community-configs.xml to redirect the clients to the new Community server sitting behind a DNS alias of sametime.acme.com whilst resetting the client and automatically signing them in to the new servers using Notes client single sign on but I kept having a problem when the client tried to log in to the new Community server.
I found that the client wouldn’t log in to the new server using the Notes single sign on method. This process sends the Notes ID to the Community server (or another Domino server). Domino then checks the Notes ID and then sends back an LtpaToken to the Notes client. The Notes client sends the same LtpaToken to the Community server which Sametime uses to authenticate the user.
This really frustrated me. I couldn’t work out why this was happening. I enabled Wireshark trace and compared a successful connection to another server with the failing one. I found that the packets were similar up until a point and then there was a FIN, ACK. This normally means one of the host terminates the connection which seemed odd.
I spoke with a colleague who is a goldmine of Domino knowledge and after a bit of experimentation we found that when I try opening sametime.acme.com in the Notes client (Ctrl + O) it failed whilst it worked when opening a database for the actual Domino server ie sametime004.acme.com worked.
When putting a trace on the client I got the following:
Using address 'x.x.x.x' for sametime.acme.com on TCPIP
Connected to the wrong server Sametime/Servers/ACME using address x.x.x.x
Using address 'sametime.acme.com' for sametime.acme.com on TCPIP
Unable to connect to sametime.acme.com on TCPIP (The server is not
responding. The server may be down or you may be experiencing network
problems. Contact your system administrator if this problem persists.)
The server document does not have sametime.acme.com listed but sametime004.acme.com since that is the name of the Domino server. I changed the name of the fqhn on the basics tab to sametime.acme.com and restarted the server. Now, I could access a database using sametime.acme.com.
Going back to the Wireshark trace it looks like the FIN, ACK was because the Notes client was stopped from connecting to the Domino server due to the different names.
My colleague then came up with NETWORK_SPRAYER_ADDRESS. This notes.ini value is described here.
When a notes client connects to a Domino server part of the protocol
exchange includes the notes client telling the server what it thinks
the server's name is.If the names do not match, the connection is
terminated. This mechanism is part of the code which supports partitioned
servers running on the same IP address. However, because of this
algorithm, we cannot use network sprayers in front of Domino servers.
When a Notes client uses a Network Sprayer address as a Domino server
address, the network sprayer may make the final connection to any of
the Domino servers behind it. If the name supplied by the client is not
the Domino server name of the selected server, the connection will be
broken. This fix provides a mechanism to skip the server name checking
to allow this configuration to work.
I stopped Domino, added NETWORK_SPRAYER_ADDRESS=* and then started Domino. On testing I could open a database using sametime.acme.com and sametime004.acme.com.
When testing managed-community-configs.xml my Notes client was signed in fine to the new Community server!
The crux is that the problem was because I was using a DNS alias to connect to Domino which didn’t match the actual Domino server name. Sametime doesn’t care normally but the Notes client obviously does. Using NETWORK_SPRAYER_ADDRESS tells Domino not to care and to allow the client to connect.