Jaharmi’s Irreality renewable hyperlinks with 0% transfat since 1999

This may work on Leopard Server as well, but I haven't tested it. There are several brute-force VPN protocol attacks rampant on the internet, and they may leave your VPN service in an unusable state by flooding it with connection requests. 

Read on for a solution... 

The best answer to this is to turn off the built-in VPN service and use OpenVPN instead, but PPTP remains the de facto standard for VPN connections--there's probably a PPTP client for your refrigerator, for crying out loud. You want to reset the VPN service periodically in order to clear these connections, but you don't want to disconnect any valid VPN users in the process. This script does it for you. I set it up as a cron job to run every six hours or so, although once a day would probably suffice.  #!/bin/sh
#
# checkvpn.sh Jon Gardner 01 Jan 2009
#
# This script resets the VPN service to clear malware attack connections, but only if there
# are no valid user connections in progress.
#
CONN=`/usr/sbin/serveradmin fullstatus vpn|grep CurrentConnections|grep pptp|cut -f2 -d'='`
echo Active VPN connections: $CONN
if [ `expr $CONN` -gt 0 ]
then
USERS=`/usr/sbin/serveradmin command vpn:command = getConnectedUsers | grep name | cut -f2 -d'='|sed -e"s/"//g"`
if [ "$USERS" != "" ]
then
echo Active VPN users: $USERS
else
echo No authorized VPN users connected. Restarting VPN service...
/usr/sbin/serveradmin stop vpn
sleep 5
/usr/sbin/serveradmin start vpn
fi
fi

A while back I wrote a teaser about having set up a process to auto-enroll your Mac with an AD-based certificate authority. This is commonly used on the PCs to set up certificate-based 802.1X setups and whatnot. While I got the script mostly working, I've not had enough time to really finish it off. So, since I'm tired of the e-mails asking when I'm done... I'll walk through the process here and see what anyone else can add.

Read on for enough info to be dangerous... 

The Setup

The process hinges on a few things. Firstly that AD has a rather robust web-based Certificate Authority. This is typically found at https://certserver.domain.com/certsrv. It's here that you can actually request and receive in a fully automated fashion your own certificate.

Secondly, this web page can be fully Kerberized, which means that you don't need a password to get to it. Instead you can use the existing machine credentials that your Mac has when you join to AD to get access to the page.

Now on to how this works, both through the GUI and via some script snippets. Note that the script bits use some variables. They're not set in this article, but they are consistent, so you'll need to set these up as you go along. Also this has all been done in bash, mostly to make Nigel cry.

Generating a Key Pair

If you use the web GUI, you can have it create a certificate signing request (CSR) automatically when you request a certificate. If you're doing this with a script you're going to need to generate this on your own.

openssl req -new -batch -newkey rsa:2048 -nodes -keyout "${KEY}" -out "{CSR}" -subj "/CN=${MACHINE_NAME}.${DOMAIN_NAME}"

Note that you probably need to ensure that the common name assigned to the cert is the fully qualified name of the machine in AD. Different organizations will have different requirements on this but typically it's the FQDN, although it can be just the machine name. You'll stash the key and the CSR somewhere safe.

Get a Ticket

Now, you can get a ticket as your machine. This assumes that you've already bound your system to AD. At which point you can use the Kerberos keytab to get yourself a TGT on behalf of the machine. Note that you'll need to do this as root.

kinit -k ${MACHINE_NAME}$

Keep in mind the trailing $ as that's important for this to work. Now, I've had issues getting this to work on a 2k8 functional level AD domain. But 2k3 should be a breeze.

Now, if you're doing this via the GUI, you'll be able to just open up Safari and navigate to the cert web page for your CA. No password will be needed. This is different than if you had authenticated as an AD user. When you go in as a machine, you'll have a different selection of certificates available to you.

Send up the CSR

In the GUI you'll be able to just manually copy/paste the CSR you previously created into the web form. If you're doing this via a script, you'll need to do some funky packing.

ENCODED_CSR=`cat ${CSR} | hexdump -v -e '1/1 "%02xt"' -e '1/1 "%_cn"' | LANG=C awk ' $1 == "20" { printf("%s", "+"); next } $2 ~ /^[a-zA-Z0-9.*()/-]$/ { printf("%s", $2); next } { printf("%%%s", $1) }'`

Then you can leverage the fact that curl is Kerberized and use the TGT you previously got.

REQ_ID=`curl --negotiate -u : -d CertRequest=${ENCODED_CSR} -d SaveCert=yes -d Mode=newreq -d CertAttrib=CertificateTemplate:ComputerCerts ${CA_URL}/certfnsh.asp | sed -e '/.*location="certnew.cer?ReqID=/ !d' -e 's/.*ID=//' -e 's/&.*//'`

This will return an ID number. You'll need that to get the signed certificate later.

Get the Certificate

In the web GUI you'll be able to just click a box and download the cert. Doing this with a script requires you to pass back up the ID number you previously received and then download the cert. Via a script, it's something like this...

curl -o ${CRT} --negotiate -u : ${CA_URL}/certnew.cer?ReqID=${REQ_ID}&Enc=b64

Import the Certs

Using the GUI you can put all of this into a keychain, probably the system keychain, using Keychain Access. From the CLI you're going to need to glob all the certificate bits together into a p12 file and then import them.

openssl pkcs12 -export -in ${CRT} -inkey ${KEY} -out ${PK12} -name "${MACHINE_NAME}" -passout pass:mypass

Read up on this command. As you'll need to decide if you need to hide the password or not. With the above method it'll be visible in a ps listing. However... you'll be stashing the p12 cert into the system keychain, so there's some security there. And you should srm all of the files you created during this process when you're done.

Finally you can import this into the system keychain.

security import ${PK12} -k /Library/Keychains/System.keychain -f pkcs12 -P mypass

 

And you're off to the races. For a full 802.1X setup, you'll need to do some config work for Airport. Take a look here for more info on that.

 

NausicaMedia, the french ACSA company, has translated the latest "Tips and Tricks for Macintosh Management for Leopard" in french.

For all the french speaking sysadmins around the world, you will be able to read the John de Troye's guide for managing your users accounts in your own language.

"Trucs et astuces pour la Gestion du Macintosh pour Leopard" is available at NausicaMedia's website.

Not sure how long this has been up, but may be of interest:

Web Help Desk which is generally well regarded as a help desk package has a free version, meaning free to use with no ads or time limits.

Get it here. 

Continuing on the iSCSI theme... a collision of worlds that will probably become more common in the future.

One part ZFS, one part iSCSI, one part TimeMachine... pour over ice and garnish with a galactic background.

http://opensolaris.org/os/project/qosug/how-tos/zfs_iscsi_integration/

I've been doing some pretty intensive research down here with iSCSI setups of various kinds. This market segment was a little rough a year ago...but it's much better now. Though there are still no "official" OS X Server setups that support it....certainly not Xsan (too bad!)

read on for a few more iSCSI notes... I've tested both the $130 ATTO iSCSI initiator, and the free one from globalSAN. Both seem to work fine, I could detect no difference in reliability. This was after several days of pounding huge files across both to a rack-mount iSCSI box from StorMagic (a company that really tries to be Mac-friendly, btw)

I've run two absolutely mission-critical apps across iSCSI links for the past week...just to be sure. The performance is much better than the NAS links I'd been using previously.
I like the globalSAN's integration as a control panel, and the nicer interface. But it's not supported, whereas the ATTO one is. The call is probably up to you....both worked well in testing.

I also tested ATTO's iPBridge, a very low-cost way to get old Ultra-3 SCSI raid units back in service over iSCSI. The interface was ugly, but once I read the docs and got it set up, it's worked flawlessly. I added 4TB of storage to my backup server for 500 bucks...hard to beat that. Since it all runs over IP, I can park a unit at another site and have remote backup very easily.

My backup server (Retrospect) couldn't seem to hold a reliable connection to the iscsi mounts until I added another gig-ethernet card and dedicated it to that task. After that, it was fine.

SO...in conclusion, with all the inexpensive iSCSI RAID boxes out there, if you need more storage, it's worth your consideration. Unless you really need FC for some reason (super-performance, or Xsan), I would say go for it. Take the time to read the iSCSI documentation and familiarize yourself with the terminology.

Since we haven't seen much about this elsewhere...

Novell have now released Open Enterprise Server 2 SP1 which includes new Novell-engineered protocol support for Apple Filing Protocol (AFP) on the Linux platform.

See http://www.novell.com/products/openenterpriseserver/ for more information.

Boy howdy can 802.1X be a pain in the behind...

To help with this Jeff Dyck has created an application to help. We've had it up in the downloads section for a little while now, but it hasn't gotten the love it needs. So, if you're in an 802.1X environment it would probably be useful to take a look at this.

First read the docs.

Then download the app.

From Jeff:

I've just put up a SVN site for this on the Google Code site - I have it working and doing the essentials in my environment, but there's lots of room for improvement and to make it more flexible.  Would love to see other people contribute to it as well.

The Google code site is: http://code.google.com/p/leopard-8021xconfig/

As far as not modifying com.apple.airport.preferences.plist and adding to the keychain, that's very very very strange as it's working here...  Maybe make sure you have the newest version from the SVN as I did modify it to deal with the newer GUID based ByHost Preferences.  I also pulled some proprietary code we have that pulls user info from a database to make it easier to setup - I may have unintentionally removed something else, although I did test this version...

The Enterprise Desktop Alliance is doing a Mac/Windows integration survey. Maybe do it for the $50 gift certifiate. Or better yet, do it because they say they'll release the results and we're all curious.

After 6 years of development, Mike Bombich is retiring NetRestore, one of the most used and useful tools for OS X mass deployment. Mike cites an aging code base and other tools in the market as reasons for his descision. Read all the details here

I have to set up the IT infrastructure for a company that has 4 different offices.  Two of the sites have Apple based clients and the other two have windows based clients.  All of the servers are Xserves.  I hope to set up a single Open Directory structure that can handle Mail, a Corporate Intranet Site, a Corporate Website, Home Folders (for both the OSX and Windows laptops/desktops), Job Folders, and Backup for all of these.  There will be roughly 75 users at the HQ, and less than 20 users at each of the 3 satellite offices.

Our current equipment includes 2 or more Xserves at every location(plus Xserve RAIDs at the main office), 55 iMacs / Mac Pros, 13 MacBookPros / Airs, 30 Windows Desktops, and 7 Windows Laptops.  Our networkinfrastructure is gigabit at all of the locations.

Currentlyeach office has it’s own Open Directory master and separate fileserversfor Job Folders and Home Folders.  The Corporate office hosts the mail,websites, and backup for all offices.

Any help or advice for creating this infrastructure in a secure and reliable way would be greatly appreciated!

Another thing to look at when locking down systems.

http://www.sans.org/press/osxchecklist.php

Please join Joseph Cohen, CTO of Aqua Connect, as he demonstrates Aqua Connect’s Terminal Server 3.0 while utilizing Microsoft’s Remote Desktop Clients from both Mac OS X and Windows. After the demonstration, Joseph Cohen will then instruct administrators on how to administer user sessions from Aqua Connect’s Admin Tool and Apple’s Workgroup Manager

For information on how to participate go to the participant information page. 

The login ID for October 21st Webcast : MacEnterprise

Passcode for October 21st Webcast is : 451234

10:00 - 11:30 am PST
1:00 - 2:30 pm EST
18:00 - 19:30 GMT

Slides for the Aqua Connect 3.0 Terminal Server webcast will be available prior to the event.

Part two in our continuing saga of getting some business continuity for ourselves. In this part we let go of the server we've configured and send it off to the co-lo, all the while keeping our fingers crossed that we didn't bone anything on the setup.

It's always been on the to do list to set up a disaster recovery site for AFP548.com there just hasn't been enough time to really do it. Well, that's all changed now. Through the generous help of MacMiniColo.net we now have a Mac Mini humming away in Vegas, perhaps having more fun then we are...

Read on for what we're doing with it... Kiss, kiss, shove, shove

If you plan on personally delivering your server to the co-lo you don't need to do nearly as much worrying on the front end. Although it's cool to be so secure in your own admin powers and not have to do any tweaking once the server has been racked, in you heart of hearts, you know that you can. As such you most likely won't be constantly second guessing yourself and your configuration.

However, if you're sending the server off to the able hands of some co-lo, and won't be personally present when the server is put into action... things are much more tricky. Packaging up something that you may never see again, if everything goes well, and putting it on a FedEx truck involves a fair amount of soul searching. Did you setup the IP right? Did you fat finger the password when you typed it in? Did you open up the right holes in the firewall... Thinking about this too much can drive you batty. It pays to be very methodical and, dare I say, anal when doing this.

We'll be talking mostly about the unattended setup, as that's the hardest. However, all of the techniques we'll discuss will help you look like a rock star to the co-lo crew even if you do attend the racking in person.

Network

First the IP address. When setting up the server it's going to need to be on your own LAN and most likely have a working Internet connection. This means you're going to have to give the server a different IP address than what it's going to end up with. With the LAN connection working you'll be able to do most of the server configuration, download all of the updates and generally do what needs to be done.

As you do this, though, in the back of your head will be a tiny voice that's suspicious of you ever being able to access your server once it lands in the co-lo and has to use it's final IP address. To combat this nagging voice, I always set up the "real" IP that the server is going to finally get even while it's on my LAN. I can set up another system on the LAN with an address in the same subnet as the final IP will be and test for connectivity. It's a completely fool-proof solution, but it should help put some fears to rest.

When doing this, just keep it as a secondary interface, that is below the working one in the Network pane of the System Preferences. That way you'll be able to reach the internet and check the real IP at the same time.

Backdoor Surprise

A common trick I've seen is to always create a "throw-away" admin account before putting the server in the box to ship off. This is an account that the co-lo crew can use if it all hits the fan. Keep in mind that some co-los will not do this, and others will only do it for a fee.

Keep the password complex, but do remember to write it down. Once you've had the co-lo crew work on the machine you'll have to ask yourself if you trust them enough to not fully wipe the box and start over. To alleviate some of this concern, I typically keep the most sensitive material off of the server, or keep it encrypted in a disk image, until I know the server is fully functional. If I need to hand out a login to the co-lo crew, I'm reasonably assured that all my secrets won't go walking.

In a similar vein I find it a good practice to always first set up non-admin accounts for the other admins that you're going to add to the server. Have them log in and change the password before you promote them to an admin. This way you don't have an admin account hanging around with a generic password.

SSH

I like to only leave the VPN and SSH externally accessible when shipping off a system. All of the other services can be turned on once I have confirmation that the server is functioning correctly on the network. This way you're not accidentally leaving an AFP guest share hanging around waiting for interlopers to peruse while you're trying to get into your system after it's been racked.

Using SSH you should be able to make any changes necessary to get the VPN working so that services like ARD and Server Admin will work. As a rule I always, always, always run SSH on a non-standard port. This isn't to suggest that doing that is some sort of security panacea, but more so that it will keep all of the script kiddies hack attempts out of your logs.

Once you've logged into the server you can enable the other services that you need, taking care to port scan yourself when it's all done to ensure that you're not leaving anything on that you shouldn't be.

VPN Stub Network

Unless you get a set of IP addresses, it's going to be hard to actually use a VPN on OS X Server. Both PPTP and L2TP/IPSec require a range of IP addresses for the client systems to use. Otherwise you won't actually route any traffic over the VPN.

To satisfy this, it's a good idea to set up a secondary IP address on your server, make sure to do this on what will be an active interface. You can pick something in any of the internal use only ranges. Give yourself a whole Class B if you want... no one else should be able to route to it. Note that doing this won't allow you to send all traffic across the VPN unless you're using NAT on the server. Instead it's typically used as a method to allow the PPTP or L2TP/IPSec traffic to actually work.

Say Bye-Bye

Unless you need to get a large amount of data onto the server, I recommend doing as little configuration as necessary on the system. This is especially true if you're planning on setting up the server as an Open Directory master or replica. Since many systems are DNS dependent it's usually easiest to get the server installed at the final IP address and fully settled in before setting up those services.

Besides this will force you to be comfortable in your SSH skills to do the configuration. This will be a huge boon if something does go wrong later.

Next Steps

In part 3 we'll begin setting up some services to truly make the server a DR system.

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 "computerid.ad.domain@ad.domain".
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/server.outside.org@AD.inside.org". 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/ad.inside.org@AD.INSIDE.ORG (ArcFour with HMAC/md5)  (0x4a8747ec32b0fcc01efa7a7838440565)
   2 10/01/08 20:22:10 afpserver/ad.inside.org@AD.INSIDE.ORG (DES cbc mode with CRC-32)  (0xf8bcef4afb203bf2)
   2 10/01/08 20:22:10 afpserver/ad.inside.org@AD.INSIDE.ORG (DES cbc mode with RSA-MD5)  (0xf8bcef4afb203bf2)
   2 10/01/08 20:22:10 ftp/ad.inside.org@AD.INSIDE.ORG (ArcFour with HMAC/md5)  (0x4a8747ec32b0fcc01efa7a7838440565)
   2 10/01/08 20:22:10 ftp/ad.inside.org@AD.INSIDE.ORG  (DES cbc mode with CRC-32)  (0x80e0f179b3d3910d)
   2 10/01/08 20:22:10 ftp/ad.inside.org@AD.INSIDE.ORG (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 ("server.outside.org@AD.INSIDE.ORG", not"ad.inside.org@AD.INSIDE.ORG").  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/server.outside.org@AD.INSIDE.ORG -k 2 -e des-cbc-md5
Key for afpserver/server.outside.org@AD.INSIDE.ORG (hex): f8bcef4afb203bf2

ktutil:  addent -key -p afpserver/server.outside.org@AD.INSIDE.ORG -k 2 -e arcfour-hmac-md5
Key for afpserver/server.outside.org@AD.INSIDE.ORG (hex): 4a8747ec32b0fcc01efa7a7838440565

ktutil:  addent -key -p afpserver/server.outside.org@AD.INSIDE.ORG -k 2 -e des-cbc-crc
Key for afpserver/server.outside.org@AD.INSIDE.ORG (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/server.outside.org@AD.INSIDE.ORG
   2    2 afpserver/server.outside.org@AD.INSIDE.ORG
   3    2 afpserver/server.outside.org@AD.INSIDE.ORG
...

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/server.outside.org@AD.INSIDE.ORG (DES cbc mode with RSA-MD5)
   2 afpserver/server.outside.org@AD.INSIDE.ORG (ArcFour with HMAC/md5)
   2 afpserver/server.outside.org@AD.INSIDE.ORG (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/server.outside.org@AD.INSIDE.ORG". 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/server.outside.org@AD.INSIDE.ORG"

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 username@OSX.Server.hostname . 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.

Aqua Connect has released version 3 of their terminal server for OS X. It now uses Microsoft's remote desktop protocol to remotely provide a Mac OS X experience to pretty much any client platform including thin clients like a Sun Ray. This is interesting and causes us to ask more than a few questions about how this changes things.

Get more information at their site. 

And we're serious about testers this time...

Group Logic has an interesting solution to solving DFS connection issues on Leopard. We've played around it with it some, and must say it shows a lot of potential.

However, with DFS being as fickle of a beast as it is, Group Logic is going to need some help flushing out the edge cases. So, if you have a very hairy DFS setup, or even if it's just medium hairy, sign up for the beta here and give it a whirl. 

Ask not what DFS can do for you; ask what you can do for DFS! 

It's been a while since the dramatic overhaul of the last release and this one is far less crazy. Rather it's the result of the steady progress made by the InstaDMG dev team.

Major points of change:

• The numbered folders can now also be disk images.
• Base OS cache files are now excluded from Time Machine backups.
• Kext caches are purged form the ASR image.
• instaUser has been replaced with createUser. (Apparently I forgot to put createUser in. It's in our donloads section though!)
  
• Lots of changes to the instaUp2Date addon.

Also I'm putting out a general call for people to test on Tiger and PPC. The dev team is very focused on Leopard deployments and on Intel Macs. If you can test Tiger or PPC (Tiger or Leopard) please do and let us know what you find!

You can grab the release from our downloads section here.
You can get fresh builds from the Subversion repository here.