This topic outlines the basic procedure by which a network login context is established. See Authentication for a detailed description of this process.
The procedure is as follows:
1. The client calls sec_login_setup_identity( ) specifying the name of the principal whose network identity is to be established. Memory is allocated to receive the principal's login context.
2. The client calls sec_login_valid_and_cert_ident( ), which does the following:
a. Forwards a TGT request encrypted with the user's secret key and with a random key, to the authentication service, which decrypts the request, authenticates the principal, and returns a TGT for the principal.
b. The client's security runtime then decrypts the TGT and forwards it to the privilege service, which creates a PAC for the principal and encloses it in a PTGT, which is returned to the client's security runtime.
c. The runtime decrypts the message containing the PTGT and returns information about the source of the authentication information to the API. (If the authentication information comes from the network security server, then the login context is validated.)
3. Finally, the client invokes sec_login_set_context( ), which enables child processes spawned from the calling process to inherit the validated context.
In A Walkthrough of User Authentication, we mentioned that one of the functions of sec_login_valid_and_cert_ident( ) is to demonstrate that a valid trust path exists between the authentication service and the host computer on which the principal is logging in. After setting up and validating a login context, any application that sets identity information for local processes should check to be sure that the server that provided the certificate of identity is legitimate in order to demonstrate that the trust path between the client and the authentication service is valid.
More:
Validating the Login Context and Certifying the Security Server
Validating the Login Context Without Certifying the Security Server
Example of a System Login Program