# Installation Guide

### Authentication on Windows platforms

Account names authenticated by EMSRV for Windows NT/2000 can come from two sources -- the name of the EMSRV user and the network names for users managed in a repository. As of this release, an account name may be in one of three formats:

    Simple name
        adrian
    Windows NT 4.0 SAM-compatible name
        engineering\adrian
    user principal name
        adrian@ral.ibm.com

Windows NT 4.0 and Windows 2000 non-domain controllers support simple names and SAM-compatible names. Windows 2000 domain controller support all three formats. Previous releases of EMSRV for Windows NT only supported simple names. The new formats allow authentication between domains as well as in an Active Directory.

Windows NT and Windows 2000 supports installable authentication and security packages, allowing the system to be extended with new forms of authentication and security. EMSRV for Windows NT/2000 only supports the default packages supplied with Windows NT and Windows 2000-namely the MSV1_0 and Kerberos authentication packages and the NTLM (NT LAN Manager) and Kerberos security packages.

#### Authentication Procedure using Windows NT and Windows 2000 Non-Domain Controllers

EMSRV for Windows NT/2000 uses NTLM (NT Lan Manager) authentication on Windows NT 4.0 and Windows 2000 non-domain controllers. User records in these systems are stored in a SAM (Security Accounts Manager) database.

To authenticate a user, EMSRV must first find the name of the domain with the SAM database that contains the user to be authenticated. The term domain applies equally to non-domain controllers because every SAM database contains a built-in domain known as 'BUILTIN' as well as for non-domain controllers, a domain with the same name as the machine or for domain controllers, the controlled domain.

If a SAM-compatible name (specifying a domain) is supplied, then the domain is already known. If a simple name is provided then the following are checked to find the user:

- a list of well-known SID (Security Identifiers
- built-in and administratively defined local accounts
- the primary domain
- trusted domains

Once the domain is known, an attempt is made to authenticate the user in that domain.

If the domain name matches the name of the SAM database on the local machine then the authentication is processed on that machine. The name of the SAM database on a Windows NT Workstation that is a member of a domain, is considered to be the name of that Windows NT machine. The name of the SAM database on a Windows NT Advanced Server is the name of the domain. If a Windows NT machine is not a member of a domain then authentication is processed locally.

If the domain specified is trusted by the domain of the machine running EMSRV, the authentication request is passed through to the trusted domain. On a Windows NT workstation, the request is always passed through to the primary domain controller of the workstation, allowing the primary domain controller to determine if the specified domain is trusted.

If the domain name specified is not trusted by the domain of the machine running EMSRV, the authentication request is processed on that machine as if the domain name specified were that domain (or computer) name. In other words, the domain name is ignored. The system does not differentiate between a nonexistent domain or an untrusted domain.

An example illustrates how cross-domain authentication can be setup:

There are two domains: KIRA and CHIEF. The domain controller for the KIRA domain is NT4PDC. The domain controller for the CHIEF domain is NT4PDC2. A trust relationship is setup so that CHIEF is a trusted domain of KIRA (and hence KIRA is a trusting domain of CHIEF). The trust relationship is one-way such that KIRA is not a trusted domain of CHIEF.

EMSRV is setup to run on `KIRA\NT4PDC`. Users in both domains can be authenticated. Account names may be specified using a simple name in which case EMSRV will locate the domain containing the user, or the domain may be specified using a SAM-compatible name such as CHIEF\ADRIAN.

EMSRV is setup to run on CHIEF\NT4PDC2. Only users in the CHIEF domain can be authenticated because KIRA is not a trusted domain of the CHIEF domain.

#### Authentication Procedure Using Windows 2000 Domain Controllers

EMSRV for Windows NT/2000 uses Kerberos authentication on Windows 2000. User records for Windows 2000 domain controllers are stored in an Active Directory instead of a SAM database. The KD (Key Distribution Center) service must be running to use Keberos authentication.

If a simple name is supplied, then the procedure for locating the user is the same as that for Windows NT 4.0 and Windows 2000 non-domain controllers. The one difference is that in addition to checking the following:

- a list of well-known SID (Security Identifiers)
- built-in and administratively defined local accounts
- the primary domain
- (explicitly) trusted domains

every domain in the forest for the machine running EMSRV, is also checked. This makes sense since a forest is a collection of Active Directory trees connected by two-way transitive trust relationships.

A SAM-compatible name will be authenticated with the domain that the name specifies. A User Principal Name will be authenticated with Active Directory Services.

The implementation of Kerberos authentication in Windows 2000 is already well-documented elsewhere and does not need to be repeated here. In summary:

The NTLM protocol requires that the server must contact a domain controller. When Kerberos is used, the server does not have to contact the domain controller. A client gets a ticket for a server by requesting one from a domain controller in the server account domain; the server validates the ticket without consulting any other machine.

An example illustrates how Active Directory authentication can be setup:

There are three Active Directory domains - ibm, ral.ibm, and engineering.ral.ibm. The engineering.ral.ibm domain is a child of the ral.ibm domain and the ral.ibm domain is a child of the ibm domain. Each parent-child relationship automatically creates a two-way transitive trust relationship. As a result, since ral.ibm trusts engineering.ral.ibm and ibm trusts ral.ibm, ibm trusts engineering.ral.ibm. The three domains form a tree.

In addition there is another Active Directory domain - bedrock, which forms a tree of one domain. The ibm tree and the bedrock tree together form a forest - they share a common schema, configuration, global catalog, and are linked with two-way transitive trusts at the tree roots.

Finally there is an NT 4.0 domain - KIRA. A one-way trust relationship is setup so that ibm trusts KIRA.

If EMSRV is run on the domain controller for the ibm domain, users from the following domains can be authenticated:

        ibm
        ral.ibm
        engineering.ral.ibm
        bedrock
        KIRA

Simple names for users in any of those domains will cause a search to be initiated to find the domain containing the user. Alternatively, names may be specified in any one of the other two formats previously described.

#### Advanced User Rights Required for Authentication

A number of advanced user rights are required for authentication to work correctly. Authentication is required even if EMSRV is not started with the -rn option since EMSRV authenticates the EMSRV account when it is started and stopped.

Advanced user rights are set in the User Manager for Windows NT 4.0 and the Local Security Policy for Windows 2000 Professional. For Windows 2000 Server, it may be necessary to also set the rights in the Domain Controller Security Policy and the Domain Security Policy so that the Effective Policy Setting for each right is correct in the Local Security Policy. Windows 2000 Advanced Server does not have a Local Security Policy. Instead, the right should be set in the Domain Controller Security Policy and the Domain Security Policy as necessary.

Each of the advanced user rights required for correct EMSRV operation are detailed below

Act as part of the operating system
  This right is required for authentication and must be set for the account from which EMSRV is started (if EMSRV is not started as a service) and the EMSRV account. Note that both accounts must also be part of the 'Administrators' group.

Logon as a service
  This right is required if EMSRV is being started as a service and must be set for the account from which EMSRV is started (if EMSRV is not started as a service) and the EMSRV account. You must also ensure that the 'Deny logon as a service' right is not set for each of the accounts.

Logon locally
  This right is required if EMSRV is being started interactively or from a batch job and must be set for the account from which EMSRV is started (if EMSRV is not started as a service) and the EMSRV account. You must also ensure that the 'Deny logon locally' right is not set for each of the accounts.

Access this computer from the network
  This right is required for each account which will be used to authenticate a client. You must also ensure that the 'Deny access to this computer from the network' right is not set for each account.

[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]