How the Novell Client operates during a user login

How the Novell Client operates during a user login

Unlike the Novell Client for Windows 95/98 and the earlier DOS-based clients, the Novell Client for Windows NT/2000/XP does not attempt to make an NCP connection to a NetWare server prior to an actual login or access attempt. Whereas those earlier clients would find a server, create an NCP connection and map a drive all before the Novell login dialog was actually displayed, the Novell Client for Windows NT/2000/XP only initiates a connection in response to an actual user login attempt and/or an application attempting to access a remote resource.

The following is a description of what is expected to happen on a Novell Client for Windows 4.90 SP2 for Windows NT/2000/XP machine during login of the user. The actions described assume the default & most common configuration, which is that NWGINA.DLL has been left registered as Windows primary GINA, and the "Initial Novell Login” setting in the Novell Client Properties has been left enabled.

This description focuses on user login activity only, and excludes any name resolution or NCP activity from other applications or services that may also be initializing around the same time. Activity being performed from the context of a Windows service should be considered wholly separate from the activity being performed during user login, because (a.) the NCP connections created by a service will be completely separate from the NCP connections created by the user login, because these NCP connections are authenticated as unique identities and do not share the same permissions or rights for actions requested over the respective NCP connections, and (b.) the user login code that executes in response to seeing the Novell login dialog is a specific set of checks and actions which will differ from the checks and actions performed or not performed by a particular Windows service programmatically logging in to NetWare. (The Windows service doesn't have concepts such as a "Location Profile", for example, and determines on its own what initial connection request should be made.)

Steps performed in the case of a user login in the described configuration:

1. When the Novell login dialog is initially displayed by NWGINA.DLL and the user is interacting with the Username: and/or Password: fields, no attempt to find a NetWare server or create an NCP connection has yet been made.
   
   (There are some actions other than logging in (pressing"OK") which can cause NCP connections to be created prior to login, such as using any of the browse buttons ("Trees", "Contexts", etc.). Note that if and when these actions were performed, the NCP connections they create could affect the decisions made later due to there being existing NCP connections when decisions are being made.)
   
   (Note that having LDAP Contextless Login enabled can cause LDAP connections to be created in order to perform name lookups as the user changes the Username: and/or Tree: fields, but these are LDAP connections and not NCP connections. There are only two specific cases for LDAP Contextless Login – having an IP address entered into the "Tree:" field of the login dialog and/or having "Treeless Login" enabled – that can cause the LDAP Contextless Login extension to create an actual NCP connection. Either to the address specified in the "Tree:" field of the login dialog and/or the IP address of the LDAP server itself in order to confirm what NDS tree the server is a member of and ensure the workstation can connect to it even if other name resolution methods such as SLP may or may not be able to resolve the NDS tree by name.)
   
   
2. In response to the user pressing the "OK" button on the login dialog with a valid NDS "Tree:" and/or"Server:" specified on the login dialog, along with a valid"Username:", "Password:" and "Context:" specified on the login dialog, the Novell user login code first looks at whether a specific server was specified in the "Server:" field on the login dialog.
   
   
3. If there was a string specified in the "Server:" field, the Novell user login code calls the Novell redirector to open a connection to this name as a server name. If there was not a string specified in the "Server:" field, the Novell user login code moves on to checking for the NDS tree name specified on the login dialog. (Jump to step 11.)
   
   
4. In response to the "open this name as a server name" request received by the Novell redirector, the Novell redirector will first look at whether the name specified matches the name on an existing NCP connection that has already been established during user login. (Typically, unless the user had invoked one of the browse buttons, the workstation would not have established any NCP connections yet during user login and no existing NCP connections will be found.)
   
   (Note that if the"name" is actually an IP address, the name resolution code in the Novell redirector will recognize this and turn the request into a"open a connection to this address" request instead. This in turn checks whether the address specified matches one of the address(es) for a NetWare server to which the user login has already established an NCP connection. Note "the NetWare server's address(es)" is specified here because the Novell redirector consults a list of addresses the NetWare server claims to be bound to NCP on; not just the address over which the workstation established its existing NCP connection during user login.)
   
   
5. Not finding an existing connection for the "Server:" name specified on the login dialog (which again, is typically the case), the Novell redirector then employs the name resolution methods configured in the "Protocol Preferences" tab to query any available mappings of that name to a network address. For example, SLP is queried for bindery.novell agents with a name matching the specified string; SAP is queried for type 0x0004 entries with a name matching the specified string; DNS is queried using the specified string, etc. (Note if the "name" is actually an IP address, this step is skipped and the Novell redirector proceeds directly to the step 6 process of attempting to connect to that address.)
   
   
6. If the "Server:" string on the dialog was successfully resolved to an address via the configured name resolution methods, the Novell redirector now makes the transport-level attempt (e.g. via TCP) to connect to the learned address and establish an NCP connection. If the transport-level connection attempt fails (address unreachable, etc.) and the name resolution methods provided additional addresses (NetWare server bound to NCP on multiple interfaces, etc.) the other addresses are also attempted within the "Name Resolution Timeout" period configured within the Novell Client Properties.
   
   
7. If a successful NCP connection to the server represented by the string in the "Server:" field could not be made, the Novell user login code now moves on to checking for the NDS tree name specified on the login dialog. (Jump to step 11.)
   
   
8. If a successful NCP connection to the server represented by the string in the "Server:" field has been made, the Novell user login code now queries the NetWare server regarding which NDS tree the NetWare server is a member of. If the NDS tree reported by the NetWare server does not match the string specified in the "Tree:" field of the Novell login dialog (if there is a string specified in the"Tree:" field of the Novell login dialog), then the server we have made a successful NCP connection to is considered "wrong", and the Novell user login code will move on to connecting to the NDS tree name specified on the login dialog, just as though "Server:" had not been specified. (Jump to step 11.)
   
   
9. If the NetWare server we have made a successful NCP connection to reports to be a member of the NDS tree specified in the "Tree:" field of the Novell login dialog (if there is a string specified in the "Tree:" field of the Novell login dialog), the Novell user login code still proceeds with checking for the NDS tree name specified in the "Tree:" field of the Novell login dialog. But because we have already made a successful NCP connection to a NetWare server in this NDS tree, when the logic reaches the point of "is the user already connected to a NetWare server in this NDS tree", the answer will be affirmative and the first/initial NCP connection to the NDS tree during user login will have been the server that corresponded to the "Server:" name name specified on the login dialog.
   
   
10. If the "Tree:" field on the Novell login dialog is blank, and we have successfully made an NCP connection to the server represented by the string in the "Server:" field, at this point the user login code will take the NDS tree name from the initial NCP connection and internally use that NDS tree name as though it had been entered on the Novell login dialog's "Tree:" field. i.e. If the Novell login dialog specifies a "Server:" but not a "Tree:", the NDS tree the NetWare server represented by the string in "Server:" field belongs to will become the NDS tree the user is logging into. If the "Tree:" field of the login dialog is not blank, this step is skipped.
    
    
11. If an NDS tree name has not been determined at this point, either by a string having been entered in the "Tree:" field of the Novell login dialog or from querying the NDS tree name from the NCP connection to the NetWare server specified in the "Server:" field of the Novell login dialog, the Novell user login code will abort at this point with a "tree or server cannot be found"-type status.
    
    
12. If an NDS tree name has been determined, the Novell user login code now calls the Novell redirector to enumerate all NCP connections the user login currently has established. For each existing NCP connection found, the Novell user login code compares the NDS tree name reported by the NetWare server against the string specified in the "Tree:" field of the Novell login dialog.
    
    
13. If the Novell user login code finds an existing NCP connection for an NDS tree name that matches the string in the "Tree:" field of the Novell login dialog, or the string in the "Tree:" field contains a period character (implying that the string is actually a DNS name or an IP address, not an actual NDS tree name), the Novell user login code will skip to step 15.
    
    
14. If the Novell user login code does not find an existing NCP connection reporting an NDS tree name that matches the string in the "Tree:" field of the Novell login dialog, and the string in the "Tree:" field does not contain a period character, the Novell user login code will take the string specified in the "Context:" field of the Novell login dialog and append the string in the "Tree:" field, creating a string similar to "MyOrgUnit.MyOrg.MyTree". The Novell user login code then calls the Novell redirector to open a connection to this name as an NDS tree name.
    
    The purpose of this attempt is specific to the SLP name resolution method. If the SLP name resolution provider queries for ndap.novell agents with the name "MyOrgUnit.MyOrg.MyTree", if"MyOrgUnit.MyOrg.MyTree" happens to represent a partition boundary within "MyTree", SLP is going to respond with all the replica holders of the "MyOrgUnit.MyOrg" partition. Having the Novell redirector make this query & connect to one of the replica addresses returned from SLP (if any) not only reduces the number of SLP agent URLs that must be processed, but also causes the Novell user login's first NCP connection to be to a NetWare server that also holds a copy of the NDS user object.
    
    This query is not effective through the other name resolution methods besides SLP. e.g. Typically"MyOrgUnit.MyOrg.MyTree.subdomain.domain.root" is not defined in DNS; period characters are not valid in SAP names, etc. So the purpose of the Novell user login code calling the Novell redirector to open a connection to this name as an NDS tree name is purely for the optimization that would occur if and when SLP is able to supply replica addresses in response to this query. Otherwise, SLP and all the other name resolution providers return "zero entries" and/or"invalid name", and the Novell user login code proceeds to the next step.
    
    
15. At this point, the Novell user login code takes the NDS tree string known (either because it was specified in the "Tree:" field of the Novell login dialog, or was learned when making a connection based on the "Server:" field of the Novell login dialog) and calls the Novell redirector to open a connection to this name as an NDS tree name.
    
    
16. In the case where the contents of the "Server:" field of the Novell login dialog had already caused us to have an NCP connection to a specific NetWare server in this NDS tree, or in the case where the"MyOrgUnit.MyOrg.MyTree" connection attempt in step 14 had connected the user to a NetWare server in this NDS tree, the Novell redirector ends up checking the user's existing NCP connections and finds that the user is already connected to an NDS tree of this name and returns the user's existing NCP connection. Meaning, for those cases, the call to the Novell redirector with the NDS tree name doesn't result in any new wire traffic because the Novell redirector is able to return an existing connection established during one of the previous steps.
    
    (This includes the case of where the NDS tree name is actually a string representation of an IP address. The Novell redirector will check the existing NCP connections to determine if the address matches one of the addresses reported by the NetWare server(s) the user already has an NCP connection to. If there isn't a match, the Novell redirector will initiate the transport-level attempt (e.g. via TCP) to connect to the address specified and establish an NCP connection.)
    
    
17. If the Novell redirector finds that the user doesn't have an existing NCP connection to the NDS tree name determined by the Novell user login code, the Novell redirector then employs the name resolution methods configured in the"Protocol Preferences" tab to query any available mappings of this NDS tree name to a network address. For example, SLP is queried for ndap.novell agents with a name matching the specified NDS tree name; SAP is queried for type 0x0278 entries with a name matching the specified string; DNS is queried using the specified string, etc.
    
    For large SLP and SAP environments, this can result in a significant number of answers being returned for the Novell redirector to process. Potentially the workstation will receive responses representing every NDS replica holder (i.e. NetWare server) in the entire NDS tree. The Novell redirector assimilates these responses and costs them according to the configured costing strategy (which by default is the ICMP Echo round trip time and TTL for IP, and hops for IPX).
    
    For this specific scenario, it is already implied that we do not have any existing NCP connections to the NetWare server addresses being returned through the name resolution methods. The only additional costing factor which comes into play here is whether a specific address is for the "Preferred Protocol" configured in the Novell Client Properties. All addresses for the preferred transport type (IP, vs IPX) will be considered better / lower cost than a an address for the non-preferred transport type.
    
    
18. If the NDS tree was successfully resolved to one or more addresses via the configured name resolution methods, the Novell redirector now makes the transport-level attempt (e.g. via TCP) to connect and establish an NCP connection to the address which has been deemed to have the lowest cost. If the transport-level connection attempt fails (address unreachable, etc.) and the name resolution methods provided additional addresses (NetWare server bound to NCP on multiple interfaces, etc.) the other addresses are also attempted within the "Name Resolution Timeout" period configured within the Novell Client Properties.
    
    
19. If a successful NCP connection to the NDS tree could not be made (either because the name resolution providers did not return any information for the NDS tree name queried, or none of the addresses returned were reachable), at this point the Novell user login code will fail login with a "tree or server not found"-type error.
    
    
20. The Novell user login code now has an open NCP connection to a NetWare server in the NDS tree specified or implied on the Novell login dialog. This NCP connection may be to the server specified or implied by the contents of the "Server:" field on the login dialog, or this NCP connection may have been in response to the SLP-specific "MyOrgUnit.MyOrg.MyTree" connection attempt in step 14, or this NCP connection may have been resolved and costed among all the NetWare servers returned when connecting based on just the NDS tree name specified or implied by the contents of the "Tree:" field on the Novell login dialog.
    
    
21. The Novell user login code now issues an NDS resolve name request for the object specified by the strings contained in the "Context:" and/or "Username:" fields of the Novell login dialog. The NDS API libraries use whatever existing NCP connection the user has to the NDS tree in question when making this NDS resolve name query. All of the steps up to this point have been intended to control and/or optimize what this initial NCP connection to a NetWare server in the NDS tree actually is, and ideally the user's existing NCP connection is to a server which actually has at least a readable copy of the NDS object in question.
    
    The purpose of this specific NDS resolve name request is to validate that the NDS user object specified is actually valid and simply resolves any readable copy of the object. If this NDS resolve name request returns -601 (object does not exist) or any other NDS object resolution error, the Novell user login code will fail login with a status reflecting the condition returned.
    
    
22. A successful response to this NDS resolve name request will return referrals (replica addresses) which hold a copy of the NDS object resolved according to the criteria specified in the request. (The criteria was simply a readable copy of the object at this point.)
    
    The NDS referral processing code now comes into play. (Up until now, the occasions in which there were multiple addresses to select from were name resolution method requests. Now the Novell redirector must pick from among the NDS referrals returned in an NDS name resolution request.) The Novell redirector examines the referral records returned, each of which represents a unique address for a replica holder containing the object.
    
    The Novell redirector costs the referrals to select which one would be the best replica holder to use. The highest level consideration is whether the referral address transport type (TCP, vs IPX) matches the configured "Preferred Protocol" in the Novell Client properties. All preferred protocol referrals will be considered ahead of non-preferred protocol referrals.
    
    The next level of consideration is whether the workstation is already connected to the NetWare server that a referral address represents. If the user already has an NCP connection to the server represented by the address in the NDS referral record, this entry receives a cost adjustment which will make this NDS referral entry more attractive than the non-connected NDS referral entries of the same network transport type (IP, vs IPX) are by default.
    
    Finally, each NDS referral record is costed according to the configured costing strategy (by default ICMP Echo round trip time and TTL for IP, and hops for IPX). Note at this step the ICMP Echo round trip time & TTL become cached for a default period of 60 minutes such that additional processing of the same address does not require immediately re-performing the same ICMP Echo round trip and TTL calculation.
    
    In addition, and stored separately from the cost value in which all the previous mentioned factors have been accumulated, is simply a random number which will be used as a tie-breaker for all routes which have otherwise accumulated equal costs.
    
    
23. If this NDS referral processing ultimately determines that the workstation has an existing user NCP connection over the preferred transport protocol to an NDS replica holder which contains the object just resolved, the Novell redirector will pick the referral which matches the existing NCP connection because it will have the most attractive cost calculation.
    
    If the NDS referral processing ultimately does not "bump" the cost of of any of the referrals due to existing NCP connections the user has, this means none of the replicas the user is currently connected to holds the object (or type of object; readable vs writable) being resolved, so the user must make a new NCP connection to one of the NetWare servers represented by the NDS referral records just processed.
    
    In all cases, the NDS referral processing is simply selecting "the lowest cost referral". It's just that referrals which happen to match existing NCP connections the user already established over the preferred transport protocol are always "the lowest cost referral", as described within the referral costing description above. If selecting "the lowest cost referral" causes the user to make a new NCP connection, it is because none of the user's existing NCP connections held the required copy of the object being requested. (i.e. None of the NDS referral record addresses matched existing user NCP connection addresses.)
    
    
24. So, in response to the NDS name resolve for "any readable copy of this object", the user may have been able to use the one existing NCP connection to a server in the NDS tree (if that server happened to hold a readable copy of the user object), or, in response to the NDS resolve name request, the Novell redirector selected the best-costed NDS referral address and initiated the transport-level attempt (e.g. via TCP) to connect and establish an NCP connection to the address which has been deemed to have the lowest cost. Note there is no "name resolution" involved in this connection, in the sense that SLP, SAP, DNS, etc. will not be used. The NDS referral records cite transport address(es) of the NDS replica holders, and the Novell redirector is able to initiate connection directly to these transport addresses.
    
    
25. Now that the user has an NCP connection to a NDS replica holder with a readable copy of the NDS user object (which may have been a new NCP connection, or may have been an existing NCP connection of the user), the user now reads the NDS object information to obtain the full DN and dereference any involved alias.
    
    
26. The Novell user login code now perform an NDS resolve name request for a writable copy of the NDS user object. This will again perform the same NDS referral processing & costing based on the NDS referral records returned from the new NDS resolve name response.
    
    If the NDS replica holder that was selected before (in response to looking for a readable copy of the NDS user object) also happens to be a writable replica, then the NDS referral processing is going to find this existing user NCP connection's address among the NDS referral records and it will receive the"already connected” adjustment and ultimately be determined as the lowest-cost NDS referral.
    
    If the NDS replica holder that was selected before happened to be a read-only replica, then the NDS referral processing will ultimately cost all of the NDS referrals and initiate a new NCP connection for the user to the lowest-cost writable replica holder as determined by the NDS referral processing & costing.
    

Obtaining an NCP connection to a writable copy of the NDS user object is technically the beginning of the actual NDS and/or NMAS authentication processing, which is outside the scope of this document. But the NCP connection and NDS referral processing described for the Novell user login code and its first two steps of finding a readable copy of the NDS user object and then a writable copy of the NDS user object (and the NCP connection evaluation and creation for the user this implied) is the same process which will repeat ad infinitum as the NDS & NMAS authentication code proceeds, as the user's login script processing occurs, as the user's ZENworks or other NDS-enabled applications cause additional NDS name resolution requests to be created, etc.

And overall the user should be shown to "stick with" and use its existing NCP connections until such time that an NDS name resolution request successfully returns referrals for which none of the NDS referral records matc.h an existing NCP connection the user already has connected. At which point the best-costed NDS referral is selected, a new NCP connection to that NDS replica holder created, and now this new NCP connection is among the ones the user should be shown to "stick with” until such time that another NDS referral list indicates that the user isn't already connected to an NDS replica that can satisfy the request.

For additional information about the operation of the Novell Client, see the Novell Cool Solutions AppNote entitled "Novell Client 4.9 SP2 : Initialization, Login and Settings."

.

Formerly known as TID# 10096674