5

Apologies if this is a re-post. I've been googling and researching the topic for over three weeks now and I've come up against the same problem over and over again and I haven't managed to get around it.

Disclaimer: I am not a sysadmin although I have been forced into the position at work.

I've been tasked to implement an Active Directory (on Server 2008) config for our environment containing Windows XP, Windows 7, Server 2003, Server 2008, Server 2008 R2 and Red Hat Enterprise 5.10 boxes. Easy enough. Get a quick guide online, setup a test VM server, connect my Win7 client to my new AD. Works.

Repeat but try to connect a RHEL 5.10 VM to the AD? No dice.

I've followed about 3 different 'guides' on how to setup Linux to connect to AD. The more thorough one would be: Authenticating UNIX/Linux to Windows 2008R2 Specifically, the RHEL setup: Part 3 : RHEL 5.6

Listed plan of attack:

  1. Get ldapsearch working with simple bind, unencrypted
  2. Configure LDAP
  3. Verify LDAP works with getent(1), id(1), etc
  4. Export the Root CA cert from Windows to UNIX
  5. Check the CA cert works with OpenSSL
  6. Import the CA cert
  7. Get LDAPS working with ldapsearch
  8. Change LDAP to use LDAPS rather than LDAP
  9. Verify Kerberos works: Initially, without a host principal (krb5.keytab)
  10. Configure PAM to use Kerberos (edit /etc/pam.conf)
  11. Verify that services like login can use kerberised IDs and that the password works
  12. Create a host principal keytab in Windows. Import it into UNIX.
  13. Verify that kinit -k works
  14. Edit /etc/krb5/krb5.conf to include “verify_ap_req_nofail = true” in the [libdefaults] section. This will secure the UNIX box to prove it is talking with the bonefide KDC.
  15. Get Single-Sign-On working

Followed the steps word for word, changing IPs and Hostnames to match my test environment. One exception was made:

C:\>ktpass /princ host/rhel5host1.example.com@EXAMPLE.COM \
/ptype KRB5_NT_PRINCIPAL /out C:\temp\rhel5host1.keytab /pass mypass \
/crypto AES256-SHA1 /mapuser EXAMPLE\rhel5host1

Got the error message: getting target domain for specified user.

C:\>ktpass /princ host/rhel5host1.example.com@EXAMPLE.COM \
/ptype KRB5_NT_PRINCIPAL /out C:\temp\rhel5host1.keytab /pass mypass \
/crypto AES256-SHA1 /mapuser EXAMPLE\rhel5host1$

Specifying a machine account with the dollar sign, and KTPASS runs through without error.

Everything works 100% up until we test Kerberos:

[root@rhelad ~]# kinit -k
kinit(v5): Client not found in Kerberos database while getting initial credentials

OK, google the error and we get:

Your kerberos principal may differ from your username on your local system.

credentials krb5_get_init_creds_password() failed: Client not found in Kerberos database Make sure that you're typing in the right name and the server has the right name (double check the account tab of the user, especially the realm)

So I checked and fiddled and googled and I've come up with nothing. According to me the config on RHEL is correct and I've got the computer and user accounts created on the AD, no problem.

My assumption here is that I've configured RHEL correctly, but messed up somewhere in creating the RHEL based clients setup on AD. Yes, I have enabled and configured the UNIX attributes, so its not that.

Could someone please point me to / show me the correct steps to add and config UNIX computers and users on AD? I'd be happy to 'dump' configs, if its so desired.

  • Is rhel5host1 using your AD DNS for resolution? And, does varying the case of the machine account change the results (e.g. RHEL5HOST1)? – JasonAzze Dec 1 '14 at 12:28
  • Yes. rhel5host1 is looking towards the AD. Tested with nslookup – ShadowedR Dec 1 '14 at 13:11
  • 1
    I've been putting off attempting an answer because the guide you've followed is huge to debug. It looks like the keytab is being exported/imported incorrectly somehow. What does the "klist -ke" command give you? – Andy Dec 5 '14 at 9:41
  • Hey, I scrapped the test VM and went the winbind route. I can tell you though the klist gave me the summary of the kerberos ticket I requested via kinit username@domain. So that seemed fine. – ShadowedR Dec 8 '14 at 9:14
  • We use SSSD to password auth our RHEL 5/6 servers against AD. Works okay. Not that I've used it much myself, but may be worth remembering that RHEL has tools like 'authconfig' which may make this easier. If you have a Red Hat subscription, then consult access.redhat.com – Cameron Kerr Apr 23 '15 at 9:07
0

You may be able to simplify your life by using a tool like Powerbroker Identity Services or PBIS. They have an open source version available at their website http://www.powerbrokeropen.org/

This is what I am currently using at work to join our linux hosts to AD and it has worked out for me across multiple versions of centos and ubuntu.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.