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