3

I followed the Configuration 3 from the RedHat AD integration (https://access.redhat.com/sites/default/files/attachments/rhel-ad-integration-deployment-guidelines-v1.5.pdf); but I am stuck.

I am on Centos 6.8.

I have a working AD connection:

 service sssd stop
 rm -r /var/lib/sss/db/*
 rm -r /var/lib/sss/mc/*
 service sssd start
 getent passwd [email protected]

This returns a sensible line: 

 robau:*:102201201:102200513:Rob Audenaerde:/:

However, when I try to connect over SSH, I can't login. I enabled SSSD debugging on all components level 5 in the sssd.conf.

The error I see (in var/log/sssd/krb5_child.log) is:

(Fri Jun 17 17:23:18 2016) [[sssd[krb5_child[3561]]]] [validate_tgt] (0x0020): TGT failed verification using key for [host/[email protected]].
(Fri Jun 17 17:23:18 2016) [[sssd[krb5_child[3561]]]] [get_and_save_tgt] (0x0020): 1240: [-1765328377][Server not found in Kerberos database]
(Fri Jun 17 17:23:18 2016) [[sssd[krb5_child[3561]]]] [map_krb5_error] (0x0020): 1301: [-1765328377][Server not found in Kerberos database]
(Fri Jun 17 17:23:18 2016) [[sssd[krb5_child[3561]]]] [k5c_send_data] (0x0200): Received error code 1432158209

The server is in the DNS, I can find it using nslookup

   nslookup server-new.mynetwork.nl

   Server:  192.168.110.56
   Address: 192.168.110.56#53

   Name:    server-new.mynetwork.nl
   Address: 192.168.210.94

And

kvno host/[email protected]
kvno: Server not found in Kerberos database while getting credentials for host/[email protected]

Any hints/tips for troubleshooting?

[EDIT] I used authconfig to setup the necessary pam and nss stuff:

authconfig --enablesssdauth --enablesssd --enablemkhomedir --update

Output of klist -kte:

  25 06/20/16 10:56:24 host/[email protected] (des-cbc-crc) 
  25 06/20/16 10:56:24 host/[email protected] (des-cbc-md5) 
  25 06/20/16 10:56:24 host/[email protected] (aes128-cts-hmac-sha1-96) 
  25 06/20/16 10:56:24 host/[email protected] (aes256-cts-hmac-sha1-96) 
  25 06/20/16 10:56:24 host/[email protected] (arcfour-hmac) 
  25 06/20/16 10:56:24 host/[email protected] (des-cbc-crc) 
  25 06/20/16 10:56:24 host/[email protected] (des-cbc-md5) 
  25 06/20/16 10:56:25 host/[email protected] (aes128-cts-hmac-sha1-96) 
  25 06/20/16 10:56:25 host/[email protected] (aes256-cts-hmac-sha1-96) 
  25 06/20/16 10:56:25 host/[email protected] (arcfour-hmac) 
  25 06/20/16 10:56:25 [email protected] (des-cbc-crc) 
  25 06/20/16 10:56:25 [email protected] (des-cbc-md5) 
  25 06/20/16 10:56:25 [email protected] (aes128-cts-hmac-sha1-96) 
  25 06/20/16 10:56:25 [email protected] (aes256-cts-hmac-sha1-96) 
  25 06/20/16 10:56:26 [email protected] (arcfour-hmac)

Output of klist

Ticket cache: FILE:/tmp/krb5cc_0
Default principal: [email protected]

Valid starting     Expires            Service principal
06/20/16 10:56:41  06/20/16 20:56:41  krbtgt/[email protected]
    renew until 06/27/16 10:56:41
06/20/16 11:36:07  06/20/16 20:56:41  ldap/[email protected]
    renew until 06/27/16 10:56:41

[EDIT 2]

If I add krb5_validate at the end of the sssd.conf section [domain/mynetwork.local] then I am able to login. However, I also set-up another server that did not need this step, so I'm reluctant to leave it like this.

[EDIT 3] During the net ads join -k I get an error/warning: 

DNS Update for failed: ERROR_DNS_GSS_ERROR 
DNS update failed!

[EDIT 4] I see the output of net ads info is not using the main Domain controller I specified in my config files (and is 2003R2 and not 2008R2). Is there a way to 'force' the net ads join -k to use a specific domain controller?

Improve this question
3
  • Did you run a kinit yet? Can you also post output of klist -te and klist -kte. The server needs a local Kerberos ticket cache to be able to do password authentication. And is your pam configuration correct, I assume yes but you didn't mention it.
    – aairey
    Jun 20, 2016 at 9:54
  • Yes. I did a kinit admin, net join ads -k and kinit -k SERVER-NEW$
    – Rob Audenaerde
    Jun 20, 2016 at 10:04
  • What is the name of the computer account in AD? AD tends to use the hostname (not fqdn) in lowercase.
    – aairey
    Jun 20, 2016 at 10:40

2 Answers 2

Reset to default
2
+50

Try installing and running msktutil (it is available through EPEL).

To install:

yum -y --enablerepo=epel install msktutil

To run it:

msktutil --auto-update --server my-ad --verbose

And run a kinit after that:

kinit -k server-new$

Also, You should cron these two jobs to run every 6 hours or so. That way your tickets do not expire.

Answer to EDIT4: you should be able to specify a server with net ads join -k -S, but by default it will search your DNS for SRV records. Which is fine. Unless you don't want that. If you want a specific site to use different DC's than another, look at Active Directory Sites & Services.

Improve this answer
5
  • Thank you @aairey; do you think the problem is that my tickets expire? I would think they should at least stay valid for 10h (the TGT if I am correct). I ran into the problem directly after setting-up sssd, kerberos etc.
    – Rob Audenaerde
    Jun 20, 2016 at 10:48
  • No. But the kerberos server cannot find the name that your client is sending. msktutil takes care of this for you and creates principals that AD likes.
    – aairey
    Jun 20, 2016 at 10:52
  • Ah I see. Am I correct to assume the net join ads -k did not create proper tickets? (see also edit 4)
    – Rob Audenaerde
    Jun 20, 2016 at 11:13
  • It uses principals based on MIT Kerberos. As always, Microsoft needs to be "special" and has developed it's own, slightly deferring, standards. (updated answer on edit4)
    – aairey
    Jun 20, 2016 at 11:33
  • Btw, it's much easier in CentOS 7 with realmd :) and on CentOS 5 ... good luck you're on your own there :D
    – aairey
    Jun 20, 2016 at 11:36
3

This is usually caused by canonicalization. Try adding:

rdns=false

to krb5.conf and also

SASL_NOCANON true

to ldap.conf

(both are already the default in RHEL-7).

Improve this answer
2
  • The first setting did not change the behaviour.
    – Rob Audenaerde
    Jun 21, 2016 at 6:55
  • rdns=false took care of it for me. The client I was trying to join had a hostname (from DHCP) that wasn't in the AD domain.
    – Jonathon Reinhart
    Mar 6, 2019 at 6:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .