RSS
|
  Integrating NetWare And Windows NT |
|
In most cases, dynamic account creation and removal should be an acceptable solution. If, however, you allow users to customize their settings (color scheme, background, bitmaps and so on), you should also consider enabling roaming profiles, which we'll discuss later. If your user base does not tend to move from one machine to another, you should consider not making your accounts volatile. If nothing else, this solution will decrease login time by a few seconds, as the system won't need to copy the default profile directory. Administration Objects To set up Workstation Manager, a snap-in module must be installed in Novell's NWAdmin, which creates NT Configuration objects. These objects control how Workstation Manager will process accounts. They allow you to specify which NetWare Client for NT tabs are displayed at login time, what login scripts and what policy files are used, and how local accounts are created, for example. Each NT Configuration object can be assigned to a user, group or OU (organizational unit). Here at the CAE Center, we have created two different NT Configuration objects. The objects are Normal Users, our default type, and Administrators. The majority of our users fall into the Normal User object type--these are our student users. Even though you may not want to treat your users like students at a university, the process is more or less the same for a corporate environment. The primary difference between Normal and Administrator NT Configuration objects is that the latter is added to the NT Administrators group, whereas Normal User profiles are associated with each of our OU objects in the NDS tree. Our configuration specifies that a dynamic temporary account should be created on a Windows NT machine when a user logs in and that a policy file should be applied andstored on the workstation. We chose to keep the policy file stored on the local workstation since faculty members may have enabled Workstation Manager on their personal office machines, and we don't want to overwrite their configurations with our own lab configuration. We do, however, want them to use our facilities from their offices. It's All About Trust One drawback to this model is that you need to trust every administrator in your tree. Should you set up your workstations to use a certain set of policies, an administrator in a different location of the NDS tree could create his or her own NT Configuration object to gain access to your NT workstations. Another problem we've identified with this approach pops up when a Windows NT Configuration object is associated with a group object. If a user is a member of more than one group, it is impossible to predict which NT Configuration object will be used at login time. With a bit of planning on how to set up the associations, this problem can be avoided by associating configuration objects with an OU or an individual user. If you associate them with group objects, any user that belongs to more than one group will have the desired NT configuration object associated with the appropriate user object. This will guarantee which NT configuration is used--user objects have the highest precedent in determining the NT configuration. The above trust and group problem should be addressed by the client that will ship with Novell's NetWare 5 and the Z.E.N.works tool. This new client will let administrators control settings for both user and workstation objects--including policy information, which print drivers should be installed, the enabling of roaming profiles and Client32 configuration. With the full version of Z.E.N.works, administrators can set user login restrictions for each workstation. Additionally, because other administrators can have their access blocked to NT workstation objects in the tree, they will be unable to make modifications to them. A fourth solution to the integration dilemma is to have your NT workstations speak native NDS. With Novell's NDS for NT, users authenticate to the domain under NDS control; administrators simply add users to the domain object under NDS. This option requires a bit more administrative work to get the environment up and running, but should save time in the long run, especially if you are using applications that require authentication to an NT Domain, such as Microsoft Exchange and other BackOffice applications. But there is one problem with the NDS for NT solution--password synchronization. Because NDS and NT use different encryption methods to store passwords, NDS for NT stores the MD5-encrypted version used by NT in a separate NDS attribute. Should you have a homegrown or third-party utility for changing passwords or use SETPASS or the DOS-based NetWare Administrator, your NDS and NT passwords will get out of sync, with only the NDS password changed.
|
 |
 Print This Page |
