What is the limit on number of objects within a container? NDS Design class #530 indicates 100,while the advanced 4.x administration states 500. Why the discrepancy?
There is not a limitation within the base NDS - displaying the objects within a container has posedproblems in the past. With NetWare 4.01 the utility limitation was about 1,200 objects that couldbe effectively processed. With the release of 4.02 and 4.10 that limit has risen to around12,000-15,000 objects per container.
The reason that there are any limitations is that NDS conforms to the x.500 standard specifying thatdata sent back to the client will not be in a specified order. This is due to the fact that if the datawere sorted - would it be in a Spanish, French, English, or Japanese order - each would be a differentsort order. The utilities then need to sort the data (i.e. contents of a container) before displaying thatdata on the screen, hence, the limitations are based on the workstation CPU speed, RAM and diskspace as well as the length of time that the user is willing to wait for a refresh on the display.
Question: Do we want to encourage companies developing NDS NetWare 4 trees to use the CountryObject? Why or Why not?
Revised Statement 3/1/95
The use of the Country code is not required for customers desiring to connect to a public datanetwork. Regardless of how a customer connects to this service, the Country code will be part ofthe public provider's tree. The Country code provides no benefit to the private tree and only addsan additional layer to the tree and to the user's context. Therefore, regardless of a company's plansto utilize a public directory, they do not need to incorporate the Country object in their private trees.
Question: What are the benefits of using an alias?
Answer: Aliases are very beneficial for making the tree structure more usable for clients. An aliascontains very little data - hence replication traffic is only the name and some data for a pointer tothe real object. Aliases change infrequently. They only change when a) they are created b) they aredeleted or c) the real object is renamed or , deleted, or renamed. Here are some ideas of wherealiases could be used.
Alias of a user where the alias is placed near the top of the tree. This helps the mobile computer userduring authentication. Provides less that the user has to remember when away from his desk interms of context. Alias of a printer, print queue, server, server volume in a container. Placingaliases of real objects that exist elsewhere in the tree in the user's container enables the user to locatethose services without tree walking - without leaving that container.
Alias of a container provides the capability for ease of transitions. During the rename container ormove subtree there is an option to leave an alias for the container. This allows for administratorsto perform these operations within the tree and not affect the users. Realize that if this alias isopened in the utilities, you will see all of the objects beneath that container (i.e. leaf objects andother containers). These other objects are the real objects. If you delete a user (thinking that it isjust an alias) the real object is deleted.
Are there any other implications of having multiple trees on a company's internet other than havingthe clients attach to the wrong tree? I have a large account that is attempting to roll out 4.1 on theirinfrastructure. Guess what, they have three trees all with the same name. Are there any problemswith Timesync in this environment?
Having multiple trees on the same (company) internet is not a problem if all trees have uniquenames. There are companies with 100+ different named trees on the same wire - no problem! If thetrees have the same name as in the question, then clients will attach to a wrong tree by gettingattached to the first to respond server. BTW - the only way to create this situation is to create thetrees on isolated networks and then connect them - the install utility will not allow two differenttrees to be named the same on the same wire. This could create alot of frustration as users attemptto authenticate, and are refused, they then re-boot their workstation and try again and behold, theyget authenticated. The dilemma is that they won't know why it worked one time and didn't work theother three times. If a user sits in close proximity to a server in another tree, that user may never beable to get attached to the correct tree. I see this as a major headache for the corporate IS or Helpdesk... This will also create frustration when installing servers into the tree - you will install intothe tree - but do you have the right tree, with the correct containers??
TimeSync is independant of tree names and in configuring or SAPping timesync, then only placeone reference and several primaries in the entire network (for all trees). Do not allow each tree tohave it's own reference and/or primaries. The biggest problem that could occur will be if every treehas a reference server - then you have some real gotchas as different trees may have different times,and a server from tree XXX picks up time from a server in tree YYY.
The following enhancements were made to the NDS install code (DSI.NLM) effective with NetWare4.02. These enhancements provide a higher level of data integrity during install/removal of serverswithin a NetWare 4 tree. The enhancements make installation of NDS on servers and the removalof NDS from servers more reliable, more robust, and able to maintain synchronization with eachoperation.
1. Partitions will not be created during the installation of a new server. Any new containerobjects will be placed in the partition in which they were created. This helps to avoid theproliferation of partitions around the network.
2. Replicas will only be added to the server if:
a) bindery files exist on the server (i.e. the server is a 3.11/3.12 upgrade)
b) the number of replicas of a partition is less than 3
If bindery services are not required on a server - replication traffic will be lessenedwith no replica on that server.
1. There is a check to determine if it is safe to remove NDS from the server - which is doneby:
a) all replicas must have a state of "ON" - i.e. fully functioning - not in a split or joinstate, etc.
b) all servers in the replica list must have a status of "UP" - no down servers or links toservers in the replica list
This helps to insure that the removal of NDS from a server is reliable.
2. The "Remove Directory Services" process saves a mapping of names to object ids. This isstored in a file that can later be used during a re-install. This procedure provides a way torestore the trustee rights upon re-installation of the server.
This will insure that the object deletes are completed and that a re-installation can beperformed without losing the trustee's for all objects.
3. The "Remove Directory Services" process will automatically delete the server object and allvolume objects associated with that server.
This insures the full cleanup of the server objects.
To grant administrative rights to only a portion of a tree while not allowing the Sub-Treeadministrator to perform partitioning operations, use the following proceedure:
1. Create the container.
2. If you desire - make it a partition root.
3. Create the administrator user object in that container.
Then grant the following rights to that administrator:
a) All entry rights except for Supervisor
b) All attribute rights
c) Only grant read and compare rights on the ACL
d) Verify that the user has NO write rights on ANY container ACL in the tree- especially higher in the tree - ROOT
This will then restrict the administrator from performing partition operations in the tree...
Question: What are the Pros and Cons of larger versus smaller partitions in an NDS tree?
What size is a larger or smaller partition? I will give some numbers here - but realize that allnumbers for partitions are combinatorial... Larger partitions would probably have more than 3 -5,000 objects. Again - do not read the numbers as "HARD" limits (i.e. the old syndrome of onlyplacing 8 replicas of a partition in the tree)...
Perhaps a calculating example is the best way to describe this issue.
First example:
30,000 user objects, 5,000 misc objects (containers, printers, queues) in a partition.
Replicate that partition on 20 servers.
Assume that each object changes 6 attributes daily - one login will change 3 attributes.
There will be 3,600,000 changes in the network to keep this replica in sync.
(calculated by multiplying the number of objects changing, by the changes, by the serversneeded to sync with - i.e. 30,000 x 20 x 6 = 3,600,000)
Realize that this is a LARGE replica on a Large number of servers on a Large network.
Second example:
Break the partition into thirds (totals equal 30,000 users, 5,000 misc)
5,000 user objects, 1,500 misc - partition 1
10,000 user objects, 2,500 misc - partition 2
15,000 user objects, 1,000 misc - partition 3
Place partition 1 on 5 servers, partition 2 on 7 servers, partition 3 on 8 servers (total of 20 servers)
Assume each user object changes 6 attributes daily (same as above)
That means that there will be:
150,000 changes for partition 1
420,000 changes for partition 2
720,000 changes for partition 3
Total of 1,290,000 changes in the network. The synchronization traffic is only 1/3 of the originalsetup. However, there are still the SAME number of servers and SAME number of objects.
Third example:
Break the partition into sixths (totals equal 30,000 users, 5,000 misc)
4,000 user objects, 500 misc - in partitions 1-4
7,000 user objects, 1,500 misc - in partitions 5-6
Place partitions 1-4 on 3 servers and partitions 5-6 on 4 servers (total of 20 servers)
Assume each user object changes 6 attributes daily (same as above)
That means that there will be:
72,000 changes for partitions 1-4
168,000 changes for partitions 5-6
Total of 624,000 changes in the network. The synchronization traffic is only 1/6 of the originalsetup. However, there are still the SAME number of servers and SAME number of objects. Placingdata "CLOSE" to the user (i.e. keep the partitions relatively small and on smaller numbers ofservers) is important to keeping synchronization traffic to a minimum in the network.
** NOTE ** where you place partitions and how large or small they are will depend on the cost oflinks, need for access to global corporate data, bindery emulation. This is just a small "tip of theiceberg" to help you understand a little more about the possible cons of very large partitions. Thisis just a very basic answer to a very complex issue.
4 types of replicas are used within NDS.
MASTER - This is a writable replica that can also handle partition operations. There is only onemaster replica per partition. Only one partition operation is valid at any time for a partition and themaster enforces that requirement. For all non- partition operations this replica is equivalent to aread/write replica.
READ/WRITE - This is a writable replica that like the master can be updated from the client. Bothread/write and masters are valid for login and authentication requests.
READ/ONLY - This is a replica that can not be changed from the client. It will be updated with thechanged data in the replica from another read/write or master. This replica can not be used forbindery emulation due to the fact that there must be a writable replica on the server for binderyusers.
SUBORDINATE REFERENCE - This is a replica of the partition root which includes the replicalist (ring). As a child partition, it will reside on every server that holds a copy of the parent partitionbut not of itself. (i.e. this replica exists "Everywhere the parent is and the child is not". This replicais used to facilitate tree connectivity (walking the tree during resolve name requests).
Final note - there are 4 types of replicas - not just 3.
In a tree there may be many partitions, but this example will mention only two partitions A and B.Partition B is subordinate to A - that is A is the parent partition and B is the child partition. Therewill be 7 servers for this example numbered Srv1 - Srv7. Servers 1, 2, 3, and 5 hold an instance(replica) of partition A. Servers 3, 4, 5, 6, and 7 hold an instance (replica) of partition B.
Operations:
Split (create a new partition) If there is a container named C in partition B and a partition is createdfrom that container, then there will an instance of partitions B and C on servers 3,4,5,6, and 7. Thisoperation only requires the operation to traverse the network - all data for both partitions is locatedon all servers.
Join (merge with parent) If partition B is merged with A for a result of just one partition then therewill be some traffic on the wire.
Servers 1 and 2 will receive an instance of the data in partition B
Servers 4, 6 and 7 will receive an instance of the data in partition A
Once all servers that will be participating in the join operation have a replica of both partitions thenthe join will proceed. For this reason, the join operation may place data on the wire.
Many companies are placing instances (replicas) of the root partition on all or most of their serversto facilitate faster tree walking/name resolution. We have seen several tree examples recently wherethere were N servers and a replica of the root partition was on all N servers. This is not a gooddesign for several reasons. Reason 6 is probably the strongest reason for more efficient placementof the root partition.
Reason 1 - Partition operations (involving that partition) would require that every server be up andreachable. If one of those many servers were down or unreachable then the administrator could not"split or join" i.e. - create a new partition or merge with a partition with it's parent.
Reason 2 - Synchronization traffic will increase as more servers hold a copy of the root. This is anexponential problem. As objects or properties are changed or ACL's on the root, then all of thatinformation will need to sync to each of the servers holding the replicas.
Reason 3 - Each of these servers holds the same replica list and thus must be in communicationevery other server. Time to synchronize will increase linearly as the number of servers increases.
Reason 4 - NDS cleanup process occur when all synchronization has been successful. If a serveris down or unreachable then cleanup processes will not run until all servers have been reached andsynchronized to that time in the database.
Reason 5 - Increased rights for the administrators to place a replica on each server will result in adecrease in security as more persons will need to have rights to place instances of the root replicaon servers.
Reason 6 -"Every time a child partition of the root is updated (object and property changes,partitioning etc.) every server that holds an instance of the child's replica list (i.e. every server thatholds a copy of root will either have a Master, R/W, R/O, or Subordinate Reference of the childpartition). Since the SyncUpTo time vector exists on the replica list then ALL servers holding thechild replica's (i.e. subordinate references also) will be contacted for every change in that replicato update the time vector value in the replica list. Thus if all servers hold the parent (i.e. root) thenthey all will be holding a replica for the child - thus they will all be contacted for changes to objectsin the child partition. Remember that the subordinate replica contains a complete copy of theroot-most container object for that partition. It holds all ACL's, attributes, partitioning information,timestamp values for the partition, pointers to all other instances of that partition, etc. It is muchmore than just a pointer.
Solution - It is important to remember that there are tradeoffs in placement of the root partition.Many instances may bring faster name resolution, but may sacrifice performance on the WAN dueto synchronization traffic. This could also cause administrative problems by requiring that allservers be in communication and less efficient security. Though it is important to place instancesof the root partition close to the users to facilitate efficient tree walking - name resolution, it is notprudent to place an instance of the root on all servers in the tree. Instances of the root partitionshould be placed in each campus environment, hubs of the company, key locations - but not on everyserver in those locations.
In the past recommendations for large companies deploying NW4 is that they create a "sub-admin"user that has all rights to a branch of the tree. The logic was that beyond managing users, etc. thatthey could add servers to their containers without using the Admin users login.
One difference with NW 4.02 and later is that if a partition (i.e. the root partition) does not have atleast 3 replicas that when a new server is added to the tree a replica of that partition MUST be puton the new server. This requires the sub-admin to connect as the Admin user, since the sub-admindoes not have rights to do this.
A solution to this difficulty would be to partition the tree for the sub-admins. When you create thesub-admin accounts it is a good policy to partition the tree so that the sub-admins own a partitionroot and the subtree beneath that partition root. If you have a tree with the following layout:
[Root]|
OU=A
|
--------------------------
| |
OU=B OU=C
| |
--------------- --------------
| | | | | | | | | |
Other OU's for partition B Other OU's for partition C
The administrator with rights to the root and containers A, B and C needs to perform the followingsteps:
1. Creates containers B and C
2. Create the B and C partitions using partition manager - they are now partition roots
3. Creates an administrator in each of the B and C containers.
Then the sub-admins in B and C will have the authority to install servers into their respectivepartitions, place replicas upon those servers and thus manage that segment of the tree. Installing aserver into partition B or C may or may not place a replica upon the server (based upon the installrules - i.e. bindery upgrade or less than 3 replicas). If the replica is needed then the administratorwill have all rights to perform that operation. This management of the tree will not require theassistance of the administrator in container A. This allows the sub-admins in containers B and Cto be independent of each other and also of the administrator at the root of the tree.
If container B or C is not a partition root then until there are 3 instances of the root partitionadministrative rights in the root partition will be required to install a server as install will place aninstance (replica) of the partition on the server being installed.
Question:
If I install a server (ABC) into the tree and I do not place any replicas on ABC, how does NDSprovide ABC with access to the root of the tree. Is this accomplished by a subordinate reference tothe root partition ?
Answer: If server (ABC) is installed into the tree with no replicas then there are also no subordinatereferences (no parent partitions, no sub refs - remember sub refs only exist where the parent is andthe child is not). Finding of the tree from server ABC is done by using the NDS server client -which operates like the user client. It will use SAP to find the nearest server in the tree and connectto that server. Using that server then the server client is able to walk the tree.
Even though server (ABC) has no replicas - it does have NDS data. Every server in the network has4 NDS partitions (different from the logical partitions created within NDS). They are:
Central Replica Repository Server(Tip #21)
What are the goods and bads or gotchas of having a single server be responsible for allreplicas.........? Performance issues? Management issues? Configuration issues? Fault toleranceissues?
Answer:
Interesting question - we have had 5 requests in the last week for the scenario of having a singleserver or set of server be responsible for all replicas even though each replica might also exist onother servers in the tree. The largest of which had 3 central servers with 500 replicas on each ofthem (the same 500). Done correctly - this could be a decent design. We then took this to thesuperlab this last week for testing to prove or disprove our gut feelings. Herewith are our findings(advantages, disadvantages, actual results, and recommendations):
Advantages:
Having a central server makes backing up the NDS tree easier - the entire tree can be backed upfrom that one server - no WAN traffic to locate objects in other replicas. Tree walking on the centralserver is faster - on external or subordinate references.
Disadvantages:
That single server will have to communicate to ALL servers in the tree that hold any type of replica.It will be updating replicas, sub ref time stamps, external reference backlinks, etc on every server.This server will have to receive ALL updates made in the tree (i.e. object creations, deletions,modifications, login timestamps, etc). This means that every change in the network will bereplicated to this single server. Execution of DSRepair on the server holding all replicas has thepotential of consuming many hours.
Actual results:
Having a network of servers, each with it's own partition and replicated on a single server or set ofservers caused difficulties when the number of servers and partitions reached certain thresholds.In striving for 500 replicas on one server - with one instance of each on a separate server meant thatthe outlying servers had 2.88 minutes each 24 hour period to communicate with the central server(i.e. 2.88 minutes x 500 servers = 86,400 seconds - one 24 hour period). The central servers werepentiums and each replica had 100 objects. During the testing, objects were added at the rate of 1per second per replica. This means that with 300 replicas, every 300 seconds replica xxx would getan object. This is much more NDS activity than would happen on a normal business network - butwas done to stress the environment. This was to simulate 500 small branch offices with a centralsite.
As the number of servers installed reached 200, responsiveness from the central servers to theoutlying servers became strained but still functioned efficiently. As the number of servers reached300, servers experienced some communication problems due to timeouts. As server n was waitingto synchronize, there might be 10, 20 or 30 other servers ahead of it trying to talk to the centralserver. This caused timeouts on about 2% of the servers. As the number of servers reached 350servers, LAN traffic was at 400 packets per second, with the wire utilization at about 12%. Veryfew errors, but thru put was hampered due to the number of packets on the wire.
Installation of servers when under 250 performed as expected. Installation of the servers above 300consumed much more time due to the fact that the central servers - with masters - was very busysynchronizing to other servers. A test of running DSRepair on the central server took over 1 hourfor just the first phase of execution due to the number of objects (50,000+ objects, plus backlinksfor servers, etc.).
Recommendations:
More detail later in the NDS Implementation Guide...
Having a server that houses the replicas of the tree does indeed have some benefits. Usingmoderation in the placement of replicas on that server is strongly encouraged! Placing replicas ona single server should follow these thoughts. Placement of 50-120 replicas upon a server with 100to 3000 objects per replica with only 2 other instances of that replica upon other servers, will workvery well. If the number of servers in the replica rings increases - then decrease the total numberof replicas on the site server. If the number of objects increases then decrease the number ofreplicas... etc. If there are 500 replicas in the tree then place 1/5 of them on each of 5 servers at thecentral site, not 500 on one server... etc.
I have had several questions come in concerning Administrative rights within NDS and the abilityto mask those rights or to prohibit the masking of those rights.
In the following example of a tree: [Root]|
OU=A
| - AAdmin
--------------------------
| |
OU=B OU=C
| -BAdmin | - CAdmin
--------------- --------------
| | | | | | | | | |
Other OU's and objects for containers B and C
There are three admin objects AAdmin, BAdmin, and CAdmin.
Question 1 - is there anyway for the AAdmin (administrator in container A) to prohibit adminsBAdmin or CAdmin from restricting the rights for AAdmin to either containers B or C?
Answers
If the lower level administrative user has full rights to the container (i.e. BAdmin has writerights to container B) then prohibiting the BAdmin user from placing an IRF at container B andrestricting the rights to that container and below for the AAdmin user is not possible. This is dueto the architectural design of NDS to be able to place "firewalls" between administrators, businessunits, etc.
If the lower level administrative user only has partial rights to the container then the upperlevel administrator (AAdmin) could insure that he would never be blocked out of the lowercontainer, however that would not give the BAdmin or CAdmin administrators full rights.
Question 2 - is there anyway for an upper level admin (i.e. AAdmin) to prohibit admins BAdmin orCAdmin from being able to create, modify or delete data in container A?
Answer
This can be done by giving the lower administrators (BAdmin or CAdmin) all rights to theirrespective containers and explicitly only giving them NO write rights at the root or A container forany object within that container. They could thereby browse, read, and compare in the uppercontainer but would not be able to make any changes in that container.
Question: If I give an object supervisor rights to another object can I mask their rights to a specificproperty?
Answer: NO
If a object (i.e. user) is given supervisor rights to another object then that will give them supervisorproperty rights to all properties. This will supersede any specific property rights that may or mightbe granted. In other words, be careful in granting the supervisor object rights as this grantssupervisor rights to the properties of the object that can not be masked.
Question: Why can't I use a password from an NDS object to unlock the server console withinMonitor.NLM when using RCONSOLE. It currently uses the password from supervisor whichrequires bindery services on that server.
Answer: Monitor is server centric for NetWare 4. As such it uses the Supervisor object (andpassword) for any authentication. Allowing Monitor to use the password from an NDS object thathas Supervisor rights on the file server(which could be many NDS user objects) is something thatis under advisement at the moment.
A practical note: A good recommendation is to have admins enter a password when they loadREMOTE.NLM. If there are problems with NDS or if you loose your RCONSOLE session whilerunning DSREPAIR.NLM, you can still access the server using RCONSOLE.
This occurs when you have granted Supervisor rights to a container object, which would give allusers in that container those rights (Supervisor) to all objects in that container. This would includeall server objects. This right is the only right that transfers to the file system directly. Hence, yourusers have supervisor file rights to the root of every volume on each server in that container.
Questions on Bindery Emulation:
A number of 3.x programs want a SUPERVISOR account in Bindery mode. Is this the way to handlethis?
Can another server use the SUPERVISOR account created above?
Answer: NO
The supervisor is an object that only exists on a server when a bindery context is set for the serverand the replica holding that context(s) is placed on the server.
Creating a supervisor account will create an object named supervisor in the directory but thisaccount will not be available as the server supervisor in the bindery services (emulation) mode onthe server. Thus there will be two accounts - separate and distinct called supervisor. If the binderycontext is removed then access to all objects in bindery services on that server will disappear.
Question:
Answer: Login with the /b option will place the client in a bindery services mode of data retrievalfrom NDS. The effect will be the same as if the client had used NETX to login to the server. Theuser will only have access to the containers in the bindery context on that server. The user will notbe able to run the NetWare 4 utilities (they require an NDS connection). This is indeed a binderyservices connection.
Question:
If server X does not have a replica for the user, and no servers are available with a replica then canserver X continue to be used for logon using NDS?
Answer:
If server X does not have a replica containing the user object for the user loging into the system (seeNDS Tip #18) then there is no user data (i.e. public/private keys stored on that server). As such thisserver can not be used for initial login. In order to login a user/service must utilize a writableinstance (replica - either master or r/w) of the user/service data. A read/only replica or a subordinatereference can not be used for login. A server with no data also can not be used for login. This isdue to the fact that upon login there are 3 properties that are updated for the user/service.
Once a user/service is authenticated to the network, then a server with either a read/only, subordinatereference, or no replicas can also be used during the background authentication for additionalservices for the client.
One other thought... a server with no replicas does not SAP the tree name - removing replicas canreduce network SAPs.
Question: In NetWare 3 there was a server centric "Guest" account - How do I accomplish that samefunction in a NetWare 4 tree.
Answer:
1) There could be a guest account(s) set up in the NDS tree. Then rights could be granted to theseusers for access to resources (i.e. servers, volumes, services, etc) in the tree. This is the easy wayout... and requires a separate account for guest privileges. You can not have guest rights whenauthenticated as yourself.
2) A better solution with one caveat is to grant the rights that would have been granted to the guestusers to public. This will give those "guest" rights to ALL connected users (including those thatare NOT authenticated and NOT logged in). Thus a user accesses the resources (servers, volumes,services, etc) that are for guest use. The caveat is that NO authentication is required to access theseresources and this could be a weak security policy for the NDS tree.
3) The best solution is to grant the rights to [root] rather than public. This will give those "guest"rights to ALL authenticated users in the tree. Thus a user can authenticate as themselves and accessthe resources (servers, volumes, services, etc) that are for guest use. This allows for flexibility forgranting rights to public services without compromising any security.
Question: Can a user login through an alias in the bindery? in the Directory? If so, where will theuser get container login scripts from? Can rights be given to an alias for the user?
Answer: Alias objects are not valid objects in the bindery and as such are not valid in binderyservices. In the Directory, aliases are in great use. An alias is merely a pointer to a real object(server, user, queue, etc) in the Directory. The alias can be used for login/authentication. When thishappens the user will use the alias as a pointer to get to the real object. Container login scripts willbe executed from the containers of the distinguished name for the real object, not for the alias. Theeffective rights for the user will be derived from the rights for the real object and the containers inthe fully distinguished name of the real object. Rights associated with the alias are not part of theeffective rights for the user.
Note -For those that might be familiar with this functionality in 4.01. This was different due to theway that Login.exe functioned. That has been corrected for the utilities shipped with 4.02 and 4.10.
Question: It has been mentioned that there were ways that you could login to the Directory withouttaking up any connections on any servers.... HOW? But to browse the tree (e.g. access and openthe Directory I'd think you'd have to be logged in...)
Answer: The key here is the definition of the types of connections. Here are the definitions of thethree types of connections.
Not_Logged_In - this is a connection from a client to a server. There has been noauthentication data (username/private-public key) exchanged between the client and server. It ismerely a physical connection and is usually the result of a server responding to a Get Nearest Serverfrom Netx or the VLM's. From this connection the client may exercise any rights granted to Publicin the Directory. This is usually just access to the Login directory on the SYS volume.
Authenticated - this is a connection where the client has retrieved the private key (throughthe exchange of username/password data). This connection is not licensed. There are no physicalserver resources (print queues, printers, drives mapped, etc) associated with this type of connection.
Licensed - this connection is an authenticated connection that is using a physicalresource on the server and as such will consume 1 license from the pool of licenses for that server.
NDS connections are "free" - that is authenticated but not licensed. The way that you could browsethe Directory without taking up a licensed connection would be to authenticate to the network. Youmust be logged in and authenticated to run the utility. This gives the client an authenticated but notlicensed connection. Then by having a copy of NWADMIN or some other browser (such as anappware application) on the client local drive (so that a MAP is not needed to a NetWare server),you could run the browser and walk the NDS tree. Because these connections are "free" the clientwill be able to walk the entire tree - across servers without being licensed.
Question:
With this tip regarding the Supervisor account, I'm not sure on a couple of things. Bycreating the bindery context, does this automatically create the user supervisor? Does usersupervisor then have all rights to the container as in standard 3.12? In order to set apassword, we would have to login via bindery emulation and change the password. Whenthe user is created, I assume he is created with no password. Would it be wise to have theSupervisor user created with some Admin user password?
Answer:
There is a (bindery) Supervisor account created for every NetWare server that is installed.This account is created regardless if the administrator installs NDS on that server.Additonally, the Supervisor user exists whether a Bindery Services Context on the server isset. The Supervisor user is stored in the Bindery Partition which is one of the four partitionsthat exists even if NDS is not installed on the server. (Note: the other three partitions beingSchema, System, and External References).
Remember, that the Supervisor user is a server-centric user and concept that only applies tothe individual server. The Supervisor user has all rights to the server (just like NetWare 3).Also, if there is a Bindery Services Context(s) set on the server then the Supervisor user willautomatically have all rights to its bindery, which includes all the bindery objects in thecontainers (OUs) where the server context points.
The Supervisor user does not show up in the NDS tree, because it is a server-centric(bindery) object not an NDS object.
The Supervisor user created will always have a password assigned. This was not the casein NetWare 4.01 because the person installing the server (usually Admin) did not have tohave a password. The Supervisor user receives its password according to the followingconditions:
Safeguard the password for the Supervisor. The password that the Supervisor is assigned isnot dependent on other the user that installs the new NetWare 4 server in to the tree. Forexample, if the Admin user installs the server and the Supervisor user is assigned the Adminuser's password then when the Admin user changes its password the Supervisor passworddoes not change.
Question:
When resolving a name in NDS, lets say I need to walk the tree upward to resolve a nameand 3 replicas of the parent partition exist. The cost to communicate to all replicas is thesame. Which replica will be used to resolve the name? Is there a set rule?
Answer:
During the resolve name operation, if the NetWare 4 server that the client is currentlyaccessing does not contain the taraget object information the resolve name operation willhave to walk the tree. Assuming