Leveraging Aliases in a Contextless Login Solution
Novell Cool Solutions: Trench
By Chris Moore
Digg This -
Posted: 14 Mar 2002
We had used a client "contextless login" product that was unsupported but developed and offered on Novell's site. It tested out and worked well in our 4.11 environment. When we upgraded to 5.1, it took minutes for the userid search to complete so we discontinued its use. We still wanted to remove context issues from our user logins because employees would routinely cross organizational lines to complete work and in so doing would be required to work on multiple workstations. Since the contexts would be set differently on each machine, the user could not login and would call the help desk. When the contexts were changed, the next day the original user of that PC would not be able to login because their context was now incorrectly set for their userid.
We created a "users" container and decided to create an alias for each user account and put the alias in the users container. A Novell utility that searches the tree, container and sub-containers, and then creates aliases for each account gave us the idea. If it was easy to create aliases, we could change the context of each workstation via ZENworks and be done. The advantages and issues we considered are listed here:
- A single context that contained an alias of each account would take "context" out of the picture when the user logged in. The user could seamlessly go to any computer in the organization and login without changing the context. This also helped the original user of the machine, since their context had not been changed for someone else (affecting their login).
- Since the aliases were in the same NDS partition, there was no tree walking to authenticate the users. The aliases and the actual userid's were in the same partition.
- Since the alias is just a pointer, it holds no properties. Users logging in still show their full context ID at the workstation and in NDS. Login scripts that run are still being run from their userid context because the alias just redirects the call to the actual userid. All administration of the user accounts, like how they are organized in the tree, is completely unchanged. Adding the "users" container and aliases just added a "contextless login" effect to the user login experience.
- Container names can be changed on the fly since user logins are no longer impacted. This allows us to change container names to reflect organizational changes without factoring in local workstation changes, context updates, notifications, change controls, ZENworks registry changes, timing issues, etc. The alias simply redirects the login call to the actual userid. NDS would take care of the container renames and the alias/userid relationship is unchanged.
- We created a ZENworks application object that changes the workstation registry to reflect the "users" container change. Since the userid and alias both exist, there is no transition issue to contend with.
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com