Configure realms under krb5.conf file for using AD Authentication for RHEL VMs

Latest response

I'm hitting a sticking point here as I've never done this before.

I'm using the following document from Red Hat for help:

https://access.redhat.com/sites/default/files/attachments/rhel-ad-integration-deployment-guidelines-v1.5.pdf

I'm to the part to install/configure Kerberos Client and I'm not sure how to configure the krb5.conf file

[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log
[libdefaults]
 default_realm = REFARCH-AD.CLOUD.LAB.ENG.BOS.REDHAT.COM
 dns_lookup_realm = false
 dns_lookup_kdc = false
 ticket_lifetime = 24h
 renew_lifetime = 7d
 forwardable = true
[realms]
 REFARCH-AD.CLOUD.LAB.ENG.BOS.REDHAT.COM = {
 kdc = WIN-SRV1.REFARCH-AD.CLOUD.LAB.ENG.BOS.REDHAT.COM
 admin_server = WIN-SRV1.REFARCH-AD.CLOUD.LAB.ENG.BOS.REDHAT.COM
 }
[domain_realm]
 .demo = REFARCH-AD.CLOUD.LAB.ENG.BOS.REDHAT.COM 
demo = REFARCH-AD.CLOUD.LAB.ENG.BOS.REDHAT.COM

For the default_realm, I believe I'm going to use the FQDN here for the local AD Server, correct

As for the realms, is this the same thing. I'm not really sure what to do for this part. Basically I'm trying to go thru this because if I do that, then I understand.

thanks

CM
Log in to join the conversation

Responses

JL Active Contributor 332 points
12 June 2018 9:40 PM

You can make a minimalist /etc/krb5.conf file without specifying anything in [realms] or [domain_realm] if you use dns_lookup_kdc = true

My [libdefaults] section just looks like

dns_lookup_realm = false
 dns_lookup_kdc = true
 ticket_lifetime = 24h
 renew_lifetime = 7d
 forwardable = true
 rdns = false
 default_realm = YOUR.DOMAIN.HERE
 default_ccache_name = KEYRING:persistent:%{uid}

This will avoid trying to guess what realms are lurking about, but use the SRV records to lookup the domain controllers. Test it by trying "kinit".

CM Expert 1215 points
13 June 2018 2:01 PM

Now that I'm reading thru the documentation again. I know that I want to use the Microsoft AD for single sign on. So I'm going to include that into the krb5.conf file.

However do I need a kerberos realm too?

The more I re-read thru this document, the more questions I have.

JL Active Contributor 332 points
13 June 2018 3:39 PM

Yes, the clients have to know the Kerberos realm context they are logging into, and have to find a KDC server for that realm. In the simple case of Redhat servers being domain members of a single Microsoft AD forest, with no cross-realm/forest trusts, a very easy way is, as stated above:

rdns = false
dns_lookup_realm = false
default_realm = YOUR.AD.FOREST.FQDNS.PREFIX.HERE
dns_lookup_kdc = true

If you have more complex requirements, you'll end up with a more complex answer. In this case you have explicitly specified the Kerberos realm as a default. That gets added to unadorned user names, so e.g. "kinit Jane.Doe" works, without specifying "kinit Jane.Doe@Very.Long.DNS.name", which also works. Each microsoft domain controller in the forest will register DNS SRV records along the lines of _kerberos._tcp.YOUR-SITE._sites.dc._msdcs.YOUR.DOMAIN pointing at itself, and the clients can and should locate the microsoft DC's using them.

CM Expert 1215 points
13 June 2018 3:49 PM

I know very little about Kerberos and Kerberos Realms. Would I have to setup a Kerberos Realm on another RHEL VM or does this live on the Microsoft AD Server?

Right now, we don't have complex requirements. We are just wanting SSO and use Smart Card Authentication with RHEL6/RHEL7 VMs.

JL Active Contributor 332 points
13 June 2018 4:55 PM

A microsoft active directory forest domain is a kerberos realm of its own, and the domain controllers there act as Kerberos Key Distribution Centers, passing out kerberos ticket granting tickets from port 88 in the usual Kerberos way. The differences from classic Unix Kerberos as pioneered at MIT are basically twofold: (1) a Microsoft AD domain controller has a much larger network attack surface than a unix Kerberos KDC and is thus more of a security risk in your infrastructure; and (2) Microsoft extended the kerberos login protocol with a "PAC" structure to pass microsoft group membership info back to the clients, be they Linux or WIndows or whatever. So in the simple case we are describing, the Linux clients are members of the same single Kerberos realm for the organization which is hosted by and served by the Microsoft AD forests domain controllers. I'm assuming a single-domain forest here.

You may want to instantiate some of the AD schema attributes for RFC-2307bis, particularly uidNumber and gidNumber. If you have a need for consistency of uid/gid/group memberships across multiple linux servers this is one of the good and simple ways to accomplish that. In my case, we have more windows users than Linux users, and all the Linux users already have windows accounts. So I give each Linux server a pair of windows groups "user_SERVER" and "admin_SERVER" used by pam and sssd and sudo to control login rights and sudo rights, and each windows account in these groups gets a "linux_USER" windows group to be the linux home directory group owner on all the Linux servers they might use. All the windows groups used on Linux have gidNumber set in AD for access via LDAP, and the user accounts have the linux group as their "primary" account group plus the uidNumber and gidNumber settings.

If you have large organization or large number of users, you can buy 3rd party products to help orchestrate this.