Authentication on Windows platforms
Account names authenticated by EMSRV for Windows 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 SAM-compatible name
engineering\adrian
user principal name
adrian@ral.vast.com
Windows non-domain controllers support simple names and SAM-compatible names. Windows domain controllers support all three formats. The new formats allow authentication between domains as well as in an Active Directory.
Windows supports installable authentication and security packages, allowing the system to be extended with new forms of authentication and security. EMSRV for Windows only supports the default packages supplied with Windows -namely the MSV1_0 and Kerberos authentication packages and the NTLM (NT LAN Manager) and Kerberos security packages.
Authentication Procedure using Windows Non-Domain Controllers
EMSRV for Windows uses NTLM (NT Lan Manager) authentication on Windows 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 Workstation that is a member of a domain is considered to be the name of that Windows machine. The name of the SAM database on a Windows Server is the name of the domain. If a Windows Workstation 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 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 and 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 Domain Controllers
EMSRV for Windows uses Kerberos authentication on Windows Domain Controllers. User records for Windows 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 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 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 - vast, ral.vast, and engineering.ral.vast. The engineering.ral.vast domain is a child of the ral.vast domain and the ral.vast domain is a child of the vast domain. Each parent-child relationship automatically creates a two-way transitive trust relationship. As a result, since ral.vast trusts engineering.ral.vast and vast trusts ral.vast, vast trusts engineering.ral.vast. The three domains form a tree.
In addition there is another Active Directory domain - bedrock, which forms a tree of one domain. The vast 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 vast trusts KIRA.
If EMSRV is run on the domain controller for the vast domain, users from the following domains can be authenticated:
vast
ral.vast
engineering.ral.vast
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 Local Security Policy for Windows Workstation. For Windows 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 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.