<rt id="bn8ez"></rt>
<label id="bn8ez"></label>

  • <span id="bn8ez"></span>

    <label id="bn8ez"><meter id="bn8ez"></meter></label>

    ivaneeo's blog

    自由的力量,自由的生活。

      BlogJava :: 首頁 :: 聯系 :: 聚合  :: 管理
      669 Posts :: 0 Stories :: 64 Comments :: 0 Trackbacks

    https://help.ubuntu.com/10.04/serverguide/kerberos.html

    Kerberos

    Kerberos is a network authentication system based on the principal of a trusted third party. The other two parties being the user and the service the user wishes to authenticate to. Not all services and applications can use Kerberos, but for those that can, it brings the network environment one step closer to being Single Sign On (SSO).

    This section covers installation and configuration of a Kerberos server, and some example client configurations.

    Overview

    If you are new to Kerberos there are a few terms that are good to understand before setting up a Kerberos server. Most of the terms will relate to things you may be familiar with in other environments:

    • Principal: any users, computers, and services provided by servers need to be defined as Kerberos Principals.

    • Instances: are used for service principals and special administrative principals.

    • Realms: the unique realm of control provided by the Kerberos installation. Usually the DNS domain converted to uppercase (EXAMPLE.COM).

    • Key Distribution Center: (KDC) consist of three parts, a database of all principals, the authentication server, and the ticket granting server. For each realm there must be at least one KDC.

    • Ticket Granting Ticket: issued by the Authentication Server (AS), the Ticket Granting Ticket (TGT) is encrypted in the user's password which is known only to the user and the KDC.

    • Ticket Granting Server: (TGS) issues service tickets to clients upon request.

    • Tickets: confirm the identity of the two principals. One principal being a user and the other a service requested by the user. Tickets establish an encryption key used for secure communication during the authenticated session.

    • Keytab Files: are files extracted from the KDC principal database and contain the encryption key for a service or host.

    To put the pieces together, a Realm has at least one KDC, preferably two for redundancy, which contains a database of Principals. When a user principal logs into a workstation, configured for Kerberos authentication, the KDC issues a Ticket Granting Ticket (TGT). If the user supplied credentials match, the user is authenticated and can then request tickets for Kerberized services from the Ticket Granting Server (TGS). The service tickets allow the user to authenticate to the service without entering another username and password.

    Kerberos Server

    Installation

    Before installing the Kerberos server a properly configured DNS server is needed for your domain. Since the Kerberos Realm by convention matches the domain name, this section uses the example.com domain configured in the section called “Primary Master”.

    Also, Kerberos is a time sensitive protocol. So if the local system time between a client machine and the server differs by more than five minutes (by default), the workstation will not be able to authenticate. To correct the problem all hosts should have their time synchronized using the Network Time Protocol (NTP). For details on setting up NTP see the section called “Time Synchronisation with NTP”.

    The first step in installing a Kerberos Realm is to install the krb5-kdc and krb5-admin-server packages. From a terminal enter:

    sudo apt-get install krb5-kdc krb5-admin-server
    

    You will be asked at the end of the install to supply a name for the Kerberos and Admin servers, which may or may not be the same server, for the realm.

    Next, create the new realm with the kdb5_newrealm utility:

    sudo krb5_newrealm
    

    Configuration

    The questions asked during installation are used to configure the /etc/krb5.conf file. If you need to adjust the Key Distribution Center (KDC) settings simply edit the file and restart the krb5-kdc daemon.

    1. Now that the KDC running an admin user is needed. It is recommended to use a different username from your everyday username. Using the kadmin.local utility in a terminal prompt enter:

      sudo kadmin.local
      Authenticating as principal root/admin@EXAMPLE.COM with password.
      kadmin.local: addprinc steve/admin
      WARNING: no policy specified for steve/admin@EXAMPLE.COM; defaulting to no policy
      Enter password for principal "steve/admin@EXAMPLE.COM": 
      Re-enter password for principal "steve/admin@EXAMPLE.COM": 
      Principal "steve/admin@EXAMPLE.COM" created.
      kadmin.local: quit
      

      In the above example steve is the Principal, /admin is an Instance, and @EXAMPLE.COM signifies the realm. The "every day" Principal would be steve@EXAMPLE.COM, and should have only normal user rights.

      [Note]

      Replace EXAMPLE.COM and steve with your Realm and admin username.

    2. Next, the new admin user needs to have the appropriate Access Control List (ACL) permissions. The permissions are configured in the /etc/krb5kdc/kadm5.acl file:

      steve/admin@EXAMPLE.COM        *
      

      This entry grants steve/admin the ability to perform any operation on all principals in the realm.

    3. Now restart the krb5-admin-server for the new ACL to take affect:

      sudo /etc/init.d/krb5-admin-server restart
      
    4. The new user principal can be tested using the kinit utility:

      kinit steve/admin
      steve/admin@EXAMPLE.COM's Password:
      

      After entering the password, use the klist utility to view information about the Ticket Granting Ticket (TGT):

      klist
      Credentials cache: FILE:/tmp/krb5cc_1000
              Principal: steve/admin@EXAMPLE.COM
      
        Issued           Expires          Principal
      Jul 13 17:53:34  Jul 14 03:53:34  krbtgt/EXAMPLE.COM@EXAMPLE.COM
      

      You may need to add an entry into the /etc/hosts for the KDC. For example:

      192.168.0.1   kdc01.example.com       kdc01
      

      Replacing 192.168.0.1 with the IP address of your KDC.

    5. In order for clients to determine the KDC for the Realm some DNS SRV records are needed. Add the following to /etc/named/db.example.com:

      _kerberos._udp.EXAMPLE.COM.     IN SRV 1  0 88  kdc01.example.com.
      _kerberos._tcp.EXAMPLE.COM.     IN SRV 1  0 88  kdc01.example.com.
      _kerberos._udp.EXAMPLE.COM.     IN SRV 10 0 88  kdc02.example.com. 
      _kerberos._tcp.EXAMPLE.COM.     IN SRV 10 0 88  kdc02.example.com. 
      _kerberos-adm._tcp.EXAMPLE.COM. IN SRV 1  0 749 kdc01.example.com.
      _kpasswd._udp.EXAMPLE.COM.      IN SRV 1  0 464 kdc01.example.com.
      
      [Note]

      Replace EXAMPLE.COM, kdc01, and kdc02 with your domain name, primary KDC, and secondary KDC.

      See Chapter 7, Domain Name Service (DNS) for detailed instructions on setting up DNS.

    Your new Kerberos Realm is now ready to authenticate clients.

    Secondary KDC

    Once you have one Key Distribution Center (KDC) on your network, it is good practice to have a Secondary KDC in case the primary becomes unavailable.

    1. First, install the packages, and when asked for the Kerberos and Admin server names enter the name of the Primary KDC:

      sudo apt-get install krb5-kdc krb5-admin-server
      
    2. Once you have the packages installed, create the Secondary KDC's host principal. From a terminal prompt, enter:

      kadmin -q "addprinc -randkey host/kdc02.example.com"
      
      [Note]

      After, issuing any kadmin commands you will be prompted for your username/admin@EXAMPLE.COM principal password.

    3. Extract the keytab file:

      kadmin -q "ktadd -k keytab.kdc02 host/kdc02.example.com"
      
    4. There should now be a keytab.kdc02 in the current directory, move the file to /etc/krb5.keytab:

      sudo mv keytab.kdc02 /etc/krb5.keytab
      
      [Note]

      If the path to the keytab.kdc02 file is different adjust accordingly.

      Also, you can list the principals in a Keytab file, which can be useful when troubleshooting, using the klist utility:

      sudo klist -k /etc/krb5.keytab
      
    5. Next, there needs to be a kpropd.acl file on each KDC that lists all KDCs for the Realm. For example, on both primary and secondary KDC, create /etc/krb5kdc/kpropd.acl:

      host/kdc01.example.com@EXAMPLE.COM
      host/kdc02.example.com@EXAMPLE.COM
      
    6. Create an empty database on the Secondary KDC:

      sudo kdb5_util -s create
      
    7. Now start the kpropd daemon, which listens for connections from the kprop utility. kprop is used to transfer dump files:

      sudo kpropd -S
      
    8. From a terminal on the Primary KDC, create a dump file of the principal database:

      sudo kdb5_util dump /var/lib/krb5kdc/dump
      
    9. Extract the Primary KDC's keytab file and copy it to /etc/krb5.keytab:

      kadmin -q "ktadd -k keytab.kdc01 host/kdc01.example.com"
      sudo mv keytab.kdc01 /etc/kr5b.keytab
      
      [Note]

      Make sure there is a host for kdc01.example.com before extracting the Keytab.

    10. Using the kprop utility push the database to the Secondary KDC:

      sudo kprop -r EXAMPLE.COM -f /var/lib/krb5kdc/dump kdc02.example.com
      
      [Note]

      There should be a SUCCEEDED message if the propagation worked. If there is an error message check /var/log/syslog on the secondary KDC for more information.

      You may also want to create a cron job to periodically update the database on the Secondary KDC. For example, the following will push the database every hour:

      # m h  dom mon dow   command
      0 * * * * /usr/sbin/kdb5_util dump /var/lib/krb5kdc/dump && /usr/sbin/kprop -r EXAMPLE.COM -f /var/lib/krb5kdc/dump kdc02.example.com
      
    11. Back on the Secondary KDC, create a stash file to hold the Kerberos master key:

      sudo kdb5_util stash
      
    12. Finally, start the krb5-kdc daemon on the Secondary KDC:

      sudo /etc/init.d/krb5-kdc start
      

    The Secondary KDC should now be able to issue tickets for the Realm. You can test this by stopping the krb5-kdc daemon on the Primary KDC, then use kinit to request a ticket. If all goes well you should receive a ticket from the Secondary KDC.

    Kerberos Linux Client

    This section covers configuring a Linux system as a Kerberos client. This will allow access to any kerberized services once a user has successfully logged into the system.

    Installation

    In order to authenticate to a Kerberos Realm, the krb5-user and libpam-krb5 packages are needed, along with a few others that are not strictly necessary but make life easier. To install the packages enter the following in a terminal prompt:

    sudo apt-get install krb5-user libpam-krb5 libpam-ccreds auth-client-config
    

    The auth-client-config package allows simple configuration of PAM for authentication from multiple sources, and the libpam-ccreds will cache authentication credentials allowing you to login in case the Key Distribution Center (KDC) is unavailable. This package is also useful for laptops that may authenticate using Kerberos while on the corporate network, but will need to be accessed off the network as well.

    Configuration

    To configure the client in a terminal enter:

    sudo dpkg-reconfigure krb5-config
    

    You will then be prompted to enter the name of the Kerberos Realm. Also, if you don't have DNS configured with Kerberos SRV records, the menu will prompt you for the hostname of the Key Distribution Center (KDC) and Realm Administration server.

    The dpkg-reconfigure adds entries to the /etc/krb5.conf file for your Realm. You should have entries similar to the following:

    [libdefaults]
            default_realm = EXAMPLE.COM
    ...
    [realms]
            EXAMPLE.COM = }                
                    kdc = 192.168.0.1               
                    admin_server = 192.168.0.1
            }
    

    You can test the configuration by requesting a ticket using the kinit utility. For example:

    kinit steve@EXAMPLE.COM
    Password for steve@EXAMPLE.COM:
    

    When a ticket has been granted, the details can be viewed using klist:

    klist
    Ticket cache: FILE:/tmp/krb5cc_1000
    Default principal: steve@EXAMPLE.COM
    
    Valid starting     Expires            Service principal
    07/24/08 05:18:56  07/24/08 15:18:56  krbtgt/EXAMPLE.COM@EXAMPLE.COM
            renew until 07/25/08 05:18:57
    
    
    Kerberos 4 ticket cache: /tmp/tkt1000
    klist: You have no tickets cached
    

    Next, use the auth-client-config to configure the libpam-krb5 module to request a ticket during login:

    sudo auth-client-config -a -p kerberos_example
    

    You will should now receive a ticket upon successful login authentication.

    Resources

    posted on 2012-12-19 18:15 ivaneeo 閱讀(2686) 評論(0)  編輯  收藏 所屬分類: GNU牛力
    主站蜘蛛池模板: 亚洲91av视频| 亚洲国产主播精品极品网红| 久久精品国产亚洲AV麻豆~ | 亚洲欧美乱色情图片| 成年人视频免费在线观看| 亚洲大尺码专区影院| 日日麻批免费40分钟日本的| 亚洲最新黄色网址| 67194成是人免费无码| 亚洲youwu永久无码精品 | 亚洲毛片在线免费观看| 亚洲第一页中文字幕| 无码av免费毛片一区二区| 亚洲中文字幕无码久久| 啊v在线免费观看| a级成人免费毛片完整版| 亚洲人成电影在线天堂| 99无码人妻一区二区三区免费| 亚洲综合偷自成人网第页色| 免费人成在线观看播放国产| 视频免费1区二区三区| 久久亚洲国产视频| 人与禽交免费网站视频| 久久亚洲精品无码网站| 亚洲区不卡顿区在线观看| 久久成人a毛片免费观看网站| 91嫩草亚洲精品| 成人亚洲综合天堂| 久久久久久久久久久免费精品| 久久久久亚洲av无码专区喷水| 免费观看成人毛片a片2008| 九九久久精品国产免费看小说| 亚洲狠狠综合久久| 成人免费a级毛片无码网站入口| 天堂亚洲免费视频| 亚洲视频精品在线观看| 免费观看四虎精品国产永久| 嫩草在线视频www免费看| 日韩亚洲国产综合高清| 色噜噜AV亚洲色一区二区| 免费人成网站在线观看10分钟|