Difference between revisions of "Unwanted server connections"

From MicroFocusInternationalWiki
Jump to: navigation, search
(Take a packet trace)
m (Added missing "not")
Line 51: Line 51:
 
=Take a packet trace=
 
=Take a packet trace=
  
When you have gone through the various things that might cause unwanted connections and you still have found out what the problem is in your case, the best option is to take a packet trace of the traffic generated by the client. This often helps seeing what caused a particular connect to be established.
+
When you have gone through the various things that might cause unwanted connections and you still have ''not'' found out what the problem is in your case, the best option is to take a packet trace of the traffic generated by the client. This often helps seeing what caused a particular connect to be established.
  
 
=Further reading=
 
=Further reading=

Revision as of 18:57, 9 October 2007


In a tree with multiple servers, you often see clients making connections to seemingly unrelated server. In most cases, these are unlicensed connections and don’t pose any problem. However administrators nevertheless often want to limit the connections just to those servers that the user really needs. The bad news first: there is no hard way to limit a user to certain servers only. While the user may not have any rights to resources on the server, he still may be able to make a connection just to read from NDS. So this document is no failsafe way to prevent unwanted connections, but just a guide to help reducing these unwanted connections to as few as possible. To limit the unwanted connections, it is important to understand the various mechanisms that can lead to unwanted connections. If you understand why in your environment, an unwanted connection is established, it is generally quite easy to eliminate the cause.


The “default server” attribute

The single most important rule to reduce unwanted connections is to correctly set the “default server” NDS attribute for each user. The most important function of this attribute is that it is read at login time and is used by the client to make the primary user connection to that server. However for this to work, the default server must have a master or r/w replica of the partition holding the user object. Only servers holding a writable replica of the user object can be used for the primary connection. If the default server does not have such a replica, the primary user connection will be made to a different server chosen by the client among all possible candidates. Note: The “default server” attribute is internally called “message server” and is used for different purposes as explained at http://forums.novell.com/showpost.php?p=210709&postcount=3


Protocol considerations

For the IPX protocol, there is a set parameter called “reply to get nearest server” which allows you to control whether a server replies to requests for finding a server. By setting this option to OFF, you can avoid a server to reply and thus that server will never be chosen for “random” initial connections, only for connections that explicitly ask for this server. For IP, there is no equivalent setting. Don’t believe people that suggest you to use the “reply to get nearest server” option in an IP only environment. It will not have any effect. This is because the main name resolution Novell uses for IP is the SLP protocol, a protocol which does not have a functionality equivalent to the nearest server requests. From the protocol point of view, the most important suggestion for avoiding unwanted connections is to avoid randomness. This translates to the more specific following rules:

  • In an IPX environment, use “Set reply to get nearest server = OFF” on servers which you don’t want users to connect to automatically.
  • Avoid clients with both IPX and IP support installed at the same time (there is no problem with servers doing both IPX and IP
  • For IP environments, use the SLP protocol as main name resolution protocol and setup an SLP Directory Agent so that you don’t have to reply on multicast replies.


Client settings

In the client settings, it is important to correctly set the default tree, context and the preferred server. The preferred server is the most important option as it specifies which server the client should try to connect to at startup. The context is also very important as an invalid context setting can cause unwanted connections due to tree walking (more on tree walking in the next section). Another client option which can influence server connections is the “ip address costing” setting. For an explanation on address costing, see TID10053626. IT is important that if address costing is set to use ICMP (which is the default), then your network should be such that ICMP packets are not blocked by firewalls. If you block your ICMP traffic, then you should change the address costing option for your clients.


Tree walking

<todo>


Licensing

If you are using limited connection licenses in a NetWare 5.x or 6.x environment, then you should be aware that licensing will force a connection to the server with the master replica of the partition holding the connection license certificate. This is not the case if you have unlimited licenses.


NMAS

Starting with the Novell client 4.90, Novell has included the NMAS client with the Novell client and the NMAS client is installed by default. However once you have an NMAS client installed, the login process will actively search for a server running NMAS to perform its login. Only servers running eDirectory 8.7.x or later will have a sufficiently new NMAS to server these clients. IF you have a mixture of servers with older eDirectory versions and eDirectory 8.7.x or later, then the initial login will always be done through an eDirectory 8.7.x server, even if that is not the default server for the user. So it is very important to only install the NMAS client on your workstations if you really need it and if all your servers are running eDirectory 8.7.x or later.


ZENworks Desktop Management

<todo>


Take a packet trace

When you have gone through the various things that might cause unwanted connections and you still have not found out what the problem is in your case, the best option is to take a packet trace of the traffic generated by the client. This often helps seeing what caused a particular connect to be established.

Further reading

  • How the Novell Client operates during a user login - TID10096674
  • How Novell Clients Cost Addresses - TID10053626
  • Users are getting unwanted connections to NetWare server. - TID10051595
  • How to troubleshoot unwanted connections--January, 2000 - TID10024928
  • Workstation getting connections to the wrong server. - TID10024809
  • Setting "Reply to Get Nearest Server" is turned off but users - TID10022977
  • Troubleshooting unwanted connections - TID10014517