Enable VNC for Zentyal Community Server

Posted: February 27th, 2013 | Author: | Filed under: Blog, DNS, Kerberos, krb5, LDAP, Linux, Networking, Work, Zentyal | 4 Comments »

Get a terminal session on your Zentyal box and install the VNC service

sudo apt-get install vnc4server

Next, run the server once to initialize a config file, kill the service and make a backup of the config file and then edit.


vncserver
vncserver -kill :1
cp .vnc/xstartup .vnc/xstartup.bak
nano .vnc/xstartup

Uncomment one line and add another:


# Uncomment the following two lines for normal desktop:
unset SESSION_MANAGER
# exec /etc/X11/xinit/xinitrc
/usr/bin/lxsession -s LXDE -e LXDE

Then just launch
vncserver

Watch the output so you can ensure what port to connect to. For example, the following means my VNC server is listening on port 5901


jordan@mrsparkle:/etc/X11$ vncserver

New 'mrsparkle:1 (jordan)' desktop is mrsparkle:1

Starting applications specified in /home/jordan/.vnc/xstartup
Log file is /home/jordan/.vnc/mrsparkle:1.log


Snow Leopard Server and Linux client using LDAP and libpam-krb5

Posted: May 24th, 2010 | Author: | Filed under: Kerberos, krb5, LDAP, Linux, Mac OS X Server, Snow Leopard | 1 Comment »

This is an extension article to my previous article Open Directory, Kerberos, Single Sign On (SSO) and CentOS with SSH and Kerberized NFS Home Directories. I had some requests from different Linux users out there how to incorporate authentication for Linux flavours other than CentOS. For this example we’re going to use Debian Lenny with some Ubuntu 10.04 refs thrown in.

Preperation – LDAP

First download all the packages that we’ll need.
Debian
apt-get install nss_updatedb ldap-utils libpam-ldap libnss-ldap nscd
Ubuntu
apt-get install nss_updatedb ldap-utils libpam-ldap libnss-ldap nscd nslcd
During the installation debconf should ask you some questions, here are my answers

LDAP server Uniform Resource Identifier: ldap:/// (Note the "ldap://", NOT "ldapi://"!)
Distinguished name of the search base: dc=foo,dc=bar
LDAP version to use: 3
Does the LDAP database require login? No
Special LDAP privileges for root? No
Make the configuration file readable/writeable by its owner only? No
Make local root Database admin. No
Does the LDAP database require login? No
Local crypt to use when changing passwords. crypt

If you’re not on Debian you can edit these options in the file /etc/ldap/ldap.conf and /etc/libnss-ldap.conf

Next, edit /etc/nsswitch.conf and change

passwd: compat
groups: compat

--to--

passwd: files ldap
groups: files ldap

Now restart the nscd service ( and nslcd if you’re using Ubuntu 10.04 )

Verify you can see the users via LDAP with the id or getent commands

jordan@elm:/$ id jordan
uid=1000(jordan) gid=100(users) groups=1001(ldap-admin),1022(fgstaff),1023(ssh-access),100(users)


jordan@elm:/$ getent passwd | grep jordan
jordan:x:1000:100:Jordan Eunson:/net/home/jordan:/bin/bash
jordan@elm:/$

Preperation – libpam-krb5

Download and install the packages
apt-get install krb5-config libpam-krb5

Then edit your /etc/krb5.conf file. Now here what you *could* do is copy the one from you Mac. If you have a Mac client already bound to your Open Directory installation then open the file /Library/Preferences/edu.mit.Kerberos and copy and paste the content to /etc/krb5.conf

Here is an example of mine for the realm FOO.BAR

[libdefaults]
default_realm = FOO.BAR
[realms]
FOO.BAR = {
admin_server = od-master.foo.bar
kdc = od-master.foo.bar
}
[domain_realm]
.foo.bar = FOO.BAR
foo.bar = FOO.BAR
[logging]
admin_server = FILE:/var/log/krb5kdc/kadmin.log
kdc = FILE:/var/log/krb5kdc/kdc.log

To test to see if this is working type the command kinit and see if we can get a ticket from the Kerberos Key Distribution Center


bart:~ jordan$ kinit jeunson
Please enter the password for jeunson@FOO.BAR:
bart:~ jordan$ klist
Kerberos 5 ticket cache: 'API:Initial default ccache'
Default principal: jeunson@FOO.BAR

Valid Starting Expires Service Principal
05/24/10 16:30:35 05/25/10 02:29:14 krbtgt/FOO.BAR@FOO.BAR
renew until 05/31/10 16:30:35

bart:~ jordan$

Kerberos Authentication

Now that we have our Kerberos client working we can integrate the local system to LDAP for user lookup and Kerberos for passwords with PAM libraries.

/etc/pam.d/common-account

account sufficient pam_unix.so
account required pam_krb5.so

/etc/pam.d/common-auth

auth sufficient pam_unix.so nullok_secure
auth sufficient pam_krb5.so use_first_pass
auth required pam_deny.so

/etc/pam.d/common-session

session required pam_unix.so
#session required pam_mkhomedir.so skel=/etc/skel/ umask=0022
session optional pam_krb5.so minimum_uid=1000

Now try to login to your Linux client either on the console to see if it works. To finish up with Kerberizing the client please read this article


Open Directory, Kerberos, Single Sign On (SSO) and CentOS with SSH and Kerberized NFS Home Directories

Posted: May 17th, 2010 | Author: | Filed under: Kerberos, krb5, Linux, Mac OS X Server, Snow Leopard, SSH | 1 Comment »

This article is a pseudo continuation of the article: Using Network Accounts on a Linux Client with Open Directory Leopard Server. In this article I’m going to be going over at a high level the single sign-on environment in Mac OS X Server and at a low level on integrating Kerberized SSH and NFS and CentOS.

Please note the benefits of Kerberized NFS is that if a local computer is compromised the attacker will not be able to read NFS shares because they will not have a valid Kerberos ticket. Oh… and the whole NFS stream will be encrypted. (pow!)

Open Directory and Kerberos

Taken from Apple’s site: Picture walking into the local county fair, and you are given two choices. You can either use your credit card at the entry of every ride or you can use it once at a booth, which grants you a ticket that you can use for the remainder of the day. It’s a pretty simple choice if you’re concerned about the security of your credit card information and want to have a hassle-free day at the park.

This is exactly what Kerberos accomplishes in its implementation of Single Sign On in network environments. At the beginning of the workday, a user enters his/her password into the system once; this action decrypts a ticket from a server running as a Kerberos Key Distribution Center (KDC). The ticket holds a set of encrypted keys, which are used throughout the day to authenticate user access without exchanging sensitive password information. It expires after a given amount of time (typically one day), so even if a would-be intruder sniffs it out and decrypts the information, the user-access information remains safe in the long term.

With your Kerberos ticket you can be granted password-less access to services across a multitude of platforms. You could be on your Mac client with a valid Kerberos ticket and authenticate to a Linux VNC server, or a Mac AFP/NFS server, or a simple SSH session. The possibilities are mind blowing!

As a side note: in this article the OD master will be referred to as foo and the linux client named lame with the domain of example.bar

Open Directory and Kerberos Setup

This article assumes your are somewhat of a valid Systems Admin and were able of getting your OD environment up and running without issue. If not please read: http://www.makemacwork.com/master-open-directory-1.htm

At a real high level here are the steps:

  1. set the hostname of your OD master
  2. in Server Admin turn DNS on and setup
  3. use `dig` to verify your forward and reverse DNS records to your OD master
  4. set Open Directory in Server Admin to `Open Directory Master`
  5. start binding clients

Extra tip and trick. In Server Admin -> Open Directory, there is an option I believe under Policy->binding that says something to effect of: Require authenticated binding between Directory and Clients. Enable this, then bind your Mac clients. What it will do when binding is ask for a username and password and computer record, enter your diradmin credentials and the FQDN of the host you are binding. For example, if your domain is example.bar and your client’s hostname is foo then enter: foo.example.bar

Kerberized SSH

For the Mac use /Applications/Utilities/Directory Utility to bind your Mac to the OD master.

On the Linux / CentOS side we’re going to setup Kerberos. First install kerberos with yum
sudo yum install krb5-auth-dialog krb5-devel krb5-libs pam_krb5-2.2.14-10 krb5-workstation

Now from the Gnome GUI go to System->Administration->Authentication

  • Check, Enable LDAP Support
  • Enter your LDAP search base and server address. Mine for this example would look like:
  • If you don’t know your LDAP search base you can get it from the Overview Pane in Server Admin / Open Directory
  • Click OK on this dialog box and then select the Authentication tab
  • Check Enable Kerberos Support and click Configure Kerberos
  • The realm should be the same as your LDAP search base in a different format, mine looks like this:
  • After binding your Mac and Linux clients let’s check to make sure it works. On either client type on the terminal kinit type in your password and then check to make sure you got your Kerberos ticket with klist. You should get the following response.

    bart:~ jordan$ kinit jeunson
    Please enter the password for jeunson@EXAMPLE.BAR:
    bart:~ jordan$
    bart:~ jordan$
    bart:~ jordan$
    bart:~ jordan$ klist
    Kerberos 5 ticket cache: 'API:Initial default ccache'
    Default principal: jeunson@EXAMPLE.BAR

    Valid Starting Expires Service Principal
    05/16/10 13:30:30 05/16/10 23:29:36 krbtgt/EXAMPLE.BAR@EXAMPLE.BAR
    renew until 05/23/10 13:30:30

    The command kinit is what is used to authenticate ourselves to the Kerberos Key Distribution Center (KDC) and grant us access to all Kerberized services. It is essential to have this ticket before proceeding.

    Now that we know that Kerberos is working correctly we’re now going to setup Kerberized SSH. For your Mac and Linux clients we’re going to edit /etc/ssh_config or /etc/ssh/ssh_config depending on your Linux distro, you will want the following options set.

    GSSAPIAuthentication yes
    GSSAPIDelegateCredentials yes
    GSSAPIKeyExchange yes
    GSSAPITrustDNS yes

    For the SSH server on the Mac side set the following options: /etc/sshd_config

    GSSAPIAuthentication yes
    GSSAPICleanupCredentials yes
    GSSAPIStrictAcceptorCheck no
    GSSAPIKeyExchange yes

    KerberosAuthentication yes
    KerberosOrLocalPasswd no
    KerberosTicketCleanup yes

    For the SSH servers on the Linux side set the following options: /etc/ssh/sshd_config

    GSSAPIAuthentication yes
    GSSAPICleanupCredentials no

    KerberosAuthentication no
    KerberosOrLocalPasswd no
    KerberosTicketCleanup yes

    Restart all SSHd services and make sure you have a fresh ticket from Kerberos.

    Testing

    First make sure you have a fresh new ticket using kinit and klist. Then try to ssh from your mac client to the Linux server or Mac server. It should let you in automagically. If not run ssh in ultra verbose mode to try and debug the problem. It’s usually comes down to some sort of DNS problem so make sure the Linux server you’re connecting to has DNS records for it and they resolve properly both forwards and reverse.

    Kerberized NFS

    First, you need to setup an NFS server on your Mac server. I’m not explaining how to do that. But I will say that you NFS mounts should be set to “Any” authentication setting for testing purposes. To learn more read the Apple server manual. 😛

    DANGER!
    First ensure that the client machine has a DNS record and is resolvable both forwards and reverse and ensure that the /etc/hosts file isn’t treading on the DNS records. Also before we proceed I must make it clear that you are very careful with this section. You will be connecting to the Kerberos Key Distribution Centre that is served inside of your Open Directory server. If you accidentally break something there is a risk that you will break your installation of OD and you will have to rebuild the whole Directory.

    SSH in the linux host and check out a kerberos for the directory administrator.

    [root@lame]# kdestroy
    [root@lame]# kinit diradmin
    Password for diradmin@EXAMPLE.BAR:
    [root@lame]# klist
    Ticket cache: FILE:/tmp/krb5cc_3001_7WM4As
    Default principal: diradmin@EXAMPLE.BAR

    Valid starting Expires Service principal
    05/16/10 23:28:42 05/17/10 09:28:42 krbtgt/EXAMPLE.BAR@EXAMPLE.BAR
    renew until 05/17/10 23:27:45

    [root@lame]#

    With this ticket you can now login to the KDC server. The following command references the file /etc/krb5.conf to locate the KDC server, it is then passed the -p switch with the name of principle to use when connecting.

    /usr/kerberos/sbin/kadmin -p diradmin@EXAMPLE.BAR

    From here on in, you must be very very careful. This is the Kerberos Key Distribution Centre. We’re going to be adding three principles to the KDC; host, root and nfs. The last one, nfs, requires a special option to make it works. Please make sure to type the FQDN of the linux client.

    addprinc -randkey host/lame.example.bar@EXAMPLE.BAR
    addprinc -randkey root/lame.example.bar@EXAMPLE.BAR
    addprinc -randkey -e des-cbc-crc:normal nfs/lame.example.bar@EXAMPLE.BAR
    Now lets copy those principals out of the KDC to the local file system
    ktadd -k /etc/krb5.keytab host/lame.example.bar@EXAMPLE.BAR
    ktadd -k /etc/krb5.keytab root/lame.example.bar@EXAMPLE.BAR
    ktadd -k /etc/krb5.keytab -e des-cbc-crc:normal nfs/lame.example.bar@EXAMPLE.BAR
    quit

    Make sure this worked by reading the /etc/krb5.keytab file:


    [root@lame]# sudo klist -k /etc/krb5.keytab
    Password:
    Keytab name: FILE:/etc/krb5.keytab
    KVNO Principal
    ---- --------------------------------------------------------------------------
    4 host/lame.example.com@EXAMPLE.BAR
    4 host/lame.example.com@EXAMPLE.BAR
    4 host/lame.example.com@EXAMPLE.BAR
    4 root/lame.example.com@EXAMPLE.BAR
    4 root/lame.example.com@EXAMPLE.BAR
    4 root/lame.example.com@EXAMPLE.BAR
    4 nfs/lame.example.com@EXAMPLE.BAR
    [root@lame]#

    Now there are two daemons that need to be running to make kerberized nfs work. They are rpcgssd and rpcsvcgssd. To get this up we must edit the /etc/sysconfig/nfs file and uncomment the following lines:

    MOUNTD_NFS_V3="yes"
    SECURE_NFS="yes"

    Then start up /etc/init.d/{rpcgssd,rpcsvcgssd} restart
    Make sure to add them to the default run level

    [root@lame]# /sbin/chkconfig rpcgssd on
    [root@lame]# /sbin/chkconfig rpcsvcgssd on

    Testing

    Let’s try mounting a Kerberized NFS mount. First let’s make the folder /mnt/nfs Now issue a mount command.


    sudo mount -t nfs -o sec=krb5p foo.example.bar:/Volumes/Data/Users /mnt/nfs
    This "should" mount the NFS share on /mnt/nfs. Use the mount command again to see the krb5p option in action!
    Some lines omitted
    foo.example.bar:/Volumes/Data/Users on /Volumes/Data/Users type nfs (rw,nosuid,nodev,hard,intr,sec=krb5p,addr=10.10.10.10)

    Tada! It Works! 😀