- In Exchange 2010 CAS a client connects to provides an encrypted cookie after the client is authenticated.Passing that cookie to a different CAS means that the receiving CAS can’t read it, so it has to ask the client to authenticate again.
- In Exchange 2013, the CAS authentication cookie is encrypted with the public key of the certificate assigned to the CAS, so any server that has the corresponding private key can decrypt the cookie.
- The Exchange 2013 CAS role server includes a new proxy engine, httpproxy.dll. This replaces the role of the oldrpcproxy.dll, and Exchange 2013 CAS thus cannot proxy RPC traffic directly. When it receives HTTPS encapsulated RPC traffic, it cannot de-encapsulate it directly; instead, it must proxy it to another CAS server that still has rpcproxy.dll. For this proxy operation to succeed, the Exchange 2013 mailbox server or the downlevel CAS servers must have rpcproxy.dll installed (it’s installed by default on the Exchange 2013 mailbox role), and they must be enabled for Outlook Anywhere.
The blog is written to the share the knowledge mainly on Microsoft Exchange Server and other Microsoft product that experienced on day-to-day life.
Wednesday, November 6, 2013
New features in Exchange 2013 Client Access Server
Subscribe to:
Post Comments (Atom)
The blog is written to the share the knowledge mainly on Microsoft Exchange Server and other Microsoft product that experienced on day-to-day life.
No comments:
Post a Comment