Account Management Administration Guidegwise.itwelzel.biz/Novellpdf/Novell Account Management...

Account Management Administration Guide

November 14, 2000Novell Confidential

Manual Rev 99a27 18 April 00

Legal NoticesNovell, Inc. makes no representations or warranties with respect to the contents or use of this documentation, and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. Further, Novell, Inc. reserves the right to revise this publication and to make changes to its content, at any time, without obligation to notify any person or entity of such revisions or changes.

Further, Novell, Inc. makes no representations or warranties with respect to any software, and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. Further, Novell, Inc. reserves the right to make changes to any and all parts of Novell software, at any time, without any obligation to notify any person or entity of such changes.

This product may require export authorization from the U.S. Department of Commerce prior to exporting from the U.S. or Canada.

Copyright © 1993-2000 Novell, Inc. All rights reserved. No part of this publication may be reproduced, photocopied, stored on a retrieval system, or transmitted without the express written consent of the publisher.

U.S. Patent Nos. 5,608,903; 5,671,414; 5,677,851; 5,758,344; 5,784,560; 5,794,232; 5,818,936; 5,832,275; 5,832,483; 5,832,487; 5,870,739; 5,873,079; 5,878,415; 5,884,304; 5,913,025; 5,919,257; 5,933,826. U.S. and Foreign Patents Pending.

Novell, Inc.1800 South Novell PlaceProvo, UT 84606U.S.A.

www.novell.com

Account Management Administration GuideNovember 2000104-001329-001

Online Documentation: To access the online documentation for this and other Novell products, and to get updates, see www.novell.com/documentation.

Account Management Administration Guide104-001329-001



Novell TrademarksConsoleOne is a trademark of Novell, Inc.eDirectory is a trademark of Novell, Inc.NDS is a registered trademark of Novell, Inc., in the United States and other countries.NDS Manager is a trademark of Novell, Inc.NetWare is a registered trademark of Novell, Inc., in the United States and other countries.Novell is a registered trademark of Novell, Inc., in the United States and other countries.Novell Client is a trademark of Novell, Inc.Novell Directory Services is a registered trademark of Novell, Inc., in the United States and other countries.

Third-Party TrademarksAll third-party trademarks are the property of their respective owners.



Manual Rev 99a25 22 March 00

Contents

Account Management 7

1111 Installation 9Minimum System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Windows NT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10Solaris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Installing Account Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10Windows NT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Linux or Solaris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Configuring Account Management on Linux or Solaris . . . . . . . . . . . . . . . . . . . . . 13Configuring Single Sign-on on Linux and Solaris. . . . . . . . . . . . . . . . . . . . . . . . 15

Uninstalling Account Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Windows NT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Linux and Solaris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2222 Managing Windows NT Domains 23Understanding Account Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23New Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Domain Cache Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Event Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Domain Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Dial In Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Anonymous Password Change. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Password Filter Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Managing Windows NT Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Creating a New Local Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Creating a New Global Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Creating a New Workstation Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Adding an NDS User to an NT Domain. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Adding an NDS User to a Local or Global Group. . . . . . . . . . . . . . . . . . . . . . . . 32Deleting an NDS User from an NT Domain . . . . . . . . . . . . . . . . . . . . . . . . . . 33Deleting an NDS User from a Local or Global Group . . . . . . . . . . . . . . . . . . . . . 34Setting a User's Primary Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Enabling Performance Enhancement Settings . . . . . . . . . . . . . . . . . . . . . . . . . 36Using NT Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Using the Replica Advisor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Contents 5



Manual Rev 99a25 22 March 00

Managing Security on Windows NT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Synchronizing a User's NDS and NT Passwords . . . . . . . . . . . . . . . . . . . . . . . 41Setting Intruder Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3333 Managing Linux and Solaris Accounts 43Understanding NDS-Based Account Management on Linux and Solaris . . . . . . . . . . . . . 43

Understanding Account Management Components . . . . . . . . . . . . . . . . . . . . . . 44Understanding Account Management Security . . . . . . . . . . . . . . . . . . . . . . . . 44Understanding Account Management Support for RFC 2307 . . . . . . . . . . . . . . . . . 45Understanding Single Sign-on Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . 46Understanding Trustee Assignments and Rights for Account Management Objects . . . . . 47

Migrating User/Group Accounts to NDS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Setting Up for Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Migrating Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52Activating and Verifying Migrated Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . 53Deleting Migrated Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54Managing Authentication, Accounts, and Passwords . . . . . . . . . . . . . . . . . . . . . 56

Migrating UNIX User and Group Accounts to NDS . . . . . . . . . . . . . . . . . . . . . . . . 58Configuring the unix2nds Migration Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Using the unix2nds Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60Migrating UNIX Groups to NDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62Migrating UNIX Users to NDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62Migrating UNIX Passwords to NDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Managing UNIX User and Group Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63Creating a UNIX Group, Template, and User Object . . . . . . . . . . . . . . . . . . . . . 63Assigning UNIX Attributes for Group, Template, and User Objects . . . . . . . . . . . . . . 65Viewing UNIX Configuration Object Details . . . . . . . . . . . . . . . . . . . . . . . . . . 67Modifying a UNIX Workstation Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Optimizing Account Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68Using the nds_uamcd Cache Daemon . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68Providing a Cache for the Most Common Name Service Requests . . . . . . . . . . . . . . 69

Troubleshooting Account Management on Linux and Solaris . . . . . . . . . . . . . . . . . . . 70Migrated Users Are Not Able to Log In . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70Verifying Whether NDS Authentication Is Working . . . . . . . . . . . . . . . . . . . . . . 71A User with Root Equivalent Rights Is Not Able to Change the Passwords of Other Users . 71A User Is Not Able to Log In . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72Password Expiration Information for the User Is Not Available . . . . . . . . . . . . . . . . 72

6 Account Management Administration Guide




Account Management

Account Management is a directory-enabled application that simplifies and unifies the management of user profiles on Windows* NT*, Solaris*, and Linux* networks. It leverages all the scalability, utility, and extensibility of NDS® eDirectoryTM and adds crucial integration capability. With Account Management, you can eliminate many of the complexities of administering a mixed-platform network while smoothing over compatibility issues.

This manual contains information on how to install, configure, and manage Account Management on the Windows NT, Solaris, and Linux network operating systems.

Account Management 7




1 Installation

This section describes how to install Account Management on Windows* NT*, Solaris*, and Linux*.

Minimum System RequirementsAccount Management runs on the following platforms:

! �Windows NT� on page 9

! �Linux� on page 10

! �Solaris� on page 10

Windows NT" Windows NT Server 4.0 with Service Pack 4 or later and an assigned IP

address.

" A Pentium* 200 computer with 64 MB of RAM and a monitor color palette set to a number higher than 16.

" Administrative rights to the NT server and to all portions of the NDS tree that contain domain-enabled User objects. For an installation into an existing tree, you need administrative rights to the Tree object to extend the schema.

" A supported version of NetWare®, only if used in a mixed NetWare/NT environment (NetWare 5 with the latest support pack).

! NetWare 4.11/4.2 server with Support Pack 8a or later with NDS 6.09b or later

Installation 9




! NetWare 5 server with Support Pack 5 or later with NDS version 7.45 or later (earlier beta version won't work)

! NetWare 5.1 with Support Pack 1 or later with NDS 8.60 or later

" Workstations running Novell® Client� for Windows 95 3.0 or later, or Novell Client for Windows NT 4.71 or later.

Linux" Red Hat 6.1 or later, Laser Linux Suse, or Open Linux with an assigned

IP address.

" A Pentium 200 computer with 64 MB RAM.

" Root (super user) access to the Linux machine. For an installation into an existing tree, you need administrative rights to the Tree object to extend the schema.

" Workstations running Novell Client for Windows 95 3.0 or later, or Novell Client for Windows NT 4.71 or later.

Solaris" Solaris 2.6, 2.7, or 8 with an assigned IP address.

" A Pentium 200 computer with 64 MB RAM.

" Root (super user) access to the Solaris machine. For an installation into an existing tree, you need administrative rights to the Tree object to extend the schema.

" Workstations running Novell Client for Windows 95 3.0 or later, or Novell Client for Windows NT 4.71 or later.

Installing Account ManagementYou can install Account Management on the following platforms:

! �Windows NT� on page 11

! �Linux or Solaris� on page 12





Windows NT1111 At the NT server, log in as Administrator or as a user with administrative

privileges.

2222 Run SETUP.EXE from the Account Management CD or downloaded file.

3333 Select from the following components. (You can install these components separately or together.)

! Integrate Windows NT Domains with NDS

Installs the Account Management components and runs the Domain Object Wizard, which transparently migrates existing NT domains to NDS. See �Integrating Windows NT Domains with NDS� on page 11 for more information.

! ConsoleOne

Installs ConsoleOneTM 1.2d. ConsoleOne can perform all the tasks previously performed in NetWare Administrator and NDS ManagerTM. See �Installing ConsoleOne� on page 11 for more information.

Integrating Windows NT Domains with NDS

Account Management installs the current release of the Novell Client (if necessary) and the Account Management components.

After the server reboots, continue with the following steps, first on your Primary Domain Controller (PDC), then on any Backup Domain Controllers (BDC).

1111 Log in to the NDS tree as User Admin or the equivalent.

2222 Log in to the domain with the same user account from Installing Account Management Step 1 on page 11.

3333 When the Domain Object Wizard launches, follow the online instructions.

You can move NT domain users to NDS or associate existing NDS users with NT domain users.

When the Domain Object Wizard finishes running, the NT server reboots.

Installing ConsoleOne

1111 Follow the online instructions in the Installation Wizard.

Installation 11




This installs ConsoleOne 1.2d as a management utility and creates a share called SYS: on the NT server.

Upgrading from a Previous Version

Before you run SETUP.EXE to install Account Management 2.1, complete the following steps:

1111 Run WNDSSCH.EXE from the \NT\DI directory on the CD.

2222 Click Open.

3333 Select NDS4NT21.SCH.

4444 Click Done.

Now run SETUP.EXE from the Account Management CD.

Linux or Solaris1111 Run the nds-install utility.

2222 Select the option to install the Account Management component.

The installation program proceeds to add the Account Management package and related components.

3333 Enter the following configuration parameters in the ndscfg.inp file:

! Name (with full context) of the user with administration rights to the Tree object

! Tree name

! Context of the UNIX* workstation

! Context of the root of the partition where Account Management will be installed

4444 To create a partition, if the partition does not exist, specify yes for the CreatePartition parameter.

5555 Save the information > close the editor.

6666 When prompted, enter the password of the user with administration rights.





The following daemons will initialize after Account Management has been successfully installed:

! slpuasa

The SLP user and service agent daemon

! nds_uamcd

The Account Management cache daemon

! nds_ssod

The NDS Single Sign-on (SSO) for Linux and Solaris daemon

! nds_identd

The NDS identity daemon for SSO operations

The following configuration files are copied to the host:

! /etc/nds.conf

The NDS configuration file

! /etc/slp.conf

The SLP configuration file

! /etc/pam.d.nds/

The directory that contains the sample files for enabling NDS authentication for all services on Linux systems

! /etc/pam.conf.nds:

The sample file for enabling NDS authentication on Solaris systems

Configuring Account Management on Linux or SolarisYou can configure Account Management using the ndscfg or the uamconfig utility. You need to configure Account Management if you exit the configuration during installation or if the configuration fails for some reason. To configure the Account Management component after installation, use the uamconfig utility.

! To configure the Account Management component interactively, enter the following command:

ndscfg -install -m uam

Installation 13




! To remove the Account Management information, enter the following command:

ndscfg -uninstall -m uam

! To configure the Account Management component, use the following syntax:

uamconfig -C [-f configuration_file] {-s value_list | -vparameter_list | -V | -h parameter_list | - H}

Using the uamconfig Utility

Use the uamconfig utility to add, remove, or configure the Account Management component. The following sections provide information about uamconfig operations you can perform:

! �Adding the Account Management Component� on page 14

! �Removing the Account Management Component� on page 14

! �Configuring Account Management� on page 14

Adding the Account Management Component

To add the Account Management component to the specified workstation, use the following syntax:

uamconfig add -a admin_name [-t tree_name] -r partition_root-w workstation_context [-o] [-c] [-p uam_preferred_server]

Removing the Account Management Component

To remove the Account Management component, use the following syntax:

uamconfig remove -a admin_name

Configuring Account Management

To configure the Account Management component, use the following syntax:

uamconfig -C [-f configuration_file] {-s value_list | -vparameter_list | -V | -h parameter_list | -H}]

Parameter Description

C Changes the configuration parameters of the Account Management component.





Configuring Single Sign-on on Linux and SolarisTo enable SSO for Linux and Solaris, configure the Workstation object for Single Sign-on (SSO) by modifying the files in the /etc/pam.d directory on

-t tree_name The tree name to which the Account Management component must be added. If the tree name is not specified, the uamconfig utility takes the tree name from the n4u.nds.tree-name parameter that is specified in the etc/nds.conf file.

-w workstation_context Specifies the context where the Workstation object will be created.

-a admin_name The distinguished name of the User object with supervisor rights to the context in which the Account Management objects are created.

-p uam_preferred_server Specifies the preferred NDS server in the tree to be contacted under which Account Management is configured.

-r partition_root The root of the Account Management domain that contains the Workstation objects.

-f configuration_file Specifies the configuration file to use instead of the default configuration file.

-s valuelist The value for the specified Account Management configurable parameters.

-v paramlist Lets you view the current value of the Account Management configurable parameters.

-o Specifies the existing Account Management configuration to be overwritten

-c Creates the partition if it does not exist.

-V Lists all the Account Management configurable parameters.

-h paramlist, -H Lets you view the help strings for the Account Management configurable parameters.


Installation 15




Linux systems, and the /etc/pam.conf file on Solaris systems. The following sections provide SSO configuration information:

! �Enabling SSO Functionality for Applications� on page 16

! �Configuring Ports Used by Single Sign-on� on page 17

! �Using Single Sign-on with FTP� on page 17

Enabling SSO Functionality for Applications

The pam_ndssso module can be loaded dynamically to provide SSO functionality for applications. When you install Account Management, an example file is copied to the /etc/pam.d directory on Linux systems and the /etc/pam.d.ndssso directory on Solaris systems.

The following are example pam entries for logging in with SSO on Linux systems:

auth sufficient /lib/security/pam_ndssso.0session sufficient /lib/security/pam_ndssso.0

The following are example pam entries for logging in with SSO on Solaris systems:

auth sufficient /usr/lib/security/pam_ndssso.0session sufficient /usr/lib/security/pam_ndssso.0

The pam_ndssso and pam_nds modules work in tandem. The pam_nds module can function without pam_ndssso, but not vice versa. For example, if pam_nds.so.0 is dropped from the authentication or session stack, SSO will not occur for TELNET*. Also, if the initial user authentication through NDS fails for some reason (such as the wrong password), but authentication through UNIX works with the same or a different password, SSO will not occur. The SSO feature is only accessed from NDS-authenticated user sessions.

The pam_ndssso.so.0 module should always be stacked for auth with the Sufficient option. If it is stacked as Required, it will fail during the first authentication of any user, preventing other modules� authentication as well.

SSO will not occur with su, even if the pam stack for su is configured to use SSO. This is intentional, because there is no way to change to a different user once a user has logged in as a particular user. Also, SSO will not occur for login because it is meant to be a primary system entry service. However, once the login is successful, subsequent access (such as with TELNET) will use the login credentials.





Ensure that pam_nds and pam_ndssso are present together in the PAM stack for session management.

Configuring Ports Used by Single Sign-on

The SSO daemon, nds_ssod, listens on two AF_INET ports, and also on one UNIX domain socket. The port numbers can be changed by adding an entry for the service names in /etc/services or any other service database that your organization is using. The UNIX domain socket endpoint is /var/.ndssso_unixsock.

The names of the services and their default values are:

ndssso_caport 1105

ndssso_port 1106

Using Single Sign-on with FTP

FTP does not specify how a server can ask the FTP client to prompt for a username and password to the server. This means that FTP cannot leverage the SSO feature.

For SSO to work with FTP, you can use a FTP wrapper script called nftp, which is provided with the Account Management component. This script is installed in the /usr/bin/ directory and can be invoked with the same parameters as FTP. The nftp utility creates the .netrc file, or appends to an existing .netrc file. The entry added is for the login with the current username as given by the id command, and a Password field with a dummy password. Once the entry is created, nftp calls FTP with the same arguments, and SSO goes through if you have already logged in.

Uninstalling Account Management! �Windows NT� on page 17

! �Linux and Solaris� on page 19

Windows NTTo uninstall Account Management and save any changes made while the domain was redirected to NDS, the NT server must have a working connection to an NDS server holding a replica of the partition that holds the Domain object.

Installation 17




IMPORTANT: You must first remove Account Management from your BDC before you can remove it from your PDC. If you uninstall from the PDC first, you won't be able to access your BDC.

1111 Log on to the BDC as an administrative user.

2222 In the Windows taskbar, click Start > Programs > Novell > Domain Object Wizard.

3333 Follow the online instructions.

4444 After the BDC reboots, perform Step 1 and Step 2 on any remaining BDCs.

5555 Log on to the PDC as an administrative user.

6666 In the Windows taskbar, click Start > Programs > Novell > Domain Object Wizard.

7777 Select from the following options:

! Uninstall NDS and Include New NDS Information in the NT Domain

This option reads the current NT domain information from NDS and moves it to the Windows NT domain. If you have added users and other objects to NDS since moving the NT domain to NDS, those objects are added to the NT domain. Any objects that were originally in the NT domain but were not moved to NDS are no longer in the domain.

! Uninstall NDS and Update the Passwords from NDS

This option makes everything the same as it was before NDS was installed except for the passwords. NT passwords remain the same as they currently are in NDS.

! Uninstall NDS

This option makes everything the same as it was before NDS was installed. The administrator account password is updated to the current password.

8888 Follow the online instructions.

You can still uninstall and revert to the original domain state without a NetWare connection. Any changes or additions made during the domain migration, however, are not reverted.





Linux and SolarisThe following sections provide uninstallation information:

! �Reverting Migrated Accounts from NDS� on page 19

! �Reverting Migrated Accounts to Files� on page 20

! �Reverting Migrated Accounts to NIS� on page 20

! �Reverting Migrated Accounts to NIS+� on page 20

Reverting Migrated Accounts from NDS

NDS lets you revert accounts to files, NIS, and NIS+ from NDS. Accounts that have been migrated to NDS can be reverted to the local databases on Linux or Solaris systems. However, this process does not do the following:

! Delete the accounts in NDS after they have been reverted to the local database

! Revert migrated accounts that have been added to NDS using ConsoleOne

! Revert migrated accounts that have been modified in NDS using ConsoleOne

To be able to revert a migration, specify the value yes for the CreateBackups parameter in the migrate2nds.inp file. Refer to �Migrating User/Group Accounts to NDS� on page 48 for more information. The default value for this parameter is yes. Accounts can be reverted from NDS to files, NIS, and NIS+. To revert migrated accounts, log in as root to the Linux or Solaris system.

WARNING: When you revert migrated accounts from NDS, the existing accounts in files, NIS, and NIS+ will be replaced by the accounts that are being reverted to these databases.

If accounts are being migrated incrementally, you should copy the backup files to a different directory. This will ensure that the previous backups, created by the migrate2nds utility, are not overwritten.

The following sections provide information about reverting migrated accounts from NDS:

! �Reverting Migrated Accounts to Files� on page 20

! �Reverting Migrated Accounts to NIS� on page 20

! �Reverting Migrated Accounts to NIS+� on page 20

Installation 19




Reverting Migrated Accounts to Files

Before migrating accounts to NDS from files, specify the value yes for the CreateBackups parameter in the migrate2nds.inp file. During migration, the tool creates the following backups of the passwd, shadow, and group files in the /var/ndsuam directory:

! revfiles_passwd

! revfiles_shadow

! revfiles_group

To revert migrated accounts, copy the above files to the /etc directory. The passwords that the accounts had before they were migrated are retained in the accounts.

Reverting Migrated Accounts to NIS

Before migrating accounts to NDS from NIS, specify the value yes for the CreateBackups parameter in the migrate2nds.inp file. During migration, the tool extracts accounts from the NIS database and creates the following backups in the /var/ndsuam directory:

! revnis_passwd

! revnis_shadow

! revnis_group

To revert migrated accounts from NDS to NIS, copy the above files to a directory. Set the path in the /var/yp/Makefile for the PWDIR and DIR parameters to the directory you have copied the files into. Run the makecommand to recreate the database.

Reverting Migrated Accounts to NIS+

Before migrating accounts to NDS from NIS+, specify the value yes for the CreateBackups parameter in the migrate2nds.inp file. During migration, the tool extracts accounts from the NIS+ database and creates the following backups in the /var/ndsuam directory:

! revnisplus_passwd

! revnisplus_shadow

! revnisplus_group





To revert migrated accounts from NDS to NIS+, copy the above files to a directory. Run the following commands to recreate the database:

nisaddent -m -f revnisplus_passwd passwd

nisaddent -m -f revnisplus_shadow shadow

nisaddent -m -f revnisplus_group group

Installation 21




2 Managing Windows NT Domains

This chapter describes how to manage Windows* NT* domains and group memberships within ConsoleOneTM.

Understanding Account ManagementOn Windows NT, resources are created and managed in a database called the System Account Manager (SAM). Applications that need information from the Windows NT domain make requests to SAMLIB.DLL. This includes applications running on the NT server or on an NT workstation.

SAMLIB.DLL communicates to SAMSRV.DLL using Remote Procedure Calls (RPCs). For applications being run on the server, this communication is done internally. For requests originating from a workstation, the RPC requests are sent to the server. Once the server RPC receives a request, it is extracted and passed to SAMSRV.DLL. SAMSRV.DLL then accesses the System Accounts Manager where the domain namebase is stored and performs the requested operation. See Figure 1 on page 24.

Managing Windows NT Domains 23




Figure 1

Account Management relocates Windows NT domains into NDS® eDirectoryTM by replacing the Microsoft SAMSRV.DLL file with an NDS eDirectory-based SAMSRV.DLL file. All application requests to the domain namebase are then redirected to NDS eDirectory (which can reside on a NetWare® server, an NT server, or both). NDS eDirectory stores the User, Computer, and Group objects that take the place of the objects previously used from the domain. See Figure 2 on page 25.

SAM

SAMLIB.DLL

SAMSRV.DLL

Applications

RPC

SAMLIB.DLL

Windows NTWorkstation

Windows NTServer

Domainnamebase

Applications

RPC





Figure 2

The advantage of this redirection is that all existing applications continue to work without any change. You can continue to use familiar Windows NT tools to manage accounts in NDS eDirectory. NDS eDirectory containers can scale into hundreds of thousands of objects, unlike NT Domain objects, which are limited to a few thousand.

New FeaturesAccount Management contains the following new features:

! �Domain Cache Management� on page 26

! �Event Logging� on page 26

! �Domain Administration� on page 27

! �Dial In Information� on page 27

NDS

SAMLIB.DLL

Applications

RPC

SAMLIB.DLL


Windows NTServer

NetWareServer

Applications

SAM

Domainnamebase

NetWareClient for

Windows NT

SAMSRV.DLL

RPC

Account Management

NDS





! �Anonymous Password Change� on page 28

! �Password Filter Support� on page 28

Domain Cache ManagementDomain cache management improves performance and lowers network utilization by updating the domain cache at specific times or time intervals. This feature is enabled from the PDC and BDC Workstation objects located in the Domain object in ConsoleOne. Cache updates can be updated all the time, at certain times, or at certain time intervals.

This is not a fault-tolerant solution. It is a performance cache management solution rather than a full-blown persistent cache.

1111 In ConsoleOne, right-click an NT Workstation object.

2222 Click Properties > Domain Cache.

3333 Click Enable Cache Updates.

4444 Select one of the following options:

5555 Click Apply > OK.

Event LoggingThis feature shows if the user is logged into the computer with the cached account and logs other critical events such as those relating to SPSENTRY.

You can also view this information in the Windows Event Viewer.

1111 In ConsoleOne, right-click a Domain object.

2222 Click Properties > Domain NT Tools.

3333 Click View Event Log.

Option Description

Update at Specific Times Updates the domain cache at the specific times you specify.

Update Every Updates the domain cache at the specific time interval (hours and minutes) you specify.





The Event Viewer starts on your local workstation but displays the Event log of the PDC.

Domain AdministrationThis feature allows and disallows user administration from NT User Manager. Using this feature, you can add users that do not have rights to your domain. To enable this, the Domain object must have trustee rights to any container that contains users you want to grant domain rights to.


2222 Click Properties > Domain Members.

3333 Check or uncheck Show.

When the Show box is checked, blue User objects can be managed from the NT User Manager, red User objects cannot be managed from NT User Manager, and clear User objects mean you don't have sufficient rights to manage the User.

Dial In InformationThe Dial In information associated with users in NT User Manager can be managed from ConsoleOne. You can grant users permission to use Dial-Up Networking when connecting to the network. User Dial In also lets you set domain-wide permissions or permissions for specific computers.

1111 In ConsoleOne, right-click a Local or Global Group object.

2222 Click Properties > Identification.

3333 Select the user you want in the Members list > click Properties.

4444 Click Domain Dial In Information.

5555 Click Grant Dial In Permission to User.

6666 Select one of the following call back options:

Option Description

No Call Back Disables call back for a user account.






Anonymous Password ChangeThis feature manages whether users must log in to their accounts to change their passwords.


2222 Click Properties > Domain Identification.

3333 Check or uncheck Users Must Log On in Order to Change Password.

If checked, the user must be logged in to change the password. If the password expires while the user is not logged in to the Domain, the administrator must change the password.

Password Filter SupportThis feature automatically allows the use of password restrictions for strong password functionality if Strong Password Encryption is enabled on the PDC. Strong Password Encryption provides enhanced security against password guessing or dictionary attacks by outside intruders by allowing you to enforce strong passwords. This means that passwords must be at least six characters long, be a mixture of uppercase and lowercase letters as well as numbers and special characters, and not contain any part of the username.

Set by Caller Prompts the user for a phone number. The server calls back the number entered by the user and receives the telephone charges for the session.

Preset To Calls the user at a fixed telephone number. Enter the fixed phone number. The server calls the user back at only this number, reducing the risk of an unauthorized person accessing the user's account. This option prevents multilink calls if the user's equipment requires more than one phone number for the group of multilinked lines.

Option Description





If Strong Password Encryption is enabled on your PDC, this feature is automatically enabled in Account Management. See your Windows NT documentation for instructions on enabling Strong Password Encryption on your PDC.

Managing Windows NT AccountsEach Windows NT domain is represented by a Domain object in ConsoleOne. This object, created with the Domain Object Wizard, is a container object that behaves similarly to a Group object in that it not only holds information about the domain and users which are a member of the domain, but the Domain object also contains member objects such as computers and groups, just as an actual domain. See �Integrating Windows NT Domains with NDS� on page 11 for more information on the Domain Object Wizard.

The Domain object acts as a group with a list of domain members. The computers and groups associated with the domain are represented as objects contained by the NDS eDirectory Domain object. By making User objects members of the domain rather than actually residing within the domain, you can place the NDS eDirectory User objects anywhere in the tree and still give users access to specific domains.

Using the NDS for NT snap-in to ConsoleOne, you can create Local Group objects, Global Group objects, and Workstation objects. You can also add users to or remove users from Group objects or Domain objects. This means that you don�t have to learn different applications to manage objects such as Users, Groups, and Mailboxes.

Creating a New Local Group1111 In ConsoleOne, right-click the domain you want the new Local group

created in.

2222 Click New > Object.

3333 In the Class list, click NDS for NT Local Group > OK.

4444 Specify the group name.

5555 (Optional) Check one of the following two check boxes:





6666 Click OK.

Creating a New Global Group1111 In ConsoleOne, right-click the domain you want the new Global group

created in.


3333 In the Class list, click NDS for NT Global Group > OK.

4444 Specify the group name.


6666 Click OK.

Creating a New Workstation Object1111 In ConsoleOne, right-click the domain you want the new Workstation

object created in.


3333 In the Class list, click NDS for NT Workstation > OK.

4444 Specify the workstation name.

The workstation name must end with a dollar sign ($). It can be up to 16 characters long including the $.

Check Box Description

Define Additional Properties Lets you set properties for the group you are creating.

Create another Local Group Lets you create another group.


Define Additional Properties Lets you set properties for the group you are creating.

Create another Global Group Lets you create another group.






6666 Click OK.

Adding an NDS User to an NT DomainYou can add an NDS user to an NT domain in either of the following ways:

! �Adding an NDS User to an NT Domain through the NDS User Object� on page 31

! �Adding an NDS User to an NT Domain through the Domain Object� on page 32

Adding an NDS User to an NT Domain through the NDS User Object

1111 In ConsoleOne, right-click the NDS User object you want to add to the domain.

2222 Click Properties > Domain Access.

3333 Select Group Memberships.

The Add button is enabled but the Delete button is disabled. (You cannot delete the Group Memberships line.)

4444 Click Add.

5555 Browse to and select the domain you want to add the user to.

You can also browse further down and select Local or Global groups. If you select a Local or Global group, both the group and the domain it belongs to will be added to the user's group memberships. The group called Domain Users will also be added, selected or not, as the user's primary group.

6666 Click OK > OK.


Define Additional Properties Lets you set properties for the workstation you are creating.

Create another Workstation Lets you create another workstation.





Adding an NDS User to an NT Domain through the Domain Object

1111 In ConsoleOne, right-click the Domain object you want to add an NDS User object to.


3333 Click Add to browse to and select NDS User objects.

or

Ctrl-click Add to browse to and select Novell NDS Group objects.

4444 Select the NDS User or NDS Group object you want to add to the domain.

If you select an NDS group, the individual users�not the group itself�are added to the domain.

5555 Click OK > OK.

Adding an NDS User to a Local or Global GroupYou can add an NDS user to a Local or Global group in either of the following ways:

! �Adding an NDS User to a Local or Global Group through the NDS User Object� on page 32

! �Adding an NDS User to a Local or Global Group through the Group Object� on page 33

Adding an NDS User to a Local or Global Group through the NDS User Object

1111 In ConsoleOne, right-click the NDS User object you want to add to the Local or Global group.


3333 Select a domain.

or

Select Group Memberships.

The Add button is enabled but the Delete button is disabled. (You cannot delete the Group Memberships line.)

4444 Click Add.

If you select a domain, then click Add, that domain's Group objects are displayed in the Select Object dialog box.





5555 Browse to and select a Local or Global group.

If the user is not a member of the domain the group belongs to, both the group and the domain are added to the user's group memberships. The group called Domain Users is also added, selected or not, as the user's primary group.

6666 Click OK > OK.

Adding an NDS User to a Local or Global Group through the Group Object

1111 In ConsoleOne, right-click the Local or Global group you want to add an NDS User object to.

2222 Click Properties > Identification > Add.

3333 Select the member you want to add to the Local or Global group.

Users that are not already members of the domain cannot be added using the browser. You must first add the user to the domain. See �Adding an NDS User to an NT Domain� on page 31.

4444 Click OK > OK.

Deleting an NDS User from an NT DomainYou can delete an NDS user from an NT domain in either of the following ways:

! �Deleting an NDS User from an NT Domain through the NDS User Object� on page 33

! �Deleting an NDS User from an NT Domain through the Domain Object� on page 33

Deleting an NDS User from an NT Domain through the NDS User Object

1111 In ConsoleOne, right-click the User object you want to delete from a domain.


3333 Select the domain you want to delete the user from.

4444 Click Delete > OK.

Deleting an NDS User from an NT Domain through the Domain Object

1111 In ConsoleOne, right-click the domain you want to delete a user from.






3333 Select the users you want to delete.


Deleting an NDS User from a Local or Global GroupYou can delete an NDS user from a Local or Global group in either of the following ways:

! �Deleting an NDS User from a Local or Global Group through the User Object� on page 34

! �Deleting an NDS User from a Local or Global Group through the Group Object� on page 34

Deleting an NDS User from a Local or Global Group through the User Object

1111 In ConsoleOne, right-click the user you want to delete from a Local or Global group.


3333 Select the Local or Global group you want to delete the user from.

A user cannot be removed or deleted from its primary group. The group name of the primary group is displayed in bold.


Deleting an NDS User from a Local or Global Group through the Group Object

1111 In ConsoleOne, right-click the Local or Global group you want to delete a user from.


3333 Select the users you want to delete.


Setting a User's Primary GroupTo belong to a domain, a user must be a member of at least one group within that domain. The user cannot be deleted from his or her primary group. This primary group is displayed on the Domain Access page in bold. By default, the Domain Users group is set as the primary group.





1111 In ConsoleOne, right-click the user whose primary group you want to change.


3333 Select the group you want to set as the new primary group.

When the Group Memberships line, a domain, or a Local group is selected, the Set Primary Group button is disabled. Only a Global group can be set as the primary group.

When the current primary group (displayed in bold) is selected, the Set Primary Group button is disabled.

4444 Click Set Primary Group > OK.

The selected group becomes the primary group and is displayed in bold; the group that was previously the primary group is no longer in bold.

IdentificationYou can view, enter, or modify information about Domain objects, Groups, and Workstations.

Domain Identification



3333 Select from the following options:


Option Description

Description Describes the selected Domain object.

OEM Information Imports information from NT domains during migration.

Default User Creation Context Sets the context that locates new users created by NT User Manager. This field is not used by ConsoleOne during the creation process.





Group Identification

1111 In ConsoleOne, right-click a Local or Global Group object.


3333 Enter or view information about the selected Group object.

Workstation Identification

1111 In ConsoleOne, right-click an NDS for NT Workstation object.


3333 Enter or view the complete name of the workstation and information describing the selected Workstation object.

Enabling Performance Enhancement Settings1111 In ConsoleOne, right-click a Domain object.


3333 In the Advanced Settings box, select from the following options:

Option Description

Default User Creation Force Password Sync

Sets the context for new users created by NT User Manager. This field is not used by ConsoleOne during the user creation process. If this check box is checked, NT and NDS passwords are synchronized for users created through NT User Manager.

Use Fast User Display Speeds up queries for user information in NT User Manager and in ConsoleOne. If this option is checked, NT User Manager displays only the username in the initial list and ConsoleOne displays only the username and context in the initial list. Once a username is selected, additional information is displayed.

On User Added through Snapin, Enable Administration from NT Tools

Allows new users created in NT User Manager to be managed from NT User Manager.






Using NT ToolsThe NT Tools page provides convenient access to several administration tools such as File and Folder Sharing, Server Manager, User Manager, and the Event Viewer. If you select View Event Log, the Event Viewer starts on your local workstation but displays the Event log of the PDC. When you select another tool, the corresponding program is located on the PDC and executed on your workstation.

To use any of these tools, you must run ConsoleOne on a Windows NT workstation or server. The tool is disabled on all other platforms.

1111 Log on to the domain with Administrator privileges.


3333 Click Properties > Domain NT Tools.

4444 Select one of the following:

Users Must Log on in Order to Change Password

Requires users to be logged in to the network to change password security information.

Tool Description

File and Folder Sharing Lets you configure security for file and folder sharing.

Server Manager Lets you administer domains and computers. You can display the member computers of a domain, manage server properties and services, share directories, and send messages to connected users. You can also reassign a BDC as the PDC, synchronize computers with the PDC, and add or remove computers in a domain.

Option Description





The tools are also found in the menu displayed when you right-click a Domain object in the ConsoleOne window.

Using the Replica AdvisorUser objects that are members of an NT domain can be relocated during or after NDS for NT installation to any partitions. The domain User objects can also be associated with existing NDS User objects in any partition of the NDS tree. This association between domain and NDS objects occurs when you run the Domain Object Wizard and migrate users to NDS, eliminating the need for accounts on both NDS and NT for a single user.

The Replica Advisor page of the Domain object shows all the partitions containing the User objects that have memberships in the domain. When the partition item is expanded, it lists User objects in that partition.

Another entry displays which partition the Domain object is in. The Domain object and its subordinate groups contain information that is used during login and authentication to resources.

To view a replica, complete the following steps:


2222 Click Object > Details.

3333 Select the Replica Advisor page.

Partitions that hold Domain, User, and Group objects are shown with the partition symbol.

User Manager Lets you manage security for domains and computers. This includes creating and managing user accounts and groups, and managing the domain�s security policies (passwords) and user rights (auditing and trust relationships).

View Event Log Lets you troubleshoot various hardware and software problems and monitor NT server security events.

Tool Description





Managing Security on Windows NTWindows NT uses an MD4 password encryption algorithm, which creates a fixed length hash from the user�s password. Such hashes are not very secure. NDS eDirectory, however, uses a public and private key method of encryption called RSA encryption to protect critical information (such as passwords). These public and private keys are created specifically for each user using the password. The public key can be easily shared and passed around. The private key is held securely within NDS eDirectory in a vault associated with the User object.

When a password is initially created at a workstation, it does not cross the wire as clear text. Instead, the Novell® ClientTM running on the workstation uses an RSA encryption key received from an NDS server to encrypt the password before it leaves the workstation and hits the wire. That password is received at the server and is entered (in its encrypted form) into NDS.

When a user logs in, the password is used to create a secret token that is sent to NDS eDirectory for verification. If the NDS server is convinced that the token has been generated only by the actual user, it allows an authenticated session to be set up. At the same time, the password is also encrypted with the MD4 algorithm and sent to the NT domain controller. This encrypted value is compared to the one stored in the domain User object. If they match, the user is authenticated to the NT server. This authentication process is secure because the encryption process that is performed on each password is irreversible. See Figure 3.

Figure 3 Password Encryption

1

2RSA

MD4Windows NTWorkstation

User creates anew password

NDS Server

NT Server(Domain Controller)

Encryptedpassword is stored

on each server





With Account Management, the respective environments check both passwords. Both passwords, however, are stored in NDS eDirectory. The authentication process is equally secure, since the encryption process performed on each password is still irreversible.

Figure 4 and Figure 5 illustrate password checking with and without Account Management.

Figure 4 Password Checking in a Mixed NDS/Domain Network

Figure 5 Password Checking with Account Management

1

…MD4-encrypted password

3

Windows NT Workstation


User logs in with RSA-encrypted password and…

2Server compares

the encrypted password

NDS Server

5

NDS database

Domain namebase

RSA

MD4

User is authenticatedif the password is valid


1

…MD4-encrypted password

3

User logs in with RSA-encrypted password and…

2Server compares

the encrypted password

5

NDS database

RSA

MD4



NDS Server






Synchronizing a User's NDS and NT PasswordsThis procedure allows you to synchronize both the NDS and NT passwords. The password change is immediate and cannot be undone by clicking Cancel.

1111 In ConsoleOne, right-click the User object for the user whose password you want to change.


If the user is not a member of a group or domain, Set Both Passwords is disabled. If groups or domains have been added to the Memberships list, but have not been committed to the NDS database, Set Both Passwords remains disabled. You must first add the user to the domain.

3333 Check the Force Password Sync check box, then click Apply.

4444 Click the Restrictions-Password Restrictions page > Change Passwords.

If you are a system administrator, the Old Password box is disabled. Go directly to Step 8.

5555 If you are the user whose object is being displayed, type your old password in the Old Password text box.

6666 Type the new password in the New Password box.

7777 Retype the new password in the Retype New Password box.

8888 Click OK.

Setting Intruder Detection1111 In ConsoleOne, right-click the domain for which you want to activate or

deactivate intruder detection.

2222 Click Properties > Domain-Intruder Detection.

3333 Check the Detect Intruders box to activate intruder detection or uncheck the box to deactivate intruder detection.

The default limit is seven incorrect login attempts in 30 minutes. Lock Account after Detection is also set automatically with a default interval of 15 minutes.

4444 Adjust the default limits and the Intruder Lockout Reset Interval, if necessary.

5555 Click OK.





3 Managing Linux and Solaris Accounts

This section contains information on the following:

! �Understanding NDS-Based Account Management on Linux and Solaris� on page 43

! �Migrating User/Group Accounts to NDS� on page 48

! �Migrating UNIX User and Group Accounts to NDS� on page 58

! �Optimizing Account Management� on page 68

! �Troubleshooting Account Management on Linux and Solaris� on page 70

Understanding NDS-Based Account Management on Linux and Solaris

The Account Management component should be installed on all systems that need to be administered using NDSTM. The installation of Account Management configures the system to use NDS instead of NIS, NIS+, or local etc/passwd files. You can modify the system to use NIS or NIS+, if desired. You need to ensure that the names of UNIX* users, groups, and workstations are unique.

The following sections provide information that help you understand the functionality of Account Management:

! �Understanding Account Management Components� on page 44

! �Understanding Account Management Security� on page 44

! �Understanding Account Management Support for RFC 2307� on page 45

Managing Linux and Solaris Accounts 43




! �Understanding Single Sign-on Functionality� on page 46

! �Understanding Trustee Assignments and Rights for Account Management Objects� on page 47

Account Management does not support merging of partitions, trees, or containers.

Understanding Account Management ComponentsThe Account Management component consists of:

! The pam_nds module that provides NDS authentication for applications

! The nss_nds module that provides NDS name service for applications

! The pam_ndssso module that provides single sign-on services for Linux* or Solaris* systems

! The migrate2nds and unix2nds migration tools for migrating existing UNIX users into NDS

! Command line utilities to add, delete, and modify existing users and groups

! The uamconfig utility to configure Account Management parameters

The pam_nds module provides authentication, account, session, and password services for all applications. After the authentication to NDS is complete, the user can continue to have the same privileges and rights that are available when authenticating to NIS, NIS+, or local files. The user profile will remain the same with rights to file and print services and the preferred UNIX shell.

The migration tool migrates User accounts and groups from the local host, on which Account Management is installed, to NDS. If there is a system that acts as the NIS master, the product should be installed on that system. The NDS schema is extended to include UNIX user and group attributes. Since NDS is an organization-wide repository, UNIX user accounts can be administered like any other NDS object using ConsoleOneTM.

Understanding Account Management SecuritySome UNIX applications send passwords on the wire in plain text. Examples of this are TELNET, FTP, rlogin, and so on. The password can be tapped while it is being sent from the TELNET client to the TELNET server. Hence, steps need to be taken to avoid compromising security. One solution is to use secure





applications that encrypt all the data between the client and the server. A popular protocol for encrypting all data communications is Secure Socket Layer (SSL). SSL can be placed between a reliable connection-oriented network layer protocol (for example, TCP/IP) and the application layer protocol (for example, HTTP).

Understanding Account Management Support for RFC 2307RFC 2307 (http://www.isi.edu/in-notes/rfc2307.txt) defines a mechanism for mapping NIS entities into X.500 entries so that they can be resolved with LDAP.

The attributes and object classes defined in the RFC 2307 are user/group-related and NIS-related. The user/group-related definitions are compiled into the /usr/lib/nds-modules/schema/rfc2307-usergroup.sch file. The NIS-related definitions are compiled into the /usr/lib/nds-modules/schema/rfc2307-nis.sch file. You will also find the corresponding files in LDIF format (/usr/lib/nds-modules/schema/rfc2307-usergroup.ldif and /usr/lib/nds-modules/schema/rfc2307-nis.ldif, respectively).

Extending the RFC 2307 Schema

You can extend the RFC 2307 schema using the ndssch utility or the ldapmodify tool. The user/group-related RFC schema are automatically extended if you install Account Management on the workstations.

To extend the schema using the ndssch utility:

1111 Enter the following command:

ndssch -t /usr/lib/nds-modules/schema/rfc2307-usergroup.sch

or

ndssch -t /usr/lib/nds-modules/schema/rfc2307-nis.sch

ndssch Parameter Description

-t The name of the tree on which the schema is to be extended. This is an optional parameter. If this parameter is not specified, the tree name is taken from the /etc/nds.conf file.





To extend the schema using the ldapmodify utility:


ldapmodify -h -D -w -f /usr/lib/nds-modules/schema/rfc2307-usergroup.ldif

or

ldapmodify -h -D -w -f /usr/lib/nds-modules/schema/rfc2307-nis.ldif

Understanding Single Sign-on FunctionalitySingle Sign-on (SSO) for Linux or Solaris enables users to authenticate to SSO-enabled Linux or Solaris systems without being prompted for their usernames and passwords. Users authenticate in the background through pam_ndssso, which is a pluggable authentication module (PAM). The pam_ndssso module works with nds_ssod, the SSO daemon, to provide SSO functionality. The pam_ndssso module always works with the pam_nds module and should be configured on the PAM stack along with pam_nds.

You can enable or disable SSO for particular applications by configuring the application files in the /etc/pam.d directory on Linux systems and the /etc/pam.conf file on Solaris systems.

The SSO daemons on various machines communicate in order to transparently and securely provide Single Sign-on for the user.

SSO does not use encryption for privacy.

ldapmodify Parameters Description

-h ldaphost Specifies an alternate host on which the LDAP server is running.

-D binddn Binds to the X.500 directory. The binddn parameter should be a string-represented DN as defined in RFC 1779.

-w passwd The password for simple authentication.

-f file Reads the entry modification information from file instead of from standard input.





Understanding Trustee Assignments and Rights for Account Management Objects

On Linux and Solaris, NDS depends on specific trustee assignments to the NDS objects and attributes for its operation. The Account Management component essentially deals with five types of objects:

! User

! Group

! UNIX:Workstation/uamPosixWorkstation

! UNIX:Config/uamPosixConfig

! Template:Class

When a UNIX Config object is created during product installation and configuration, the [Public] trustee is assigned [Read] rights to the UNIX Workstation contexts attribute. When the UNIX Workstation object is created during product configuration and installation, the [Public] trustee is assigned [Read] rights to the Group Membership attribute and [Compare] rights to the CN attribute.

When a User object is being migrated to NDS, or when an NDS user is being assigned a UNIX profile, the following trustees are assigned:

! [Read] rights for all UNIX-related attributes to the [Public] trustee

! [Read] rights for the Group Membership attribute to the [Public] trustee

! [Compare] right for the CN attribute to the [Public] trustee

These trustee assignments occur only when a UNIX profile is being assigned to a user. When the UNIX profile is deleted, these trustee assignments are not reverted, since these assignments could have been modified by the administrator.

When a Group object is migrated to NDS, or when an NDS group is assigned a UNIX profile, the following trustees are assigned:

! [Read] rights for the Members attribute to the [Public] trustee

! [Read] rights for all UNIX-related attributes to the [Public] trustee





Migrating User/Group Accounts to NDSAll existing users and groups can be migrated to NDS after NDS is installed and configured. Use the migrate2nds utility to move accounts to NDS. Before proceeding with the migration, ensure that NDS has been configured during installation. If it has not been configured during installation, it can be configured using the ndscfg utility.

If you are not using shadow passwords, run the pwconv utility, which enables shadow passwords.

The migration process consists of four phases:

! �Setting Up for Migration� on page 48

! �Migrating Accounts� on page 52

! �Activating and Verifying Migrated Accounts� on page 53

! �Managing Authentication, Accounts, and Passwords� on page 56

Setting Up for MigrationThe following sections provide setting up information that is required for migrating User/Group accounts to NDS:

! �Prerequisites for Migration� on page 48

! �Consolidating User Accounts� on page 49

! �Creating the migrate2nds.inp File� on page 49

Prerequisites for Migration

Ensure that you meet the following prerequisites before you begin migration:

! In the /etc/nsswitch.conf file, the passwd and groups entry is set only to files, files nis, or files nisplus, depending on where the User accounts are being migrated from. NDS must not be specified in these entries when you execute the migration tool.

! If accounts are being migrated from files, run the pwconv command to update the entries in the /etc/shadow file with those in the /etc/passwd file. This will ensure that the entries in both the files are consistent.

! There are no invalid entries in the files, NIS, and NIS+ databases. If you are migrating accounts from NIS or NIS+, ensure that the service is available before migrating the accounts.





Consolidating User Accounts

User and Group accounts with the same name can exist on various hosts. You will need to consolidate accounts to one host and ensure that there are no duplicate uids and gids.

If duplicate account names remain after the preparation stage, you will have to handle each such account while migrating and specify whether the accounts do the following:

! Map to the existing account

! Should not be migrated

! Should be migrated with a different name

Also, by consolidating the User accounts you can resolve duplicate uids and gids across users and groups.

If accounts are being migrated from two databases on the same system, such as files and NIS, ensure that duplicate accounts do not exist on the databases.

Creating the migrate2nds.inp File

Before migrating accounts to NDS, you will need to create the migrate2nds.inp file in the /etc directory. A sample migrate2nds.inp file is in the /etc directory.

The following input to the migrate2nds tool is mandatory:

! Admin Name: The name of the user with administration rights to the NDS tree in to which the users are to be migrated.

The following inputs to the migrate2nds tool are optional:

! User Context: The context the users should be migrated to. If the context is not specified, the tool creates a container named UNIX Users under the root of the partition and migrates the users into this container. The partition root is read from the /etc/nds.conf file. The root of the partition is specified during product configuration.

! Group Context: The context the groups should be migrated to. If the context is not specified, the tool creates a container named UNIX groups under the root of the partition and migrates the groups into this container. The root of the partition is specified during product configuration.

! Workstation Access: If Workstation Access is set to yes, groups and users are given access to all the workstations in the partition. This information





is taken from the /etc/nds.conf file. If the value is set to No, groups are given access only to the workstation where the migration tool is executed. The default value is yes.

! Force Password Expiry: By default, migrated users are forced to change their passwords when they log in for the first time. We recommend retaining the default value of yes. If the value is set to no, migrated users do not have to change their passwords when they log in for the first time.

! Set Search Context: Users can have accounts in both UNIX and NDS. You can specify the contexts in which the migrate2nds utility can search for existing NDS User accounts. If NDS accounts without a UNIX profile or duplicate NDS UNIX accounts are found in that context, you can further specify whether the accounts should be upgraded to UNIX, or whether the accounts that are being migrated can be mapped to existing NDS UNIX accounts. Enter the following string in the input file:

SearchContexts=context

You can specify additional contexts on new lines. All the lines after the SearchContext parameter are treated as a search context until another valid input parameter name is encountered. The search can be a subtree search or restricted to that container. For the migrate2nds utility to search the subtree in that container, set the value to yes for the SubtreeSearch parameter. The migration process is slower if more search contexts are specified in the migrate2nds.inp file.

! Unattended Migrate: By default, the migrate2nds utility prompts for input on how to handle duplicate accounts during the migration process. You can migrate all the accounts without being prompted for input when you execute an unattended migration. You have to set parameters for handling duplicate accounts. For more information, see �Unattended Migration� on page 51.

! Delete Migrated Accounts: You can delete accounts from the local database once they have been migrated to NDS. Set the value to yes for the DeleteMigratedAccounts parameter in the migrate2nds.inp file. The migration tool creates files with accounts that have not been migrated. For more information, see �Deleting Migrated Accounts� on page 54. The default value is no.

! Create Backups for Revert Migrate: You can revert the accounts that have been migrated to NDS. Set the value to yes for the CreateBackups parameter in the migrate2nds.inp file. The migrate2nds utility creates backups of all the migrated accounts and stores them in the /var/ndsuam directory. If a backup file exists in the /var/ndsuam directory, it is





renamed to .old. To revert these accounts from NDS to the local database on the Linux or Solaris system, refer to �Reverting Migrated Accounts from NDS� on page 19.

Unattended Migration

You can migrate all users without being prompted for input. In the migrate2nds.inp file, set the value to no for the PromptIfDuplicateAccounts parameter and specify the following guidelines for the migrate2nds utility to follow:

# inputs to migrate2ndsUpgradeNDSUsers=yesUpgradeNDSGroups=yesMapToExistingUNIXUser=noMapToExistingUNIXGroup=no

The default value for all the above parameters is yes. If an NDS User/Group with the same name as the UNIX User/Group exists, you can specify whether the NDS User/Group should be upgraded to UNIX or not. If you specify no, the users and groups will not be migrated if these situations are encountered. Also, you can specify whether the duplicate UNIX User/Group should be mapped to the existing NDS User/Group. When accounts are mapped, the UNIX-specific values of the NDS user will not be modified, but the group memberships will be updated.

If you set the value to yes for the PromptIfDuplicateAccount parameter, the values are ignored, even if they have been entered in the migrate2nds.inp file.

A sample migrate2nds.inp file is shown below:

# sample migrate2ndsinp fileadmin=cn=admin.ou=unix-users.o=novellUserContext=ou=unix-users.o=novellGroupContext=ou=unix-groups.o=novellAccessToAllWorkstations=yesForcePasswordExpiry=noDeleteMigrateAccounts=noPromptIfDuplicateAccounts=noUpgradeNDSUsers=yesUpgradeNDSGroups=yesMapToExistingUNIXUsers=yesMapToExistingUNIXGroups=yesSearchContexts=ou=uams.o=novellSubtreeSearch=yesCreateBackups=yes





There should be no blank spaces when you enter the contexts in the migrate2nds.inp file.

Migrating AccountsAccounts can be migrated from the files NIS and NIS+. You should run the migrate2nds utility on the NIS master when you are migrating accounts from NIS so you delete the migrated accounts from NIS. If you do not want to run the tool, then it can be run on any client.

To migrate accounts from the root domain in NIS+, run the migration tool on the root master server. If accounts are to be migrated from a non-root domain, run the migration tool on the client of the domain. The client should be in the Admin group of the domain and should have Modify rights to the table.

If accounts are being migrated from two databases, files NIS or NIS+, ensure that there are no duplicate accounts in the two databases. If there are duplicate accounts, specify the duplicate accounts be mapped. If you decide not to migrate either of these accounts, the account will be considered as non-migrated from both the databases.

The tool migrates the groups first, then the User accounts, and finally the group member list. NDS does not allow two or more users with the same name to be moved into the same context in NDS. Similarly, it does not allow multiple groups of the same name to be migrated to the same context. The situations that can occur, and the options that are available to the user, are described below:

! An NDS Group/User object with the same name and without a UNIX profile exists. You can do one of the following:

! Upgrade the existing NDS User object to a UNIX User object.

! Migrate the Group/User object with a different name.

This option is not available with an unattended migration.

! Choose not to migrate the Group/User object.

! An NDS Group/User object with the same name exists and it has a UNIX profile. You can do one of the following:


This option is not available with an unattended migration.






! An object, with the same name, but of a different object type exists. During unattended migration, these accounts will not be migrated. You can do one of the following:



If you are running Unattended Migrate, the migrate2nds utility will not prompt you for any input. Passwords will not be updated for accounts that have been upgraded or for accounts that have been mapped to an existing account.

If a user account has been locked on the local host, the account will be migrated and disabled. You can enable these accounts using ConsoleOne. User accounts with no password will also be disabled. If the accounts has a password status of Prompt User On First Login, users can press Enter when prompted for the password. They will then be prompted for the new password.

The migrate2nds utility handles system accounts like any other account, but system accounts will not be deleted from the Linux or Solaris system.

IMPORTANT: When User/Group accounts from the local host are migrated to NDS, the migrate2nds utility does not check for the uniqueness of the uids and gids.

A migrated user can log in using the Novell® ClientTM only after first logging in from a Linux or Solaris system. If the administrator changes the password after migrating, this restriction does not apply.

If the administrator is in the same partition as the root user, the root user will be able to change the profile of the administrator.

Activating and Verifying Migrated AccountsWhen the migration is complete, you must add the nds source to the passwd and group database entries in the /etc/nsswitch.conf file to activate the migrated accounts. However, the nds source should always follow (not precede) the files source in the passwd and group database entries in the nsswitch.conf file, as shown below:

passwd: files nds

group: files nds

hosts: files nds





The files in the /etc/pam.d directory on Linux systems should be modified to use NDS authentication. On Solaris systems the /etc/pam.conf file should be modified to use NDS authentication. For more information, see to �Managing Authentication, Accounts, and Passwords� on page 56.

After modifying /etc/nsswitch.conf to use the nds source, the SSO daemon (nds_ssod) needs to be restarted for the users and groups in NDS to be identified by nds_ssod.

Enter the following commands to restart the daemon on Linux systems:

/etc/rc.d/init.d/nds_ssod stop

/etc/rc.d/init.d/nds_ssod start

Enter the following commands to restart the daemon on Solaris systems:

/etc/init.d/nds_ssod stop

/etc/init.d/nds_ssod start

If the nscd daemon is running, the above steps do not need to be executed.

The migrate2nds utility creates the migrate2nds.log file in the /var/ndsuam/log directory. This log file will mention the following:

! Whether an account has been migrated

! The new name of the migrated account, if it has been migrated with a different name

! The host to which the group has been granted access

You can view this log file to verify the status of all the migrated accounts.

Deleting Migrated AccountsYou can delete accounts from the local database once they have been migrated to NDS. To do so, set the value yes for the DeleteMigratedAccounts parameter in the migrate2nds.inp file.

The migrate2nds utility creates files containing User/Group accounts that have not been migrated. These files are located in the /var/ndsuam directory.





The User/Group accounts that have not been migrated from files to NDS will be stored in the following files in the /var/ndsuam directory:

! files_passwd

! files_shadow

! files_group

To delete the migrated accounts, copy the above files to the /etc directory.

The User/Group accounts that have not been migrated from NIS to NDS will be extracted from NIS and stored in the following files in the /var/ndsuam directory:

! nis_passwd

! nis_shadow

! nis_group

To delete the migrated accounts, build the NIS database using these files. Set the path in the /var/yp/Makefile directory, for the PWDIR and DIR parameters, to the directory into which you have copied the files. Run the make command to re-create the database.

User/Group accounts that have not been migrated from NIS+ to NDS are extracted from NIS+ and stored in the following files in the /var/ndsuam directory:

! nisplus_passwd

! nisplus_shadow

! nisplus_group

To delete the migrated accounts, build the NIS+ database using the following commands:

nisaddent -m -f /var/ndsuam/nisplus_passwd passwd

nisaddent -m -f /var/ndsuam/nisplus_shadow shadow

nisaddent -m -f /var/ndsuam/nisplus_group group

User/Group accounts with IDs in the 0-99 range will not be deleted from the local host.





Managing Authentication, Accounts, and PasswordsAfter installing and migrating accounts to NDS, NDS-based authentication, account management, and password management can be provided for UNIX accounts. The pam_nds module can be dynamically loaded to provide the necessary functionality upon demand.

On Linux systems, the path to this module is provided by files in the /etc/pam.d directory. For example, the login application uses the /etc/pam.d/login file for PAM configuration. You can add the contents of the /etc/pam_nds_sample to the /etc/pam.d/application file for the local host to use NDS authentication. A sample file, pam_nds_sample, is installed in the /etc/pam.d directory when NDS is installed. Add the contents of this file to the application file for the local host to use NDS authentication for the application.

On Solaris systems, the path to the pam_nds module is provided by the /etc/pam.conf file.

The following is an example of an entry in the configuration file for login on Linux systems:

auth required /lib/security/pam_nds.so.0

The following is an example of an entry in the configuration file for login on Solaris systems:

auth required /usr/lib/security/pam_nds.so.0

The first field is the application requiring the authentication service. The name of the service provided is specified in the second field. In the third field, specify the control flag. In the fourth field, specify the name of the module providing the service. The control flag can be of the following types:

! Required

This flag is set when authentication by the module is required. If the authentication using this module was not successful, an error message is returned to the caller, after executing all the modules in the stack.





! Optional

This flag is set when authentication by the module is optional. If the module fails, the PAM framework ignores the module failure and continues with the processing of the next module in the sequence. If this flag is used, the user is allowed to log in, even if that particular module failed.

! Sufficient

This flag is set when authentication is required only by one module. If the module succeeds, the application will not try another module. When authentication fails, the modules with flags set to Sufficient are treated as optional.

The following options can be passed to the NDS module:

! use_first_pass

This option compares the password in the password database with the user�s initial password (entered when the user authenticated to the first authentication module in the stack). If the passwords do not match, or if no password has been entered, the module quits and does not prompt the user for a password. This option should only be used if the authentication service is designated as optional in the files in the /etc/pam.d directory.

! try_first_pass

This option compares the password in the password database with the user�s initial password (entered when the user authenticated to the first authentication module in the stack). If the passwords do not match, or if no password has been entered, the user is prompted for a password. When prompting for the current password, the NDS authentication module will use the prompt, password, unless one of the following scenarios occur:

! The try_first_pass option is specified and the password entered for the first module in the stack fails for the NDS module.

! The try_first_pass option is not specified, and the earlier authentication modules listed in the files in the /etc/pam.d file have prompted the user for the password.

In these two cases, the NDS authentication module will use the prompt NDS password.





Migrating UNIX User and Group Accounts to NDSUse the unix2nds utility, also known as the flexible migration tool, to migrate required UNIX user, shadow, and group accounts. When you migrate UNIX user accounts to NDS, the passwords of the UNIX users are also migrated to NDS User objects. This enables you to log in to the NDS User object with the UNIX user password that was used to log into the UNIX machine. Since this tool uses LDAP calls to access, modify, or create objects in the NDS database, ensure that you specify all FDNs in the LDAP format.

The utility takes migration inputs either from the standard input or from file. Input formats can be either in /etc/passwd, /etc/group, or /etc/shadow file formats. The input format can be specified using the -t option followed by the appropriate argument of passwd, group, or shadow.

Configuration information for the utility is taken from the default configuration file /etc/unix2nds.inp. If you do not specify a value for the required parameters such as an administrator name, the utility prompts you to specify a value before using the default values from the configuration file.

The following sections provide information about using the unix2nds utility:

! �Configuring the unix2nds Migration Utility� on page 58

! �Using the unix2nds Utility� on page 60

! �Migrating UNIX Groups to NDS� on page 62

! �Migrating UNIX Users to NDS� on page 62

! �Migrating UNIX Passwords to NDS� on page 63

Configuring the unix2nds Migration UtilityThe default configuration parameters are provided in the /etc/unix2nds.inp file. You can edit this file to modify the values of the parameters. The following table explains the unix2nds configuration parameters.


admin The fully distinguished name of the user with administration rights.

password The password of the user with administration rights.





The following is a sample unix2nds.inp file:

admin=admin_FDNpassword=admin_passwordpromptIfDuplicateExist=yes/nopromptIfDuplicateAccounts=yes/nomigrateContext=user_contextforceExpirePassword=yes/no

promptIfDuplicateExist Specifies whether you want to be informed about the existence of duplicate accounts.

promptIfDuplicateAccouts Specifies whether you want to be prompted to change the account name when duplicate accounts are found.

migrateContext Specifies the user or group context.

If you do not specify the user or group context, the utility will use the default value. The default values are UNIX users or UNIX groups.

forceExpirePassword Specifies whether you want to use the password of the migrated NDS.

Upgrade Specifies whether you want to upgrade to UNIX accounts if a NetWare® account exists with the specified name.

AccessToAllWorkstations Specifies whether you want to provide access to all workstations in the Account Management domain.

SearchContext Specifies the searchable context in which to look for duplicate names. If you have more than one searchable context, this parameter must specified for every searchable context.

SearchSub Specifies whether you want to do a subtree search for all the searchable contexts.

type Specifies whether the input file containing the UNIX accounts information is in the passwd, group, or shadow formats.

createContainer Specifies whether you want to create a context if the migration context does not exist.






Upgrade=yes/noAccessToAllWorkstations=yes/noSearchContext=FDN1_context_in_which_you_want_to_search_for_a_duplicate_accountSearchContext=FDN2_context_in_which_you_want_to_seach_for_a_duplicate_accountSearchSub=yes/notype=passwd/group/shadowcreateContext=yes/no

Using the unix2nds UtilityUse the following syntax for flexible migration tool operations:

unix2nds [-a admin_FDN][-p password][-i][[-Cmigrate_context][-G group_context][-w][-x][-h][-?][-ggroup_file][-u][-m][-S searchable_context][-b][-s] [-tpassword/group/shadow] [-f input_file][-cconfiguration_file]

Option Description

-a admin_FDN The fully distinguished name of the user with administration rights to the NDS tree.

-p password The password of the user with administration rights.

-i Specifies whether you want to be informed about the existence of duplicate accounts

-C migrate_context Specifies the user or group context into which you want to migrate or upgrade accounts.

-x Specifies that you do not want to use the password of the migrated NDS accounts. The default is yes.

-m Calls the migrate2nds utility to migrate accounts into the NDS tree.

-G group_context Migrates User accounts under Group accounts in the specified group context only. This option is used only when you are migrating User accounts.

-w Provides access to all workstations in the Account Management domain. The default value is to give access to the current workstation only. This option is used only when you are migrating Group accounts.





NOTE: When you use both the -i and -u options, existing NetWare accounts will be upgraded to UNIX accounts. If you use only the -i option, any existing NetWare accounts will not be upgraded. If you use only the -u option, you will be prompted to select whether you want to upgrade or change the name of the User or Group account.

-t passwd/group/shadow Formats of the accounts you want to migrate into the NDS tree. The default value is passwd.

-h Displays help on the utility.

-g group_file Specifies the group file that was used to migrate the groups. This option is required while migrating users to NDS.

-u Upgrades to UNIX accounts if a NetWare account already exists with the specified name. The default value is not to upgrade.

-S searchable_context The searchable context in which to look for duplicate names. If you have more than one searchable context, this option is specified for every searchable context. The default value is to search only the context into which you are migrating the accounts.

-s Specifies not to do a subtree search. The default value is to search in the subtree.

-f input_file The input file containing the UNIX account information in password, group, or shadow formats to be migrated. If you do not specify this option, the utility will look for account information from the standard input in the format specified using the -t option.

-c configuration_file Specifies the configuration file to use instead of the default /etc/unix2nds.inp configuration file.

-b Specifies not to create a context if the migration context does not exist. The default value is to create a migration context.

Option Description





Migrating UNIX Groups to NDSGroups are migrated with group names and GIDs. The member list (users belonging to the group) for the groups are updated after migrating the users, because there is a possibility that the names of the users might not be migrated or might change during migration. The utility will read the UNIX group account information either from the input file specified in the command line or standard input in /etc/group file format. Group objects are created in the default context or in a context the user specifies. Creation of the Group object fails if a group by that name already exists in the specified context. If the existing group is a NetWare group, you can upgrade that group to a UNIX group.

If a UNIX Group object of the specified name already exists, you can migrate the group with a different name. Ensure that you migrate the users accounts under the changed group. Otherwise, the users will become the members of a different group in NDS. After migrating User accounts, the Group objects are updated with the users belonging to the group.

To migrate UNIX Group accounts into NDS:


unix2nds -t group -f GroupAccountsFile

The utility takes the group account information from the GroupAccountsFile, and migrates the information into the default group ou=unix-groups context.

Migrating UNIX Users to NDSThe utility takes UNIX user account information from the input file specified from the command line or from the standard input in the /etc/passwd file format.

Creation of a User object in NDS fails if a User object by that name already exists in the specified context. If the existing user is a NetWare user, you can upgrade that user to a UNIX user. If the existing user is a UNIX user, you can migrate the User with a different name.

To migrate UNIX user accounts into NDS:


unix2nds





UNIX user account migration information will be taken from the standard input in /etc/passwd format. The utility will take default configuration information from /etc/unix2nds.inp.

Migrating UNIX Passwords to NDSUNIX user password information can be migrated after migrating the UNIX user accounts. The input file to migrate the passwords of the User accounts will be in /etc/shadow file format. If the UNIX user is not yet migrated, the utility will not migrate the passwords.

Managing UNIX User and Group AccountsThe following sections provide information about managing UNIX User and Group accounts:

! �Creating a UNIX Group, Template, and User Object� on page 63

! �Assigning UNIX Attributes for Group, Template, and User Objects� on page 65

! �Viewing UNIX Configuration Object Details� on page 67

! �Modifying a UNIX Workstation Object� on page 68

Creating a UNIX Group, Template, and User ObjectUNIX user accounts, groups, and workstations are represented by objects in NDS. Each UNIX system that needs to be accessed by users must have a corresponding Workstation object in the NDS tree. A UNIX group can be granted membership to the Workstation object. This allows all users in the UNIX group to be granted access to the UNIX system represented by that Workstation object. The steps to create UNIX User, Group, and Workstation objects are described in the following sections.

You must ensure that the usernames and IDs in a context are unique.

The following sections provide information about creating UNIX Group, Template and User objects:

! �Creating a UNIX Group Object� on page 64

! �Creating a UNIX Template Object� on page 64

! �Creating a UNIX User Object� on page 64





Creating a UNIX Group Object

1111 Right-click the container where you want to create the Group object > click New > click Group.

2222 In Create Group, enter a name for the new Group object.

3333 Click Define Additional Properties.

4444 Click OK.

To define UNIX attributes for the Group object, refer to �Assigning UNIX Attributes to a Group Object� on page 65 and follow the instructions from Step 2 on page 65.

Creating a UNIX Template Object

If you need to set up several new users who share certain common requirements, you can create a Template object to facilitate the task. Do not use a Template object to create a user whose requirements are entirely unique.

1111 Right-click the container where you want to create the Template object > click New > click Object.

2222 From the New Object dialog box, click Template > OK.

3333 In the Name field, enter a name for the new object.

4444 (Optional) To base the Template object on an existing Template or User object, check Use Template or User.

5555 Check Define Additional Properties.

6666 Click OK.

To define UNIX attributes for the Template object, refer to �Assigning UNIX Attributes to a Template Object� on page 66 and follow the instructions from Step 2 on page 66.

Creating a UNIX User Object

1111 Right-click the container where you want to create the user > click New > click User.

2222 In the Name field, enter the user�s login name.

3333 In the Surname field, enter the user�s last name.





4444 (Optional) In the Unique ID field, enter an identifier to enable LDAP access for the user.

The identifier must be unique for each user in the NDS tree.

5555 Click Define Additional Properties.

6666 Click OK.

You can assign a password to the user in the Create Authentications Secrets dialog box. If you want to assign it later, click OK. To define UNIX attributes for the User object, refer to �Assigning UNIX Attributes to a User Object� on page 66 and follow the instructions from Step 2 on page 66.

Assigning UNIX Attributes for Group, Template, and User ObjectsThe following sections provide information about assigning UNIX attributes for Group, Template, and User objects:

! �Assigning UNIX Attributes to a Group Object� on page 65

! �Assigning UNIX Attributes to a Template Object� on page 66

! �Assigning UNIX Attributes to a User Object� on page 66

Assigning UNIX Attributes to a Group Object

1111 Right-click the Group object you want to assign UNIX attributes to > click Properties.

2222 Click the UNIX Profile Identification tab.

3333 In the Group ID field, enter an ID for the group.

This field is mandatory for the group to be identified as a UNIX group.

4444 To delete the UNIX profile of the selected Group object, check the Delete UNIX Profile check box.

5555 Click the UNIX Profile Workstation Memberships tab.

6666 Click Add.

A browser window lists the available workstations. You can assign workstation memberships in this window.

7777 Select the required workstations > click OK.

The selected Workstation objects appear in the Workstation Membership list.





8888 (Optional) To remove workstations in the Workstation Memberships list, select the Workstation object > click Delete.

9999 (Optional) To add users to the group, click the Members tab.

A browser window lists the available User objects. You can assign secondary group memberships for the listed User objects.

Select the required objects > click OK.

The selected objects appear in the Group Members list.

10101010 (Optional) To remove secondary group memberships in the Members screen, select the User objects > click Delete.

11111111 Click OK.

Assigning UNIX Attributes to a Template Object

1111 Right-click the Template object you want to assign UNIX attributes to > click Properties.

2222 Click the UNIX Profile tab.

3333 To select the Primary Group the user should belong to, click the browse button.

Select the required group > click OK.

It is mandatory to select a UNIX group.

4444 Select a login shell from the Login Shell drop-down list: Bourne, C, Korn, or Other.

Bourne, C, and Korn are pre-defined login shells and the paths to these shells cannot be modified. Select Other if you want to specify the path to the login shell.

5555 In the Home Directory field, specify the default directory for the user.

The default home directory is /home/username.

6666 (Optional) In the Comments field, enter a description for the template.

7777 Click OK.

Assigning UNIX Attributes to a User Object

1111 Right-click the User object you want to assign UNIX attributes to > click Properties.

2222 Click the UNIX Profile tab.





3333 In the User ID field, enter a unique identification for the user.

4444 To select the primary group the user should belong to, click the browse button.

Select the required group > click OK.

It is mandatory to select a UNIX group.

5555 Select a login shell from the Login Shell drop-down list: Bourne, C, Korn, or Other.

Bourne, C, and Korn are pre-defined login shells and the paths to these shells cannot be modified. Select Other if you want to specify the path to the login shell.

6666 (Optional) In the Home Directory field, specify the default directory for the user.

The default home directory is /home/username.

7777 (Optional) In the Comments field, enter a description for the user.

8888 Click the Group Membership tab > click Add to assign secondary group memberships for the User object.

9999 Select the required objects > click OK.

10101010 (Optional) To remove secondary group memberships in the Members list, select the group > click Delete.

11111111 Click OK.

The home directory for the user has to created manually on the Linux or Solaris host.

Viewing UNIX Configuration Object Details1111 Right-click the UNIX Config object.

2222 Click Properties.

3333 Click the Configuration tab.

The Property page displays the contexts that UNIX Workstation objects reside in.

4444 Click the Identification tab.

The Property page displays the name for the UNIX Config object.





Modifying a UNIX Workstation Object1111 Right-click the UNIX Workstation object > click Properties.

2222 (Optional) Click the Identification tab > in the Description field, enter a description for the Workstation object.

3333 Click the Members tab.

4444 Click Add.

A browser window listing the available groups opens.

5555 Select the required groups > click OK.

All users belonging to these groups will be granted access to the UNIX system represented by the Workstation object.

6666 (Optional) To delete the groups from the Members list, select the groups in the Member list > click Delete.

7777 Click OK.

To delete the UNIX Workstation object, right-click the object > click Delete. This is not recommended. If you delete the Workstation object, bring down the Account Management cache daemon, nds_uamcd, on the corresponding Linux or Solaris host and restart it.

WARNING: Do not delete the UNIX Workstation object using ConsoleOne. Run the nds-uninstall program, then select the Account Management option on the Linux or Solaris host. This will remove the UNIX Workstation object as part of the uninstallation process.

Optimizing Account Management The following sections contain information about optimizing the performance of the Account Management component:

! �Using the nds_uamcd Cache Daemon� on page 68

! �Providing a Cache for the Most Common Name Service Requests� on page 69

Using the nds_uamcd Cache DaemonNDS provides a caching daemon, nds_uamcd, which caches the fully distinguished name (FDN) of User objects. Whenever the pam_nds and the nss_nds modules access the NDS database to get a User object, the nds_uamcd





daemon caches the FDN of that User object. NDS searches the cache before accessing the NDS database, making the access quicker.

Start the nds_uamcd daemon when the system is rebooted.

To run the nds_uamcd daemon:

! On Linux systems, enter the command:

/etc/rc.d/init.d/nds_uamcd start

! On Solaris systems, enter the command:

/etc/init.d/nds_uamcd start

To stop the nds_uamcd daemon:


/etc/rc.d/init.d/nds_uamcd stop


/etc/init.d/nds_uamcd stop

The nds_uamcd daemon can be configured using the uamconfig utility.

Providing a Cache for the Most Common Name Service RequestsRed Hat (6.0 and later) and Solaris systems provide a cache daemon, nscd, which provides a cache for the most common name service requests. The nscd daemon caches the profiles of user and group entries, improving the performance of applications such as ls and ps. The nscd daemon can be configured using the /etc/nscd.conf file.

To run the nscd daemon:


/etc/rc.d/init.d/nscd start


/etc/init.d/nscd start





To stop the nscd daemon:


/etc/rc.d/init.d/nscd stop


/etc/init.d/nscd stop

Restart the nscd daemon each time the NSS, PAM, or NDS configuration is modified using /etc/nsswitch.conf, files in the /etc/pam.d directory, or /etc/nds.conf files. You must also restart the daemon if you find that the password or username entries do not get reflected quickly after changes.

Troubleshooting Account Management on Linux and Solaris

The following sections provide information about troubleshooting Account Management:

! �Migrated Users Are Not Able to Log In� on page 70

! �Verifying Whether NDS Authentication Is Working� on page 71

! �A User with Root Equivalent Rights Is Not Able to Change the Passwords of Other Users� on page 71

! �A User Is Not Able to Log In� on page 72

! �Password Expiration Information for the User Is Not Available� on page 72

Migrated Users Are Not Able to Log InDuring migration, the migrate2nds utility may not be able to provide group access to the Workstation object that corresponds with the Linux or Solaris host, if the value no has been specified for the AccessToAllWorkstations parameter in the input file. This might be because there were two Workstation objects corresponding to the Linux or Solaris host and one object was deleted. The Account Management cache daemon, which caches the names of the objects, has still cached the name of the deleted Workstation object. The migrate2nds tool displays the following message:

Unable to find the Workstation object.





To grant workstation access to the migrated groups, bring down the Account Management cache daemon using the following commands:

! On Linux systems, enter:

/etc/rc.d/init.d/nds_uamcd stop

! On Solaris systems, enter:

/etc/init.d/nds_uamcd stop

To restart the Account Management cache daemon, use the following commands:

! On Linux systems, enter:

/etc/rc.d/init.d/nds_uamcd start

! On Solaris systems, enter:

/etc/init.d/nds_uamcd start

Add the migrated groups to the Workstation object using ConsoleOne.

Verifying Whether NDS Authentication Is WorkingNDS provides a diagnostic utility to verify NDS authentication.

To verify whether NDS authentication is working properly using the ndslogin utility, enter the following command:

/usr/bin/ndslogincanonical_name.organizational_name.TREE_NAME

To check whether user Bob is being authenticated, enter the following command:

/usr/bin/ndslogin bob.is-calls.provo.novell.DEMO_TREE

You will be prompted for the user�s password. The ndslogin utility will report whether NDS authentication is working successfully.

A User with Root Equivalent Rights Is Not Able to Change the Passwords of Other Users

! If the root equivalent user (with uid=0) has been migrated to NDS, this root equivalent will not be able to change the passwords of other users in NDS, even though this user will be prompted for the root password. Only the root user will be able to change a user�s password in NDS.





To overcome this issue, assign administration rights to the root equivalent user through ConsoleOne.

! The root user is prompted for the user�s old password while using the passwd command. This happens when a user�s ID is changed to root through the su utility.

To overcome this issue, log in as a root user through TELNET* or any other utility and use the passwd command.

! If UNIX users are added through LDAP, [Public] must be given Read permission to various attributes of the created user.

A User Is Not Able to Log In! A user is not able to log in and is getting the following message: Nosuch entry. The user entry is cached in two daemons, nscd and nds_uamcd. You decide an optimal cache interval. Within the cache interval, if you modify the user entries, it will not be reflected on the Linux or Solaris host. For the changes to be effective immediately, you must stop and restart the nscd and nds_uamcd daemons. On Linux systems, the nscd daemon is available only with Red Hat 6.0 and later.

! If the time to log in takes more than 60 seconds, the login utility times out. This is a limitation of the Linux and Solaris operating systems.

! If you have created a user through ConsoleOne, and assigned a password that is longer than eight characters, the user may not be able to log in. This is because the passwd command cannot process passwords that are longer than eight characters. The password is truncated.

! A migrated user may not be able to log in using the Novell ClientTM. This is because a migrated user can log in using the client only after logging in from a Linux or Solaris host. If you change the password, this restriction does not apply to the user.

! The uids must be less than 65535. If you have assigned a uid greater than 65535 through ConsoleOne, or migrated the user from a Solaris system where the uid is greater than 65535, the user will not be able to log in.

Password Expiration Information for the User Is Not Available When Account Management is installed, a Workstation object representing the Linux or Solaris host is created in NDS. A key pair (public and private key) is generated for this object. Background applications, such as Cron, check for





the validity of the user account without invoking the authentication feature of pam_nds. The private key of the user is required to give details such as password expiration of the user. In case the file in which the private key is stored is corrupted, the password expiration information will not be available.

In such a case, you can run the ndswskey utility to generate a new key pair for the Workstation object. You are prompted to enter the administrator�s name with full context and password.

IMPORTANT: This utility can be run only if Account Management has been installed.




Account Management Administration Guidegwise.itwelzel.biz/Novellpdf/Novell Account Management...

Documents

Transcript of Account Management Administration Guidegwise.itwelzel.biz/Novellpdf/Novell Account Management...