Below is a detailed description of the difference between local and domain logons...
Have you looked at your GPO's? You said you can manage the workstations that have the issue yet you did not say that the group memberships are as described in previous posts... On your FSMo role holder, look at AD, system, Group policy logs to see if there
are any issues... Also make sure your time settings are correct and in line with your NTP server (normally set on the DC holding the roles)
Local Logon
Local logons give users access to local computer applications and resources but not to domain applications and resources. When users log on locally, their identities are validated by authentication
packages to local account information stored in the Security Accounts Manager (SAM) database. The SAM operates in the security context of the LSA; it protects and manages user and group information in the form of security accounts stored in the local computer
registry. Because user accounts are stored on the local computer, network access is not required for local logons. However, if a computer has a network connection and a user logs on to a local account, there is no interaction with the network.
Local logons can be performed on Windows client operating systems, such as Windows 7 and Windows Vista. Windows server operating systems, such as
Windows 2008 Server, and Windows Server 2012, also permit local logons.
The following figure shows the local logon architecture.
Interactive Local Logon
![]()
A successful local logon begins when a user presses CTRL+ALT+DEL. Winlogon and the GINA DLL collect the user's credentials and then send the credentials to the LSA. The LSA verifies the user's identity and then returns a logon success and the user's
access token to Winlogon and the GINA DLL. Winlogon and the GINA DLL then activate the user's shell by creating a new process, such as Explorer.exe.
Domain Logon
Domain
logons give users access to resources throughout the domain. Domain user
accounts are stored in an Active Directory domain. Active Directory is deployed
on each domain controller, and domain user accounts are replicated throughout a
domain.
Before
a user can log on to a computer by using a domain account, the computer must be
joined to a domain. If the computer has access to a network connection, the
user can log on to a domain if the user has an account in the domain's Active
Directory.
The
computer must transparently authenticate to the domain's Active Directory. This
form of logon is called a computer logon. Both users and computers are
considered equal security principals in Active Directory; to be granted access
to network resources, both must be able to verify their identities.
Users
can use a domain account to log on to Windows client operating systems, such as
Windows 8. Windows server operating systems, such as Windows Server 2012
R2, also permit domain logons. Only server operating systems can function as
domain controllers and deploy Active Directory.
On
a domain-joined computer, Windows is hard-coded to show only the last logged on
user or Other
user. Additional tiles for other users to log on are available
only for computers joined to a workgroup.
The
following figure shows the domain logon architecture.
Interactive Domain Logon
![]()
Unlike a local logon in which the local LSA validates the user, during a domain logon, the LSA on a domain controller validates the user. The LSA evaluates the user's credentials to determine
if the logon should be processed as a logon to a local account or a logon to a domain account. After determining the logon type,
either the NTLM or Kerberos authentication package validates the user. If the authenticating domain controller is a computer running Windows 2008 or Windows Server 2012, the LSA will use Kerberos, the default authentication package for domain and
network logons. The LSA uses NTLM to process domain logons in Windows NT 4.0 mixed environments.
-
Edited by
Jedi_Administrator
Wednesday, August 12, 2015 4:15 PM
Other recent topics
