Environment
Situation
Resolution
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.
- 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.) - 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.
- 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.)
- 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.) - 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.)
- 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.
- 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.)
- 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.)
- 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.
- 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.
- 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.
- 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.
- 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.
- 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. - 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.
- 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.) - 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. - 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.
- 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.
- 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.
- 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. - 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. - 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.) - 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.
- 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.
- 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.
Additional Information
Formerly known as TID# 10096674