On Wed, 16 Jun 2010 18:22:39 -0700, BrantRaven
<> wrote:
>Hello Everyone,
>
>I am trying to discover somthing about desktop client communications with
>Active Directory.
>
>One can imagine that an AD client would initiate communications to an AD
>server...for authentication say....but once authenticated...does the client
>maintain a session with the server? Also...does (or can) the server ever
>initiate (of its own accord) communications to the client..say for policy
>updates?
>
>I am only talking about AD here...not any other MS based services. If
>someone could provide a reference...that would be very helpful.
>
>Thank you all.
>
>Brant
Brant,
I agree with Florian. Once the session has been established, there is
no further communications. If a resource needs to be accessed,
depending on where it is, the workstation goes through the kerberos
authentication process to the resource.
Here's more specific info regarding the kerberos logon and
authentication process ...
Kerberos Authentication
From MOC 2823, "Implementing and Administering Security in a Microsoft
Windows 2003 Network," pp 7 - 9
http://www.microsoft.com/learning/en...B&locale=en-us
In a Kerberos environment, the authentication process begins at logon.
The following steps describe the Kerberos authentication process.
1. When a user enters a user name and password, the computer sends
the logon credentials to the KDC. The logon credentials include the
user name, account domain, and preauthentication data encrypted with a
secret key derived from the user?s password. The KDC contains a master
database of unique long-term keys for every principal in its realm.
2. The KDC looks up the user?s master key (KA), which is based on the
user's password. The KDC then creates two items: a session key (SA) to
share with the user and a Ticket-Granting Ticket (TGT). The TGT
includes a second copy of the SA, the user name, and an expiration
time. The KDC encrypts this ticket using its own master key (KKDC),
which only the KDC knows.
Kerberos implements secret key cryptography, which is different
from public key cryptography in that it does not use a public and
private key pair.
3. The client computer receives the information from KDC and runs the
user's password through a one-way hashing function, which converts the
password into the user?s KA. The client computer now has a session key
and a TGT so that it can securely communicate with the KDC. The client
is now authenticated to the domain and is ready to access other
resources in the domain by using the Kerberos protocol.
When a client receives the session key and TGT from the server, it
stores that information securely in volatile memory and not on the
hard disk. Storing the information in the volatile memory and not on
the hard disk makes the information more secure.
4. When a Kerberos client needs to access resources on a server that
is a member of the same domain, it contacts the KDC. The client will
present its TGT and a timestamp encrypted with the session key that is
already shared with the KDC. The KDC decrypts the TGT using its KKDC.
The TGT contains the user name and a copy of the SA. The KDC uses the
SA to decrypt the timestamp. The KDC can confirm that this request
actually comes from the user because only the user can use the SA.
5. Next, the KDC creates a pair of tickets, one for the client and
one for the server on which the client needs to access resources. Each
ticket contains the name of the user requesting the service, the
recipient of the request, a timestamp that declares when the ticket
was created, and a time duration that says how long the tickets are
valid. Both tickets also contain a new key (KAB) that will be shared
between the client and the server so that they can securely
communicate.
6. The KDC takes the server?s ticket and encrypts it using the server
masterkey (KB). Then the KDC nests the server?s ticket inside the
client's ticket, which also contains the KAB. The KDC encrypts the
whole thing using the session key that it shares with the user from
the logon process. The KDC then sends all the information to the user.
7. When the user receives the ticket, the user decrypts it using the
SA. This exposes the KAB to the client and also exposes the ticket for
server. The user cannot read the server?s ticket. The user will
encrypt the timestamp by using the KAB and send the timestamp and the
server's ticket to the serveron which the client wants to access
resources. When it receives these twoitems, the server first decrypts
its own ticket by using its KB. This permitsaccess to the KAB, which
can then decrypt the timestamp from the client.
Now both the client and the server have the KAB. The server can be
sure that the client has truthfully identified itself because the
client used the KAB to encrypt the timestamp. If it is necessary for
the server to respond to the user, the server will use the KAB. The
client will know that the server has truthfully identified itself
because the server had to use its KB to get the KAB.
Ace
This posting is provided "AS-IS" with no warranties or guarantees and confers no rights.
Please reply back to the newsgroup or forum for collaboration benefit among responding engineers, and to help others benefit from your resolution.
Ace Fekay, MVP, MCT, MCITP EA, MCTS Windows 2008 & Exchange 2007, MCSE & MCSA 2003/2000, MCSA Messaging 2003
Microsoft Certified Trainer
Microsoft MVP - Directory Services
If you feel this is an urgent issue and require immediate assistance, please contact Microsoft PSS directly. Please check
http://support.microsoft.com for regional support phone numbers.
Similar Threads
Linear Mode
