Sun N1 Grid Engine 6.1 Installation Guide

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 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.”