“Type your credentials to access the corporate address book”
There are a number of good articles out there for troubleshooting these issues. UCNoEvil is a good place to start. There’s another on the Communicator blog. By following the steps on the later I confirmed my issues were with authentication, specifically kerberos.
Open the OCS Snapin from Administrative tools, expand ‘Standard Edition Servers’ and click on the pool name. In the right window expand ‘Address Book Server Settings’ and copy the ‘File share location for internal connections’. It will look like “https://server.example.com/Abs/Int/Handler”
Open IIS on your OCS server and expand ‘Websites’, ‘Default Websites’, ‘Int’. Right click files and choose open. Copy the filename and create a url like: https://server.example.com/Abs/Int/Files/D-0b3e-0b3f.dabs
Put that in a web browser and when prompted enter DOMAIN\Username and your password. If you don’t get the option to save the file, such as getting another password prompt or an HTTP 401.1 error, then you have authentication or authorization (permissions) issues.
I was seeing errors in the event log sometimes when I’d try to log in 3+ times that looked like:
Event Type: Error
Event Source: Kerberos
Event Category: None
Event ID: 4
Date: 12/17/2008
Time: 10:50:03 PM
User: N/A
Computer: SERVER
Description:
The kerberos client received a KRB_AP_ERR_MODIFIED error from the server host/server.example.com.
The target name used was HTTP/server.example.com.
This indicates that the password used to encrypt the kerberos service ticket is different than that on the target server.
Commonly, this is due to identically named machine accounts in the target realm (EXAMPLE.COM), and the client
realm. Please contact your system administrator.
These didn’t always come up though.
You can get a list of domain-wide SPN’s with:
“ldifde -f spn.txt -l servicePrincipalName -r (servicePrincipalName=*)” then view spn.txt with notepad or whatever. ldifde should exist on a domain controller.
You can see what accounts a site uses by right clicking a folder in IIS such as Abs, choosing properties and looking at ‘Application pool’ on the ‘Virtual Directory’ tab. Then right click and choose properties for that application pool under ‘Application Pools’ in IIS. On the identity tab you’ll see the username. Some users found that this user wasn’t created by OCS with Password Never Expires set, and they had to reset the account password in AD and here. The application pool being stopped was a sign of this.
You can download ‘setspn.exe’ from the Server 2003 Support Tools. Then you can run ‘setspn -L RTCComponentService’ and see what spn’s were set for that account. I had none set. the ‘CWAService’ account for Communicator Web Access had ‘http/HOSTNAME’ and ‘http/fqdn’. I set these on the RTCComponentService account with ‘setspn -A http/fqdn.example.com DOMAIN\RTCComponentService’ and ‘setspn -A http/HOSTNAME DOMAIN\RTCComponentService’. Setting these fixed my problems. CWA appears to still work, although you’re not supposed to have multiple accounts with the same SPNs. If it comes to it and I have problems I’ll probably delete the CWAService account and move it’s application pools to use the RTCComponentService account. Perhaps it was installed at a later time by another admin, or perhaps this is a bug.
