Let's take a closer look at the sign in process when a user attempts to sign into a computer the computer
first it searches for a domain controller to authenticate the user by using DNS.
Look up the computer then send the user name and password to the Domain Controller for authentication.
The local security authority on the domain controller handles the actual authentication process.
If the signing succeeds their LSA builds an access token for the user that contains the security I.D.
for the use around and groups in which the user is a member.
The token provides the access credentials for any process that the user initiates.
For example after assigning to 80 days if a user attempts to open a Microsoft Word file vault uses the
credentials in the user's access token to verify the level of the user's permissions for that file.
Please note that a seat is a unique strain in the form of letters and numbers for example as the swan
does five there's 25 followed by set or sets of numbers where else indicates that the string is in seed
one stands for r or revision level.
And in this case it's the first revision 5 stands for X that is identifier authority while you.
That is fifth and tier authority then follows the main identifier and the last set of numbers.
In this example it's 500.
It's a relative identifier a read which is five.
In this case every user and computer account and every group that you create has a unique seed.
This sets differ from each other only because of the unique read the setting.
This example is a well known seed for a domain administrator account.
The default accounts and groups use well known sets the domain administrator account seed always and
with 500.
Also the signing process appears to the user rather single account.
It consists of two parts the first part.
The user provides credentials.
Usually a user account name and password which are checked against the HDD database.
If the user account name and password match the information stored in the 80 days database the user
becomes an authenticated user and the domain controller issues the user TGT or ticket Grant and ticket.
At this point the user does not have access to any resources on the network.
A secondary processing the background submits the TGT to the Domain Controller and requests access to
the local computer the domain controller issues a service ticket to the user who then can interact with
the local computer.
At this point in the process the user has authenticated to edit yes and signed in to the local computer.
When a user subsequently attempts to connect to another computer on the network the secondary process
runs again and the TGT is submitted to the nearest domain controller.
When the Domain Controller returns a service ticket the user can access the computer on the network
which generates a log on a wound at the computer.
Please remember that domain joint computer also signs into ADT s when it starts.
You do not see the transaction when the computer uses its computer account name and password to sign
into a tedious after authentication.
The computer becomes a member of the authenticated user group.
Although the computer log on a wound does not have visual confirmation in a gooey they went like records
it.
Also if you have enabled auditing the security lock off we went through your records Additionally once.