Kerberos internals

Realm: An authentication administrative domain. Each administrative domain has its own kerberos database. Database contains information about users, hosts and services. Authentication between user and service in different realms can take place with trust relationship known as cross-authentication. User/services share a secret (password/key) with authentication server in the same realm. Traditionally, kerberos realms match DNS names and are written in capital letters.

Kerberos provides ticket and ticket session key. Together they are called credentials.

Principal: name or type of service/instance (specific machine offering the service)@realm_name. Principal is a set of specific entity to which credentials may be assigned. Principals are allocated to user or service or host. Used to refer to entries in authentication server database. Service principals are normally of the form, Service/Hostname@REALM (e.g imap/mail.example.com@EXAMPLE.COM). Some principals do not refer to users or hosts but play a role in operation of authentication system e.g krbtgt/REALM@REALM

Service Key: Known to both service and kerberos, stored in database. On server, these keys are stored in keytab files.

Keytab: A key tab file contains keys. Host/service used this file.

Kinit program can be used to get ticket. Ticket and session key are encrypted by user password, before returning to the user. Kinit stores the ticket in credential cache on the client machine.

Tickets are issued by authentication server and are encrypted using the secret key of the service they are intended for. As secret key of service is only shared between authentication server and app server, client can not read the ticket. A ticket contains user and service principal, IP address of client machine, ticket start and expiration time along with session key. Client in addition to the ticket, also encrypts another packet containing user principal and time stamp with the session key. This packet is called authenticator and is valid for 2 minutes. Replay cache on the application and AS/TGS server rejects duplicate authenticator packets. Tickets and session key is stored in credential cache at client end.

* Some of the insecurities that kerberos avoids is password storage on clients (AS/client generates secret key based on user password and salt), authentication information stored at multiple points, password over the network, multiple logins to applications etc.

* Kerberos is strict about DNS reverse resolution, so reverse resolution of server IP address should point back to FQDN or host part in service principal.

* Kerberos uses symmetric encryption. string2key function in kerberos converts user password into an encryption key suitable for the type and strength of encryption algorithm in use. Kerberos 5 supports salted password, meaning a string is concatenated with the unencrypted password before applying string2key function. Both kerberos clients and services share a secret with KDC. For users, it is the key derived from their password, for services it is secret key set by the administrator. User and services shares a key with each other, known as the session key. Role of session key listed in a ticket is fundamental in kerberos transactions.

Authentication server = Key distribution center (KDC) consists of three parts, authentication server (AS), ticket granting server (TGS) and database. Database is encrypted with master key associated with principal, K/M@REALM. Database backup or replication is encrypted with same key. Entries in the database are made up of:

1) Entry principal
2) Entry encryption key and its version
3) validity of ticket for the entry
4) No of times ticket can be renewed
5) Password expiration date
6) Expiration date of the principal.

Client request for service tickets after having being issued a valid ticket granting ticket (TGT). TGT is issued by authentication server, whereas service tickets are issued by ticket granting server.

* Application server does not communicate directly with the KDC. User tickets are forwarded to the server from the client. Sequence of kerberos authentication is as follows:

Client to Authentication server: initial request by kinit (AS_REQ), request is unencrypted and contains user and service principal (krbtgt/REALM@REALM for TGT request), allowed client IP list and validity lifetime

Authentication server to client: contains TGT (encrypted with TGS secret key) and session key (AS_REP). User and service principal in KDC database. AS creates a random session key, which serves as a shared secret between client and TGS. Along with TGT, AS also sends information such as principals, allowed IP and lifetime (encrypted with user secret key) to the client. The client asks user to enter password, password is concatenated with salt, string2key function applied to get user secret key. This key should be able to decrypt AS provided information. Pre-authentication forces client to prove its identity, by sending request encrypted with user long term key, before it can be provided the service ticket.

Client to TGS: requests service ticket by sending TGT and authenticator, encrypted with session key (TGS_REQ)

TGS to client: Sends service ticket, encrypted with service's secret key, service session key, encrypted by previous session key generated by AS (TGS_REP)

Client to application server: Sends request by sending service ticket, authenticator, encrypted with service session key (AP_REQ). This request is not standard but varies with application. Server checks if user principal in request matches with that in service ticket.

Application server to client: Only, if mutual authentication is required

* Trust relation between realms can be direct, transitive and hierarchical. KDCs in two realms share keys in trust relationship. There is a remote TGT of the form krbtgt/B@A and is associated with a secret key. Transitive trust reduces the number of keys required to share between KDCs of different realms.

Ticket flags:
I = Initial
R = Renewable

Keys
Service secret key = Only known to service and KDC
User secret key = Only know to user (as generated from user password) and KDC
session key between client and application server
session key between client and TGS

The all-encompassing Symantec End Point Protection

* Symantec end point protection replaces the following legacy Symantec products:

Symantec anti-virus corporation edition
Symantec client security
Sygate enterprise protection

The new product is a comprehensive end point security product delivering malware (virus, spam, spyware, adware), network/internet protection, firewall, IDS, application and device control. It combines both signature and heuristics based detection to capture known and zero-day exploits. The product comes with an embedded database recommended for servers managing upto 500 clients or can use an external MSSQL database.

* End point protection contains protection manager, which is a server managing protection clients and is administered via protection console. Console can be installed on the server or any client to manage remotely. The product also contains network access control in dormant mode, which can be enabled by procuring the appropriate license.

* End point protection is configured centrally using policies. Live update and anti-virus policies are the most common used to control definitions update and scheduled scanning. Policies can be applied globally, group-wide or within locations inside groups. Locations are identified by client IP addresses, DNS servers etc, enabling enforcement of different policies for remote clients or for telecommuters.

* Installation is done by first installing end point protection manager and console, running deployment and migration wizard to create a client package. Client package can then be deployed through the manager or through in-house deployment architecture. Migration wizard also allows migrating the server from previous version of the product such as anti-virus corporate edition and client security.

Bringing Mac OS X to Windows environment

* Apple has an active directory (AD) plug-in to integrate Mac OS X in a windows AD environment. The plugin enables Mac OS X clients to authenticate with AD server by binding to them using Directory utility and allows Mac OS X server to share folders and host user home directories using SMB or AFP protocols. AD password policies are enforced on Mac OS X clients. Single sign-on through Kerberos is also supported. Plug-in is site-aware and connects to the right site domain controller (DC) obtained from global catalog server. Plug-in has been successfully tested with Windows 2003 R2 in both native and mixed modes. AD plug-in supports Kerberos, LDAP, Kerberos password change (port 464), Global catalog (port 3268) protocols and AD related DNS records (SRV etc)

* DFS shares and GPO settings are not supported by the plug-in. A third party solution from Centrify or Thursby enables support on Mac OS X. Similarly, Mac OS X managed preferences are not supported by the plug-in, meaning they are not stored in AD without schema extension or deploying third party tools. Another option is to use Apple's Open Directory (OD) to stored managed preferences, while retaining AD for authentication.

* Mac OS X provides command line utilities such as dsconfigad, dscl and graphical utilities such as kerberos, directory to support windows AD integration.