Apple & Microsoft – Kerberos Authentication that works

Now I have always been one of those Techs that said that Microsoft and Apple don’t work together… on anything…

But now that I am older and wiser (well not MUCH older) I have seen the Light. I was fortunate to cross technical swords with a worthy opponent a while back (PJ van Dyk). He is certainly the most talented Mac Architect that I have ever met. Not that I go seeking them out either.. :-) We were thrown together to solve some challenges at a media company we had as common client.

This is where my realization occurred. Microsoft does many thing right but as many things not so right. Apple on the other hand makes really pretty toys. Let’s be honest, there is not many mobile devices as pretty as the iPhone, iPad and Mac Book Air. And between PJ and I we started on the journey of figuring out how well the two technologies can work together.

So there we are at a Academy of Visual Learning. The place where creative design fundie’s go to study. PJ and I were discussing how to manage and report on the internet connection which is being heavily abused (edited)…used… by the students. We came up with a very logical answer of Microsoft’s Threat Management Gateway 2010 (TMG). we chose it for a few good reasons:

  • TMG seamlessly integrates with Microsoft Active Directory to facilitate a single point of management
  • Microsoft has unbelievable pricing models for the Educational sector
  • and Threat Management Gateway with Service Pack 2 support Kerberos Authentication

Now for the less informed among us (which I was one) Kerberos is and awesome authentication protocol which supports single sign on and is also supported fully by both Microsoft and Apple Mac OS. Check out this wikipedia’s informative site for more info.

So adding the Mac’s to Active Directory is pretty straight forward and I won’t go into that here but if you want more info just drop me a comment and I’ll post it. The installation of the TMG is simple if you do your planning right. Read through Microsoft deployment guide, answer the questions before you start and then your set to go. I always say that every extra hour planning equates to 2 hours less troubleshooting.

Now the thing to remember about TMG 2010 is that it didn’t support Kerberos fully until Service Pack 2, and to install Service Pack 2 you have to first install SP1, the rollup patches and then Service Pack 2. (Check the downloads section at the bottom for direct links). Once you have installed TMG and updated to the required SP it is time to start the configuration. We had installed it in a “Single-NIC” scenario which basically means that it doesn’t do much more that a proxy server. There is an important step to remember during the install of TMG, it creates a default system rule that only allows the IP you are connecting from say with Remote Desktop (RDP) to access the server. This can be inconvenient if you run DHCP and want to connect again later when your PC has a new IP.  When opening the TMG console its a good idea to start the Web Proxy wizard and configure the user internet access. What is also very cool is that it automatically creates a Blocked sites rule for those users that happen to stumble onto naughty websites.

Now the Windows PC’s that connect through the proxy automatically authenticate if they are joined to the AD. What you won’t figure out unless you running traces on the network activity it defaults to NTLM authentication. The Mac’s don’t like NTLM they will prompt you for the login details. This is where I had to really quickly study up on Kerberos. The basic principle is that Microsoft does most of the hard work for you. All you theoretically need to do is open AD Users and Computers console find your TMG server, right click on it, select Properties. Open the Delegation Tab and check check the box. You can get creative about which services you want to publish with delegated Kerberos authentication or just select “All services with Kerberos”…. but sadly this did not work. The Mac’s still got prompted for user info… WTF..

I must admit the best site I could find that helped me troubleshoot this was a Microsoft site where I downloaded the Server 2003 Troubleshooting Kerberos Delegation (check downloads). The short version of troubleshooting was running the SETSPN command to query the Kerberos SPN records created. Surprise, surprise.. there were no SPN’s created for the TMG server. Easily fixed. you can create the SPN’s manually using the SETSPN utility. Just remember the create SPN’s for HOST/devicename and HOST/FQDN_devicename. Then you need to create the services SPN’s like http/devicename and http/FQDN_devicename. You can add the ‘cifs’ SPN if you have file shares on the server that the Mac’s need to access.

Well there you have. Your Mac’s joined to the AD are using single sign-on with Kerberos accessing the internet through your Threat Management Gateway…. or not… how to configure all these Mac’s to point to the proxy? Easily again… we used the WPAD auto proxy configuration script. When you tick the “Publish this server automatically” box on the TMG it creates the file and publishes it on http://servername/wpad.dat. WPAD’s are really cool but could also be bad if there are malicious gremlins on your network. Basically they allow most browsers today that are set with “automatically detect proxy” to query DNS for the WPAD website and be routed through the configuration in the file. Thats why Microsoft added WPAD to the DNS block-list. So even if you create an A record  for WPAD in the local DNS the clients can’t resolve it. This can be changed by overwriting the Block-List using the “dnscmd” command line utility.

Great now I can query the A record for WPAD and the TMG has created the file, it should work.. right? well yes except when the WPAD file was automatically created by the TMG it used the IP address of the TMG in the WPAD.dat file and not the FQDN. This causes Kerberos authentication to fail and then the user is prompted for login credentials again.  *sigh*.. luckily fixed by running a simple script and guess what….

WALLA!! Kerberos authentication on your Mac’s joined to AD being proxy’d through Microsoft Threat Management Gateway.


So now I am a Microsoft Tech who runs around with a iPad, iPhone and Mac Book Pro running both Mac OS and Windows….. go figure :-)

Downloads & Links: Microsoft TMG 2010 SP1, TMG Software Update 1 for SP 1, Microsoft TMG 2010 SP2 , Server 2003 Troubleshooting Kerberos Delegation, FQDN on the WPAD, DNSCMD Utility,WPAD How to..


Crackberry – Active Directory Authentication fails on Webconsole

Do you know when at times you have to “fortune” (notice I did not add the prefix of good-) of reminding oneself of the pieces of technology you really don’t like…. well I believe today was one such day.

Great for consumers, often not so great for techs


When you hear me say “.. I don’t like Blackberry…” its not because the devices are ugly, cumbersome and ultimately limited and out of date (even though the preceding statement is true). It is really because there are some fundamental pains that any Administrator of such a system has to endure with a smile.


I forget to count how many times I have had to solve this similar issue where the AD authentication with the BES database fails… and yes, there are always “mitigating” circumstances that precede such an event, like user deletions, wrong passwords reset, server crashes, techy blunders etc but it is never fun to resolve it once occurred.





So here is my account of today’s scenario:

  • Somehow Mr S.Tshabalala became the preferred account BES would try read/write to Exchange with. (I found this out by running the IEMSTest.exe utility found here “c:\Program Files (x86)\Research In Motion\BlackBerry Enterprise Server\Utility”
  • Fixing this by deleting and recreating the MAPI profile(follow this article )
  • I found some EWS Calendar issues after rerunning the IEMSTest.exe utility.
  • Proceeding to the Login issue I found some inconsistencies in the Data base.
    • for some reason I could update the password field but still not login
    • i noticed that the AuthenticationType field was neither a “1″ nor a “0″ for the admin user(1 being AD Auth and 0 being BBAS Auth)
    • this lead me to believe that something must have gone wrong at an earlier attempt to reset passwords
    • I corrected this by manually editing the mode to “0″ (not recommended)
  • This now allowed me to run the right script (find it here) to reset the password to “blackberry”

And There you have it… Logging into the Administration Console with the user: admin and the password: blackberry

Some notes for reference:

  • To reset the password using this script you do NOT have to stop or start services
  • Once the DB has been changed to BBAS authentication it can’t be changed back to AD (I can’t find anything relating to this on the net, but you could escalate to RIM if you deem it important)

I really hope this assists some admins to solve this pain faster than I did.