In order to support new features in Communications Server 14 (CS14) such as IP Phones and Branch Office Survivability an additional authentication method has been added along with the introduction of User Certificates.
This additional Authentication method is in the form of an Extension and Pin combination allowing for users to login to the new IP Phones, this allows a user to easily login to a phone rather than needing to use their domain username and password.
The authentication method is limited to CS, in that CS authenticates the login within it’s own database, if the login is successful a User Certificate is issued to the IP Phone, this is then used to provide access to the CS Web Services and used for authentication with the CS Servers.
Due to this being a CS authentication method, a Kerberos Token is not issued to the IP Phone, meaning that an IP Phone can not authenticate to Exchange Web Service causing some functionality loss (More details in a future post).
The Extension and Pin used for this processes is the same for Dial In Conferencing removing the “yet another Pin issue” although Exchange still uses it’s own Extension and Pin combination.
Moving forward it would be useful if Exchange could use the CS Pin Authentication Web Service rather than use it’s own when operating as part of an OCS environment. With Exchange 2010 Service Pack 1 moving to use UCMA for Unified Messaging hopefully having an option to use CS Pin Authentication is a logical next step.
The Pin is managed via a Web Interface in a similar way to the Dial In Conferencing Pin in OCS 2007 R2, the management of this has been moved from Communicator Web Access (CWA) to be part of the Web Components Role which is co-located with the CS Front Ends.
Taking a look at the User Certificates, these are issued by CS acting as the Issuing Authority, rather than proxying these requests to an Enterprise CA (Server Certificates issued by an Enterprise or Public CA are still required for TLS\MTLS).
Certificates are issued to the Client Endpoints (IP Phones, Office Communicator etc) allowing authentication to CS14, rather than using the Kerberos token each time. When using Office Communicator Kerberos is used for the initial logon (to get the Certificate) and for non-CS Web Services such as Exchange.
Certificates are also an integral part of the new Resiliency options in CS, allowing a client to authenticate and register to CS if connectivity to Active Directory Serves are lost; this is of particular importance in the branch office scenario when using the Survivable Branch Appliance (SBA).
When using Office Communicator these are issued to a user SIP URI and stored within the User’s Certificate store, meaning that if the same Domain User logs in as a different SIP URI, a new authentication process will be initiated rather than using an existing certificate.
On IP Phones certificates are deleted when the “Switch User” process occurs, or a hot desking users session expires. Allowing for a new user to login using their Extension and Pin.
User Certificates by have a life span of several months helping to ensure that if a user logs into Communicator during a WAN outage they are still able to authenticate with CS. While it is currently unclear if this life span can be shortened the ability to deactivate certificates when necessary should suffice for most organizations.
Hopefully these additions will not add additional complexity and will simply become a backend process within CS14.