Friday 25 May 2012

SSH Single Sign On (SSO) for Ubuntu 12.04 using a Windows 2008 R2 / 8 Server Beta AD domain

In my previous post I discussed how to join a Ubuntu 12.04 server to a Windows AD domain (so far I've tried it for both windows 2008 R2 and Windows 8 Server Beta AD domains)
 
In this post I discuss how to get Kerberos based single sign on working. I have tested this method with an openSSH client from Linux and with Putty from Windows.
  1. Install auth-client-config an kerberos libraries for PAM:
    sudo apt-get install auth-client-config libpam-krb5
  2. Configure PAM for Keberos authentication:
    sudo auth-client-config -t pam-password -p kerberos_example
That is it.

It is very important that name resolution is working correctly as you could get issues if it doesn't work properly, thus an up to date DNS server is crucial.

In order to test SSO from Putty, you need to ensure that you don't connect via IP address and that you set the auto-login username to a valid domain user, see below:


In order to test SSO from another Linux box do the following steps (note that depending on your distro you might have to install some packages):
  1. Get Kerberos ticket:
    kinit domainuser@TEST.ORG
  2. Login:
    ssh servername -l 'test\domainuser'
If you hit any problems, the simplest way to trouble shoot is to open a debug ssh daemon, which you can do like this (you can add a couple more ds for extra debug info but I think debug1 is all you need):
sudo /usr/sbin/sshd -p 31415 -d
You'll need to allow traffic on port 31415 or the port you choose, which you can easily do by stopping iptables. Clearly this should only be done in servers that are not internet facing. If the server is internet facing then just open port 31415, e.g:
sudo iptables -I INPUT -p tcp --dport 31415 -j ACCEPT
You can connect to this server with:
ssh servername -p 31415 -v
This should tell you what the problem is, e.g:
debug1: Unspecified GSS failure.  Minor code may provide more information
Key table entry not found
This was actually caused by a name resolution problem.
Posted by at 17:56
Labels: , ,

7 comments:

  1. Its Always The Network3 July 2012 at 00:36

    okay, first, YOU ROCK! Thanks for the easy how-to's.

    1 thing though, I'm not sure I understand the second command you have listed :

    "sudo auth-client-config -t pam pam-password -p kerberos_example"

    I get that you are executing the auth-client-config using a type of "pam", but I don't get what I'm supposed to fill in, if anything, under "pam_password" and "kerberos_example".

    I will say, that entering things exactly as you have them, I can use AD Security Groups, and adjust the sudoers file and login just fine with my AD Accounts. I'd just like to fully understand the syntax.

    ReplyDelete
    Replies
    1. manyrootsofallevil3 July 2012 at 08:57

      You need to type the command as is. pam-password is a type and kerberos_example is a profile.

      You can list types and profiles with the -l and -L flags respectively.

      In essence, auth-client-config is writing information to the various config files for you, you are just telling it what type of authentication you want.

      Delete
    2. Its Always The Network3 July 2012 at 21:53

      AHA! Now I get it! Thanks for clarifying man!

      Delete
    3. Its Always The Network11 July 2012 at 19:32

      Okay, so I'm in a bit of a quandry here. I have to uninstall auth-client-config, libpam-krb5, and likewise-open5 to get these servers back to default.

      Now, I removed the packages, and immediately I couldn't SSH in. I fixed that by changing an /etc/ssh/sshd_config entry for "UsePAM yes" to "UsePAM no" and was able to at least get back in via SSH.

      So the problem is, I have to leave "auth-client-config" installed or I can't use the "sudo" command anymore. I have the feeling it's that command above for "sudo auth-client-config -t pam pam-password -p kerberos_example" that is causing this issue. Does one of the PAM entries get changed that would dissallow sudo from taking place on a local account?

      Delete
    4. Its Always The Network11 July 2012 at 23:34

      Well, I figured out a fix. Here's what I did. Turns out it wasn't "auth-client-config", it was the "libpam-krb5" package that modified all the PAM modules.

      1. sudo-apt-get remove likewise-open5 -y
      2. sudo apt-get remove auth-client-config -y
      3. sudo apt-get remove libpam-krb5
      A. When prompted to override settings, Select YES
      4. sudo vim /etc/ssh/sshd_config
      A. Ensure you have a local user that's part of a Group in "AllowGroups" or "AllowUsers".
      B. Change "UsePAM yes" to "UsePAM no"
      C. Save your changes
      D. sudo service ssh restart
      5. sudo apt-get install libpam-krb5
      A. When prompted to override, select NO
      6. sudo apt-get remove libpam-krb5
      A. If you did it just how I listed, you won't be prompted this time, and you will now be able to login fine with both local users, and also use the sudo command, all while having removed the aforementioned packages.

      This tutorial is great, and I appreciate the hard work. I have to say though, Likewise open still has a ways to go on some of it's consistency. We had it deployed on over 40 servers. Some virtualized, some in the cloud, and some physical. We've had off and on problems with half of them just randomly not accepting logins. Of all things, a reboot fixed the issues. Luckily they weren't deployed in production. For now, I think I'll stick with setting up SSH and the PAM Modules to use our RADIUS Servers via NTLM Authentication.

      Delete
    5. manyrootsofallevil12 July 2012 at 08:04

      The project I set the servers up for got canned, so the servers have never been used in anger.

      Thanks for the comments on using likewise open in a bigger environment.

      Delete
  2. Unknown7 July 2014 at 15:27

    alternative method

    http://blog.it-kb.ru/2014/07/06/single-sign-on-sso-server-connection-ubuntu-server-14-04-lts-via-ssh-using-putty-from-windows-based-active-directory/

    ReplyDelete

Subscribe to: Post Comments (Atom)