RHEL7: Configure a system to authenticate using Kerberos.

Share this link

Note: This is an RHCE 7 exam objective.

Prerequisites

Before configuring a Kerberos client, you have to configure a KDC.
Also, to get Kerberos running, NTP synchronization and hostname resolution must be working.
If no working DNS, add the following lines in the /etc/hosts file (replace the specified ip addresses with yours):

192.168.1.11 kbserver.example.com
192.168.1.12 kbclient.example.com

Client Configuration

Install the Kerberos client packages:

# yum install -y krb5-workstation pam_krb5

Edit the /etc/krb5.conf file, uncomment all the lines, replace EXAMPLE.COM with your own realm, example.com with your own domain name, and kerberos.example.com with your own KDC server name (here kbserver.example.com).

Alternatively, you get the /etc/krb5.conf file from the KDC server (here kbserver.example.com):

# scp root@kbserver.example.com:/etc/krb5.conf /etc/krb5.conf

Create a user for test:

# useradd user01

Add the client machine name (here kbclient.example.com) to the principals:

# kadmin
Authenticating as principal root/admin@EXAMPLE.COM with password.
Password for root/admin@EXAMPLE.COM: kerberos
kadmin:  addprinc -randkey host/kbclient.example.com
WARNING: no policy specified for host/kbclient.example.com@EXAMPLE.COM; defaulting to no policy
Principal "host/kbclient.example.com@EXAMPLE.COM" created.

Create a local copy stored by default in the /etc/krb5.keytab file:

kadmin:  ktadd host/kbclient.example.com
Entry for principal host/kbclient.example.com with kvno 2, encryption type aes256-cts-hmac-sha1-96 added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal host/kbclient.example.com with kvno 2, encryption type aes128-cts-hmac-sha1-96 added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal host/kbclient.example.com with kvno 2, encryption type des3-cbc-sha1 added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal host/kbclient.example.com with kvno 2, encryption type arcfour-hmac added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal host/kbclient.example.com with kvno 2, encryption type camellia256-cts-cmac added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal host/kbclient.example.com with kvno 2, encryption type camellia128-cts-cmac added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal host/kbclient.example.com with kvno 2, encryption type des-hmac-sha1 added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal host/kbclient.example.com with kvno 2, encryption type des-cbc-md5 added to keytab WRFILE:/etc/krb5.keytab.
kadmin:  quit

Edit the /etc/ssh/ssh_config file and add/uncomment the following lines:

GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes

Reload the sshd service configuration:

# systemctl reload sshd

Configure the PAM component at the command line:

# authconfig --enablekrb5 --update

Test your configuration (here kbserver.example.com is the KDC server name):

# su - user01
$ kinit
Password for user01@EXAMPLE.COM: user01
$ klist
Ticket cache: KEYRING:persistent:1000:1000
Default principal: user01@EXAMPLE.COM

Valid starting Expires Service principal
07/22/2014 17:20:15 07/23/2014 17:19:54 krbtgt/EXAMPLE.COM@EXAMPLE.COM
 renew until 07/22/2014 17:19:54
$ ssh kbserver.example.com

Now, you should be able to quit and reconnect without giving any password.
In addition, the first time you log in to a Kerberos client, you have to provide a login/password (see kinit above). Then, you get a ticket that allows you to log in to all the other Kerberos clients in the same realm and you don’t need to provide a password any more as long as your ticket is valid.
Note: To delete a ticket, use the kdestroy command.

Source: RHEL 5 Deployment Guide.

Additional Resources

The chapter 11 of the RHEL 7 System-Level Authentication Guide provides many Kerberos configuration details.

1 Star2 Stars3 Stars4 Stars5 Stars (1 votes, average: 5.00 out of 5)
Loading...
56 comments on “RHEL7: Configure a system to authenticate using Kerberos.
  1. SkoolofManoovah says:

    Hi, could you clarify please… in /eetc/hosts for the kdc server

    192.168.1.11 kbserver.example.com
    192.168.1.12 kbclient.example.com

    why include the ip for the client? and on a kdc client, does it need it’s own ip in /etc/hosts? or to puut another way, why not just use 127.0.0.1 for the kdserver on the kdc server, and 127.0.01 for the kdclient on a client? Hope that makes sense.

    • CertDepot says:

      Normally, to avoid any problems, you should use a master DNS server.
      If you don’t want to set up one, the KDC must resolve all the hostnames (forward and reverse name resolutions).
      After I didn’t try all the combinations.

  2. SkoolofManoovah says:

    Ok, thanks for clarification.

  3. jerky_rs says:

    Centos7 – It appears as though “GSSAPIDelegateCredentials yes” is not longer a valid configuration option available to SSHD for Centos7.

    From journalctl
    /etc/ssh/sshd_config: line 160: Bad configuration option: GSSAPIDelegateCredentials

    It is also not listed in “man sshd_config”.

    Annoyingly “systemctl restart sshd” shows no error and sshd silently dies..

    It is however documented in RHEL7 = https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System-Level_Authentication_Guide/Configuring_a_Kerberos_5_Client.html

    Not sure if this is the case for RHEL

    Source RPM : openssh-6.4p1-8.el7.src.rpm7

    • anserk says:

      The link you provided is pretty clear (at least at the time I checked it):
      “If the client also has GSSAPIDelegateCredentials enabled, the user’s credentials are made available on the remote system.”

      This option is a client-only option, as can be seen in man ssh_config vs man sshd_config. You don’t have to put this option in the config file, you can use ssh -K youserver to delegate credentials when connecting.

      How do you know whether to use it or not? It’s actually rather simple concept. I have 3 servers which are all members of Kerberos realm. I log in to server1 console session as krbuser1 (the same user exists on all 3 servers). This is the first and only time I need to provide the password.

      Upon logging in you can confirm you have Kerberos ticket by running klist command.

      Then from server1 you log in to server2 via ssh, either having GSSAPIDelegateCredentials option in the ssh_config file on server1 (client machine in this case) or using this:

      ssh -K server2.example.com

      You get logged in without password (might get the usual prompt about SSH key if this is the first time).

      Now on server2 you can run klist again to check if you have the ticket. Because you delegated credentials (ticket), you will have it. Without the delegate option, you won’t, meaning you can’t use SSO further down the line.

      Next, within the same ssh session (being on server2 now) you connect to server3:

      ssh server3
      Or:
      ssh -K server3 if you want to keep the ticket even on server3.

      And again, you get connected without providing password for server3 connection, because you have your Kerberos ticket delegated from previous session.

      This is the beauty of Kerberos: Single Sign On.

      I hope this helps.

    • Carl says:

      You’re supposed to update the ssh_config file, not the sshd_config file. I had the same problem 🙂

      • Mike_ says:

        I made this same mistake, but it worked for me anyway. i.e. I updated sshd_config, could not restart daemon/service. I removed the GSSAPIDelegateCredentials entry, it started, and I was able to log onto the system. The entry is neither in ssh_config or sshd_config. Centos 7.4.1708

        Weird…

  4. laurentiu.v says:

    When taking the RHCE exam what exactly is provided?

    Is there a Kerberos/LDAP server that can be used? Or do we have to set-up one?

  5. Shikaz says:

    can’t i do all the configuration for kerberos from authconfig-tui ?

  6. sendtodeji says:

    Thank you for the awesome work. I was wondering if one can achieve this objective by installing ipa-client and running ipa-client-install instead of doing it manually? I found that easy to accomplish because the utility is interactive.

    • CertDepot says:

      When I wrote the Kerberos tutorials in July 2014, I thought the RHCE exam would deal with a standard Kerberos KDC.
      Now, I believe the exam deals with a FreeIPA server. In this case, using ip-client & ipa-client-install is definitely the way to go.
      It’s what I believe but I’ve got very limited information on what is really in the exam!
      This means that you need to understand and be prepared for the two situations!

  7. Sam says:

    Hopefully this will help some one. I had a problem when connecting to kadmin using admin/root, however, kinit worked !! the error message was :

    kadmin: GSS-API (or Kerberos) error while initializing kadmin interface

    The link http://research.imb.uq.edu.au/~l.rathbone/ldap/kerberos.shtml came close but did not solve my problem, which was restarting the ntp server.

    As it turns out my internet connection is v.poor, with a delay of about 300ms. My solution ended up changing the ntp.conf from the default (server) to peer :

    peer 0.centos.pool.ntp.org iburst
    peer 1.centos.pool.ntp.org iburst
    peer 2.centos.pool.ntp.org iburst
    peer 3.centos.pool.ntp.org iburst

    note, only the ntpserver.exmaple.com was changed to peers, the remainder workstation /VM were set to ntpserver.example.ie

  8. alamahant says:

    Dont we need to add a principal also nfs/kbclient.example.com ???Or only adding users principals and host principal is sufficient?

  9. alamahant says:

    If in the exam they use an ipa-server then can we still in /etc/krb5.conf point to the ipa-servers kdc???
    Or we should install an ipa-client instead??
    Because ipa-server and ipa client like to operate at the top level and do not allow kerberos-only interactions between server and client..
    I hope you understand what i mean…….

    • CertDepot says:

      From my understanding, exam candidates don’t need to know if there is an IPA server or a Kerberos-only server behind.
      Also, there is nothing in the RHCE 7 exam curriculum specifying an IPA server.
      Therefore, I advice to test Kerberos configuration with a Kerberos KDC-only server. After, if it’s easier to set up, you can install an IPA server but you shouldn’t use any IPA-specific feature or command on the client side.
      This is what I think on a subject with almost no available information.

  10. alamahant says:

    I checked it..It works fine with krb5-workstation on client and ipa-server as kdc 🙂
    Thanks dear and sorry for the redundant question

  11. anserk says:

    I just wanted to add a note about what you said in the last paragraph (using kinit). This is normally not needed if you log in to the server as Kerberos user. Or if you do su – user01 under unprivileged user. In both cases you get prompted for a password and obtain a ticket. From there you could use SSH right away, no need to issue kinit command.

  12. konrad says:

    Hi there,

    Just did read Sander van Vugt’s book and I see you present two different positions on the issue of Kerberos authentication. He assumes that we have user credentials stored on IPA server, you are creating them on local machine and then adding client machine details to the KDC. Please can I have any comment on that?

    • CertDepot says:

      You are absolutely right. There are at least two ways to do it.
      Sander decided to go the IPA way. I thought it was more relevant to install a KDC server.
      I can’t tell you which way is the best. You should know both!

  13. hunter86_bg says:

    Dear Certdepot,
    I have followed Appendix D of the Sander van Vugt’s book and I have created a freeipa server with DNS .But when I configured the client, I had to install the ipa-client and 2 more packages. Running ipa-client-install modified sssd.conf, ldap’s conf ,ssh conf , etc.
    Have you tested this method and do you think that using ipa-client even without an freeipa server to connect with , would do the job ?

  14. algorisms says:

    It seems this discussion omits Realmd which I just learned about through recent Redhat training.

    With my domain, I was able to join my domain via kerberos very simply with the following:

    [root@BTS-RHEL7-1 ~]# yum install realmd

    [root@BTS-RHEL7-1 ~]# realm discover 192.168.1.221
    bts.test
    type: kerberos
    realm-name: BTS.TEST
    domain-name: bts.test
    configured: no
    server-software: active-directory
    client-software: sssd
    required-package: oddjob
    required-package: oddjob-mkhomedir
    required-package: sssd
    required-package: adcli
    required-package: samba-common

    [root@BTS-RHEL7-1 ~]# yum install oddjob oddjob-mkhomedir sssd adcli samba-common
    [root@BTS-RHEL7-1 ~]# realm join 192.168.1.221
    Password for Administrator:
    [root@BTS-RHEL7-1 ~]#

    Done.

    I then log into my DC and I can see the computer object. This daemon works for IPA and AD servers from reading through the documentation and seems simpler to configure. At least to me. With time being of the essence, this seems to do the trick quickly though it might not be what RH is looking for.

  15. twostep says:

    Could you explain why do you create the keytab for client host principal?
    kadmin: ktadd host/kbclient.example.com?

    • CertDepot says:

      I believe you need a keytab file for all the machines, client and servers.

      • Lisenet says:

        That’s correct, however, the host principle doesn’t seem to be mandatory – in my test lab it works fine with nfs principle only .

        • twostep says:

          No it is not, you can not say “thats’s correct however” please 1 or 0.
          So in my opinion you need the principal of the service to which you want connect to only.
          On the client side you do not need any keytab, because you run kinit, so the principals of your user are in cache already.
          The best way to show it, would be, prepare 3 machines:
          1. KDC,
          2. service with principal e.g. sshd
          3. client machine

          • Lisenet says:

            What happens when you don’t know Kerberos admin password and you cannot run “kinit admin” command on the client machine? You need a keytab.

          • twostep says:

            On the client machine at first you have to
            1. login as the proper user
            2. execute “kinit”, and put your user password.
            3. check your cache via “klist”
            4. ssh servername

            I do not know what do you want to achieve by “kinit admin”.

          • Lisenet says:

            My bad, I thought we were talking about kerberised NFS, not SSH.

          • Mike_ says:

            I have found this to be correct for me, that all hosts must have a keytab file

            It does not matter which user I am logged in as, that I use to issue the kinit to gain a new token; I can issue a kinit as any user. e.g. As user01 I issue “kinit user02”. Then when I attempt to become user02 via ssh or su the kerberos login fails and I am left with a password prompt. However, create a keytab file, I no longer see the password prompt but instead gain access to the user. I therefore, assume the local keytab must exist. e.g. 1. kadmin. 2. ktadd host/client.example.com. or copy the keytab file from the kdc server.

            At least this is what I find using a kdc server and krb5 client.

            Mike_

  16. yarilc says:

    I believe knowing how to configure centralized authentication with authconfig-* tools should be enough

  17. asifshabir says:

    In both the articles:

    RHEL7: Configure a system to authenticate using Kerberos
    And
    RHEL7: Configure a Kerberos KDC.

    You have created same user user01 on both the machines (server and client).

    Should we just create user01 on server and access it from client?
    or we will have to create the same user on all the client machines locally?

    • CertDepot says:

      I don’t remember why I did that (perhaps to avoid the AutoFS+NFS configuration). I suppose you shouldn’t need to create the user on the client.

      • Sam says:

        Short answer : the user needs to be created on all local machines .

        Long answer: Kerberos only supplies a Password token valid for a period of time. The transport of the token from server to client should be encrypted. Additionally local settings and permissions are required. Not all services have a Kerberos protocol built into them.

        To do what you ask would require an internet user naming protocol such as LDAP.

  18. POC says:

    Hi
    Since we are likely to be supplied a keytab file for the client, how much of the above configuration is really necessary? Will we have the kadmin password to add the client as a host?

    • Sam says:

      RHCE is about test of ability for practical implementation.

      Questions on the exam vary from time to time. Knows and understands it all. This is required for troubleshooting different problems.

  19. jrios9 says:

    Please, someone who took the RHCE exam could tell me how the part “Configure a system to authenticate using Kerberos” is?

    I don’t know if in the exam is going to be an admin user to register the server on the kerberos. Can someone give a trick or tips to crack this part of the exam?

    Regards!

  20. Oxygen says:

    Thanks for the article, but I think there is an easier way though. If the goal is to get the kerberos ticket, that could be achieved with authconfig for kerberos only (1 command and 2 RPMs on 7.1). And then:

    root# kinit user01
    root# klist
    root# ssh user01@kbserver.example.com

    That works without adding principals and keytabs, GSSAPIAuthentication is enabled by default.

    Cheers

Leave a Reply

Upcoming Events (Local Time)

There are no events.

RHCSA7: Task of the day

Allowed time: 10 minutes.
Boot and change the root password before the end of the boot process.

RHCE7: Task of the day

Allowed time: 10 minutes.
Configure a httpd server that executes a Perl script in the /var/www/cgi-bin directory displaying "Hello!".

Follow me on Twitter

Poll for favorite RHEL 7 book

What is your favorite RHEL 7 book to prepare RHCSA & RHCE exams?

View Results

Loading ... Loading ...

Poll for most difficult RHCSA 7 topic

What do you think is the most difficult RHCSA 7 topic?

View Results

Loading ... Loading ...

Poll for most difficult RHCE 7 topic

What do you think is the most difficult RHCE 7 topic?

View Results

Loading ... Loading ...