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:kerberoskadmin: 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.
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.
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.
Ok, thanks for clarification.
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
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.
You’re supposed to update the ssh_config file, not the sshd_config file. I had the same problem 🙂
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…
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?
No, you don’t need to set up a Kerberos/LDAP server, this is not a RHCE objective.
All the necessary information is provided.
By all the necessary info is provided, you mean that the Kerberos admin password is also provided, right? Because I can’t see how one can run ‘kinit admin’ in a Kerberos client to do ‘ktadd’ or ‘ipa-getkeytab’.
Yes, this is what I suppose. But I can’t be sure.
can’t i do all the configuration for kerberos from authconfig-tui ?
You can use authconfig-tui or authconfig but all the configuration can’t be done with only these commands.
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.
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!
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
Interesting. Thanks.
Dont we need to add a principal also nfs/kbclient.example.com ???Or only adding users principals and host principal is sufficient?
It is sufficient.
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…….
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.
I checked it..It works fine with krb5-workstation on client and ipa-server as kdc 🙂
Thanks dear and sorry for the redundant question
No problem. You’re welcome.
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.
Interesting. Thank you.
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?
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!
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 ?
I haven’t tried this method. I think it’s a very good question for Sander van Vugt! Sorry.
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.
Yes, I think Realmd is geared towards Active Directory connection. I also don’t think it is part of the RHCE curriculum.
Could you explain why do you create the keytab for client host principal?
kadmin: ktadd host/kbclient.example.com?
I believe you need a keytab file for all the machines, client and servers.
That’s correct, however, the host principle doesn’t seem to be mandatory – in my test lab it works fine with nfs principle only .
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
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.
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”.
My bad, I thought we were talking about kerberised NFS, not SSH.
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_
I believe knowing how to configure centralized authentication with authconfig-* tools should be enough
Yes, but it’s better to set up a KDC to be able to test your knowledge in a real situation.
Otherwise, if anything doesn’t work as expected at the exam, it will be too late.
I think this objective is met in section 8.2 of RH134. Pretty easy to do with authcongfig-gtk. (I just needed to repeat steps til I had it down cold) I’m assuming that LDAP server has been configured and Root CA is provided. Are these assumption good?
Yes, they are.
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?
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.
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.
Interesting. Thanks.
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?
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.
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!
Tip: know how to use a Kerberos keytab file.
Lots of thanks for your tip. Now I’m able to obtain kerberos ticket in different ways. By the way, all your posts on https://www.lisenet.com/ about RHCE preparation are really useful.
I’ll crack the RHCE exam. Thank you CertDepot and Lisenet.
I’m glad you found it useful, best of luck with your studies.
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
Interesting. Thanks.
Yes. On ssh client, only kinit command and /etc/krb5.conf are needed.
On sshd side, the Kerberized service needs other settings which should also be the objective of RHCE EX300.
Hope this post will add “how to kerberize sshd” in future.
authconfig-tui has been deprecated. Any idea if there’s a way to use pam-krb5-migrate to migrate user passwords from say NIS to Kerberos? as mentioned for Solaris here:
https://docs.oracle.com/cd/E23824_01/html/821-1474/pam-krb5-migrate-5.html#REFMAN5pam-krb5-migrate-5
Sorry, no idea.