Event Logging in AD Integration Scenarios

To test what kind of logging occurs, I simply used my existing installation of Windows Server 2003 R2 and Active Directory, for which the logging options had not been modified from their “out of the box” settings. From there, I cleared the security event logs and then attempted an SSH login to a CentOS 4.3 server that has been configured for AD authentication via Kerberos (through PAM, not directly inside SSH).

After the login, I reviewed the event logs and found a large number of entries for the LDAP bind account (the account that is used to bind to Active Directory to retrieve account information, such as UID number, GID number, login shell, home directory, etc.). These are useless for identifying unique logons to Linux/Unix-based systems. However, there is one event that is useful—an event ID 672 with the following text:

    Authentication Ticket Request:
        User Name:      bjones
        Supplied Realm Name:    EXAMPLE.NET
        User ID:            EXAMPLE\bjones
        Service Name:       krbtgt
        Service ID:     EXAMPLE\krbtgt
        Ticket Options:     0x40800000
        Result Code:        -
        Ticket Encryption Type: 0x17
        Pre-Authentication Type:    2
        Client Address:     172.16.28.111
        Certificate Issuer Name:    
        Certificate Serial Number:  
        Certificate Thumbprint: 
    
    For more information, see Help and Support Center at 
    http://go.microsoft.com/fwlink/events.asp.

As you can see, this entry clearly identifies the user that was authenticated as well as the IP address of the host to which the user logged in. Note that the IP address of the workstation from which the user logon originated is not captured here.

OK, that takes care of the typical Linux system. Now, what about Solaris 10? I cleared the security event logs (saving them) and attempted an SSH logon to a Solaris server. As it turns out, Solaris 10 logs two event entries—event ID 672, as above, as well as event ID 673. The text for event ID 673 is as follows:

    Service Ticket Request:
        User Name:      bjones@EXAMPLE.NET
        User Domain:        EXAMPLE.NET
        Service Name:       host-solarishost01
        Service ID:     EXAMPLE\host-solarishost01
        Ticket Options:     0x40800000
        Ticket Encryption Type: 0x3
        Client Address:     172.16.28.112
        Failure Code:       -
        Logon GUID:     {3a653f45-928c-1f72-2c59-ca951986ac42}
        Transited Services: -
    
    For more information, see Help and Support Center at 
    http://go.microsoft.com/fwlink/events.asp.

This provides the same sort of information as well as the name of the service ticket that was requested by the host. (Keep in mind, too, that Solaris 10 logged both the event ID 672 and event ID 673, whereas CentOS logged only the event ID 672.)

But what about “native” Kerberos authentication, when a Kerberos ticket is used to authenticate the user? In this case, I tested three different operating systems: CentOS 4.3, Solaris 10, and OpenBSD 3.9. In all three cases an event ID 673, similar to above, was logged. However, this time it was the IP address of my actual workstation—not the IP address of the server—that was included in the event log text.

In all of the tested scenarios, there was information that identified the specific account that was being authenticated. However, depending upon whether PAM was involved, the Windows event logs may or may not capture the actual IP address of the originating workstation. In almost all cases, though, the logs on the Linux, Solaris, or OpenBSD server would capture the IP address of the originating workstation, even if the Windows event logs did not.

Metadata and Navigation