Sun Microsystems
Products & Services
 
Support & Training
 
 

Previous Previous     Contents     Index     Next Next
Appendix B

User Management For N1GE on Windows Hosts

Overview

Every user of the N1GE execution environment of a Windows machine must have a user account. User accounts contain information about the user, including name, password, various optional entries that determine when and how users log on. and how their desktop settings are stored.

Following sections describe how you would use Windows user management to support N1GE. Windows machines are referred to here using three different terms. The following table lists the terms and the operating systems which might run on each corresponding host:

Windows Host

Microsoft Windows 2000, Microsoft Windows XP, Microsoft Windows 2000 Server, Microsoft Windows Server 2003

Windows Server

Microsoft Windows 2000 Server, Microsoft Windows Server 2003

Windows Workstation

Microsoft Windows 2000, Microsoft Windows XP

Managing Users on Windows Hosts

It is possible to administer user accounts on all Windows hosts individually. Each Windows Host has an authentication centre which validates usernames and corresponding user rights. User accounts which are defined on a Windows workstation are referred to here as local user accounts or local users.

Each Windows Host has it's own local domain and each Windows Server has the ability to make that domain available to other hosts. Account names within a local domain and account names within a server domain can collide. To avoid such collisions, you must specify the correct user account by providing the domain name as a prefix to the user account name followed by a '+' character.

Windows User Example

The following is an example that illustrates the potential complexity of Windows host accounts interacting with Windows Domain accounts. Suppose Windows Workstation host named CRUNCH has a local user account named Peter. This Windows Workstation is part of the domain named ENGINEERING. This domain is provided by a Windows Server which also has a user account named Peter. In this example, the ENGINEERING domain is the default domain of the host named CRUNCH. The following table shows the possible results of what would happen if a person tried to login to CRUNCH.

Table B-1 Using Domain Accounts

Login Name

Result

CRUNCH+Peter

Peter is logged in with his account as a local user of the machine CRUNCH.

ENGINEERING+Peter

Peter is logged in with the account provided by the Windows Server hosting the ENGINEERING domain.

Peter

This approach is equivalent to using ENGINEERING+Peter because CRUNCH has ENGINEERING as it's default domain. Otherwise, the local account would be used.

Each domain has a special user account providing super user access. The default name for that account is Administrator. Only this Administrator can start applications on behalf of other user accounts without needing to know the Windows password for each account. So, a local administrator can start applications for local users and a domain administrator can run processes under the account of domain users.

UNIX User Management

UNIX has no equivalent to the Windows domain concept. Win UNIX, each user has a local account and is authenticated as a local account even if the underlaying account information lies on a LDAP or NIS server. The UNIX super user (root) is similar to the local Windows super user (Administrator). The UNIX super user can start applications and processes on behalf UNIX accounts without knowing each corresponding password.

Using N1GE in a Microsoft Windows Environment

The N1GE execution environment has to start jobs on behalf of the submitting user. The execution daemon (sge_execd) on UNIX hosts runs as the user root so it can start jobs on behalf of all users.

On Windows Hosts the execution daemon runs as the local Administrator user so it can start jobs for local users without knowing their passwords. However, to start a job for a domain user, the execution daemon needs the password for that domain user. To facilitate this process, each user with a domain account needs to have their corresponding Windows password registered with N1GE.

Registering Windows Domain User Passwords

Domain users who want to start N1GE jobs on Windows execution hosts register their Windows passwords with N1GE using the sgepasswd client application. The following example shows Peter who has a user account in the domain ENGINEERING registering his Windows password.

> sgepasswd -D ENGINEERING
   Changing password for ENGINEERING+Peter
   New password:
   Re-enter new password:
   Password changed

Using the sgepasswd Command

sgepasswd modifies the Grid Engine password file (sgepasswd(5).) This file contains a list of usernames and their Windows passwords in encrypted form. You can use the sgepasswd to add a new entry for your user account or change your existing password. Additionally, the root user can change or delete the password entries for other user accounts. sgepasswd is only available on non-Windows hosts. It has the following syntax:

sgepasswd [[ -D domain ] -d user ]

       sgepasswd [ -D domain ] [ user ]

This command has these options:

--D domain

By default sgepasswd adds or modifies the current UNIX username without a domain specification. You can use this switch to add a domain specification in front of the current user name. Consult your Microsoft Windows documentation to get more information about domain users.

--d user

Only root can use this parameter to delete entries from the sgepasswd(5) file.

--help

Prints a listing of all options.

Additionally, The following environment variables affect the operation of this command.

SGE_CERTFILE

Specifies the location of public key file. By default sgepasswd uses the file $SGE_ROOT/$SGE_CELL/common/sgeCA/certs/cert.pem

SGE_KEYFILE

If set, specifies the location of the private key file. The default file is /var/sgeCA/port${SGE_QMASTER_PORT}/private/key.pem

Previous Previous     Contents     Index     Next Next