Haiku #85
Password expire and
The machines fall silent. Where
Could Kerberos be?
Last night the author of today's haiku spent 45 minutes at the gym, dutifully working out on the StairMaster. Because there was nothing even remotely interesting on TV (hockey? soccer? golf reruns?!?) that left him alone with his thoughts.
Note. OK, if you want to get technical, it left him alone with his thought.
At any rate, for 45 minutes he trudged up the stairs, one foot methodically following the other, only to realize that, when his workout was finally over, he had accomplished absolutely nothing: all the work, all that effort, all that pain and torture, and he was still standing in exactly the same spot he was standing in when the workout began. "Wow," he mused. "I wonder if this could be a metaphor for something." But when he couldn't think of anything, he just grabbed his stuff and went home.
Of course, as it turned out, it was a metaphor for something: the Dark Ages. (If you aren't sure when the Dark Ages were, most scholars define the Dark Ages as the days before Lync Server PowerShell was released.) Back in those primitive times, IIS (an important part of Office Communications Server) typically ran under a standard user account. So what, you ask? Are we saying that IIS shouldn't run under a standard user account?
No, we're not saying that: a plain old user account worked just fine. However, there was a potential problem: the passwords for plain old user accounts tend to expire after a set period of time. If the password for your IIS account expired, you could potentially lose all your Communications Server Web services. (Would that be bad? In a word: yes. Very bad.) That's bad enough; even worse, trying to diagnose and fix this problem (figuring out what went wrong, then tracking down the culprit and changing its password) was a bit of slog, to say the least. And then, after all the work, all that effort, all that pain and torture, administrators were still standing in exactly the same spot they were in standing before: they still had multiple machines running IIS, and running IIS using multiple accounts and multiple passwords.
And no, that wasn't as bad as it sounds. It was worse.
So has Microsoft done anything about this problem in Lync Server 2010? You bet we have: we've introduced the notion of "Kerberos accounts," and we've included a bunch of new cmdlets to help manage those accounts. And those cmdlets include the subject of today's haiku: New-CsKerberosAccount.
Kerberos, as you probably know, is a network authentication protocol; the Windows operating system relies heavily on Kerberos as a way to authenticate user logons. The new "Kerberos accounts" available in Lync Server also use Kerberos authentication, and so we decided to call them, well, Kerberos accounts.
Note. Kerberos, incidentally, is the three-headed dog who, in Greek mythology, guards the gates of hell. (You might be more familiar with the alternate spelling: Cerberus.) According to legend, Cerberus (or Kerberos, if you prefer) was the offspring of a half-woman and half-serpent, and a fire-breathing giant. So if you happen to be half-woman, half-serpent and you're thinking about marrying a fire-breathing giant, well, now you know what your kids will be like.
But what exactly are these Kerberos accounts? These are accounts that can serve as the authentication principal for all the computers in a site that are running IIS. (Note that, although the cmdlet parameters refer to them as user accounts, they're actually computer accounts.) What's the point of that? Well, suppose you have 25 servers in a site. In the old days, that would be 25 accounts, and 25 passwords, to keep track of. Is that a hassle? You bet it is. With Lync Server, however, you can assign a single Kerberos account to the site, and have all 25 of your computers run IIS under that account. One account and one password to keep track of. Is that less of a hassle? Well, we were never all that good at math. But it sure seems like it, doesn't it?
It probably won't come as a major shock to learn that the New-CsKerberosAccount cmdlet is used to create one of these Kerberos accounts. This turns out to be a three-step process:
1. You use New-CsKerberosAccount to create a Kerberos account.
2. You use the New-CsKerberosAccountAssignment cmdlet (or the Set-CsKerberosAccountAssignment cmdlet) to assign that account to a site.
3. You use the Enable-CsTopology cmdlet to cause these changes to take effect.
The whole thing looks something like this:
New-CsKerberosAccount -UserAccount "litwareinc\kerberostest" -ContainerDN "ou=LyncServers,dc=litwareinc,dc=com"
New-CsKerberosAccountAssignment -UserAccount "litwareinc\kerberostest" -Identity "site:Redmond"
Enable-CsTopology
The only command we're going to talk about today is the first one, the one that creates the new account. As you can see, all we did in that first command is call New-CsKerberosAccount followed by two parameters:
· UserAccount, which specifies the name of the new account (using the format domain_name\user_name). Incidentally, this has to be a brand-new account: if we already have an account named litwareinc\kerberostest then this command will fail.
· ContainerDN, which is simply the Active Directory container where the new account will be created. Note that this parameter is optional; if you don't include it, the new account will automatically be created in the Computers container in Active Directory.
That's pretty much all we have to do. After we run the first command, we'll have a new computer account in Active Directory, a computer account that can then be assigned to all the Lync Server machines in a site. (Or in multiple sites, for that matter.) If we ever need to change the password for that account all we have to do is change the password, and the account information will automatically be updated on every Lync Server computer that uses that account (i.e., every Lync Server computer in the site). It's not even half the workout or even half the drudgery of the ways things were done in the Dark Ages. But, hey, try to make the best of it, OK? After all, if you're like the author of today's haiku, it's never too hard to find another source of drudgery, especially when you're at work!