Maybe this is what you want to do?
The descriptors that reference a shared socket can be used independently for I/O. However, the Windows Sockets interface does not implement any type of access control, so it is up to the processes involved to coordinate their operations on a shared socket. Shared sockets are typically used to having one process that is responsible for creating sockets and establishing connections, and other processes that are responsible for information exchange.
If not, a simple solution to the original problem to that is to to have the secondary servers connect to the primary one, and have the primary one demultiplex the data as it comes in (however you propose to handle that) and copy it to the correct "local" connection to the secondary server.
One approach might be for the secondary server to connect to the problematic socket, and identify itself as a server somehow. The primary server would echo data back out that socket when it is intended for this sub-server. Another might use a local IPC mechanism, like a named pipe, to connect to the primary server, not unlike what you were trying to do with the socket description, but with the actual data instead.
That said, this is still highly unusual. Multiplexing connections like that is generally handled at a different level (e.g. a SSH tunnel), if it is indeed necessary at all.