What is Kerberos?
[The name Kerberos comes from Greek mythology; it is the three-headed dog that guarded the entrance to Hades.]
Most users access many systems and networks during the day. A single sign-on technology allows a user to sign on once at the beginning of the day and remain authorized throughout the day on the entire network.
Kerberos Terminology
Key Distribution Center (KDS) - Holds secret keys (the crytographic keys) for "principals"; provides authentication; creates and distributes session keys (crytographic keys). Session keys and secret keys are crytographic keys. The KDS utilizes symmetric cryptography. A KDC has a Ticket Granting Service (see TGS) and the Authentication Service.
Principal - Any object such as user, application, service, or resource which utilizes Kerberos authentication is referred to as principal. Collectively, the objects using Kerberos are principals. A Key Distribution Center (KDC) is responsible for one or more "realms" of principals. Any principal must "trust" the KDC. Principals do not directly trust each other. Only the KDC is supposed to have a copy of each principals "secret key".
Realm - The group or set of principals which are grouped together logically by a network administrator is called a realm. Again, a Key Distribution Center (KDC) is responsible for one or more realms.
TGS (Ticket Granting Service) - That part of the Key Distribution Center (KDS) which creates and distributes tickets to the objects (principals) containing session keys.
Ticket - Simply a digital authentication token sent from the Authentication Service (AS). The first ticket sent from the AS to a principal (user, application, service or resource) is called the Ticket Granting Ticket (TGT).
Secret keys and Session keys - Symmetric cryptography keys used for both authentication and/or data encryption.
Kerberos in a Nutshell
(How it Works)
(1) A user logs in: Authentication information is sent to the AS (Authentication Service) of the KDC (Key Distribution Center)
(2) The AS sends back a ticket (encrypted) to the user's computer.
(3) Ticket gets decrypted with the secret key (user's password). User is authenticated to the network if the right password is used.
User Needs a Resource
(2) Tricky step:1 TGS makes another ticket: User authentication information, plus TWO instances of the SAME session key. This ticket goes to user computer. One instance of the Session key gets encrypted with the user's secret key. The other instance of the Session key is encrypted with the secret key of the desired resource.
(3) User computer software (Kerberos) decrypts and extracts one instance of the session key, then inserts authentication information of the user into the ticket and sends ticket to the desired resource. The resource must decrypt the second instance of the session key with its own secret key and revfiews authentication information of the user. The resource was convinced that the ticket came from the KDC because the ticket it received had a copy of the resource's own secret key. Logically, only the KDC should have a copy of the resource's secret key. The resource now "trusts" the incoming ticket because of the encrypted secret key of the resource being on the ticket. The resource also compare's user information in the ticket with user information inserted by the user to ensure the identity of the user.
Some Features and Problems of Kerberos 1
- Does not provide for availability of principals (resources)
- KDC can be a single-point of failure
- Secret keys stored on workstations
- Vulnerable to dictionary attacks
- If encryption is not enabled, the network is not protected
- The KDC should not allow any non-Kerberos network activitiy to take place.
- All prinicipals must have Kerberos software installed
- The KDC must be readily available at all times and must be able to support the number of requests that it receives from all of the principals in the realm.
- It is easier to control and maintain one system responsible for all access requests, so administration can be easier, but at the cost of possible security breeches.
http://www.hitmill.com/computers/kerberos.html
Kerberos and its place in NAS authentication
Kerberos security has been around since the 1980s, but many people are still unfamiliar with how Kerberos works, where it's used and how it may help improve security for users of network attached storage (NAS) resources.
Kerberos, derived from the name of the three-headed dog that guarded the gates to Hades in Greek mythology, was developed as a security project at MIT during the 1980s to help improve network security. Early password authentication and access control lists helped provide security for data within a machine, but passwords sent over a network as clear text for access to remote resources was not secure since it could be "sniffed" or "hacked" by malicious users.
Kerberos authentication:
- Provides "single sign on" for network resources.
- Provides strong authentication services for client/server applications by using key based authentication services rather than passing clear or encrypted passwords over the network.
- Provides a centralized security mechanism for network access.
Kerberos is used only for network-level security, and does NOT provide a mechanism to protect the actual stored files. Operating system level permissions are still required to control access to files. When a user logs onto a network that uses Kerberos security, that user is understood to be a trusted user, and uses that login credential to access all resources the user was granted. Kerberos is now the default network security mechanism used for Windows 2000 and 2003 active directory running in native mode. Traditional NTLM security (which is less secure) is used for "mixed-mode" security to support legacy Windows NT servers.
When using Kerberos security, passwords are never transmitted over the network. Instead, users contact the Active Directory, a Kerberos server or the Kerberos Key Distribution Center (KDC) service, which stores and retrieves all information about security. Clients requesting access to services on another computer, such as a NAS share, contact the KDC directly to obtain their session credentials -- or "ticket" -- to gain access permissions to the network resource.
Windows CIFS-based NAS Resources
If you are using Windows XP to access a NAS share on a Windows server that is using native mode active directory security, then you are probably using Kerberos without even knowing about it. If your network uses "mixed mode" security to provide backward compatibility for Windows NT networks, then you may be using the older and less secure CHAP protocol. If your NAS storage provider allows native active directory integration for security, then they should provide Kerberos security by default.
Unix-based NFS NAS resources
Unix NFS-based NAS resources are a different story. Unless your NAS provider uses NFSV4, it may not be integrated with Kerberos security. Although NFS versions 2 and 3 support Kerberos (version 2 supports Kerberos version 4, while NFSV3 and NFSV4 support Kerberos version 5), they must be integrated with an existing Kerberos server. Also, you need to make sure that your Unix clients (Linux, Solaris, HP-UX, AIX, Tru64, etc.) also support integrated Kerberos security. Contact your NAS provider to find out which Unix clients they support using Kerberos security.
Integrating Kerberos security for access to NAS resources provides an added layer of protection that assures users accessing the network are trusted. Since Kerberos uses keys rather than passwords, network resources are more secure. Kerberos may already be in place for Windows CIFS shares using native mode active directory security. NFS NAS shares need to be integrated with a Unix-based Kerberos server. For more information, visit this MIT Web site about Kerberos.
http://searchstorage.techtarget.com/tip/0,289483,sid5_gci1205412,00.html
http://www.ibm.com/developerworks/aix/library/au-kerbauthent/
Kerberized authentication of Windows Terminal Service
22 Aug 2006
Discover how to configure the Microsoft® Windows® 2003 Server to authenticate Terminal Service users with the IBM Network Authentication Service (IBM NAS) Key Distribution Center (KDC) being hosted on their AIX® 5.3 system. Such a setup not only gives Kerberized authentication for Terminal Service users, but it also allows users to have uniform user IDs and passwords across AIX and Windows Server systems. It allows application developers to exploit the advantages of Kerberos interoperability between IBM NAS and Windows in Kerberized applications spanning across systems.
Kerberos, which provides a secure means of authentication for network users, is one of the most popular authentication mechanisms. Most modern operating systems support Kerberos-based (Version 5) authentication. IBM AIX® 5.3 also supports Kerberos-based authentication.
The IBM version of Kerberos is called IBM Network Authentication Service (IBM NAS), and it can be installed from AIX 5.3 Expansion Pack CDs. IBM NAS for AIX supports both Kerberos clients and Kerberos servers. Many enterprises worldwide use IBM NAS for AIX as the Key Distribution Center (KDC) for their Kerberos realm. It is being used in Network File System (NFS) Version 4 deployment, IBM DB2® Universal Database™ (DB2® UDB™) security, Kerberized AIX integrated login, enterprise-wide authentication, and more.
Today customers generally have a heterogeneous setup, with a mix of UNIX® and Windows® systems. A major challenge for administrators with heterogeneous environments is to have uniform user IDs and passwords across different systems, preferably with a centralized authentication server. Microsoft® Windows Server editions provide a facility called Terminal Services that are widely becoming popular in the Windows world. This facility allows multiple users to log in to a Windows server simultaneously. Microsoft Windows Server editions also support Kerberos-based authentication, which is interoperable with IBM NAS.
In this article, administrators learn how to configure the Microsoft Windows 2003 Server to authenticate Terminal Service users with the IBM NAS KDC being hosted on their AIX 5.3 system. Such a setup not only gives Kerberized authentication for Terminal Service users, but it also allows users to have uniform user IDs and passwords across AIX and Windows Server systems and allows application developers to exploit the advantages of Kerberos interoperability between IBM NAS and Windows in Kerberized applications spanning across systems.
Scenario: IBM NAS KDC on AIX and Kerberized authentication of Windows Terminal Service
We'll use a scenario that takes you through the steps required to set up IBM NAS KDC on an AIX system and have Kerberized authentication of Windows Terminal Service by configuring Windows 2003 Server to IBM NAS KDC.
The following definitions are used in the example in this article:
- Kerberos realm name
- AIXKERBEROS.IN.IBM.COM
- KDC (IBM NAS 1.4)
- hostname: fsaix11.in.ibm.com,OS: AIX 5.3
- Windows Terminal Service
- hostname: windce14.in.ibm.com, OS: Windows 2003 Server (Service Pack 1 with Hotfix for Article ID :902336)
- Kerberos administrator name
- admin/admin
Figure 1 shows the setup of the example.
Figure 1. Example setup
 |
|
Installing and configuring IBM NAS Server on AIX 5.3
This section covers the installation and configuration of an IBM NAS server (Kerberos KDC) on AIX 5.3.
Installing Kerberos KDC on AIX 5.3
IBM NAS is shipped with AIX 5.3 Expansion Pack CDs. To install the IBM NAS server package, install the krb5.server.rte fileset. You can use the following command to install the NAS server fileset:
[root@fsaix11 / ]# hostname |
Then export the following
PATH to ensure that you execute IBM NAS commands from the respective IBM NAS directories: [root@fsaix11 / ]# export PATH=/usr/krb5/sbin:/usr/krb5/bin:$PATH |
Configuring Kerberos KDC on AIX 5.3
To configure an IBM NAS server on an AIX machine, use the command in Listing 1 below. In this example, we're using the legacy configuration, where the principals are stored in a database on the local file system. Instead of the legacy configuration, IBM NAS server can also be configured to Lightweight Directory Access Protocol (LDAP) using an LDAP directory plug-in. For more information on configuration of IBM NAS with LDAP, see the IBM NAS Version 1.4 Administration Guide, shipped with AIX Version 5.3 Expansion Pack CD.
Listing 1. Configuring an IBM NAS server on an AIX machine
[root@fsaix11 / ]# hostname |
Because the Windows Kerberos implementation currently supports only DES-CBC-MD5 and DEC-CBC-CRC encryption types, you need to change the IBM NAS Kerberos server default encryption settings so that the Windows workstations can authenticate to an IBM NAS server. You must make the following changes on the AIX machine (fsaix11.in.ibm.com, in your case) hosting the IBM NAS KDC:
- Edit the /var/krb5/krb5kdc/kdc.conf file and change the value of supported_enctypes to have des-cbc-md5:normal and des-cbc-crc:normal at the beginning of the encryption-type list.
- After editing, the supported_enctypes section of the /var/krb5/krb5kdc/kdc.conf file should look similar to:
supported_enctypes = des-cbc-md5:normal des-cbc-crc:normal des3-cbc-sha1:normal
arcfour-hmac:normal aes256-cts:normal
Restart the AIX NAS server daemons (for example, krb5kdc and kadmind) so that the above encryption-type changes take effect. To restart the AIX NAS server daemons, use the following commands, as shown in Listing 2.
Listing 2. Restarting the AIX NAS server daemons
[root@fsaix11 / ]# stop.krb5 |
Required Kerberos principals for the Windows Terminal Service users
Now you need to create Kerberos principals corresponding to the Windows Terminal Service users (and services) who wish to have Kerberized authentication over the network. In this setup, you want the "administrator" user of the windce14.in.ibm.com machine hosting the Windows Terminal Service to be authenticated using IBM NAS KDC hosted on fsaix11.in.ibm.com, an AIX 5.3 machine. You are required to create administrator and host/windce14.aixkerberos.in.ibm.com Kerberos principals using the kadmin.local command of IBM NAS on fsaix11.in.ibm.com, as shown below in Listing 3.
Listing 3. The kadmin.local command
[root@fsaix11 / ]# kadmin.local |
The administrator is required to create Kerberos principals corresponding to each Windows Terminal Service user that needs Kerberos authentication. In this example, we are demonstrating it only for the "administrator" principal.
|
|
Windows 2003 Server Terminal Services readiness
If you have already deployed the Windows 2003 Server Terminal Server in your environment, all you are required to do is install a Microsoft Hotfix for Terminal Services. For Terminal Services to work well with Kerberized authentication configured to IBM NAS KDC on the Windows 2003 Server, you must install a Hotfix provided by Microsoft for the Windows Server 2003-based Terminal Server.
Once you have installed the Hotfix (or the proposed workaround), you are all set to configure the Windows 2003 Server to IBM NAS KDC and run the Windows Terminal Service with Kerberized authentication. For detailed information on installation and configuration of the Microsoft Terminal Server, see the appropriate Microsoft documentation.
Configure Windows 2003 Server (Kerberos client) to IBM NAS server
After installing the Hotfix, you need to configure the Windows 2003 Kerberos client to the IBM NAS server on AIX 5.3. For that, you need to download the Resource Kit Tools from Windows 2003 Server CD, which installs the Windows Kerberos utilities (ksetup, ktpass, and so on).
To configure the Windows 2003 Server to act as a Kerberos client to the IBM NAS server:
- Make the Windows Server (windce14.in.ibm.com) a part of your Kerberos workgroup by setting it to your Kerberos domain using the
ksetupcommand:C:\>hostname
windce14
C:\> ksetup /setdomain AIXKERBEROS.IN.IBM.COM
- Configure the Windows Server machine to the Kerberos realm by specifying the Kerberos realm name and Kerberos server name, as shown below:
C:\> ksetup /addkdc AIXKERBEROS.IN.IBM.COM fsaix11.in.ibm.com
- Set the local machine account password, as follows:
C:\> ksetup /setmachpassword laurel
This password must match the password used when you created the Kerberos host principal (host/windce14.aixkerberos.in.ibm.com) by invoking
ankfrom kadmin.local, explained earlier. - Map the Kerberos user to a local Windows user. The command below maps the local windows administrator user to administrator@AIXKERBEROS.IN.IBM, a Kerberos principal:
C:\> ksetup /mapuser administrator@AIXKERBEROS.IN.IBM.COM administrator
- Restart the computer for the changes to take effect.
Figure 2 summarizes all the steps executed above on the Windows machine.
Figure 2. Configuration of Windows 2003 Server as Kerberos client to AIX KDC
You are now all set to exercise the Kerberized authentication of Windows Terminal Service users against IBM NAS KDC hosted on the AIX V 5.3 machine. Log in to the Windows Server machine (windce14.in.ibm.com) using the Remote Desktop Connection from any of your Windows desktop machines.
On connection, it presents you with the logon screen for the windce14.in.ibm.com machine. Select Log on to. You should see that the Kerberos realm you created is also present in the drop-down list. Now enter your Kerberos username and the password (in this case, the username is administrator and the password is laurel), select AIXKERBEROS.IN.IBM.COM(Kerberos Realm) in the "Log on to" option, and select OK. This will then carry out the Kerberized authentication process, and upon success will log the Terminal Service user into the Windows machine.
Figure 3 shows the Remote login to the Windows server machine.
Figure 3. Kerberized authentication of Windows Terminal Service users against IBM NAS KDC
This article explains how administrators can use the IBM NAS KDC on AIX 5.3 for authentication of Windows 2003 Terminal Service. This should help simplify administration, and it also allows users to have common user IDs and passwords across AIX and Windows Terminal Service systems.
No comments:
Post a Comment