Keep External Drives Mounted in OS X when logged out

This tip was graciously donated by my good friend Luis Giraldo from Fully Managed
Create:
/Library/Preferences/SystemConfiguration/autodiskmount.plist
Put the following contents in the plist file:

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<plist version="1.0">

<dict>

<key>AutomountDisksWithoutUserLogin</key>

<true/>

</dict>

</plist>

Magic Triangle, Snow Leopard Server, Lion Clients

Just tried to bind a Lion client to our Magic Triangle infrastructure. Apple describes the problems as: A Mac OS X v10.7 Lion client may be unable to connect to a Mac OS X v10.6 Open Directory Server. This can happen if Lion uses Authenticated Binding to a Mac OS X v10.6 Open Directory Server that is also bound to Active Directory by means of a magic triangle.

Apple’s fix is to use Terminal to run a pair of shell commands on the Snow Leopard Server Open Directory Master Server and Replicas. Apple says:

Note: These commands will turn off GSSAPI authentication for the LDAP Server on the Mac OS X v10.6 Open Directory Master Server and Replicas. The servers will then use CRAM-MD5 authentication.

sudo rm /usr/lib/sasl2/openldap/libgssapiv2.2.so
sudo rm /usr/lib/sasl2/openldap/libgssapiv2.la

Restart the server after making this change.

If you want to restore the original settings, execute these commands:

cd /usr/lib/sasl2/openldap
sudo ln -s ../libgssapiv2.2.so
sudo ln -s ../libgssapiv2.la

Restart the server after making this change.

How to Force Propagation on Apple Secondary DNS Server

As you all probably know that using Apple’s DNS server can be challenging at times. If you make changes on the primary you usually have to wait some time before those changes propagate to the secondaries. However with the following commands you can force this propagation without having to nuke files or folders in /var/named

1. On the secondary server, run this command. (use whatever zone you want to transfer in place of lan.example.com
rndc -p 54 retransfer lan.example.com IN com.apple.ServerAdmin.DNS.public

2. Reload configuration
rndc -p 54 reload

3. Forcing client cache flush
dscacheutil -flushcache

The reason I think this is better in my opinion is it gets rid of the potential “oops” of deleting critical files in /var/named.

Snow Leopard SSL Certificate Authority

As more services are introduced into your network and thus the more users you have, the need for security goes up. Maintaining your own certificate authority is a simple and free way to ensure the highest level of security while not breaking the bank.

1. Create the Certificate Authority

First we’re going to hop into a terminal on any Mac OS X Server box and navigate to `/etc/certificates` and create some directories

cd /etc/certificates/
sudo mkdir -p myCA/cert myCA/key
cd myCA


We need to create the CA signing certificate and key. After executing the first command you will be asked a series of questions. Enter them as needed.


homer:myCA jordan$ sudo openssl req -new -x509 -keyout key/myca.key -out cert/myca.crt -days 3650
Generating a 1024 bit RSA private key
.....++++++
............................................................++++++
writing new private key to 'key/myca.key'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:CA
State or Province Name (full name) [Some-State]:BC
Locality Name (eg, city) []:Vancouver
Organization Name (eg, company) [Internet Widgits Pty Ltd]:YAweb2.0CA LTD
Organizational Unit Name (eg, section) []:DevOps
Common Name (eg, YOUR name) []:yaweb20ca.ca
Email Address []:systems@yaweb20ca.ca


Two files are created:


chmod 0400 /etc/certificates/myCA/key/myca.key


2. Create the Server Key

Next, go up one level to `/etc/certificates` We can now start creating SSL certificates for our various servers and services. Create a directory named hostname.domainname corresponding to the hostname for the computer or service you are creating the certificate for and enter the directory.

Next up on the list is to create a key that corresponds to our server. We will do that with this command:

openssl genrsa -des3 -out hostname.domainname.key 4096

Again, those pass phrases are something you make up right then. You are not authenticating anything, but rather setting up a pass phrase for authenticating later. Don’t forget to store the password somewhere safe, I suggest creating a new keychain on your Mac OS X server box.

Now, we have to create a signing request, or CSR, from the server key we just made. This signing request will usually make a trip to a genuine Certificate Authority to have the key signed and a real, verified, bonafide signed certificate returned back to us. So, to generate our signed certificate, we’ll need to first have a signing request so we can make the signed cert. See how that works?

3. Create a Certificate Signing Request

To create the CSR, we do this:

openssl req -new -key hostname.domainname.key -out hostname.domainname.csr

Now remember, kids. This is the part where we do put in our actual real information because the server does in fact belong to us. Put in the real domain where it says “Common Name (eg, YOUR name) []:”. Fill out everything correctly. So for a wildcard cert enter, *.top.level.domain

4. Sign the Certificate

Now, we are going to take all these files and make them do some voodoo. We are going to sign the signing request using the Certificate Authority certificate and key that we made at the beginning. What we will get is our perfectly forged signed certificate. OK, not perfectly, because we are not a real CA. But we’ll get a pretty darn good signed cert that will work for us rather nicely and be valid for 10 years! What value!

The command we’re going to run looks like this:

openssl x509 -req -days 3650 -in hostname..csr -CA ../myCA/myCA.crt -CAkey ../myCA/myCA.key -set_serial XX -out hostname.domainname.crt

It will ask you for the password for the myCA.key file. Which is referenced at the top of this article. The set_serial switch is a two digit value to denote the certificate serial number. Every certificate you sign from this CA must have a unique serial number.

5. Create a Passwordless Certificate

Now, we have a little problem. Our hostname.key file will cause apache2 to prompt us for a password every time it starts. We need to fix it so that doesn’t happen. We’ll do that with these three commands:

openssl rsa -in .domainname.key -out .domainname.key.insecure
* Enter the password that you entered when creating this key
mv hostname..key hostname.domainname.key.secure
mv hostname.domainname.key.insecure hostname.domainname.key


Then set permissions for the files

chmod 0600 hostname.key.secure hostname.key hostname.csr hostname.crt


6. Outcome

The final list of files and their purpose is as follows:

drwxr-xr-x 2 root root 4096 2008-06-02 13:54 .
drwx------ 10 root root 4096 2008-06-02 13:35 ..
-rw-r--r-- 1 root root 2049 2009-04-02 13:32 hostname.tld.crt [our server certificate]
-rw-r--r-- 1 root root 1748 2009-04-02 13:23 hostname.tld.csr [our server signing request]
-rw-r--r-- 1 root root 3243 2009-04-02 13:54 hostname.tld.key [our password-less server key]
-rw-r--r-- 1 root root 3311 2009-04-02 13:13 hostname.tld.key.secure [our passworded server key]


7. Don’t Forget

Don’t forget to load the myCA.crt file into your various Mac clients. This will allow the computer to verify the identity of the SSL certificates to the end user, mitigating the risk of a MITM (man in the middle) attack. To do so simply copy the file to all your workstations and double click the cert. Keychain manager should load and ask what security setting you would like, select Always Trust.

Resolving HomeSync Errors on SMB

This is a follow up post in regards to my previous update: http://jordaneunson.com/2010/10/apple-magic-triangle-deployment-results/

A client of mine is being plagued with HomeSync errors on a Windows backed file server. One user in particular had over 2,000 file sync conflict issues, two others had around 70. After investigating the logs I believe I have an explanation as to why HomeSync is failing. To understand my theory I’m going to explain a bit about permissions on the Mac side.

When any Mac users logs into the desktop their home is mounted from the server into a “magic” folder. I say “magic” because technically it’s not a folder, it’s a program. The directory “/Network/Servers” is an auto mount program, if you enter this directory on the command line or in the GUI and specify a sub directory, such as “/Network/Servers/filer.DOMAIN.com” the computer will try to contact filer.DOMAIN.com over AFP, NFS, and SMB, to get a share listing and then display that listing as subfolder to the FQDN. For our example we would receive the following folder listing as user1:

vaW80401YGAGZ:filer.DOMAIN.com user1$ ls -al /Network/Servers/filer.DOMAIN.com
total 36
drwx—— 1 user1 wheel 16384 26 Oct 15:17 Homes
vaW80401YGAGZ:filer.DOMAIN.com user1$

We see here that there is only one entry “Homes” but notice the owner and group. The owner seems fine, user1, however the group is “wheel” Wheel is a local group on every Macintosh that is more or less a system group. The share is mounted as group wheel because the mounting program runs as “wheel” Thus all the directories inside of user1’s home folder also have the group “wheel”

Let’s compare group owner to what is assigned when we mount the share manually:

vaW80401YGAGZ:Volumes user1$ ls -al /Volumes
total 72
drwxrwxrwt@ 9 root admin 306 26 Oct 22:11 .
drwxrwxr-t 30 root admin 1088 26 Oct 13:14 ..
drwx—— 191 user1 DOMAIN\domain users 6450 21 Oct 11:05 CurrentProjects
drwx—— 1 user1 DOMAIN\domain users 16384 26 Oct 15:17 Homes
drwx—— 1 user1 DOMAIN\domain users 16384 26 Oct 15:36 Production
drwx—— 31 user1 DOMAIN\domain users 1010 15 Oct 14:11 Promo
drwx—— 41 user1 DOMAIN\domain users 1350 26 Oct 20:53 SCANS
lrwxr-xr-x 1 root admin 1 26 Oct 13:13 Workstation -> /
drwx—— 23 user1 DOMAIN\domain users 738 26 Oct 15:26 joost

See that? The group is different! The mac mounts the directory as the proper default group “DOMAIN/domain users” for the user user1. I know this is the default group for user1 by asking the AD server details about the user1 user:

vaW80401YGAGZ:Volumes user1$ id user1
uid=421864987(user1) gid=1278872894(DOMAIN\domain users) etc……

Now that we understand a little about permission sets in the Mac world I’ll explain my theory.

When I a HomeSync user authenticates for the first time the Mac must mount their home directory in /Network/Servers and thus the group owner is set to “wheel.” The contents of the users home directory is then copied to “/Users/” for our continued example it would be /Users/user1. Here’s the kicker: when the Mac wants to do any HomeSync after the initial is complete, it does not mount the user’s home directory to /Network/Servers. Instead the Mac mounts the home directory to /Volumes like a standard manual mount. Therefore the group ownership in the user’s local home folder DOES NOT match the group ownership of the user’s server side home folder. Thus, HomeSync tries to update the server side’s group ownership to the group “wheel.” This is usually when all the errors start spewing out of HomeSync because the Windows server has no record in Active Directory of the group “wheel”

I then went on to test my theory. I changed the group ownership for three separate user’s LOCAL home folders from “wheel” to “DOMAIN/domain users” For one user this resolved 68 of 70 HomeSync errors. For two others it resolved all of them.

There are other problems regarding HomeSync that are not included in this above mentioned theory such as illegal characters. For one example, Parallels is installing files into ~/Applications that have the { } characters in them. This is causing more problems to the HomeSync users. I have excluded this directory from synchronizing, however there are more HomeSync issues because of these illegal characters.

Apple Magic Triangle Deployment Results

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.

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.

oduser:aduser

oduser:aduser

oduser:aduser

oduser:aduser

oduser:aduser

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

Apple Magic Triangle Setup with Windows File Server backed Portable Home Directories.

Recently I was hired to give my opinion about merging an existing Macintosh Open Directory(OD) network into a Windows Active Directory(AD) network. This was being done because Company A merged with Company B, and Company B being more powerful and larger wanted to stay with their AD infrastructure. My opinion was to move to a “Magic Triangle” setup where an OD server is bound to an AD Domain Controller(DC). The users and groups are managed by Active Directory, however the Mac clients are bound to both AD and OD for the purpose of being able to hand out MCX records to users, groups, and computers. I wrote this how to because no matter how much documentation I read I have not been able to find some of the key pieces of information I needed to accomplish this goal. On a side note, I would like to give a big hello to Alper Bac, current Systems Administrator of Cohos Evamy for his invaluable help in solving some of the AD configuration issues we were having.

On the Mac Server 10.6

Step 1: Check the Active Directory configuration.
Make sure your Active Directory server and its DNS service is properly configured and running.

Step 2: Turn on Open Directory service.
Use Server Admin to turn the Open Directory service on. After the service is turned on you can configure Open Directory service settings.

Step 3: Ensure the computer is a standalone directory service.

Step 4: Connect to Active Directory.

• Go to Server Admin, Open Directory.
• Click Settings button at top, then the General tab. The window should report that its role is “Standalone Directory.” If this is correct you can now click change, otherwise go to Step 3.
• In the pop-up dialogue choose “Connect to another Directory”
• Then Continue, and click “Open Directory Utility”
• The Directory Utility application will appear. If it is locked please unlock it.
• Ensure that active directory is uncheck
• Double click “Active Directory”
• Type in your domain and expand the arrow beside “Show Advanced Options”
• Ensure that “Create mobile account at login” and “Force Local home directory on startup disk” is uncheck. Then click OK
• Quit Directory Utility
• Back in the Open Directory Wizard box click Done
• Open System Preferences and go to Accounts
• Click on Login Options and Click “Join”
• Type the name of Active Directory Domain Controller (DC) in where it says “Server:” as well as the AD Admin user/password credentials in the appropriate boxes. Also give the computer an record name. This name will be the record that is created in Active Directory.
• Once joined the Mac will ask about Kerberos. Just ignore this for now.

Step 5: Set up an Open Directory master.

• Go to Server Admin, Open Directory
• Click Settings button at top, then the General tab. The window should report that its role is “Connected to another directory” If this is correct you can now click change, otherwise go to Step 4.
• Choose the first option “Remain connected and set up an Open Directory Master”
• If it complains about Kerberos just ignore this again.
• Setup the diradmin account. Give it a secure password as this is our Directory Administrator account.
• Now type in a relevant LDAP Search Base. If you don’t know what should go here just click continue. However if you don’t know what goes here yet you’re trying to integrate a Mac into AD I must say that you may be in over your head. 😉
• Confirm your settings and click continue.
• Now in Server Admin we want to set a policy under Open Directory. So click on Policies tab and then Bindings subtab and enable the “Require authenticated binding….” check box.

Step 6: Disable Kerberos on Open Directory master.
Disable Kerberos on your Open Directory Master server to avoid conflicts with your Active Directory Kerberos realm. In a terminal type: (use the diradmin credentials)
sudo sso_util remove -k -a username -p password -r NAME. OF.KERBEROSREALM

Step 7: Kerberize services.
Kerberize your Open Directory server services with the Kerberos realm of your Active Directory server, in a terminal type:
sudo dsconfigad -enablesso

On the Windows Server 2003

What we need to do is assign a home folder to an existing user account. So let’s grab the user account “Test” and map a home folder to it.

• Go to Start, Administrative Tool, Active Directory Users and Computers
• Right click domain name and search for users
• Open Properties and then profile tab
• Click the “home folder” radio button and select an unused drive letter. For our example it will be “Z:” and then enter beside it the Windows File server fqdn in this format. \\fqdn\share\username
• Once you accept Windows will go and create this folder and assign all the appropriate ACLs

On the Mac Client 10.5

What we need to do on the Mac client is bind it to both AD and OD.

Active Directory

• Login as a the local admin user
• Open Applications/Utilities/Directory Utility.app
• Click on “Services” and then double click “Active Directory”
• Expand the Show Advanced Options arrow and disable “Force local home directory on startup disk”
• Now click on “Directory Servers” and click on “+”
• From the drop down select “Active Directory” and type the name of the DC
• Enter the computer ID and AD username/password and click join.
• If this fails then try clicking on Services and double click on Active Directory
• Type in the domain and client ID here and click “Bind”

Open Directory

• Open Applications/Utilities/Directory Utility.app
• Click “+” and select “Open Directory” from the drop down menu
• Type in the name of the ODM
• The computer should ask you for the OD diradmin password and client ID. Type in the same ID as you did for the Windows box (for consistency’s sake)

Now you should have two directory servers listed in the Directory Utility both with green lights.

You should now have a working Magic Triangle. The user and group accounts come from Active Directory and their home folders come from a Windows back File Server. We can now use WGM to introduce things like Portable Home Directories and MCX records. Yay!

Portable Home Directories

• Open WGM (WorkGroup Manager) and authenticate as diradmin
• Create a new group called “Mobility” we’re going to use this group to designate PHD users.
• Under the members tab click on the Plus sign, a side bar should appear.
• At the top of the side bar will be a text string like “Directory: /LDAPv3/127.0.0.1” click on this and change it to “/Active Directory/All Domains”
• Wait up to a couple minutes and you will start to see users from Active Directory appears. You can drag these users into the members pane of WGM. AFAIK you can also embed AD groups although I’ve never tried this.
• Now we have an OD group with an AD user member as well as a computer record from the mac client.
• Let’s click on Preferences for the mobility group and then click on “Mobility” under Overview tab.
• Under account creation tab click on “Always” and check “Create mobile account when user logs into network account” a
• Then click on rules tab and select always for all three subtabs yet leave their default values. Except for checking on “Show status in menu bar” under “options” sub tab
• Now try logging in with your AD account again and watch as the mac creates you a PHD and enables the HomeSync menu.

If you have problems with this process then feel free to leave a comment with some contact info and I’ll try to get back to you and help. I’ll have another post coming up for you Windows Sysadmins on how to easily managed your mac clients with Group Policy. If you would like me to help you directly then please refer to my company website and use our contact form.

Update: Please check out next post regarding the deployment of this solution: http://jordaneunson.com/2010/10/apple-magic-triangle-deployment-results/

Update #2:I had a reader have trouble with this above procedure, we communicated for a while about his setup here: http://www.edugeek.net/forums/mac/72958-magic-triangle-permissions.html

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

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

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

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

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

---

Using Network Accounts on a Linux Client with Open Directory Leopard Server

I have two linux machines at home and I want to be able to use my network home directory and network account from my Leopard Open Directory server. One is running Ubuntu 9.10 and the other OpenSuSE 11.2. Here’s what I had to do:

In this post I assume you already have an Open Directory environment and network based user accounts as well as AFP homes setup. In other words, a working Open Directory setup with bound AND working Mac clients.

Exporting User Home Directories with NFS

First we want to make sure that the home directories are being exported via NFS. Open Server Admin and connect to your OD master. At the top of Server Admin click on File Sharing and then your AFP home folder volume. Click on File Sharing up at the top and select your AFP home volume. The click on the “Share Point” button in the bottom pane and then “Protocol Options” (Note: if “Enable Automount” is not checked you either have the wrong volume selected or your configuration is incorrect)

In the Protocol Options drop down select the NFS tab and select a means by which to export the NFS share. I would recommend using subnet and if you know what you’re doing select a minimum security of “Kerberos v5 with data integrity and privacy” however you should only select this if you REALLY know what you’re doing. I will make a walk through for this at a later date. If you don’t know Kerberos like the back of your hand then I would select “Any” for now. Check Allow Subdirectory Mounting. Click OK and you’re done.

Ubuntu 9.10 Authentication

On the Ubuntu Linux client first install the necessary packages:

sudo apt-get install libpam-ldap libnss-ldap nss-updatedb libnss-db nfs-common nscd

In the following wizard just accept the default answers, they should be correct. Then edit /etc/ldap.conf and make it sure it contains the following lines. Note this is not a verbatim output of /etc/ldap.conf


host 192.168.1.1 # this should be the IP of your OD server or better yet service based CNAME record
base dc=example,dc=com # this is of course the ldap search base configured in the OD server
bind_policy soft


Now edit /etc/ldap/ldap.conf

BASE dc=example,dc=com
URI ldap://example.com

protocols: db files
services: db files
ethers: db files
rpc: db files


openSuSE 11.2 Authentication

On the command line start yast

Navigate to Network Services and then LDAP client type in your LDAP server IP and search domain, unclick TLS and bam you’re done. God I love Novell 😉

Ubuntu 9.10 & openSuSE 11.2 Automount

Create the directory /Network/Servers then all that is needed is to create the following line in /etc/auto.master

/Network/Servers /etc/auto.net

Restart autofs

sudo /etc/init.d/autofs restart

After this you should be able to log in and access your home folder.