Users, Workstations, Domains and Machine Domains Explained (by Chuck Chopp)

Keywords:   Users, Workstations, Domains and Machine Domains Explained

A workstation [in the NT platform family, includes NT/2K/XP systems], joins a domain so that all users in the same domain [or in other domains trusted by the workstation's primary domain] may access resources on the workstation w/o having to have a local account on the workstation. When a workstation joins a domain, it effectively says that it trusts anybody in the domain and allows them access to its local resources. Furthermore, if the domain controllers in the workstation's domain also trust other domains, then users in those other domains may also access the resources on the workstation.

At the low level, domain membership causes the NetLogon service to become functional on a workstation. Instead of only authenticating user accounts via the local SAM database on the workstation, the NetLogon service actually hands the authentication process off to a domain controller to perform on its behalf. Once the domain controller has processed the authentication request, the workstation simply agrees to honor the results of the authentication process and allows the user access to local resources.

A workstation cannot belong to multiple domains. However, the domain that it belongs to may trust other domains or may be trusted by other domains. Traditional NT style domains have the ability to set trust relationships up in a unidirectional or bi-directional way. For example, a master domain may contain all of the user accounts at a central site while resource domains exist at each local site and provide localized control over print & file sharing services. The resource domains are configured to trust the master domain so users in the master domain have trusted access to resources in the resource domains. However, user accounts in the resource domains have no access to the master domain as the resource domains are not trusted by the master domain. Under AD, inter-domain trust relationships are extended in that they automatically exist if there is a hierachical ancestor/descent relationship between any two domains. Also, under AD, trust is transitive in that if A trusts B and B trusts C, then A implicitly trusts C. Under the legacy NT domain model, trusts are not transitive and have to be explicitly established; this was one of the real headaches in that a network with N individual master domains with a fully meshed birectional trust relationship required something on the order of N! trusts to be established. Yuck!

> 2) When a user logs onto a machine, they can specify userid and domain.  
> Does this have anything to do with the machine domain?

Yes, it does. Since the workstation is a member of a domain, it does not actually perform the authentication. Instead, a domain controller performs the authentication. If the user that is logging on is in a domain other than the domain in which the workstation belongs then workstation's primary domain must trust the user's domain or else the logon will be denied.

> Also the user can be a member of a workgroup that is different from the domain.
> I had thought domain membership and workgroup membership were mutually exclusive.
>

User's never really belong to a workgroup. In fact, user's don't have their domain membership granted/revoked/changed in the way that workstations do. User accounts are really represented by RIDs [Relative Identifiers] that are tacked on to the end of the domain's SID value. Each user in domain has a unique RID value. Users in different domains may have duplicate RID values, but when qualified by the SIDs for their respective domains they become globally unique identities.

Workstations always have a local SID that belongs to the workstation and which is used to qualify the RIDs for local accounts in the workstation's own local SAM database.

Now, when you have several computers in a workgroup all that you really have is several independent SAM databases on those computers with all of the computers agreeing that they're friendly enough to allow each other to see themselves as neighbors, but they don't have any trust relationship between them. You cannot grant permissions on workstation A for users on workstation B in a workgroup. You either have the users on workstation B explicitly connect to the "IPC$" share with credentials that are for an account on workstation A, or you set up duplicate account names on the workstations and give them the same password. This second case results in implicit trust where there is no explicit domain::member trust relationship, but the fact that you have the same username & password grants you transparent access to resources on the remote workstation.

Workstations, now they can be members of a domain [e.g. the trust a domain controller], or they can be part of workgroups and not trust a domain at all.

> So we're trying to pin down a user account the best we can.
> 
> So we seem to have various groups of data (and working with 95/98/ME/NT/2000/XP
>

The Win9x platform family [Win95/98/ME] does not have the concept of security and a SAM database. The entire OS and all user processes execute in the same security context. All domain resource access is really handled through a dummied up shim that fudges all of the SMB traffic packets so that they contain the acces token that is normally an integral part of every process that exists on a NT platform family system. This means that "user accounts" on 9x/ME systems are really nothing more than a way to implement something like user profiles so that personal settings may be customized for different people who share the same 9x/ME workstation.

> Stanalone machine
> Machine as a member of a single domain.
> (Can there be multiple domain a machine is a memeber of?)

No. See above. However, in a situation where there are inter-domain trusts established, users from many different domains might be able to logon to any given workstation that is itself a member of any of those domains.

> 
> Userid on local machine - Member of workgroup
> userid on domain account  workgroup==domain  (What relation does the machine domain have to this)
> userid on domain account workgroup!=domain
> 
> does the domain have to be the same domain that the machine is part of?  If not, what role
> does the domain the machine belongs to have in all this.
>

The previous group of questions should be pretty much answered by the discussion above. It all comes down to who trusts who and who the keepers of the keys are w/respect to authenticating logon requests.

> How can all this be determined (for extra credit - without loading an extender)

The NT extender is the tool to use for this. Specifically, the wntLsaPolGet() function does a marvelous job of telling you what you need to know about domain membership for the workstation [or workgroup membership] as well as telling you what domain the current interactive user belongs to.

To do this w/o an extender would take doing some DllCall() work with binary buffers. I'd have to actually review the NT extender source code for the wntLsaPolGet() function to determine exactly what needs to be done and how easy/difficult it would be to perform via DllCall().

Article ID:   W15551

File Created: 2003:05:13:11:28:42

Last Updated: 2003:05:13:11:28:42

	Domain
	Logon Issues
	Microsoft Client
	Novell Netware
	Server Configurations
	Services
	WhitePapers

Database Search

TechHome

Users, Workstations, Domains and Machine Domains Explained (by Chuck Chopp)