CyberSafe & Microsoft Operating Systems

During the early design of the Windows 2000 operating system (when it was called NT5.0) Microsoft decided to adopt a standards based approach and upgrade the proprietary NTLM protocol being used for domain authentication in NT4.0 with a more secure and standards based protocol - Kerberos was the chosen protocol. At this time CyberSafe collaborated with Microsoft and delivered the first ever Windows 2000 Kerberos interoperable product - To see Microsoft's press release concerning this collaborative work please click

With CyberSafe's expertise and product solutions, combined with Microsoft's operating systems using the Kerberos protocol for domain authentication it is possible to deploy a common security infrastructure, covering both Windows operating systems and UNIX as well as allowing Microsoft and non-Microsoft applications to share, and take advantage of the same authentication and security framework.

CyberSafe's product solutions are perfectly positioned to bridge the gap with non-Microsoft applications and operating systems and thus complement the Microsoft offerings for both customers and vendors and take advantage of any investment in Microsoft operating systems that have already been made. To find out more about our comprehensive security solutions please click

Benefits of Kerberos Authentication in Microsoft Operating Systems

The Kerberos protocol is more flexible and efficient than NTLM, and more secure. The benefits gained by using Kerberos authentication are:

• More efficient authentication to servers. With NTLM authentication, an application server must connect to a domain controller in order to authenticate each client. With Kerberos authentication, the server does not need to go to a domain controller. It can authenticate the client by examining credentials presented by the client. Clients can obtain credentials for a particular server once and reuse them throughout a network logon session.
• Mutual authentication. NTLM allows servers to verify the identities of their clients. It does not allow clients to verify a server’s identity, or one server to verify the identity of another. NTLM authentication was designed for a network environment in which servers were assumed to be genuine. The Kerberos protocol makes no such assumption. Parties at both ends of a network connection can know that the party on the other end is who it claims to be.
• Delegated authentication. Windows services impersonate clients when accessing resources on their behalf. In many cases, a service can complete its work for the client by accessing resources on the local computer. Both NTLM and Kerberos provide the information that a service needs to impersonate its client locally. However, some distributed applications are designed so that a front-end service must impersonate clients when connecting to back-end services on other computers. The Kerberos protocol has a proxy mechanism that allows a service to impersonate its client when connecting to other services. No equivalent is available with NTLM.
• Simplified trust management. One of the benefits of the Kerberos protocol is that trust between the security authorities for Windows 2000 domains is by default two-way and transitive. Networks with multiple domains no longer require a complex web of explicit, point-to-point trust relationships. Instead, the many domains of a large network can be organized in a tree of transitive, mutual trust. Credentials issued by the security authority for any domain are accepted everywhere in the tree. If the network includes more than one tree, credentials issued by a domain in any tree are accepted throughout the forest.
• Interoperability. Microsoft’s implementation of the Kerberos protocol is based on standards-track specifications recommended to the Internet Engineering Task Force (IETF). As a result, the implementation of the protocol in Windows 2000 lays a foundation for interoperability with other networks where Kerberos version 5 is used for authentication.

How Microsoft products work with CyberSafe products

The capabilities are summarised below :

• Windows 2000 or XP workstations can log into a CyberSafe KDC (hosted on a hardened UNIX server) as a domain controller. Once the login is complete the credentials can be used to access applications on both Microsoft or UNIX servers.
• Windows 2000 or XP workstations can log into a Microsoft Active Directory KDC and obtain service tickets through a trust relationship with a CyberSafe KDC (typically being hosted on a hardened UNIX server).
• CyberSafe Secure Client software on UNIX or Windows (95,98,NT,2k or XP) can authenticate using a Microsoft Active Directory KDC.
• Through a CyberSafe developed password synchronisation add-on it is possible to cause any password changes for a principal in a CyberSafe Kerberos realm to be automatically made in a Microsoft Active Directory domain and vica-versa.

Product Interoperability Testing

CyberSafe products have been through extensive interoperability testing at Microsoft's HQ, including the TrustBroker™ Secure Client, KDC and GSS-API based application security toolkit.

Web Services Security, Microsoft and CyberSafe

About WS-I and WS-Security

The WS-I (Web Services Interoperability) Organisation was formed during 2002 at the behest of companies including IBM and Microsoft to promote Web Services interoperability across platforms, operating systems, and programming languages and has now (March 2003) just turned their attention to the security interoperability considerations. Currently the security standards for Web Services are defined in a white paper prepared jointly by Microsoft, IBM and Verisign which provides the basic building blocks, known as WS-Security - a security architecture for Web Services. The white paper can be viewed if you click

WS-Security describes enhancements to SOAP messaging to provide quality of protection through message integrity, message confidentiality, and single message authentication. These mechanisms can be used to accommodate a wide variety of security models and encryption technologies.

WS-Security also provides a general-purpose mechanism for associating security tokens with messages. No specific type of security token is required by WS-Security. It is designed to be extensible (e.g. support multiple security token formats). For example, a client might provide proof of identity and proof that they have a particular business certification.

Additionally, WS-Security describes how to encode binary security tokens. Specifically, the specification describes how to encode X.509 certificates and Kerberos tickets as well as how to include opaque encrypted keys. It also includes extensibility mechanisms that can be used to further describe the characteristics of the credentials that are included with a message.

The technical work at the WS-I until now has focused on its "basic profile," a series of guidelines, sample applications and tools to test product compatibility. The basic profile has been in draft form since early 2002 and is expected to be completed by the second quarter 2003. It addresses the first Web services standards written, including XML document definitions, Simple Object Access Protocol (SOAP), Web services Description Language (WSDL), and Universal Description, Discovery and Integration of Web services (UDDI).

In taking on the hot-button issue of security, the WS-I has its work cut out for it. Matching numerous overlapping proposals for security standards to a huge number of business usage scenarios makes for a complex undertaking.

For example, a Web service for accessing customer information internally may not have the same stringent security demands as a Web service that transmits sensitive data on customer accounts between financial institutions over the Internet. The WS-I intends to give corporations guidance on how to use security effectively with Web services in different business situations and clarify any ambiguities in the security specifications for IT providers.

Summary - Kerberos, CyberSafe, Microsoft and WS-Security

Clearly there are many challenges to be addressed before a common, consistent and global standard for Web Services Security has been agreed and adopted by the various vendors and companies involved. However, with the involvement of Microsoft in WS-I and WS-Security and the strategic nature of the .NET framework and Microsoft operating systems in many corporations it is inevitable that Kerberos will become a major part of the Web Services security framework for internal business application authentication and protection. With this in mind, and the future Web Services goal, where any company will be capable of communicating with their business partners, customers and suppliers with no interoperability barriers - the investment in Kerberos technology for securing applications within your business now makes strategic sense, thus improving your ability to do business electronically using Web Services in the future.

Microsoft's .NET Passport will use the Kerberos protocol in the future to give Internet Single Sign On services to customers and partners of Microsoft. Microsoft also plans to make this technology available to business partners who have a desire to provide an SSO service to their customers. The tools used to provide this capability will position these companies to introduce Web Services standards in the future, when they are finalised. For more information, click