Earlier this year a blog on the Exchange Team site was poste by Ross Smith IV. In this blog he encouraged to use Kerberos as authentication method for Outlook clients.
In a lot of Exchange environments you will see that it is implemented. When you are using a CAS Array you will need to create an alternate service account (ASA) for this. This can be done by using the RollAlternateserviceAccountPassword.ps1 script. Keep in mind that when using the CreateScheduledTask parameter the scheduled task will run as the account who created the scheduled task.
After registering the correct SPN’s on the ASA account Kerberos will work in most cases. In some scenario’s a typo is made which results in incorrect SPN’s being registered. When this is the case you can solve it by using setspn or AdsiEdit.
But what if Kerberos sometimes works and sometimes not, or does only work for specific users? If it doesn’t work a user will not be able to access his/her mailbox.
The easiest way to figure out if Kerberos is to change the Outlook profile.
On the security tab of the account you will need to change the value of Logon network security _to _NTLM. If the user can access his/her mailbox after this you know that Kerberos is causing the issue.
Besides this an event will be logged in the system event log. Because a small set of logging is enabled on the Windows Servers you won’t see the Kerberos issue on that side. To enabled the logging you will need to make a change in the registry:
- start regedit
- browse to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
- create a Dword called LogLevel
- change the value of the Dword to 0x1
Logging is directly enabled after creating the registry key and after a refresh you will see several Kerberos errors in the log.
Another option is to create a network trace using Wireshark or Netmon. In both cases you will see the following message in the trace:
0xD – KDC_ERR_BADOPTION: KDC cannot accommodate requested option
When you will search the internet for this error you will see you are not the only one. But let’s start from the begin instead of going to directly to the solution.
One of the first things you will need to do is run SetSPN -L “ASA account” to verify that all correct SPN’s are registered. The SPN’s should be unique. Despite I have seen environments where the domain controllers also contain two SPN’s named ExchangeAB _followed by the netbios and fqdn. To verify if the SPN’s are unique you can use _SetSPN -Q “SPN VALUE” , for example SetSPN -Q ExchangeAB/*.
As displayed in the screenshot above you will see ExchangeAB will be found four times. Two times on the Exchange Server and two times on the DC.
As fas as we can see at this moment everything looks OK. Time to continue troubleshooting. But with which step can you continue when you have the error above? Klist.exe or Kerbtray.exe will not help a lot because in most cases renewing the tickets won’t solve the issue.
After some research together with a customer we found the root cause of the issue.
Microsoft did change the UDP packet size starting from Windows 2003. In Windows XP the UDP packet size was set to 2000, starting from 2003 it has been set to 1465. I think you know what will happen when Kerberos will send a package. Kerberos will use UDP by default . This will result in incompleted packages which will arrive at servers containing Windows 2003 or above as OS.
But why does the issue only happens for some users? This depends on the Kerberos ticket size. The size of a Kerberos ticket is determind by:
- length of the password
- membership of groups
- do the groups contain other nested groups
To solve this issue you will need to make a registry change:
- start regedit
- browse to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\ Kerberos\Parameters
- create a Dword called MaxPacketSize
- change the value of the Dword to 1
By making this change all Kerberos packages which are bigger then 1K will be send by using Kerberos over TCP.
Restart the computer and change the Outlook profile to Negotiate Authentication. Verify if you can access the mailbox. Using klist.exe or kerbtray.exe verify of the tickets will be created correctly. Both tools are part of the resource kit for Windows 2003. In Windows 7 and 2008 klist is a part of the OS.
In this screenshot two Kerberos tickets are listed which are being used by Exchange. If all authentication is performed by using Kerberos you will see the following Kerberos tickets:
- exchangeMDB
- exchangeRFR
- exchangeAB
- http
When you will look in the event log of the client you won’t find any Kerberos messages.
Microsoft has published a complete document about troubleshooting Kerberos authentication issues. You can find the document here.
Comments
