Open Directory Replication 10.8.5 problems with Kerio Connnect 8.3.0

Posted: June 22nd, 2014 | Author: | Filed under: Kerberos, Kerio, LDAP, Mac OS X, Mac OS X Server, Mountain Lion, Open Directory | Tags: , , , , | No Comments »

kms_bubbleI recently was hired to implement an Open Directory Master/Replica into a network that wanted to leverage Kerio Connect mail server. At first, all seemed fine. I created the directory, the replica, and installed the kerio extension on both servers as was instructed by the fine folks at Kerio. Now I’d just like to say that this is different than what I remember in the days of 10.6. Back then you only had to install the OD extension on the master, the replica would then copy the schema over so that it could import the extended schema data at that time.

The problem comes into play when you have a master with already provisioned users in Kerio and you want to add an OD replica. Since the replica does not copy over the extended LDAP schema it is unable to replicate any provisioned users. The result is that those users will not exist in the replica which is bad news if you have services relying on that replica. To resolve this problem use the following procedure on the replica you wish to build:

sudo slapconfig -createreplica <master IP> diradmin

Once complete install the Kerio extention.

slapconfig -stopldapserver
slapadd -v -F /etc/openldap/slapd.d -c -l /var/db/openldap/openldap-data/backup.ldif
slapconfig -startldapserver

#gowellandinpiece
#replication


Zentyal 3.0, Mountain Lion, Kerberos and SSO

Posted: March 2nd, 2013 | Author: | Filed under: Blog, Kerberos, Mac OS X, Mountain Lion, Open Directory, Zentyal | Tags: , , , , , , | No Comments »
Now with Zentyal you can kerberize your shoes.

Now with Zentyal, you can kerberize your shoes.

This article is a continuation of a really great read by shabangs.net His article is great to bind your Macintosh to a Zentyal directory server however, after completing the how-to I was unable to change a network user’s password, store a local copy of the network user’s password for “mobility” nor leverage some great single sign on services from zentyal.

What we will attempt is to configure /etc/krb5.conf for Mac OS X 10.8, Mountain Lion, so that we will receive a TGT from zentyal when the user either logs in or wakes the computer from sleep.

First you need to get the kerberos realm. To do this sign into Zentyal and go to Users and Groups. In here you’re looking for the LDAP search base, this base will also be your Kerberos realm.

Now we want to search and replace EXAMPLE.COM with that realm, and replace your.server.example.com with the FQDN of your Zentyal server. Only set the dns_lookup_* values to true if you’re using the Zentyal server for DNS.

All edits are client side ONLY
If /etc/krb5.conf does not exist then just create it.

[libdefaults]
default_realm = EXAMPLE.COM
dns_lookup_kdc = true
dns_lookup_realm = true
default_tgs_enctypes = arcfour-hmac-md5 des-cbc-md5 dec-cbc-crc
default_tkt_enctypes = arcfour-hmac-md5 des-cbc-md5 dec-cbc-crc
preferred_enctypes = arcfour-hmac-md5 des-cbc-md5 dec-cbc-crc

[realms]
EXAMPLE.COM = {
admin_server = your.server.example.com
kdc = your.server.example.com
kpasswd = your.server.example.com
}

[kadmin]
default_keys = des-cbc-crc:pw-salt des-cbc-md5:pw-salt arcfour-hmac-md5:pw-salt aes256-cts-hmac-sha1-96:pw-salt aes128-cts-hmac-sha1-96:pw-salt

In order to obtain a Ticket Granting Ticket (TGT) when logging in via the login window, edit /etc/pam.d/authorization and append default_principal option to the pam_krb5.so line.


auth optional pam_krb5.so use_first_pass use_kcminit default_principal

In order to obtain a Ticket Granting Ticket (TGT) when authenticating to the Screen Saver, edit /etc/pam.d/screensaver and append default_principal option to the pam_krb5.so line.


auth optional pam_krb5.so use_first_pass use_kcminit default_principal

Now sign out and back in as a network user, open a terminal and type klist You should get something like:


lisa:~ test$ klist
Credentials cache: API:51104:6
Principal: test@EXAMPLE.COM

Issued Expires Principal
Mar 2 09:28:04 Mar 2 19:28:04 krbtgt/EXAMPLE.COM@EXAMPLE.COM

If so, great! This means kerberos is running, now try to change the user’s Open Directory password. It should succeed as well. If not make sure you have the console open to see what’s going on. 99% of the time it’s a DNS issue or the clocks on your workstation is out of sync with Zentyal.

Now try to mount an SMB volume from the Zentyal server, it *should* mount without credentials and a new ticket will appear in the output of klist


Issued Expires Principal
Mar 2 09:34:52 Mar 2 19:34:48 krbtgt/EXAMPLE.COM@EXAMPLE.COM
Mar 2 09:34:56 Mar 2 19:34:48 cifs/your.server.example.com@EXAMPLE.COM


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


Apple Magic Triangle Deployment Results

Posted: October 15th, 2010 | Author: | Filed under: Active Directory, DNS, Kerberos, LDAP, Mac OS X Server, Migrate, Snow Leopard | Tags: , , , , , , , | No Comments »

This is a follow up to my last blog entry: Magic Triangle Setup with Windows File Server backed Portable Home Directories. Myself and a team of amazing people deployed the Magic Triangle solution in an architectural firm that recently was involved in a merger and needed to be brought into one unified “domain.” I place that word in quotations after some disagreements and long discussions with AD administrators as to the default definition of the word. Before we begin let’s just go over our Magic Triangle deployment and the roles of our servers.

  • vandc01.tld.ca is the local AD domain controller.
  • vanfile.tld.ca is the Windows based file server for all network home directories
  • od01.tld.ca is the Open Directory server which was also bound to AD
  • od02.tld.ca is the OD replica and netboot server for Deploy Studio
  • For all intensive purposes, the migration went fairly smoothly. The client was quite happy with the result, although the users of the network do not have as fast of a desktop environment as they did with a pure Macintosh network. The final outcome was Mac clients bound to both AD and OD. AD handled all the user and group authentication and authorization while OD took care of computer and group client management through MCX. I put a standard computer heirarchy in place on the OD side for computer group so different settings could be applied to different sets of computers. Such as, making all laptops automatically create portable home directories and install the HomeSync menu in the top menu bar. However, there was one very strange problem I encountered while binding the Macintosh clients to the Open Directory server.

    Normally, when you set “Require authenticated binding between directory and clients” to on in Server Admin the Mac client will prompt you for directory administrator credentials when binding a client. However, this was not happening for us. We were using 10.6.4 server and client everywhere, yet the clients were just not asking for authentication. Thus, a computer record was not being generated on the server side. What I did for the first few test cases was create computer records manually inside of Workgroup Manager, but this was not fun and tedious.

    Update: One of my readers, JJ, pointed out a great kb article from Apple on how to require directory authentication while binding. http://support.apple.com/kb/HT4068 End of Update

    I whipped up a quick AppleScript to bind the clients for me, this script had the diradmin login and pass embedded in it which I know is not best practice yet it was a temporary fix. The reason for using the script is so that the command line utility dsconfigldap is passed the ‘-f’ flag which forces the client to authenticate to the directory server.

    The script is as follows:


    tell application "Terminal"
    do shell script "dsconfigldap -u diradmin -p 'diradminpass' -f -a od01.tld.ca -c `hostname` -n od01.tld.ca -l localsudouser -q localsudopass -v > /Users/Shared/odbind.log" with administrator privileges
    do shell script "echo 'Writing Search policy to plists' >> /Users/Shared/odbind.log" with administrator privileges
    do shell script "defaults write /Library/Preferences/DirectoryService/SearchNodeConfig 'Search Node Custom Path Array' -array '/LDAPv3/od01.tld.ca'" with administrator privileges
    do shell script "defaults write /Library/Preferences/DirectoryService/SearchNodeConfig 'Search Policy' -int 3" with administrator privileges
    do shell script "defaults write /Library/Preferences/DirectoryService/ContactsNodeConfig 'Search Node Custom Path Array' -array '/LDAPv3/od01.tld.ca'" with administrator privileges
    do shell script "defaults write /Library/Preferences/DirectoryService/ContactsNodeConfig 'Search Policy' -int 3" with administrator privileges
    do shell script "echo 'Successfully added the Open Directory server to your search path' >> /Users/Shared/odbind.log" with administrator privileges
    do shell script "echo 'Writing LDAP in your search paths' >> /Users/Shared/odbind.log" with administrator privileges
    do shell script "dscl /Search -append / CSPSearchPath /LDAPv3/od01.tld.ca" with administrator privileges
    do shell script "dscl /Search/Contacts -append / CSPSearchPath /LDAPv3/od01.tld.ca" with administrator privileges
    end tell
    tell application "Finder"
    activate
    display dialog "Computer is now bound to Open Directory as " & (do shell script "hostname")
    end tell

    File Migration from Apple Filer to Windows Filer

    This was one of the more challenging issues at hand. We had a whole bunch of OD user’s home folders on two Apple XRAIDs served out via AFP and needed to move the data to the Windows Filer using SMB. What we ended up doing is creating an LACP link to a MacPro and using the following script to migrate the users one by one.

    syncit.sh is a shell script that mounts two network homes for one user, one from AD and one from OD. It then transfers all data from OD to AD via rsync. To make this script work it depends on a couple things.

  • The users to be migrated are entered into a file called ‘users’ with NO extension in the following format
    1. oduser:aduser
      oduser:aduser
      oduser:aduser
      oduser:aduser
      oduser:aduser
  • When the script executes it will create the folder /Users/Shared/syncit_logs and two log files for each user. username.log username.err. The .log is all the stdout of rsync while .err is all the errors.
  • And finally when you download the script you’ll need to edit the variables at the top of the script with the FQDN’s for you file servers and shares.

    You can get the script here.

    Caveats

    Home Directory Ghost Mount
    One issue that we’ve seen appear more than once is home directory ghost mounting. When a user logs out of their profile sometimes their home directory does not unmount cleanly. As a result when the user tries to log in again on the same workstation they are unable to due to the computer believing the home directory is already mounted. This may also affect logins of the same user account to other workstations due to the home directory filer not timing out the mount session.

    Slow Network File System Access
    There have been at times severe client stalls due to slow file system access. This was noticed on literally zero network traffic congestion. This is a noted issue from many different implementations of using SMB shares for Mac home directories. Read http://www.macwindows.com/snowleopard-filesharing.html#091709k for more information. One suggested solution is to turn on Internet Sharing on the Mac client, however this is not a wise idea.

    Portable Home Directory Will Not Sync
    Sometimes homesync will become cranky. Definitely cranky. The easier and fastest way to resolve a home directory that does not sync is to perform the following.

  • Erase the contents of the users’s ~/.FileSync and ~/Library/FileSync directories.
  • Manually mount the user’s network home directory and erase the same directories on the server
  • Try the sync process again. Note: It will take longer to catalog the file system.
  • For most HomeSync problems it usually has something to do with file conflict resolution. To find out always open Console.app and look at FileSyncAgent.log. Try to perform a FileSync and watch the output of the log. If you are having problems with an initial sync try erasing the login.keychain file found in ~/Library/KeyChains on both server and client. Many times this will cause problems due to The Chicken and The Egg issues.

    Illegal Characters in File Names
    “ ‘/ \ + * ( ) [ ] are all illegal characters for file names on the Windows File Servers, as are directories or files that end in a space. As a result you may have issues creating working with these files. The Windows file server use unicode to map these characters, however there are failures often. Resolution is done by manually replacing filenames. This is also a LARGE contributor to File Sync failing.

    Summary

    Like I mentioned at the beginning everything went quite smoothly. There were of course strange things that happened through out the deployment, and the short one week runway I had to prep for this was WAY too short but in the end we pulled it off. If any of you out there are planning on deployment or need questions answer feel free to contact me via the About Me button at the top of blog!

    Update: Please check out my next post regarding HomeSync errors on an SMB server.

    Update 2: One of my readers, JJ, pointed out a great kb article from Apple on how to require directory authentication while binding. http://support.apple.com/kb/HT4068


    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! 😀