Now consider the cloud. Or, rather, clouds, because you'll find several offerings that fit under the cloud umbrella.
While VMware-powered private clouds can fully participate in the goodness of Active Directory and Kerberos, hybrid clouds involving external computing resources are a different story. How authentication takes place in a hybrid environment depends on how it is implemented. If the external cloud resources are connected to the private cloud via a VPN, the two are effectively part of the internal network and everything should work OK.
Things get messy with pure public cloud options.
Public cloud are generally defined as being external to the companies that use it. It is where software-as-a-service (SaaS)-type applications (typically web-based) run. How does authentication work in this context? When you log on to a web application, how are your credentials validated? The answer is, unfortunately, "all kinds of ways", LDAP, database lookups, file lookups even Kerberos sometimes.
The problem with this lack of cohesion is it makes it difficult to affect things that we take for granted in the private cloud. When somebody leaves the company, how do we disable his user accounts on outside SaaS apps? How do users keep track of passwords for all their various applications since they don't support single sign-on? How can we enforce password policies when no two systems use the same authentication mechanism?
We are just beginning to solve some of these problems. For example, the Security Assertion Markup Language and Active Directory Federation Services protocols allow identity federation. That makes it possible for apps that run in public clouds to authenticate users using corporate credentials.
SalesForce, for example, allows you to log on with your own corporate username and password if you set up a federation agreement with them. Unfortunately, identity federation is well defined only for some simple web application use cases.
There's no easy way for you to back up your local disk to a public cloud service automatically using your corporate credentials to authenticate you to the service. You can't write a local application that accesses a SQL database on a public cloud that enforces security using your federated corporate identity.
Ultimately, we need to remove the distinction between corporate and web authentication, all authentication should be based on Internet-routable protocols and the nature of identity federation should become simpler (there should be no need for internal/external identity federation servers).
This will take a long time. Microsoft's version of LSASS knows nothing about web-based authentication protocols. When we do figure this out, however, we should make sure that we do not lose the many benefits of our current mechanisms. Kerberos is a great security protocol, offering the user much convenience. Let's figure out how to more broadly apply it in the public cloud context.