Configuring OD/AD Kerberos with a Disjoined Namespace

I just surfaced out of a situation with a Mac Server connected to ADwith Kerberos Authentication.  Much help was received from Apple and I was given permission to share the "fix" for anyone else out thereattempting this type of solution.  
The problem was the server name in AD and the DNS name were different(Disjointed Namespace).  This is because our external domain name[server.outside.org] differs from the AD domain [ad.inside.org] and theAD domain is not available on the internet.  Since this server isavailable to the outside world, we could not use the AD name.  TheActive Directory Plug-in cannot reconcile this difference.

Read on for more….

First step, to make changes in the AD DNS ( DNS server ) to resolve theOS X Server's hostname forward and reverse. To check this type "hosthostname" and "host ip" to make sure everything resolves. Only one nameshould be returned for the reverse lookup.

Second step, setting the OS X server's DNS name to reflect the DNSchanges in the first step. You should unbind the server from AD beforeyou go through making the hostname changes. Type "sudo changeip-checkhostname" . If the "current hostname" and "DNS hostname" do notmatch you'll need to run "sudo changeip <node> oldipaddressnewipaddress olddnsname newdnsname" . The syntax will be provided if"changeip -checkhostname doesn't match". Restart the server afterrunning changeip.

Third step, binding the server to Active Directory to create(principals). First remove any keytab that has been created. On the OSX Server type "sudo rm -r /etc/krb5.keytab". To make sure you haveremoved the keytab type "sudo klist -k", you should see a "klist: Nosuch file or directory.." error. At this point you have corrected DNS,Unbound from AD and Deleted the keytab file. We are now ready to bindto AD. Open Directory utility and make sure the "Computer ID:" fieldmatches the first part of your hostname, for example if your hostnameis imac.adserver.lan the "Computer ID:" field should have "imac" in it.The reason for this is due to the fact that the AD plugin createsprincipals using the "Computer ID:" name and prepends it to the addomain. You'll end up with principals on the AD Server-side and OS XServer-side that look like "[email protected]".
Fourth Step, go ahead and promote the server to an Open DirectoryMaster.  After you have bound to AD we need to make the principalsmatch.

Fifth Step, getting the correct principals on the OS X Server-side.After performing the above steps type "sudo klist -k". You will seeservice principals created in the format mentioned above. We would likethe principals to match DNS. For instance it should be formatted likethis "afpserver/[email protected]". To correct this youwill need to use ktutil to show the encryption key for each principaland encryption type and then use ktutil to create a new keytab withcorrect principal names.  First, output using "sudo klist -k -t -K -e":

sudo klist -k -t -K -e
Keytab name: FILE:/etc/krb5.keytab
KVNO Timestamp         Principal
—- —————– ——————————————————–
   2 10/01/08 20:22:10 afpserver/[email protected] (ArcFour with HMAC/md5)  (0x4a8747ec32b0fcc01efa7a7838440565)
   2 10/01/08 20:22:10 afpserver/[email protected] (DES cbc mode with CRC-32)  (0xf8bcef4afb203bf2)
   2 10/01/08 20:22:10 afpserver/[email protected] (DES cbc mode with RSA-MD5)  (0xf8bcef4afb203bf2)
   2 10/01/08 20:22:10 ftp/[email protected] (ArcFour with HMAC/md5)  (0x4a8747ec32b0fcc01efa7a7838440565)
   2 10/01/08 20:22:10 ftp/[email protected]  (DES cbc mode with CRC-32)  (0x80e0f179b3d3910d)
   2 10/01/08 20:22:10 ftp/[email protected] (DES cbc mode with RSA-MD5)  (0x80e0f179b3d3910d)
…

Note the hex value at the end.  This is the encrypted key.  Go intoktutil and start creating a keytab that uses the correct serviceprincipal name ("[email protected]", not"[email protected]").  For the encyption types, use"des-cbc-crc" for "DES cbc mode with CRC-32", "des-cbc-md5" for DES cbcmode with RSA-MD5, and "arcfour-hmac-md5" for ArcFour with HMAC/md5. Also, make sure you use the correct "KVNO" for "-k <value>" showin the klist output above (under KVNO).  This is the key value number,and is used to see if the KDC and the server have the correct version. If not, access will be denied.

xs2:~ root# ktutil

ktutil:  addent -key -p afpserver/[email protected] -k 2 -e des-cbc-md5
Key for afpserver/[email protected] (hex): f8bcef4afb203bf2

ktutil:  addent -key -p afpserver/[email protected] -k 2 -e arcfour-hmac-md5
Key for afpserver/[email protected] (hex): 4a8747ec32b0fcc01efa7a7838440565

ktutil:  addent -key -p afpserver/[email protected] -k 2 -e des-cbc-crc
Key for afpserver/[email protected] (hex): f8bcef4afb203bf2

Do this for all the principals that showed up in the klist -ke from thekeytab above.  Be sure to include the machine accounts too("xserve$@AD.INSIDE.ORG").  Do a listing to check that you have themcorrect:
ktutil:  l
slot KVNO Principal
—- —- ———————————————————————
   1    2 afpserver/[email protected]
   2    2 afpserver/[email protected]
   3    2 afpserver/[email protected]
…

Write out the keytab to a temporary location and quit:

ktutil:  wkt /tmp/newkeytab.keytab
ktutil:  q

Check to make sure it looks like you want (has a different server name from the REALM name):

xs2:~ root# klist -ke /tmp/newkeytab.keytab
Keytab name: FILE:/tmp/newkeytab.keytab
KVNO Principal
—- ————————————————————————–
   2 afpserver/[email protected] (DES cbc mode with RSA-MD5)
   2 afpserver/[email protected] (ArcFour with HMAC/md5)
   2 afpserver/[email protected] (DES cbc mode with CRC-32)
…

Then backup your copy of /etc/krb5.keytab, and move the new keytab intoits place.  Make sure that it is owned and read/write for user root andreadable only for group _keytabusers and no access for others.

Note:  This is a great opportunity for someone to write a script to do this for you.  

After repairing the klist type "sudo klist -k" to verify that yourprincipals now look like "cifs/[email protected]". Onceyou have done this you need to enter the correct principals on the ADServer-side.

Sixth Step, adding the correct principals on the AD Server-side.  Sincewe would like to use the DNS name we need to edit the principals inActive Directory to have the correct hostname. Instead of"cifs/computerid.ad.domain" the principal should read"cifs/hostname.of.OS.X.Server". To accomplish this adsiedit needs to beused to add the correct principals. Information on adsiedit can befound here http://technet.microsoft.com/en-us/library/cc773354.aspx.Once adsiedit is installed use the following steps to modify theprincipals:

1. On the domain controller click "Start" and then "run".
2. In the run dialog type "adsiedit.msc" and press "OK"
3. In the ADSI Edit window locate "Domain" and click the "plus" sign to expand it.
4. Click the plus to expand "DC=ad,DC=domain,DC=com"
5. Locate the "CN=Computers" object and select it.  ( if you store computer records in another object modify steps accordingly).
6. On the right side locate the computer name you wish to changeprincipals for, it should look like "CN=computerID". Right-click on thecomputer name and click properties.
7. In the "Properties" window for the machine click the "Show only attributes that have values" checkbox.
8. Scroll down and find the "servicePrincipalName" attribute. Highlight the attribute and click the edit button.
9. Note down all of the principals, take a screenshot or write them down.
10. You will be removing each principal and changing just the DNSportion of it. There should be something like 15 principals. You'llnotice the DNS portion of the principal looks like"computerid.ad.domain". We simply want this to read"hostname.of.OS.X.Server". For example we'll use the cifs principal.You'll see "cifs/computerid.ad.domain" we want to remove that principaland replace it with "cifs/hostname.of.OS.X.Server". This way we matchthe DNS name you want for the Mac OS X 10.5.x Server. Do this for eachprincipal. After you are done click ok and then select  the"servicePrincipalName" attribute again to verify the changes took.After you verified the changes click OK, and then Apply.
11. You can exit ADSI Edit
12. Open the command prompt on the Domain Controller and execute"setspn -l computerID" . You should see all of the principals you havemodified. If any of them don't match our changes then repeat the abovesteps. To get output of "setspn -l computer-name" .  Information on thesetspn command can be foundhere http://technet.microsoft.com/en-us/library/cc773257.aspx . Onceyou have verified the changes we are ready to test kerberos.

You may have to set the service principal for AFP as well:

serveradmin settings afp:kerberosPrincipal = "afpserver/[email protected]"

and then stop and start AFP.

You also may need to map the external domain to the correct domain in the edu.mit.kerberos file on each of the client:

# WARNING This file is automatically created, if you wish to make changes
# delete the next two lines
[libdefaults]
    dns_fallback = no
    default_realm = AD.INSIDE.ORG
[domain_realm]
    .outside.org = AD.INSIDE.ORG
    .baranaba.com = AD.INSIDE.ORG
[logging]
    admin_server = FILE:/var/log/krb5kdc/kadmin.log
    kdc = FILE:/var/log/krb5kdc/kdc.log

If the machine account password changes (and it does by default every14 days), it will invalidate your changes and you'll have to recreatethe keytab (and update the KVNO by 1) on the Mac OS X server.  The ADplugin will only update the principals with the incorrect DNS name. You can get around this by setting the time that the password changeswith "dsconfigad -passinterval", but if your AD infrastructure requires you to cycle you machine account password, you may find that yourserver is locked out of AD after a while.  You can also edit the /Library/Preferences/DirectoryService/ActiveDirectory.plist file and change the date associated with the "Password Change Date" key to something way in the future or to 0 to disable password updating.  This is the date the password will next be changed by the AD plugin.  You may have to reboot the server or do a "killall DirectoryService" to be assured that the AD plugin rereads the plist file.

iChat Service:

   For iChat service the AD users do not support cram-md5authentication ( which is what iChat service uses if kerberos isn'tused ). To get around this you need to followkbase http://www.info.apple.com/kbnum/n306749  ( Option 2: Disable useof CRAM-MD5 authentication on the iChat server). This will disablecram-md5 and allow the supported authentication methods ( Kerberos andPlain ) to work. Leave the Authentication field for the iChat serviceset to "Any Method" for this approach to work.   The reason for option2 instead of option 1 ( using kerberos ) is mainly for the 10.4.11iChat users. 10.4.11 doesn't support kerberos authentication for iChat( jabber users).10.5 iChat supports Kerberos authentication therefore,if strictly 10.5 clients were being used you wouldn't need to disablethe cram-md5 authentication however, this is best for ultimatecompatibility. As a side note the "Host Domains:" field for the iChatservice should list your Fully Qualified Domain Name for the OS XServer ( the services server). Users will configure iChat using theusername (Jabber ID:) format of [email protected] . Theserver port should be 5223 optionally select "Connect using SSL" if youhave configured SSL for the iChat service. *Users will not authenticateif the client isn't bound to both AD and Open Directory. To make allexisting users buddies you will need to execute "sudo/usr/bin/jabber_autobuddy -m" in the terminal after each user haslogged into the iChat server. You can use sudo/usr/bin/jabber_autobuddy -h" for additional commandssupported. Hopefully this will help others that run into this problem. Please feel free to contact me if you need to discuss your experiencewith this solution.

[email protected]

More Posts