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 that has the same name as on the UNIX hosts. 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:

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.

Each domain has a special user account that provides superuser access. The default name on English systems for that account is Administrator. For native Windows, the members of the Administrators group and of the Domain Admins group in the server domain also have superuser access. However, for Interix, only the user Administrator of the local domain is the superuser of the local host.

The local Administrator can start applications under an users account without knowing the password of this user, but because - in opposition to the Unix super user 'root' - even the local Administrator is not fully trusted by the network, the application wouldn't be able to access network resources then. This is why there is the sgepasswd tool to register the users passwords, as explained in “Using N1GE in a Microsoft Windows Environment.”

UNIX User Management

UNIX has no equivalent to the Windows domain concept. With 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 on behalf of users without knowing their password, but these jobs wouldn't have the permissions to access network resources. Only fully authenticated users can access network resources, and for a full authentication the users password is needed. Therefore all users who want to submit jobs to a Windows execution host have to register their password with N1GE. The execution daemon still needs to run as the local Administrator to have the permissions to do several administrative tasks. .

Registering Windows User Passwords

Users who want to start N1GE jobs on Windows execution hosts use the sgepasswd client application to register their Windows passwords with N1GE. The following example shows Peter who has a user account in the domain ENGINEERING. Because ENGINEERING is the principal domain of the Windows execution host CRUNCH, Peter does not need to register his password for a specific domain. This should be the default in any properly set up single domain environment. sgepasswd must be run on a non-Windows host.

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

Only in multiple domain environments it could be necessary to register the password explicitly for a specific domain.

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:

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

Adding Windows Hosts to Existing N1 Grid Engine Systems

If you have a running N1 Grid Engine system on which Windows support is not enabled, you can enable the support manually. The following steps provide a Windows-enabled N1 Grid Engine system that allows additional Windows execution hosts.

How to Add Windows Hosts Later

1. Copy Windows binaries to the <sge-root> directory.

2. Type the following command:

   qconf -mconf

   Set the execd_params to "enable_windomacc=true."

3. Type the following command:

   qconf -am <win_admin_name>

4. Run the following command:

   $SGE_ROOT/util/sgeCA/sge_ca -init -days 365

5. For a CSP installation, run the following command:

   $SGE_ROOT/util/sgeCA/sge_ca -user <win_admin_name>

6. Type the following command:

   qconf -ah <new_win_hosts>

7. Copy certificates to each Windows host.

8. Set the owner of the certificates to ADMINUSER

   Use a command similar to the following example:

   chown -R foo:bar /var/sgeCA/port<SGE_QMASTER_PORT>

9. Run normal exec daemon installation on each execution host.