6

Good afternoon folks. I've been perusing various posts already about getting linux systems to authenticate using AD, but haven't seen anything approaching what I'm beating my head against.

There's a lot of setup here, so please bear with me.

First off, the goal is to have all of our Linux and Unix systems authenticate against AD. This isn't optional with several hundred systems; user account management is long past being an issue.

We have several instances of AD: one is a "management AD" ("MAD") where all sysadmin accounts should live. MAD trusts no other domains. All other domains ("CAD", "FAD", "BAD") trust MAD. Most systems will be associated with CAD, FAD, or BAD. Only internal systems will be associated with MAD.

The main platform is RHEL, and I have a mixture of 5, 6, and 7. 5 isn't going away anytime soon, and despite it going out of support with RH in less than a year, I still have to get the population of 5's integrated with AD. Any solution needs to work across 5, 6, and 7 as we don't want to be supporting multiple ways of doing things.

My main options (at least the ones I am working on) are Winbind and SSSD. Given the choice between the two, I'd prefer SSSD as Winbind is "pretty old". One more requirement is that "groups" and "id" produce information out of AD as we intend to use openssh's "AllowGroups" feature to restrict logins to particular AD groups.

I have followed every manual, every howto, every guide, and when it comes down to it, there's always one little thing that doesn't seem to be usefully documented that blocks me.

I am fairly strong with unix/linux in general, but I am not strong with AD, Kerberos, or LDAP.

For lab purposes, I'm starting with a fresh install of RHEL7 off ISO (kickstart with some basic config stuff), with no authentication bits set up within the KS.

Step 1: Sync time. Done.

Step 2: Install/activate oddjob. Done.

Step 3: Make sure there are both forward and reverse DNS entries for the target system. Done. Manually as so far I can't depend on later steps to get it right. I'll cope.

Step 4: Configure Kerberos. Sanitized version of /etc/krb5.conf:

includedir /var/lib/sss/pubconf/krb5.include.d/
[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

[libdefaults]
 default_realm = CAD.LAB
 dns_lookup_realm = true
 dns_lookup_kdc = true
 ticket_lifetime = 24h
 renew_lifetime = 7d
 forwardable = true

[realms]
 CAD.LAB = {
  kdc = cad_dc_01.cad.lab
 }

[domain_realm]
 .cad.lab = CAD.LAB
 cad.lab = CAD.LAB

Step 5: Setup samba.conf just enough for SSSD. /etc/samba/smb.conf [globals] section, sanitized:

[global]
workgroup = CAD
client signing = yes
client use spnego = yes
kerberos method = secrets and keytab
log file = /var/log/samba/%m.log
log level = 0
password server = cad_dc_01.cad.lab
realm = CAD.LAB
security = ads

Step 6: Join the system to CAD. "kinit Administrator" followed by "net ads join -k". Works without any problems.

Step 7: Configure SSSD. Sanitized /etc/sss/sssd.conf:

[sssd]
domains = CAD
services = nss, pam
config_file_version = 2
cache_credentials = true
debug_level = 7

[domain/CAD]
enumerate = true
# I know enumerate will cause problems later, I'm only turning it on for lab
debug_level = 7
id_provider = ad
ad_server = cad_dc_01.cad.lab
auth_provider = ad
chpass_provider = ad
access_provider = ad
default_shell = /bin/bash
fallback_homedir = /home/%u

[nss]
debug_level = 7

[pam]
debug_level = 7

Followed by "systemctl start sssd". Which appears to work, but no AD logins work.

Browsing through /var/log/sssd/sssd_CAD.log, I find a few things that give me a clue as to where things are screwing up, but I've not been successful in finding a way to fix them: every guide I read gives a sequence of steps and assumes every step works. I've found nothing to help me figure out what's wrong when one of those steps doesn't work.

I won't post the entire sssd_CAD.log unless someone asks, but here are the first indicators that something is wrong.

(Tue May 31 12:35:05 2016) [sssd[be[CAD]]] [ad_set_sdap_options] (0x0100): Option krb5_realm set to CAD
(Tue May 31 12:35:05 2016) [sssd[be[CAD]]] [sdap_set_sasl_options] (0x0100): Will look for rhel7lab.CAD.LAB@CAD in default keytab
(Tue May 31 12:35:05 2016) [sssd[be[CAD]]] [select_principal_from_keytab] (0x0200): trying to select the most appropriate principal from keytab
(Tue May 31 12:35:05 2016) [sssd[be[CAD]]] [find_principal_in_keytab] (0x0400): No principal matching rhel7lab.CAD.LAB@CAD found in keytab.
(Tue May 31 12:35:05 2016) [sssd[be[CAD]]] [find_principal_in_keytab] (0x0400): No principal matching rhel7lab$@CAD found in keytab.
(Tue May 31 12:35:05 2016) [sssd[be[CAD]]] [find_principal_in_keytab] (0x0400): No principal matching host/rhel7lab.CAD.LAB@CAD found in keytab.
(Tue May 31 12:35:05 2016) [sssd[be[CAD]]] [find_principal_in_keytab] (0x0400): No principal matching *$@CAD found in keytab.
(Tue May 31 12:35:05 2016) [sssd[be[CAD]]] [find_principal_in_keytab] (0x0400): No principal matching host/*@CAD found in keytab.
(Tue May 31 12:35:05 2016) [sssd[be[CAD]]] [match_principal] (0x1000): Principal matched to the sample (host/*@(null)).
(Tue May 31 12:35:05 2016) [sssd[be[CAD]]] [select_principal_from_keytab] (0x0200): Selected primary: host/rhel7lab.CAD.LAB
(Tue May 31 12:35:05 2016) [sssd[be[CAD]]] [select_principal_from_keytab] (0x0200): Selected realm: CAD.LAB

There are later entries that complain about sssd_ad not being connected to the AD, but that's no surprise given what I see here.

So: fresh image with timesync/krb5.conf/smb.conf all done, now "kinit Administrator" followed by "klist"

[root@rhel7lab]# kinit Administrator
Password for Administrator@CAD.LAB: 
[root@rhel7lab]# net ads join -k
Using short domain name -- CAD
Joined 'RHEL7LAB' to dns domain 'CAD.dev'
[root@rhel7lab]# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: Administrator@CAD.LAB

Valid starting       Expires              Service principal
05/31/2016 12:46:35  05/31/2016 22:46:35  krbtgt/CAD.LAB@CAD.LAB
        renew until 06/07/2016 12:46:30
05/31/2016 12:46:39  05/31/2016 22:46:35  cifs/CADDC01.CAD.LAB@CAD.LAB
        renew until 06/07/2016 12:46:30
05/31/2016 12:46:39  05/31/2016 22:46:35  ldap/cad_dc_01.cad.lab@CAD.LAB
        renew until 06/07/2016 12:46:30
[root@rhel7lab]#

I am guessing that this list should be much longer, but not being strong in kerb, I don't know if this really is correct, if not what it should look like, nor how to get it there.

I'm at the end of my rope with this thing, and beginning to think making sandwiches would be a less annoying career choice.

Any guidance from you folks would be greatly appreciated. If there's more stuff I need to add here, just say the word and it'll be up.

Thanks, -9

Kill Dash Nine
  • 61
  • 1
  • 3
    Did you [check this post](http://serverfault.com/q/589750/13325) out? – ewwhite May 31 '16 at 20:31
  • Have you looked at [RHEL Windows integration guide](https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/pdf/Windows_Integration_Guide/Red_Hat_Enterprise_Linux-7-Windows_Integration_Guide-en-US.pdf)? – shodanshok May 31 '16 at 22:05
  • @ewwhite. Yes I read that. That's one of the various reasons I'm preferring SSSD. My problem is not selecting what to use, it's getting the thing to work as documented. – Kill Dash Nine May 31 '16 at 22:57
  • @shodanshok: it's a permanent fixture on my second display. Feel free to look at page 7, item 3.c.b, where the last item is "klist -k" and reads "List the keys for the system and check that the host principal is there." There's no example output of what to be looking for, and no troubleshooting guidance; the document just assumes it works. I've also looked at https://access.redhat.com/solutions/1755013 which is a less confusing document. I've followed both of these to the letter only substituting my names, neither one works, and both produce the same results I've given detail on above. – Kill Dash Nine May 31 '16 at 23:02
  • In my experience, sometimes AD takes a few minutes before you can start authenticating users on a Linux system. Not really sure why. That was also on a single-domain forest. Now, if your main purpose is user auth, let's focus on that. Can you provide some of your /var/log/secure (rhel) for a failed user login? Describe that workflow: ssh, console session, what? – bgStack15 Jul 14 '16 at 19:44
  • Not sure if this is just 6&7, but when we join machines to AD (using adcli admittedly) I have to run `authconfig` as well to make it all wire up correctly - `authconfig --enablesssd --enablesssdauth --update` – shearn89 Feb 23 '17 at 08:46

2 Answers2

0

Your SSSD config might be the culprit:

No principal matching rhel7lab.CAD.LAB@CAD found in keytab.

Shouldn't that be CAD.LAB@CAD.LAB, as per the klist output?

Can you try this SSSD conf (note the default suffix):

[sssd]
domains = CAD
default_domain_suffix = CAD.LAB
services = nss, pam
config_file_version = 2
cache_credentials = true
debug_level = 7

Restart SSSD, see if it works?

shearn89
  • 3,143
  • 2
  • 14
  • 39
0

I'm not sure it directly addresses your question, but have you tried realmd? It handles a LOT of the conf file setup automatically. This tends to produce more predictable errors with messages that are more readily Googled.

In your case, the mixed-case keytab search looks wrong to me:

rhel7lab.CAD.LAB

Is your hostname or hosts entry capitalized? Kerberos realms should be all-caps but I don't believe that applies to anything else. Here's an example of the list that's generated during a test bench "realm join":

LIN3$@LDAP.<REALM>.COM
host/LIN3@LDAP.<REALM>.COM
host/lin3.ldap.<domain>.com@LDAP.<REALM>.COM
claytond
  • 371
  • 1
  • 3
  • 6